Thought On React And Redux

Note: This post is in response to a client asking why a single state store is preferable to a more object-oriented approach with multiple objects, each managing its own state.

First, a caveat: I don't have much hands-on experience with React, and I've never used Redux, although I plan to as soon as the opportunity presents itself. I do try to keep up with the latest trends though.

Components can store state as long as they don't modify it. If you find you need to modify it, move it up the tree to a parent component and pass it down as a property. You wouldn't want to modify it anyway, because React expects/demands you not to. React adds this constraint so it safely apply its optimizations to your application tree.

In my opinion object-oriented programming is good to know, in the same way it's good to know your enemies. Obviously at some point something needs to get mutated, but with functional programming the system (framework or language) generally offloads that for you, leaving you free to think at a higher level. Once you unlearn the bad habits you picked up from OOP, you really can get more done with less effort.

Since React/Redux take a functional approach, the fundamental programming unit is not objects, but functions. It isn't difficult to write higher-level reducer functions to segment the state tree and dispatch to lower-level functions to handle the actual state transformation. Having a single store is beneficial in other ways, in the same way that having a single database is useful for most apps. You decide what to put into the state tree anyway, along with what actions to write, so you can easily segment the tree at the top level if you like.