When to use Redux

A common question many people have when using the Redux state management library with React is when to start using it. The tendency is to use it all the time at first, but in my experience this approach is a little excessive. Redux actions and reducers can create some extra boiler plate so it’s good to have a standard set of criteria on when to use it.

Reasons to use Redux:

1. Same piece of application state needs to be mapped to multiple container components. A good example of this is session state. When the app first loads, often information about the user needs to be shared with various components in the titlebar and each page. It’s likely these components don’t have any direct relationship so Redux provides a convenient way to share state.
2. Global components that can be accessed from anywhere. It’s common to have components that live for the life of the application (for a single-page app this is every time the entry point is reloaded) that do things like show notifications, snackbars, tooltips, modals, interactive tutorials, etc. With Redux, you can create actions that dispatch commands to these components so, for example, if the code makes a asynchronous request to the backend it can dispatch a show snackbar action if the request fails. Without Redux, you would need some other event system or have to instantiate the snackbar component every time it gets used.
3. Too many props are being passed through multiple hierarchies of components. If a higher-level component is provided with a dozen props and uses only two of them, and the rest are passed down to a lower-level component, then consider refactoring with Redux. This scenario happens a lot with wrapper components that just provide layout styles, but don’t require a lot of data or configuration. It’s more practical to side-chain Redux directly into a lower-level component in this case.
4. State management using setState is bloating the component. This is pretty subjective, but components that are over several hundred lines of code start to become harder to reason and maintain. Separating out the state management into a reducer breaks up the code and makes it more readable.
5. Caching page state. When the user does some stuff to a page, then goes to another page and comes back, the expectation usually is to have the page in the same state. Some of this can be addressed by saving the page state in the backend and recalling it on page load. But, often things like search input values and expanded/collapsed accordions are just overkill to store in the backend. Since reducers typically initialize and live throughout the session, they can cache the page state so things remain the same.

If the component you’re working on doesn’t meet any of these criteria, then setState would likely do just fine. Redux really just becomes a tool to use in the right situation.

I recommend consider using Redux right from the start. This differs from other opinions I’ve seen on social media. A lot of people say to only start using Redux when you absolutely need it. But, in my experience, state management can get ugly and hard to maintain very quickly. In addition, Redux can actually reduce boiler plate for reasons 1–3 above and facilitate cleaner code. It has become an essential tool for me.