Thanks for writing this book Eric, I've been waiting for a Flutter text. I think you've found a market that needs filling. From what I've read so far it's obvious your book is going to be a good one.

One question, if I may? In the State Management section, will there be anything about the BLOC pattern? For me at least that's been the trickiest thing to learn in Flutter. Maybe you have other state management solutions at hand and if so I'd be grateful to know about them.

As for typos, this is a nitpick but on page 14 of the MEAP you have a line that reads "It’s job is
just to wait to be pressed, and then execute a function when that happens
"...the first word should be 'Its', without the apostrophe since it's possessive and not the contraction for 'it is'.
Looks like I double-posted; *that's* how excited I am to have this VSCode configuration!
Thanks for the configuration info, as a VSCode user myself this is going to be a big help.
Just got the notification today. I'm about halfway through the MEAP, and this is great news. Congratulations to the author, this must be a big milestone for him. Well done!
I'm happy that you can write a technical book in two months (would love to know the subject) but in my experience, and in particular with the 30+ MEAPs I've bought from Manning and O'Reilly over the years, most pre-release books go from start to release in about a year. Some take considerably longer; three years is not unheard of. In that respect, 18 months, such as this one has taken, is about average. I'm aware that finishing a book doesn't mean it's published the next day, but it's not going to take anywhere near 10 months to publish a finished, written book that's been pre-commissioned and has an editor working alongside.

I'll state again my contention that a change in React from 15 to 16 takes more than a day or two to incorporate into a mostly-finished text. Reformatting the code and double-checking that all of your React 16 bits don't actually have leftover 15 text in them would itself take at least a day I'd figure, and that's without taking into account writing the new text and code snippets themselves.

I'm still unclear what you were asking the author to do vis-a-vis the book; you go from saying that if he doesn't even have time to spend in the forum he should cede control of it to someone else, to saying about his perceived lack of forum time that "I'm not sure what this has to do with 'giving the project to someone else'" to stating again that if he can't even spend time in the forum he should hand the book over.

In fact, looking at the forum history I see the author answering questions all the time-- see his responses on React.CreateClass on Jul 12th 2017, to the 'Waffle' question of Feb 2nd, to numerous others. The only ones at a glance in the past year I didn't see him answer directly were the slew sent by 'abergquist' on Oct 23rd and 24th, which were all of a sort that read 'typo on page 26' or 'misplaced figure #45' that in my view, didn't need individualized answers.

I'll say again that I'm also eagerly awaiting the book's publication; I don't believe the author has shortchanged us on his effort and time.
When you said he should give up the 'project' to someone else, that implies giving up the book and not just the task of replying to the forum. You should be more precise in your language if you meant the latter.

I'm not sure where you got the idea the book has been in printing stage since October (six months) but the author has stated in his post on Mar 12th that he's still addressing points in it, so apparently it's not gone to the printer's yet. And you're positive it should only take a day or two to update a book based on a change such as React 16? I think you underestimate the book writing process considerably; I'll note too that very few authors-- especially of tech books-- make a full time living writing, and Manning isn't providing six figure advances for their titles, so Mr Thomas has other obligations to fulfill.

I want the book completed as much as anyone. That said, I can sympathize with why it's taking the author as long as it has, and again appreciate his efforts to keep the book up to date. I've purchased other titles where the material was several versions behind when the book came out and it's no fun when that happens.
The book is in production, or very close to it, so it's unreasonable for the author to give the project to someone else-- I'm grateful to him instead, for keeping the book updated to React 16, which must have necessitated some last minute editing, which would account for any delays.
Speaking for other purchasers, I appreciate the author's efforts on this, as well as Manning's commitment to publish an up-to-date book. For me if that means waiting, not a big deal. I've had other MEAPs that were cancelled and Manning always gave the option of a refund or *two* additional books of my choice. Can't argue with that.

Looking forward to this text,

Sounds good, thanks Keith.
I know the book is CSS-focused, but I wondered if you'll discuss CSS meta-languages such as Less or Sass and how they fit into the ecosystem. Many developers like me, CSS novices, use one or the other in our day-to-day work and I'm not sure if it's important that we know how the end-result CSS is generated or if there are steps we can take higher up the food chain to ensure good CSS in the end.
Great, thanks Jeremy.
I'm interested in Ionic, but am new to Angular. Does the book provide an introduction to Angular, or somehow walk people through the apps who aren't experts in the subject? Or do you need to come to this book with at least intermediate Angular experience?
I know this is a forum for the book (which I'm loving so far, even in early format) but my stackoverflow question on this has unhappily gone unanswered. Hoping someone can set me straight on this generic CORS question.

I'm having trouble making an ajax call from my browser, using jQuery 1.10. The page running the ajax client is and the ajax call is to a web api at

I cannot get that call to work. I'm getting a forbidden, 403, forget it larryq message. I have control of and have set the response headers with what I believe to be wide-open access:

Access-Control-Allow-Origin = *
Access-Control-Allow-Methods = "GET, POST, PUT, DELETE"

My question-- do I have to set those same headers on for this all to work?
Thanks Monsur. I've got the MEAP and have gone through half of it so far-- great read, love the examples.
I own a copy of the first version and like it quite a lot.

I'm interested in the 2nd edition too, and --aside from the use of ExtJS 4 instead of 3-- will there be any differences in it? I ask because while Jay did a great job on the first edition, my only qualm was a lack of working apps in it until the final two chapters, when a full app was implemented.

Until the final two chapters it was essentially a series of driver apps, showing the specific feature in question for that chapter. Then, when the final app came about it was almost too much. We went from zero to sixty in about two seconds, it felt like.

It would be ideal to have a couple of apps developed this time around; the full, final app but before that, maybe a medium-sized one that we can chew on a bit before diving into the deep end of ExtJS development? That would help the newbies considerably I think.

Thanks for reading this.

There was a posting from Manning some while ago, stating the authors were going to (essentially) rewrite the book to take Sencha Touch 2 into account. That's why the delay is occurring.

But it would be nice to hear from Manning again, letting us know what the new timeline is, since it has been a while.

I just received an email / MEAP update from Manning about this. The authors are working on updates to the book now to incorporate Sencha Touch 2.0. That's one reason why we haven't seen a MEAP update in a while.

My question to Manning and the authors is, do you have an ETA on when the new 2.0 features will start to appear in the MEAP edition?
If this book is like other MEAP editions, the source code will be released as it's ready. However, that usually trails the chapter releases by a good bit-- after all, if the book isn't in solid form the source code is still subject to change.
I'm an admirer of ExtJS in Action, Jay's previous book. I used it to get up to speed on Sencha Touch. It helped quite a bit.

The only quibble I had with it (other than the extensive coverage of the GridPanel component, which I couldn't use in Sencha Touch - not anyone's fault) was the lack of a complete app, showing how to tie the components together using best practices, until the final chapters of the book. But when the application was discussed, it was incredibly full featured and really showed how to build something using ExtJS. But I do wish there had been a "mini-app" demonstrated before that point.

I'm very happy to see in the new book that an application is shown within the first hundred pages. This will help considerably in showing how to build a proper Sencha Touch program outside of a stuffed "onReady()" method. I think this is an excellent way to go about things and my props to the authors.
I read in the most recent Manning newsletter that Mark's book won a 2013 Dr Dobbs Jolt award, which was well-deserved. Congratulations Mark!

Anyone out there hesitating to get this book shouldn't think twice before putting it in their shopping cart. And if you're not a .Net developer then no problem, much of the book is technology-agnostic, so you can learn proper DI theory (while seeing the large ecosystem out there of .Net solutions.)

Mark's blog is a must-read as well (
Great points Mark, thanks much for them.

I was thinking about a scenario where you might swap out a middle-tier component. For example, allowing a client to swap a SQL Server backend for Oracle or MySQL without our sending a new executable. Sounds like an XML configuration for the DI containers is one way to go, along with your conventions and auto-wiring option mentioned in your reply. Is your Booking example on github discussed in the book at some point?
Interesting github project Mark, that booking Visual Studio solution. I’ve looked it over and while I won’t pretend to understand it all, am I correct in assuming that for convention and autowiring purposes the places to go are the BookingWebUIWindsor directory and the BookingDaemon VS project? Specifically, the DirectoryConvention and ExtensionConvention classes?

Those are pretty straightforward but I’m not entirely sure what’s going on in the ConsumerConvention class. Some sort of automapping obviously, after it’s been registered by the WindsorContainer. Do you have a blog post on this project, or a scheduled one? I guess it would help too if I read the Windsor section of the book before diving too much deeper...
...of course, aving just typed that message, I now realize that you can probably keep the references to a minimum by loading dependencies in the composition root using, say, reflection. Is this how it's usually done in the real world?
I'm on page 204 right now, dealing with the command line "UpdateCurrency" application. On that page it's noted that the program's entry point and composition root are the only code in the executable, and all true work is done in the deeper layers-- as it should be.

However, this raises a question to me. Since the composition root has to know about all the possible runtime components that might be used, we need references to all of them in the executable's project.

Is this ok in a real world application? Using this approach, a WPF/command line/WCF service's entry point would need all possible run time constituents in their References section. A reference to the SQLCurrencyProvider, for instance, and later a MySQLCurrencyProvider, then a'd then have to recompile the application each time and redistribute it. Wouldn't you?

I'm always ready to stand corrected, and if this problem has been covered previously in the text, or if the genuine DI Containers (instead of the poor man's DI used in this example) are kept separate somehow from the various Main() entry points and we discuss how that's done later in the book, my apologies.
I'm probably staring right at it, so apologies upfront, but in the book on page 179 it's stated as part of the circular dependency problem that ViewModel depends on IWindow. I can't see that however in the text?

No problem spotting the dependency Window has on ViewModel, and a WindowAdapter on a Window. But I don't see where the ViewModel has a dependency on IWindow?
Thanks again Mark.
I want to make sure I follow this, and thought I'd post to make sure. On page 142 you state this in a sidebar:

A degenerate case occurs when the ProductRepository ABSTRACTION and the consuming
ProductService are defined in the same assembly (as is the case in the
implementations I’ve created in the book so far). Let’s assume that this is the
Domain Model assembly. In that case, the ProductRepositoryFactory must also
be in the same assembly—otherwise we would have a circular reference, which
isn’t possible.

Is this because (referring to the diagram on page 141), the ProductRepositoryFactory depends on the ProductRepository, while at the same time the ProductService depends on the ProductRepositoryFactory?

So you can't compile the ProductService/ProductRepository assembly without first compiling the ProductRepositoryFactory assembly, but you can't compile that assembly without first compiling the ProductService/ProductRepository assembly. Which means you're stuck unless you put all those classes in the same assembly. Am I following this correctly?
Great, thanks for the confirm Mark.
> A major point of the listing is that an automatic
> property cannot properly guarantee the class'
> invariants. You may want to refer to this blog post:
> erty.aspx
> As for listing 4.4, everything's there. The reason
> why the public setter is being invoked from the
> public getter is exactly to protect the invariant
> that states that you should only be able to set the
> property once. This rule is encapsulated in the
> setter.
> The text on the page explains it too: "Notice that
> the Local Default is assigned through the public
> setter, which ensures that all the Guard Clauses get
> evaluated."

I stand corrected. Thanks for the explanation, serves me right for posting just before bedtime.
I'm enjoying the book and I realize the sample code's unit tests are outside the scope of the text, but I was wondering if Mark had any documentation on how his unit testing assemblies worked? They look interesting, though I can't pretend to know all the details of what ISpecimenBuilder does, for instance.

Mark, if you have any outside links or blog posts demonstrating how to use your testing framework and how it works, a number of us would be in your debt smilie
> The AutoFixture library (which defines the
> ISpecimenBuilder interface, among other things) is
> also open source: At
> the AutoFixture home page you'll find links to
> documentation, blog posts, etc.

Perfect, thanks Mark. I didn't realize AutoFixture was an outside project; I thought it was something you came up with on your own.

Enjoying the book immensely, but one quick question-- on page 109, listing 4.4, in the getter block, should it be this.currencyProfileService = new DefaultCurrencyProfileService... , with a lower case "c" after the this? Otherwise you're using the property getter without referring to the backing field. I know C# has automatic getter / setter functionality now, to ease the busy work, but I don't believe that's in play in this example? (Always ready to be corrected however.)
I've looked at both the production and final MEAP editions side by side, in the same chapters and (when equivalent) paragraphs, and think I prefer the production copy. I'm using Adobe Acrobat reader for both. The production font is a bit "bolder" and therefore more readable to me. This is nothing more than a FWIW comment.

In other news, many congratulations to Mark for getting the book published-- quite a journey I'm sure. I'm enjoying the book and encouraging everyone I know to get it.

I wouldn't sweat Ninject. I've used it but it's not vital that it be in the book-- you've got plenty of other DI containers in there. You'll drive yourself crazy if you try to cover every base and there's no reason for it.

You've got the right balance-- DI theory, followed by coverage of some existing products. As for dealing with or even mentioning every product out there, forget it. The theory is the most important aspect, as the containers themselves will be out of date before any of us likes to think about! The book is great as is, I'd tie up the loose ends, spit and polish and edit, and put 'er out there.
Hi Mark,

Thanks for the info regarding Chapter 9's contents. It sounds plenty comprehensive for someone trying to get their heads around interception, AOP and other such goodies.

When I mentioned LinFu, I should have been more precise in my wording-- I certainly don't expect step-by-steps for all or most dynamic proxy libraries out there. I brought up LinFu only because I've heard of it. As long as DP is discussed and one or two real world examples are shown most readers will be well on their way.

Thanks again,

Hi everyone,

I just ordered the MEAP book, and am scanning it now. It looks great, but I was curious if in the Interception chapter any coverage of Castle DynamicProxy or LinFu will be included?

I understand the basics of DI (but can always learn more-- thus this book) but dynamic interception I'm still very fuzzy on, and wondered if there would be specific, existing products covered. There's no index for the book yet, so I'm not able to look to see what'll be there in the end. Thanks much for the book, before I forget.

Thanks Jon. I actually had written something similar to my post earlier, then cancelled it after reading the book's section again-- I think something in my brain caught your "would've happened" bit in the subconscious. Then later, I saw the actual code, using counter and not index, and overrode my earlier reservation. (Captured variables play tricks on the mind alas...)

I also hesitated the first time because I couldn't believe I was the first one to find the (nonexistent) errata. Manning does a fine job editing and it would have been hard to believe that could have slipped through after all the reviewing they do. Thanks again for the correction.

On page 151 it's said that the output would be the numbers 5 to 13. However, since we're outputting the value of counter and not index (see listing 5.13) wouldn't it start at 50?

By my guess, should the output be 50, 50, 50, 50, 50, 51, 52, 53, 51? I'm not 100% certain about that (Jon's correct, captured variables are tricky) but I'm pretty sure you'd start at 50 and not 5.

Great book by the way, it explains difficult subjects (like captured variables) in about as easy a manner as is possible.
No disrespect intended for the authors, their English is far better than my grasp of their native language, but based on the most recent pre-release of the book can it really be the case that this is coming out in December?

Better to hold off another month or two and give the grammar and syntax a thorough going over than put something out that's not ready. EF is hard enough without dealing with stylistic and language problems. If any Manning editors are reading this, please take your time editing the book.

The good news is that Manning has always done a good job editing and there's no reason to think they won't here either. If the book is in fact released in December with most of the grammar issues taken care of then the editors deserve a big Christmas bonus.
Thanks Jay. Not sure what happened to the formatting in my original message, as it wasn't my intent to form a single run-on sentence. I'll try your suggestion.

May I ask what the CH{0} x CW{1} stuff does?
Hi everyone,

I'm on chapter 5 of the book, talking about Anchor layouts, and in example 5.2 there's a listener created with some code involving an html fragment, which doesn't appear in the book.

Does anyone know what this snippet is supposed to be doing, for instance? Have I missed something here?

var htmlFrag = String.format(
'CH{0} x CW{1}
PH{2} x PW{3}
diffH{4} x diffW{5}',
I'm on page 75 now and is this ever a good read. I've enjoyed 'Eloquent Javascript' and am also going over 'Javascript Enlightenment', which is also very nice.

There are other good Javascript books out there (Mr. Zakas has written a couple) but this one is doing just the right job of explaining traditionally difficult Javascript topics in an easy-to-read manner with examples that don't lose the reader. (Kudos to the Manning editors for providing informative code listings as well.)

I was worried the book wasn't going to come out, as it had been in MEAP forever. It appears to have been percolating to just the right flavor, reminding one of the Orson Welles phrase about 'selling no wine before its time'. Well dones all around and my thanks to the authors.