Henrik joreteg human redux download pdf

This book is not yet featured on Listopia. Add this book to your favorite list ». Community Reviews. Showing Average rating 4. Rating details. More filters. Sort order. Start your review of Human Redux. Jul 02, Daniel Dent rated it it was amazing Shelves: kindle. Makes an excellent case for reducing boilerplate bundlers , keeping clean manageable abstractions, separating application logic brains from view react components. Book provides best practices author has developed and used on projects.

Book is well written and easy to read. Many of the ideas he's advocating are universal in software development like embracing change, separating concerns and assuming open platforms will win over time. I considered that bonus material on top of learning some R Makes an excellent case for reducing boilerplate bundlers , keeping clean manageable abstractions, separating application logic brains from view react components.

I considered that bonus material on top of learning some Redux tips and supporting libraries for additional flexibility. Rosie Watson rated it it was amazing Jan 02, Josh Mock rated it really liked it Jan 06, Ezequiel Actis Grosso rated it really liked it Feb 21, Sameoldmadness rated it liked it Nov 03, Matt Busche rated it it was amazing Oct 07, Colin Byrne rated it liked it May 16, Mateusz rated it really liked it Jun 27, Artem Sapegin rated it really liked it Jul 05, Jen rated it really liked it Aug 04, Ty Carlson rated it really liked it Jul 11, Adam marked it as to-read Apr 21, Vaibhav Gupta marked it as to-read May 05, Luissette marked it as to-read Jun 01, Jason Hoffmann added it Jun 10, German Tebiev marked it as to-read Jun 19, Phil Keys added it Jun 21, Krzysztof marked it as to-read Jun 28, Igor marked it as to-read Jul 01, Mateusz Soltysik marked it as to-read Jul 22, Com marked it as to-read Aug 01, Ritesh Yadav marked it as to-read Aug 30, Na Umeed marked it as to-read Nov 28, Alexander Temerev marked it as to-read Jul 17, Since Redux isn't tied to a particular platform or framework, it can't make assumptions - it can't rely on dependency-injection.

As such or more likely by choice , it relies heavily on functional programming paradigms where various objects get partially applied to other partially applied objects which eventually get invoked and leverage lexical bindings in order to implement stateful behaviors.

Essentially, partial application does with functions and lexical bindings what classes do with instance properties. It's a different mechanism, but the outcome is the same: some execution context uses bound state in order to implement some behavior. Now, to be clear, I suck at both classical programming and - especially - functional programming.

My intent here is not to get into the strengths and weaknesses of different programming methodologies. My intent is only to say that by not fully embracing an Angular-oriented, dependency-injection view of the world, it has made it especially hard for me to reason about the choices being made in a Redux application.

Also, if down the road we decide that adding a todo should trigger an asynchronous fetch, the code that is calling the action creator doesn't need to change. Using action creators allows us to expresses the intent without having to worry about the implementation; this includes caring about whether it is async or not. So even if it has to make 50 different API calls that will re-position satellites in orbit before finishing, the intent has not changed.

That's the power of abstraction. Kindle location In this case, he's talking about the abstraction of the action creator; but, in other portions of the book, he talks about the power of abstraction in terms of selectors. This all comes to a head - for me - towards the end of the book when Joreteg details the way in which he decorates his Stores. Essentially, he takes all of his action creators and all of his selectors and adds them to the key-space of the Store API. Henrik you're nuts, you'll make a mess of the store instance!

It does sound a bit messy, but with a bit of convention, it's quite manageable. Sure you'll have a bunch of methods on the store instance, but they'll either start with "select" or "do" which keeps things quite tidy. Plus, as it turns out, this makes a lot of other things way less messy. At this point, what Joreteg has is an object Store with private state that exposes public methods for accessing selectors and mutating action creators said private state.

And this is where it all sort of clicked for me. What Joreteg created was an abstraction that completely encapsulated the very notion of Redux as the state container. Essentially, what he ends up with is a "strategy" object whose implementation could be swapped out with another implementation that doesn't use Redux at all. Now, circling back to my earlier tangent about the differences between Angular and React, you don't even need to squint to see that, in an Angular application, this would simply be a Service class with private state and public methods that implements a "strategy" interface.

In fact, it looks exactly like the Facade pattern discussed by Thomas Burleson and the Sandbox pattern discussed by Brecht Billiet - both of which are discussed in the context of Angular.

At this point, I want to share two other excellent pieces of insight that Joreteg puts in Human Redux:. If you don't actively fight for simplicity in software, complexity will win Many times, we over-engineer by creating generic solutions that include solutions for problems we don't actually have. All together, what this helped me to realize was that I've been trying to implement a "React pattern" inside an "Angular application.

By not aligning my technique with my context, I'm not fighting for simplicity - I'm incurring complexity. In other words, by starting with Redux and trying to shoehorn it into an Angular application, I'm starting at the wrong end of the plan. What I really should be doing is starting with the abstraction, constructing it in such a way that is Angular-friendly, and then seeing if Redux can be a helpful implementation detail.

You can tell that this is a decent conclusion because it doesn't change the benefits that Joreteg points out in the book:.

You don't even need to have built the UI yet, and you can still "run your app.