When to use redux?

Somehow frontend developers seem to like to suggest a huge refactoring to use redux when the codebase evolves and becomes larger. However, they cannot seem to justify when redux is needed. Here, we want to help you justify whether you need it or not.

When to not use redux?

Frontend developers should really think about whether they are following status quo or have a legit justification. You often will find problems in the future when a design document says we use “xyz” without much justification.

Team size

This is not a huge factor in deciding whether to use redux or not because team size should not be the sole deciding factor on correct design.

On the one hand, if you are in a team of 1 to 2 people, you should consider the overhead of introducing redux. For instance, if you decide to use redux toolkit (RTK) and manage all async requests, each domain/feature will be a few files and your development time increases for adding a simple request to GET data from the backend. A red flag is when you have developers spending a lot of time copy and pasting slices for every simple PR.

On the other hand, if you have a big team, and you have decided to introduce redux because too many developers are contributing to the codebase. You should really consider if it is better to just refactor existing code or introduce redux. Sometimes, your code might need better intent and clearer responsibility whether it is a component or container.

Manage asynchronous requests

When frontend developers decide to use redux solely for asynchronous requests, they should really consider using dedicated packages for async requests like react-query. Dedicated packages like react-query are more fitted in normal use cases. Usually, they are easy to setup and have caching done correctly. If you decide to use rtk query, you better know how caching data properly with normalization to deduplicate data. Red flags include:

Local request states/data are in global state, only 1 component is using those data - improper use of redux
Refetching the same data causes re-rendering - signs of no proper normalization
No caching or no optimistic updates required - you probably don’t need to use redux

Bringing local state to global state

A good exercise is to determine what state you want to bring into redux, this will really help you make a good decision on whether you need redux. Usually, you just have to determine whether or not the state is better fitted as a local state or global state.

For instance, if you want to use redux to store search queries and pagination data for a request. Is this a local state or global state? It depends on how you would use it. If nested components need to read & update the same search query & pagination data, it probably fitted as a global state. However, if the search query & pagination data changes per component, it is better suited to be a local state. Red flags include:

Resetting these states (ie. search query and/or pagination data) on mounting each component that subscribes to these states.
Find it difficult to have two components that are subscribing to the same state on the same view/page
Copy and pasting slices with these states for each component/view/page. If you keep them as local states, you can just create a custom hook and reuse it per component/page that needs them.

If you have these symptoms, maybe it’s time to consider these states as local states, remove them from global state and create a hook to be reused.

State predictability

A good question is to ask your team whether you really need them or it is just a nice to have, if a product feature is to track activity and you would like to batch the activities and send a request to your analytic service, or a feature to undo actions like drawing diagrams in UI, it does make sense to add redux. However, if you are just going to look at the actions or use replay once and never use it again, you have to think if it actually makes sense to add redux.

If most nested components only need to read the data that is shared, maybe you should consider React’s Context API instead. It will reduce a lot of overhead.

Conclusion

In short, you should justify your technical decision to introduce redux or your team might suffer a lot. Hopefully, this helps you decide whether to use redux or not.

#	Question	Decision
1	Are you building an SPA?	1. Yes - continue considering `redux`. 2. No - you have a high chance of not needing it and look into state hydration between server & client.
2	Are you in a small team?	1. Yes - first look into simpler state management solutions like `zustand`. 2. No - have you consider refactoring your codebase first.
3	Are you planning to use `redux` for asynchronous requests only?	1. Yes - look into other asynchronous request solutions like `react-query` first. 2. No - continue considering `redux`.
4	Have you consider whether the shared states belong to local or global?	1. Yes - there are global states, continue to consider `redux`. 2. No - use custom hooks and stop considering `redux`.
5	Do you need state predictability? Or nice to have?	1. Yes - continue considering `redux`. 2. No - maybe you don’t need `redux`.
6	Do you need to share data to nested components for read-only purposes?	1. Yes - look into using React’s Context API. 2. No - continue considering `redux`.