Do we need Redux? - Fraser Walker-Saunders
Skip to content

Do we need Redux?

Fraser Walker-Saunders  at 

Reimagining State Management: Do We Always Need Redux?

Redux has been a go-to solution for sharing immutable data across complex applications. However, it’s time to question whether we always need Redux, especially with the emergence of alternatives like React Query.

Redux: More Than Just a Cache

One common pitfall with Redux and similar state management libraries is that we often treat them as mere caches for our backend state. We fetch data, add it to our store using reducers and actions, and periodically re-fetch it to keep it up-to-date. Essentially, we’re asking Redux to do much more than it was designed for, turning it into a catch-all solution for our problems.

However, we should remember that our frontend and backend states are never perfectly synchronized. At best, we create the illusion of synchronization. This inherent disconnect is a consequence of the client-server model and underscores the need for caching. Attempting to recreate the entire backend state on the frontend, as Redux often encourages, blurs the line between frontend and backend responsibilities.

The Proliferation of Redux Add-Ons

To address the complexities of managing data from the backend, numerous libraries emerged, including redux-observable, redux-saga, and redux-thunk. These libraries added layers of complexity to an already boilerplate-heavy Redux. However, it’s arguable that most of these solutions miss the mark, introducing more complexity than necessary.

Embracing Simplicity with React Query

React Query is an alternative library that excels at storing backend state without the complexity associated with Redux. Let’s delve into why React Query is a compelling option:

  • Simple API: React Query offers a straightforward API with hooks for managing queries (data fetching) and mutations (data changes).

  • Productivity Boost: Since adopting React Query, developers often find themselves writing significantly less boilerplate code compared to Redux. This allows them to focus more on crafting a seamless UI/UX.

  • Data Handling: React Query handles data refetching, caching, and stale data invalidation efficiently, out of the box. Configuration options are available for fine-tuning.

  • Simplified Usage: Developers can use the useQuery hook wherever data is needed, specifying a unique key for the query and the asynchronous function to fetch the data. The implementation details don’t matter, whether you use Axios or the Fetch API.

  • Mutations: React Query also provides the useMutation hook for changing backend data, simplifying the process.

What About Frontend State?

Once you start using React Query, you’ll likely notice that, in most projects, Redux becomes overkill. As data fetching and caching are handled effectively, there’s minimal global state to manage on the frontend. The remaining state can be managed using React’s built-in state management tools, such as Context or useState. There’s no inherent problem with this approach, and it can simplify your code significantly.

This is all just my opinion and of course there are many cases where Redux is the best choice and the decision to use it or not is up to you. I just wanted to share my perspective on this topic and I hope you found it useful. Happy coding!