🏠 Home

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.

Sharing read only data to nested components

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.


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.

1Are 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.
2Are 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.
3Are 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.
4Have 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.
5Do you need state predictability? Or nice to have?1. Yes - continue considering redux.
2. No - maybe you don’t need redux.
6Do 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.