Things I wish I knew about state management when I started writing React apps

Just xState. Each machine is responsible it’s own piece of the global state pie by using its internal `context`.

This allows a similar approach to redux’s actions and reducers (or events and `assign` for xState), but each machine can focus on its area of responsibility and enforce its behaviour through defined state transitions.

This approach also makes it easy to coordinate between multiple services (e.g. having the “NavigationService” change which links should be available by listening to a state change on the “UserSession” service as a user becomes authenticated.

This started as a bit of an experiment to see what a stateful UI “service layer” might look like, but as we’ve progressed, we haven’t found a need for anything else like redux or mobx.

Or are trying to follow fads so they're more employable (resume-driven development?) Which is a strategy I am not criticizing in the slightest. It can suck when it means the whole team has to learn the fad framework, though.

Great article! I have only done a few simple projects with React, except for one where we used Redux. For me, Redux is too much clutter. I can recommend a look at this article: https://medium.com/@yiyisun/redux-vs-the-react-context-api-v... I've been working on an AppRun based hobby project for a couple of months now, and I find state management there to be quite easy. No clutter!

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].

[0] https://facebook.github.io/flux/docs/overview/

[1] https://blog.isquaredsoftware.com/presentations/workshops/re...

[2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...

[3] https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

[4] https://blog.isquaredsoftware.com/2019/03/presentation-state...

[5] https://redux-toolkit.js.org

> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework

Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that already knows the tools for your framework. You'll be spending all of the next eternity cobbling together features that you could have had out of the box had you adopted somebody else's framework instead.

The choice is never "use a framework" vs. "don't use a framework". The choice is "do we use somebody else's framework" vs. "do we build our own framework". What you implicitly and unknowingly chose was the "we are gonna build our own framework" option.

In my experience, the minute the few folks who pushed the "no framework" option leave the company, all the rest of the developers smile and scramble to replace the hot mess of a codebase with something using an industry accepted framework.