Ok, only tangentially related. I would appreciate anyone more knowledgeable than me in React chipping in: Why Redux is the norm for React state management?
Follow-up specific question: In which cases is it better than react-easy-state[0]?
I am using react-easy-state on my company and on my side-project web apps. For me at least, it seems to add much less cognitive overhead than Redux. It is simpler to understand, simpler to use, simpler to read and maintain.
Am I missing anything? Because react-easy-state seems very underrated in my opinion.
I'm a Redux maintainer. There's a bunch of reasons why Redux took off:
- In 2014, a year after introducing React, Facebook announced the "Flux Architecture" concept [0]. Since it was mostly just a pattern and not a library, over the next year the community created dozens of competing Flux-style libraries, which I've referred to as "The Flux Wars" [1].
- Redux came out in the middle of 2015. Its design took inspiration from many of the existing Flux libraries, but then added some Functional Programming principles on top of that [2]. Many React devs concluded that Redux was the better Flux implementation, and several of the other Flux library authors promptly stopped working on their libs and began recommending Redux.
- Redux was designed to work well with React from the beginning, including the design of the React-Redux API [3]. Among other things, React-Redux made use of what was then a little-known React feature called "context", which enabled users to avoid prop-drilling values all the way down the component tree. In addition, the initial sales pitch concepts of "time-travel debugging" and "predictable state updates" appealed to many developers who had seen problems with libraries like Angular and Backbone.
- Along with all that, Dan Abramov had already picked up a bit of a reputation in the React community from his work on things like React-DND and some Flux-related blog posts.
Once Redux hit an initial critical mass, it became self-sustaining. People in the community assumed that if you were going to use React, you _had_ to use Redux. Tutorials were written that taught both of them together (along with setting up Webpack and Babel from scratch). Now you've got bootcamps teaching beginners React and Redux at the same time (which is unfortunate, because we recommend that people should focus on learning React first, and only tackle Redux once they're already comfortable with React).
Today, there's certainly plenty of other good options out there, with varying tradeoffs. My own estimates are that around 50% of all React apps do use Redux, and overall absolute usage is continuing to grow [4].
More recently, our new official Redux Toolkit package has been designed to simplify many common Redux usage patterns, and is now our recommended approach for writing Redux logic [5].
Sorry, I have no experience with Flutter or knowledge of how Redux is being used with it, other than having seen one or two random comments where the two names appeared together.
Thanks anyhow. I think part of the difference is javascript doesn't have streams, but Dart does. And that it's recommended to use the tools built in to the lang, but there must be more to it.
Hi - author here. I haven't used react-easy-state unfortunately. But like when building a company, the best product doesn't always win: the company that executes the best does.
Executing well includes building a great product, but it also requires marketing, which the Redux community has done a great job of to the point where it's the de facto solution.
Follow-up specific question: In which cases is it better than react-easy-state[0]?
I am using react-easy-state on my company and on my side-project web apps. For me at least, it seems to add much less cognitive overhead than Redux. It is simpler to understand, simpler to use, simpler to read and maintain.
Am I missing anything? Because react-easy-state seems very underrated in my opinion.
[0] https://github.com/RisingStack/react-easy-state