I've seen this expressed many, many times, and it is something that I've honestly never quite understood. I started with React less than a year ago, and it wasn't until I added Redux to my stack that I began to feel perfectly comfortable with,
To me, the fact that actions dispatched in whatever component would cause the global state to be recomputed which then got handed to react to render it just a no-brainer. This truly makes data in React flow just one direction. The tooling around it -- Redux DevTools -- also made seeing my app in action and debugging it so incredibly clear.
Without it, for me initially it was a struggle about where exactly to store certain state, and passing props and callbacks up and down all over the place. It wasn't clean or easy to reason about at all.
As someone who had very limited experience in the framework, Redux felt like a tool which made the pit of success for me pretty darn large. I do know that even Dan himself has suggested that people not learn them in conjunction, but to me, the coupling of them is so perfect that React only became a joy to use WHEN I introduced it.
The amount of things you need to know in order to use react and redux is ridiculously low.
You're basically just composing functions of two types "(state, action) => state" , and "state" => html.
The boilerplate consists of a few functions (really mostly createStore and connect) that are incredibly well documented.
There's almost nothing to understand and redux itself is almost not a lib (only 318 LOC). The whole thing is a pattern and redux is just a small, very well written key component of the pattern.
When people debate redux they debate about programming, not about a tool. That's why it's interesting and why it will never end.
Well, if you're coming in from a non-FP background, learning Redux is intimidating. I'm a aspiring web developer (I'm coming from tech support role and my programming skill is mostly bash and bit of Python) and started looking into Redux, and yay struggled with getting started.
const store = createStore(reducer)
Per your quote, Dan Abramov (creator of Redux) advises that people should focus on learning React first, and _then_ try to learn Redux. I'm one of Redux's current maintainers, and I completely agree with that advice. (My "standard advice for learning React" includes exactly that instruction.)
However, while it's absolutely possible to build a React app without an additional state management library, there _are_ excellent reasons to move most of your state outside the component tree: simpler props passing, optimized app performance with less re-rendering, and the ability to maintain more of your application's current state in the middle of hot module reloading. And, in the case of Redux specifically: benefits like time travel debugging, centralized middleware for dozens of use cases, more easily testable code, and the ability to straightforwardly trace data flow through the system.
A lot of the issues I see with people trying to learn Redux are more about people who either have little JS or React experience to begin with, or are completely used to OOP, and are having issues trying to get used to functional programming principles in general.
Is Redux for everybody? No. Should it be the first thing that a learner jumps into? Probably not.
Does Redux help solve real problems for front-end developers? Definitely.
(Note: In addition to "You Might Not Need Redux" [0], it's fascinating to read Dan's earlier pre-Redux article "The Case for Flux" [1], where he not only discusses the benefits of using the Flux Architecture to solve use cases like caching data on the client, but also argues against doing things purely out of dogma: "A dogma is born when the solutions are presented without enough original context, and newcomers feel pressured to delegate crucial decisions to an authority." So in that sense, yes, I'd absolutely agree that newbies are being pushed to use Redux out of dogma, but disagree that learning to use Redux is a bad thing.)
[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
The problem is because the community reveres Redux so highly that react and Redux are coming to be equated as a pair. Not much you Redux developers can do about that, it's a testament to the value of your work.
Also worth noting that Redux can absolutely be used with any UI layer, _is_ being used with frameworks like Angular and Ember, and has also inspired variations like vuex and ngrx/store.
I think most people are more comfortable with object composition rather than function composition, so Mobx feels more natural.
I added a event emitter to AsyncStorage and that's basically it.
I feel that every Redux blog post should start by pointing out that despite react/Redux almost being discusssed synonymously, as the author of Redux points out, "you might not need Redux".
I would go further and say "avoid Redux until you know you need it", and point people to more simple ways of reaching the same goals.
Redux is a power tool for experts that is disheartening beginners and sending them down the wrong path.
I was speaking to someone recently who had tried Reactjs. I wanted to enthuse with him about how awesome it is. He said it was too hard and he went with vuejs instead. When I questioned him further it became apparent that he had started to learn react/Redux and gave up in confusion.