On state management tools in React

It’s 2020 but I still see questions everywhere about “Which state management solutions should I use?” in React.

Should I use Redux? Oh, I might not need it?
What then? Is local state enough or do I need React Context?
How about MobX (mobx-state-tree?), Recoil, Storeon, Zustand?
Or should I embrace streams/observable and use RxJS?
If my backend is GraphQL, should I use dedicated clients like Apollo Client or the ones above would be enough?
There’s also a new trend on “data-fetching libraries” which is higher-level than state-management libraries but still backend agnostic. Or should I just use React Query or SWR?

After 5 years of experience with React, my opinion is now summed up in this picture (click to view full size):

Instead of seeking the perfect state management solutions for your use case, remember that as a project grows, its use cases tends to changes, seek to learn how to build well-factored software. The programming is terrible blog, The Architect Elevator website, and Martin Fowler’s website are filled with great advice. Then all the solutions out there will become tools that can be wielded effectively.

I have observed that a single piece of data will be reused in multiple views. Let’s consider a chat application where you can mark certain chats as pinned.

Before React Query existed, I might use Redux to do this. So naturally, each view component would use useSelector and useDispatch.

Fast forward to 2020, and now React Query is a thing. Now I am envy of all the greenfield apps that gets to use it.

Looking back, the original implementation we have its full of boilerplate and is bug-ridden. Sometimes the state would not synchronize correctly due to me forgetting to put useEffect in some places. The buggy code is then copy-and-pasted all over the place.

And so, it seems more effective to just switch to React Query. In this case I would use the useQuery and useMutation hooks instead. But then I would need to change several components. This is a laborious and boring task.

In an alternative universe…

Now, what if, back at that time, I decided that “UI components should not be aware of what state management solution is being used”?

Then after the initial implementation using Redux, I would spend a few minutes harvesting the data-binding code and refactor it into a custom hook.

In the end, what defines a module is what pieces of the system it will never responsible for, rather what it is currently responsible for.
— Tef, “Repeat yourself, do more than one thing, and rewrite everything”, programming is terrible

2020 comes and React Query becomes popular. In this alternate reality, the work required of me was much fourfold smaller. The UI components can be blissfully ignorant that behind their backs, the state management solution has been replaced.

Decoupling UI from state management

Multiple techniques exist:

Hooks are generally the cleanest solution
```
const pinnedChats = usePinnedChats()
```
Connector components (using render props) can help if you have a lot of class-based components. Class components cannot use hooks so in these cases you can create an adapter which lets class components access hooks through render props.
```
function PinnedChatsConnector({ children }) {
  const pinnedChats = usePinnedChats()
  return children({ pinnedChats })
}
```

Higher-order components are generally considered legacy. If your code have a lot of higher-order components and you are not ready to rewrite the whole component yet, you can, again, create an adaptor that allows connectors to be used as a HOC.

function withPinnedChats(WrappedComponent) {
  return Object.assign(function WithPinnedChats(props) {
    return (
      <PinnedChatsConnector>
        {({ pinnedChats }) => (
          <WrappedComponent {...props} pinnedChats={pinnedChats} />
        )}
      </PinnedChatsConnector>
    )
  })
}

In 2018, I talked about this idea with more examples in my talk Smells in React Apps.

Why do I recommend this?

In an alternative universe…

Decoupling UI from state management