The new wave of React state management

UI programming is much harder than going to the moon. Do not confuse danger, scale, glamour, etc with difficulty

Most state management libraries help you deal with the problem of sharing state between multiple components. In modern React, most components are just functions, so this boils down to passing state through deep call stacks.

If you have a component A, which renders component B, which in turn renders component C, without a state management library you'd have to pass state from A to B to C (this is often called prop drilling). The longer the call stack, the more irritating this becomes.

State management libraries allow component C and component A to modify, and subscribe to a shared state store. Redux et al. are effectively the reactive version of global variables.

Question for you since you seem knowledgeable about React state management. When I did a lot of back-end programming in Java we frequently coded to interfaces where we could swap out back-end implementations for ORM for example if needed. There's an ongoing joke where nobody actually did that.

Is there something like that in React? My understanding is that there's a lot of coming and going of state management frameworks, and it would seem to me committing to thr API methods of a particular framework would be risky. Or am I thinking at the wrong abstraction level?

To some extent, this was the purpose of the "container/presentational" pattern that was popular for a few years [0]. By splitting your components into "containers", which were responsible for managing data fetching, and "presentational" components, which just received data as props and displayed the UI, in theory you could swap out the state layer someday without having to alter most of the display handling.

But, the community really began over-obsessing about that, and often treated it as a rule you _had_ to follow (to the point of people seeming to panic and asking for help about whether a particular component should live in a `/containers` folder, `/components`, or somewhere else).

Dan Abramov, who wrote the article that helped really popularize that approach, later updated it to say he no longer finds it very useful.

In addition, React hooks push you towards a very different approach, where each component is now responsible for calling the hooks that it relies on for data fetching. That hook may still abstract where the data actually comes from, but the calls are now part of the component itself. I talked about this change in approach in a blog post and conference talk conference talk [1] [2].

Finally, the testing approaches in the ecosystem have changed as well. Instead of "shallow rendering" components using the Enzyme library, the community has moved on towards more "integration"-style tests with React Testing Library. This does require more setup work in tests to ensure you have all the various data providers wrapping the components under tests, and real or mock data being loaded, but the tests themselves become simpler and any state library usage becomes basically irrelevant to the actual test implementation. See [3] and [4] for some thoughts on that.

Soooo... yes, you _can_ write more abstraction layers, split your components by "containers", and even add DI via React context or some other purpose-built library if you want to. You could even abstract out all the UI components you use from a particular library just in case you end up swapping date pickers or something. But as always, it's a question of whether that will actually provide a benefit, now or in the future. And in general, most React apps do not bother with those extra abstractions.

[0] https://medium.com/@dan_abramov/smart-and-dumb-components-7c...

[1] https://blog.isquaredsoftware.com/2019/07/blogged-answers-th...

[2] https://blog.isquaredsoftware.com/2019/09/presentation-hooks...

[3] https://kentcdodds.com/blog/testing-implementation-details

[4] https://blog.isquaredsoftware.com/2021/06/the-evolution-of-r...

I'd like to share my approach to React state management, because after a decent amount of industry experience I've stumbled onto a solution I find to be very excellent.

Firstly, I use the open source library Pullstate[1], which I find to be as effective as any alternative but _far, far_ simpler to understand and use.

All my components are functional components. For any state that _only_ that component needs, of course I simply use the useState hook.

When things need to be shared among multiple components, I create a Pullstate store - for instance, for an app I'm working on now I have a UiStateStore like so:

    type UiStateStore = {
      isSidebarOpen: boolean;
      // etc
    };

    export const uiStateStore = new Store({
      isSidebarOpen: false,
    });

Then, in the components that need to know if the sidebar is open, I import this store and use its state hook _the exact same as the normal useState hook_, like so:

    const isSidebarOpen = uiStateStore.useState(s => s.isSidebarOpen);

You simply pick which properties you need off the state object ("s"). When you open the sidebar, you simply update the store like so:

    onClick={() => { uiStateStore.update(s => { s.isSidebarOpen = true; }) }}

And automatically, any components using uiStateStore.useState and watching the isSidebarOpen property will get updated, exactly the same as the normal useState hook - just shared.

It's so dead simple and has made complex app-building so much easier for me.

By comparison, Redux in my experience has a harder learning curve with a lot of unnecessary pieces and boilerplate - it seems crazy to me that people think it's a great solution and it feels like people have convinced themselves all those pieces are "necessary", where in my experience they are anything but.

The one caveat is that if I have a component with many handlers, e.g. onClick, onMouseMove, onContextMenu, onMouseLeave, etc (and in some cases I do), components can get bloated. I haven't found a fix to that yet. But that's more an inherent issue with react than anything to do with state management.

[1] https://github.com/lostpebble/pullstate