Context vs Redux
Tags: webdev, javascript, react
Published: 2023-05-30 13:00:34

---
title: Context vs Redux
published: true
date: 2023-05-30 11:31:04 UTC
tags: 
canonical_url: https://merza.hashnode.dev/context-vs-redux
---

One of the questions that people often ask is whether **React Context** can replace **Redux.** Before I answer that, let's talk about what **Redux** is and what problems it aims to solve.

## What is Redux?

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1685443624283/e6095c39-ea69-49ae-b137-f940f20f9957.jpeg)

[Redux](https://redux.js.org/) provides a centralized store to store the application state. So instead of storing local state in our components, we store all the state in a single global store and have each component access the piece of state it needs. This way, we don't have to pass data via props through many components in the middle. So one of the benefits of using state management tools is that they help us avoid prop drilling.

## What about React Context?

[Context](https://react.dev/reference/react/useContext) on another hand also helps us avoid prop drilling. But it's not a state management tool since it doesn't have a way to store and update data. When using context, we store the state somewhere else. So context is just a way to transport and share the state in our application. So comparing context with redux is like comparing a box with a truck carrying that box.

So both react context and redux allow us to share state in our application. But does context replace redux ??, well it depends on who you ask. If you ask Nerd _(my guy obsessed with tools)_, he will tell you that with redux, you can:

- Cache the server state

- Persist it in local storage

- Components can select pieces of state

- Undo Things

- Use middleware and log actions

- Decouple from React

- See state change over time

Isn't that awesome !!. In response to your argument that Redux adds excessive boilerplate code and complexity, they will present you with that old famous lightman. Have you used the Redux toolkit? It's good and reduces boilerplate. Look. The problem with this mentality is that people like Nerd are more focused on the features of the tools than on the problems they need to solve. As a software engineer, You should be focused on solving problems for businesses and individuals. If Redux allows you to undo things or log every action, that's not a requirement in the application you're going to build, you're just increasing complexity by using the wrong tool to solve your problem, and you will only add complexity. It's like the old saying, give a fool a hammer and he will see everything as a nail.

### Understanding The Problem

So let's take a step back and understand the problem that most react applications face before we talk about tools as the solutions. Most if not all react applications need a way to manage some state that can be server or client state. A few years ago before we had tools like [React Query](https://tanstack.com/query/v3/) or [Zustand](https://docs.pmnd.rs/zustand/getting-started/introduction). People started using Redux to store both the client and server state in a single global store. But Redux brings so much unnecessary complexity. When building applications with Redux, we have to deal with several concepts like store, actions, producers, dispatch, middleware, selectors and more. These days, we can manage server state using React Query. And we don't have to deal with any of the nonsense that comes with Redux. The only concepts we have to deal with are queries and mutations.

But what about the client state? Well, once we manage the server state with React Query, there is actually very little client state that should be managed for simple applications, we can define local state in our components and share it using context. If our state management logic is complex, we can consolidate it using a reducer. But if you're still having unnecessary re-renders and we need more control over data management, we can use Zustand. I believe Zustand is good enough for most applications, but there is no one size that fits all every project is different.

### Conclusion

<mark>The reality is I think redux has served its purpose. There was a time when we didn't have better alternatives. But these days with React Query and Zustand around I think redux is an overkill for the majority of applications. So it's time to move on</mark>. I know a lot of projects are still using redux but just because something is popular, it doesn't mean it's the best solution. I kind of blame this on online instructors who created courses to teach, React with Redux just to show you how to build, to do apps something completely unnecessary. So a lot of people started using React with Redux and that's why they're having a hard time divorcing from Redux.

Now, with all that, if you're still in love with Redux and want to make your life more complicated and write more code to get things done, that's totally fine. You search for people like Nerd on the internet so you can hang out and talk about your memories with Redux day and night.