|
I'm a little confused by what you're trying to say, so help me out here. You say "it's overly decoupled for simple applications" and then "it is only a tool you should reach for after you find you need it." This would imply that you view Redux as a tool that primarily helps maintain larger React applications -- does that mean you think it doesn't make sense as the defacto standard as compared to, say, Flux? Or that there shouldn't be a defacto standard, or that neither of these is a good enough defacto standard? I'll take this as an opportune time to link to two very helpful and useful posts about Redux from its author (Dan Abramov) about upsides (http://stackoverflow.com/questions/32461229/why-use-redux-ov...) and downsides (http://stackoverflow.com/questions/32021763/what-could-be-th...) of using Redux. Namely, I see Redux offering a nice advantage over flux in encouraging reducer composition (and functional purity) for modularity. "This pattern also enables wonderful features like no-user-code undo/redo. Can you imagine plugging Undo/Redo into a Flux app being two lines of code? Hardly. With Redux, it is—again, thanks to reducer composition pattern. I need to highlight there's nothing new about it—this is the pattern pioneered and described in detail in Elm Architecture which was itself influenced by Flux." In short, the key value add for Redux, is not necessarily that it's (overly/inadequately) decoupled, but that it is necessarily forcing a decoupling via functional purity for the /purpose/ of modularity. That is, it is taking a more functional approach to state management for React components, favoring the event log paradigm rather than black box paradigm. This brings with it the ability to be "designed with use cases such as logging, support for Promises, Observables, routing, immutability dev checks, persistence, etc, in mind." Of course, these aren't impossible with Flux, but these things follow intrinsically from Redux. Take my opinion with a grain of salt because I'm not super experienced with Redux yet, but I really like what I've seen so far playing with it. |
It will take a person a couple of days to "grok" Redux, and a quite a bit longer to fully understand the ins and outs so one can make informed, confident decisions on how to solve problems "the Redux way".
Now you gain "cool" things by doing it, but here is the catch: Is the benefit worth the time investment to get there?
His argument is that for a lot of simple apps it isn't. You get very far with plain React, and a project has to have significant complexity to pay back the costs of fully understanding Redux.
I would argue a lot of people picking the React ecosystem make the mistake of choosing too much architectural complexity, not too little.
The extreme pluggability helps to broaden usage of Redux. But it is overkill for many projects. Decoupling is important, but it is not free (see parts of the Java ecosystem).
Devs should consciously decide what to introduce, and leave out stuff that simply doesn't increase development efficiency given the nature of their project.