My current views of state management in React
Tags: react
Published: 2021-03-15 04:07:34

React development has always had a bit of a *choose your own adventure* experience. By that I mean there are a LOT of choices to make in any react app. Other frameworks are much more prescriptive in how you build applications. You won't get very far down your adventure before you must make some choices in how you handle data and state within your application. React components can have state using `setState` in a class component or `useState` in a function component. That along with `context` is really all React gives you out of the box. Over the years there have been countless state management solutions that have risen and fallen in popularity. Have a look at[ React State Museum](https://github.com/GantMan/ReactStateMuseum) to see dozens of the most popular approaches over the years. There was a time where it looked like Redux was going to be the clear winner and for maybe a couple of years it did seem like every enterprise react app was built with redux. It's sort of fallen out of favor in recent years although it is still a solid pattern. Over the years my preferences have changed as the options have expanded. Back in the redux hay day I was all in on global state management but these days I do not find myself reaching for a global state management solution. I'll try to break down my preferences for data/state management. So pretty much every app out there talks to some sort of API to query/mutate data on the server. I prefer to synchronize my app with the server using [ React Query](https://react-query.tanstack.com/) or [ Apollo Client](https://www.apollographql.com/docs/react/). I've been working mostly with GraphQL APIs in recent years so I've typically found myself using Apollo Client. Apollo client has a memory cache that your app can use to synchronize the UI with the server. I only recently learned about React-Query which has a very similar API as Apollo Client with the `useQuery` hook, but can be used with anything that returns a promise like the Fetch API for example. React Query is useful for synchronizing your app with server data regardless of if it is GraphQL or REST, or something else. I find that once your app data is synchronized with the server using one of these approaches, then there is not really much left that needs to go into global state.  It is worth noting that Apollo Client does allow you to add some local state to the cache, but I’ve found it to be a little heavy handed for my tastes. Most apps you will want some state available globally for example you might want to track dark mode settings, or if a particular modal is open and things of this nature. In these cases I find `useState` or `useReducer` with React `Context` is sufficient. I tend to prefer to keep my state closer to where it is relevant. I do have a fascination with Finite State Machines - and [XState](https://xstate.js.org/docs/) is awesome for state machines in your app. I do like to use state machines at the component level, for complex operations or to orchestrate some nuanced sequence or application flow.

My “choose your own react adventures” these days tend to follow this approach.