For the last month or so during my tram ride into work I’ve been digesting the next book that I’ll be reviewing here on The Reactionary.
Flux Architecture by Adam Boduch is over 300 pages of in depth information and analysis of the Flux architecture. He covers how to implement it using best practices and provides an in depth knowledge based on what you can tell is all of the author’s vast experience in the subject material.
Unfortunately, this is also going to be probably the hardest review I’ve had to write for The Reactionary thus far. As a content creator I’m not excited about having to be critical, but I’m conflicted because I feel that if I’m to be taken seriously as a reviewer then I must be critical when it I have to be. Let’s talk more about it.
Please note, the book cover in the photo above has been photoshopped in because I own the digital edition.
Who is this book for?
Now there’s a question. It’s the question that I spent the entire book asking myself and I still don’t have a really good answer for it. But maybe I should take a step back here and begin at the beginning.
After picking up the book I found the early chapters to be exactly what you’d expect; kind of a round up of what Flux is and the problems it solves. I already sort of knew this so the first couple of chapters, for me, were pretty dry but where a good reintroduction to the basic concepts, I guess.
The next chapter was about setting up a Flux skeleton architecture. The premise being that best practice dictates that before you begin building the components that will comprise your UI you should organise the Flux pieces that are going to drive your front end application. The thought process behind this being that by starting slim you are able to see any potential growing pains your implementation may have early enough to avoid as much refactoring as possible.
A good insight though this may be, and one that was obviously drawn from personal experience, this beginning set the tone for the book. One where I just didn’t really feel like I was learning anything that was going to take my knowledge of the architecture up to the next level.
Don’t get me wrong, not that every book needs to shatter your development reality. But when you pick up such a specific book about such a niche and advanced topic, I’m thinking of books like C# in Depth, there is certainly an expectation that you are going to find some best practice, pattern and usage gems. For an advanced book this lack of really good, advanced, outside the box thinking type best practices is a major problem because it makes picking an ideal audience for this book next to impossible.
Who this book isn’t for
“Who this book isn’t for”, is the biggest problem for this book. In my opinion it isn’t really for anybody. Let’s take for granted that this is not a beginner’s book because it is quite obviously designed to be an intermediate to advanced level book.
Given this you also have to assume that the reader will probably have at least read one book on React or consumed some material on the framework. We know they probably already have a surface knowledge of what Flux is going in.
Taking this into account, spending the best part of 40 pages explaining Flux architecture is pretty overkill. Sure, explain what Flux is and the theory of why it’s useful at the beginning, I have no problem with that, but taking 40 pages to do it is bordering on patronising.
Also, perhaps it’s my fault but, when I started reading the book I was expecting to find lots of practical real world examples and perhaps an application to build throughout the book. Maybe one that is a little larger than the ones you build in most books so that the author could really demonstrate the power and flexibility of Flux. Instead there were a number of disparate and disconnected examples of code.
So what the points above add up to is this: This book isn’t really for beginners. I’d say that this book isn’t for anyone wanting fast knowledge because the book goes at a very slow pace. Also, developers looking for examples they can easily apply to the real world might need to look elsewhere.
What I didn’t like about this book
There are three major points that I found really difficult to get along with in this book, the repetition of the content, the examples that were used in the code and the way that the author would sometimes cover irrelevant topics.
To be fair to the author, part of the reason there may have been so much repetition in this book is because there just isn’t that much to cover. I mean Flux can be a topic that is difficult to get your head around and to get it right can definitely be a big task. But when you try and fill 350 pages with content relevant to Flux, inevitably, you are going run out of things to say.
I wouldn’t have minded as much if the author was to only briefly mention something he spoke about in an earlier chapter. Instead I found that in some places he would reference something he’d said earlier and go on to do a full recap of the topic again! I found this to be too much and the book could have been shorter without out.
As I mentioned above I was most disappointed that we didn’t build a “thing TM” to show how Flux really hung together and to better demonstrate some of the concepts that the author spoke about. Rather than the disjointed examples which made for a real mental exercise when it came to each code snippet .
Finally, I found that far too often the author would lead me down a path that didn’t even need to be travelled. I remember in one part of the book where the author poses the question of something along the lines of “You may be asking yourself why we used an import statement instead of a require here.”
Now I’m the sort of reader who doesn’t like to just have these things handed to me. I find it far more interactive to answer the question in my own mind and then check my working. So I sat there thinking for some time and eventually gave up and admitted that I couldn’t see the substantive reason for why you would pick one over the other in the context in which he posed the question. I read on only to find that the answer was, there was no substantive difference.
The problem with the question was that the answer was so obvious that I had to assumed it was a trick question. So my question is; if something is so completely obvious to the point where your reader is thinking it must be a trick question why point it out at all?!
This happened a number of times throughout the text where the author would ask questions that no one was asking and then go on to answer these questions and in doing so didn’t lead us toward significant gains in knowledge other than helping us to avoid a dead end path of inquiry that we probably weren’t going to follow anyway.
What I did like about this book
There were a couple of things that I liked about this book. First and foremost, the author was definitely not afraid to go deep into the subject material. He really managed to pull out more finer details than you could shake a stick at. If you ever wanted to be the “office Flux know-it-all” then given the time and patience this book could help you do that.
He didn’t just stop at explaining the principles of Flux either, taking a walking through Alt.js and Redux as well before finally showing you how to put together your own custom implementation of the Flux pattern ready to be wrapped up in npm packages for ultimate reuse.
Because of this depth I think this book is going to make a really good addition to my library as a reference book. This book will definitely be the first one I flip open if I have any questions of best practice or patterns, how to scale my applications or the ups and downs of pure Flux vs Redux. I mentioned that there’s nothing ground breaking in here but there’s certainly more than I want to keep in my head all at once and flipping open a book sometimes gives such a better experience than trawling through the many blog posts you can find on the topic.
Is it good or what?!
Well, it’s hard to really answer this question. It is not necessarily a bad book in and of itself. It’s my opinion that the examples needed work but, in fairness, I might have been coming at this book from the wrong angle.
I was expecting a book that I could sit down and read start to finish as is the case with so many tech books these days but what I got instead was a reference book which really did make it feel like I was reading the dictionary at times. It can’t be denied the content is complete, thorough, accurate and up to date and these are all good qualities to have in a reference book.
The real reason why I can’t recommend this book is because I don’t really know who to recommend it to. It’s too advanced for beginners and anyone who has already read a book on React has most likely come in contact with Flux to a degree sufficient enough to begin using and learning about it through experience and backing that up with blog posts.
I’m going to suggest that a need to know the Flux pattern to the sort of intimate levels that this book goes to is rare. So to avoid someone buying this book and not getting what they expect from it. I won’t be explicitly recommending this book other than to say this: It’s worth it if you just want to have a book to reference from at hand. You’ll have to decide if the cover price is worth it yourself.
If you’d like to check out any of my other (perhaps more positive) reviews check them out in the link in the menu above!