Redux vs. React Context: Which should you use?

Redux has been the go-to solution for state management since its conception in 2015. “You should you use Redux” became such a universal truth, that so many started using it without really understand why. And there are situations where Redux isn’t the best option. Some started to look alternatives, including adopting other state management libraries or creating their own.

Before we talk about React, you need to know two more things.

What is state management and why you need it?

State management is the repository for the current state of the app and its data. It’s a common part of the views. For example, in the case of user data; the avatar, the full name, etc. are stored in Redux/

Front-end state management is a kind of logic that stores and refreshes current data, such as the information about the options button being highlighted, about the authorization of the user. etc. Or, if we were to put it in a more abstract way, it makes sure that business transactions are completed — by storing input data of the user interface and synchronizing it across the pages, back-end, and front-end parts.

It’s also helpful in drawing a line between the business and view layers. This makes the app run faster without having to load the same elements all over again — they’re simply stored in Redux.

What is Flux architecture?

When introducing React, Facebook also shared a new concept of one-way data flow: Flux. It’s a general concept rather than a specific implementation, popular in front-end applications created with React or Vue. Facebook recommends using Flux for SPA projects — thus the widespread support of this solution found in many libraries.

Is Redux still relevant? And what is it anyway?

Redux is an open-source JavaScript library for managing application state. It works best in extensive, sprawling applications. However, to utilize it properly, first you need to prepare. Everything should go smoothly as long as your middleware is all done and you have full control over fetches, states, etc. In Redux, you don’t have to fetch everything all the time. This is the reason why Redux remains the most popular flux-based tool for state management.

From the architecture point of view, Redux helps maintain order in the folders and files of the project. It helps programmers understand the application’s structure and introduce new people to the project (providing that they have previous knowledge of Redux). Its components are: global JS object, reduction functions, actions and subscriptions.

  • It’s easy to test.
  • There’s a good React Redux package for integrating React.
  • Good debugging, allowing you to log states and actions.
  • Nice code structure - Redux apps usually have similar architecture, so experienced programmers can easily switch to another project.
  • It’s designed for use with frequently updated data.
  • Reux eliminates unnecessary re-renders and the view refreshes when changing a specific object in the store.
  • Redux has access to middleware for async actions, but only when we use, for example, redux-thunk or redux-saga and expand the store with this functionality.
  • It’s not built-in-react, which increases the ultimate size of the package.
  • Even if used with Redux toolkit, it can be confusing for beginners due to its hidden logic.
  • It requires more configuration than Context API, and there’s more terminology to learn.
  • Problem with large boilerplate (this can be solved by using Redux-toolkit).

What is Context API of React?

Context API is an intelligent built-in function for solving issues with sharing data between nested components that are not linked directly. It is built in to React and doesn’t require any additional building. All the “uses” here are ReactHooks, bases for context Object, context provider, context consumer.

Integration of Redux with React-Redux

To use Redux in React, you need to connect the React-Redux library.
Redux and React-Redux are two different things, Redux allows you to manage the state of the application and possibly inject middleware using other libraries (e.g. Redux-Thunk) and it does not matter whether it is used in an application written in Angular Vue or pure JS.
Only React-Redux allows you to inject store into components, it makes sure that these components are not rendered unnecessarily. Important to mention, React-Redux partially uses Context-API.

  • Simple to use.
  • Great for static data as it doesn’t update frequently like Redux.
  • Low entry barrier due to minimal configuration. Just create a context (sometimes also a package component).
  • Good documentation for the React segment.
  • The app can include multiple local contexts for separate logic tasks.
  • Not designed to use with frequently refreshed or changed data.
  • The maintenance of complex apps can be difficult, especially if we use non-standard solutions.
  • Improperly passed data / parameters to components can make it difficult or impossible to reuse them outside of React-Context.

Lookout, it’s a trap!

At the time of writing this article, the interface of Context API isn’t optimized for high-frequency updates. You can face this issue when trying to move to React Context internally in your package. The new context is ready to use in unlikely, infrequent updates such as localization/theme. It’s advised to use it in the same way as the old context, for static values. It is not recommended for general state management.

Here are some examples of uses in specific cases

1. We used Context in the Metrix project. Metrix is a tool for analyzing data based on demand, supply, and freight rates of the European market. The frontend queries the backend using GraphQL’s „query language,” and displays data in the form of graphs, statistics, and maps. The data is visualized through React and supports libraries like Recharts, D3, Leaflet, and OpenStreetMap. We use Context to store the ‚user’ — the login data, avatar, etc. The amount of data is small, the data must always be up-to-date so there was no need to use Redux.

2. In, our other case, we used only Redux. This project involved large quantities of data, articles, commentaries, likes, dislikes, and user data. Managing the state of such a complex app is a job for Redux.
It’s a database and a powerful maintenance tool for the front.

Will React’s Context API replace Redux?

In our opinion, it won’t. Many projects are running on Redux and no one in their right mind is going to rewrite them for React. Both solutions will exist next to each other.

If you use Redux only to avoid transferring props, Context can replace it. But if that’s the case, you didn’t need Redux in the first place. There’s nothing like Redux DevTools in Context, there’s no state update tracking, middleware for adding centralized logic or other powerful capabilities of Redux.

Context is just a mechanism for sharing values to a nested subtree of components, and not an approach to state management itself. What this means is that you have to write any state management logic you need to define the value that is transferred to the context provider. Usually it happens through the React component state, but the point is that Context itself won’t manage the state for you.

Should I choose Context or Redux?

Let’s sum it up. Redux allows the use of a third-party library so that middleware can be accessed. It’s designed for use with frequently refreshed data. There’s an active community around it. There are frequent updates.

Context is quickly implemented and offers a lower entry barrier. It’s easy to expand it, but hard to switch from Context to Redux. Context is built into React, you don’t have to install it or get any additional dependencies. You get a smaller package and better project maintenance. The API interface is also relatively simple to use, once you get a hold of it. You don’t need packages like Redux-Thunk for async actions.

Redux is just a library that can be used in JavaScript, but to be able to use it, e.g. in React, you need to integrate with React-Redux, thanks to which we will have the so-called Provider (it is also in Context-API) which will wrap the entire application and give us additional functionalities (HOC connect or useSelector hook) thanks to which we will be able to extract data from the store anywhere. It will ensure that the component only re-renders when a specific object in the store changes. Context API does not provide this and that is its biggest downside (this problem can be solved in short by using several providers, using memoization. Both involve the use of boilerplate code — but we could create a separate article about solving this issue).

So what should you choose? Context or Redux? First, estimate the size of your project or app. You don’t want to find out later that it increases in size and you have to rewrite it from Context to Redux. You need to know which data needs refreshing and how often. You need to know what your project actually is. If we work on a larger, complex endeavor, we choose Redux for global state management. If the project is smaller — Context is the way.

If you want to take your programming skills to the next level, be sure to check out “Zero to Full Stack Hero” here.

Share this article with anybody you think would benefit from this. If you have any suggestions, feel free to hit me up. I hope you enjoyed this article. If you did, make sure to let me know in the comments down below and don’t hesitate to buy me a coffee by clicking below👇!

Thank You!

Darshan mandade
(PAPA Team Writer)

Python Fullstack Developer | Blogger | Web Developer | Mentor. Let's Connect on IG: