Tapajyoti Bose

Posted on Nov 28, 2021 • Updated on Jun 26, 2022

Redux vs Context API: When to use them

#webdev #javascript #react #redux

The simplest way to pass data from a parent to a child in a React Application is by passing it on to the child's props. But an issue arises when a deeply nested child requires data from a component higher up in the tree. If we pass on the data through the props, every single one of the children would be required to accept the data and pass it on to its child, leading to prop drilling, a terrible practice in the world of React.

To solve the prop drilling issue, we have State Management Solutions like Context API and Redux. But which one of them is best suited for your application? Today we are going to answer this age-old question!

What is the Context API?

Let's check the official documentation:

In a typical React application, data is passed top-down (parent to child) via props, but such usage can be cumbersome for certain types of props (e.g. locale preference, UI theme) that are required by many components within an application. Context provides a way to share values like these between components without having to explicitly pass a prop through every level of the tree.

Context API is a built-in React tool that does not influence the final bundle size, and is integrated by design.

To use the Context API, you have to:

Create the Context

const Context = createContext(MockData);

Create a Provider for the Context

const Parent = () => {
    return (
        <Context.Provider value={initialValue}>
            <Children/>
        </Context.Provider>
    )
}

Consume the data in the Context

const Child = () => {
    const contextData = useContext(Context);
    // use the data
    // ...
}

So What is Redux?

Of course, let's head over to the documentation:

Redux is a predictable state container for JavaScript apps.

It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. On top of that, it provides a great developer experience, such as live code editing combined with a time-traveling debugger.

You can use Redux together with React, or with any other view library. It is tiny (2kB, including dependencies), but has a large ecosystem of addons available.

Redux is an Open Source Library which provides a central store, and actions to modify the store. It can be used with any project using JavaScript or TypeScript, but since we are comparing it to Context API, so we will stick to React-based Applications.

To use Redux you need to:

Create a Reducer

import { createSlice } from "@reduxjs/toolkit";

export const slice = createSlice({
    name: "slice-name",
    initialState: {
        // ...
    },
    reducers: {
        func01: (state) => {
            // ...
        },
    }
});

export const { func01 } = slice.actions;
export default slice.reducer;

Configure the Store

import { configureStore } from "@reduxjs/toolkit";
import reducer from "./reducer";

export default configureStore({
    reducer: {
        reducer: reducer
    }
});

Make the Store available for data consumption

import React from 'react';
import ReactDOM from 'react-dom';
import { Provider } from 'react-redux';
import App from './App.jsx'
import store from './store';

ReactDOM.render(
    <Provider store={store}>
        <App />
    </Provider>,
    document.getElementById("root")
);

Use State or Dispatch Actions

import { useSelector, useDispatch } from 'react-redux';
import { func01 } from './redux/reducer';

const Component = () => {
    const reducerState = useSelector((state) => state.reducer);
    const dispatch = useDispatch();
    const doSomething = () = > dispatch(func01)  
    return (
        <>
            {/* ... */}
        </>
    );
}
export default Component;

That's all Phew! As you can see, Redux requires way more work to get it set up.

Comparing Redux & Context API

Context API	Redux
Built-in tool that ships with React	Additional installation Required, driving up the final bundle size
Requires minimal Setup	Requires extensive setup to integrate it with a React Application
Specifically designed for static data, that is not often refreshed or updated	Works like a charm with both static and dynamic data
Adding new contexts requires creation from scratch	Easily extendible due to the ease of adding new data/actions after the initial setup
Debugging can be hard in highly nested React Component Structure even with Dev Tool	Incredibly powerful Redux Dev Tools to ease debugging
UI logic and State Management Logic are in the same component	Better code organization with separate UI logic and State Management Logic

From the table, you must be able to comprehend where the popular opinion Redux is for large projects & Context API for small ones come from.

Both are excellent tools for their own specific niche, Redux is overkill just to pass data from parent to child & Context API truly shines in this case. When you have a lot of dynamic data Redux got your back!

So you no longer have to that guy who goes:

Wrapping Up

In this article, we went through what is Redux and Context API and their differences. We learned, Context API is a light-weight solution which is more suited for passing data from a parent to a deeply nested child and Redux is a more robust State Management solution.

Happy Developing!

Research says, writing down your goals on pen & paper makes you 21% to 39% more likely to achieve them. Check out these notebooks and journals to make the journey of achieving your dreams easier: https://www.amazon.com/Tapajyoti-Bose/e/B09VGDDHRR

Thanks for reading

Need a Top Rated Front-End Development Freelancer? Contact me on Upwork

Want to see what I am working on? Check out my GitHub

I am a freelancer who will start off as a Digital Nomad in mid-2022. Want to catch the journey? Follow me on Instagram

Follow my blogs for Weekly new Tidbits on Dev

FAQ

These are a few commonly asked questions I get. So, I hope this FAQ section solves your issues.

I am a beginner, how should I learn Front-End Web Dev?
Look into the following articles:
1. Front End Development Roadmap
2. Front End Project Ideas
Would you mentor me?

Sorry, I am already under a lot of workload and would not have the time to mentor anyone.
Would you like to collaborate on our site?

As mentioned in the previous question, I am in a time crunch, so I would have to pass on such opportunities.

Connect to me on

Top comments (29)

Lenz Weber • Nov 28 '21

You are referring to a style of Redux there that is not the recommended style of writing Redux for over two years now. Modern Redux looks very differently and is about 1/4 of the code. It does not use switch..case reducers, ACTION_TYPES or createStore and is a lot easier to set up than what you are used to.

I'd highly recommend going through the official Redux tutorial and maybe updating this article afterwards.

Tapajyoti Bose • Nov 28 '21 • Edited

Thanks for pointing it out, please take a look now

Its great to have one of the creators of Redux reviewing my article!

Lenz Weber • Nov 28 '21

Now the Redux portion looks okay for me - as for the comparison, I'd still say it doesn't 100% stand as the two examples just do very different things - the Context example only takes initialValue from somewhere and passes it down the tree, but you don't even have code to change that value ever in the future.

So if you add code for that (and also pass down an option to change that data), you will probably already here get to a point where the Context is already more code than the Redux solution.

Tapajyoti Bose • Nov 28 '21

I'm not entirely sure whether I agree on this point. Using context with data update would only take 4 more lines:

Function in Mock data
useState in the Parent
Update handler in initialValue
Using the update handler in the Child

Lenz Weber • Nov 28 '21

In the end, it usually ends up as quite some more code - see kentcdodds.com/blog/how-to-use-rea... for example.

But just taking your examples side by side:

Usage in the component is pretty much the same amount of code.
In both cases you need to wrap the app in a Provider (you forgot that in the context examples above)
creating a slice and creating the Provider wrapper pretty much abstract the same logic - but in a slice, you can use mutating logic, so as soon as you get to more complex data manipulation, the slice will be significantly shorter

That in the end leaves the configureStore call - and that are three lines. You will probably save more code by using createSlice vs manually writing a Provider.

Tapajyoti Bose • Nov 29 '21

But I had added the Provider in the Context example 😐

You are talking about using useReducer hook with the Context API. I am suggesting that if one is required to modify the data, one should definitely opt for Redux. In case only sharing the data with the Child Components is required, Context would be a better solution

Lenz Weber • Nov 29 '21

Yeah, but you are not using the Parent anywhere, which is kinda equivalent to using the Provider in Redux, kinda making it look like one step less for Context ;)

As for the "not using useReducer" - seems like I read over that - in that case I 100% agree. :)

Mangor1no • Nov 29 '21

I myself really don't like using redux toolkit. Feel like I have more control when using the old way

Lenz Weber • Nov 29 '21

Which part of it exactly is taking control away?

Oh, btw.: if it is only one of those "I need the control only 10% of the time" cases - you can always mix both styles. RTK is just Redux, there is absolutely no magic going on that would prevent a mix of RTK reducers and hand-written reducers.

Philipp Renoth • Nov 30 '21 • Edited

Referring to your example, I can write a blog post, too:

Context API vs. ES6 import

Context API is too complicated. I can simply import MockData from './mockData' and use it in any component. Context API has 10 lines, import only 1 line.

Then you can write another blog post Redux vs. ES6 import.

There are maybe projects which

need to mutate data
want smart component updates
want time-travel for debugging
want a solid plugin concept for global state management

And then there are devs reading blogs about using redux is too complicated and end up introducing their own concepts and ideas around the Context API without knowing one thing about immutable data optimizations and so on.

You can use a react context to solve problems that are also being solved by redux, but some features and optimizations are not that easy for homegrown solutions. I mean try it out - it's a great exercise to understand why you should maybe use redux in your production code or stick to a simpler solution that has less features at all.

I'm not saying, that you should use redux in every project, but redux is not just some stupid boilerplate around the Context API => if you need global state utils check out the libs built for it. There are also others than redux.

adam-biggs • Oct 27 '22

One of the best and most overlooked alternatives to Redux is to use React's own built-in Context API.

Context API provides a different approach to tackling the data flow problem between React’s deeply nested components. Context has been around with React for quite a while, but it has changed significantly since its inception. Up to version 16.3, it was a way to handle the state data outside the React component tree. It was an experimental feature not recommended for most use cases.

Initially, the problem with legacy context was that updates to values that were passed down with context could be “blocked” if a component skipped rendering through the shouldComponentUpdate lifecycle method. Since many components relied on shouldComponentUpdate for performance optimizations, the legacy context was useless for passing down plain data.

The new version of Context API is a dependency injection mechanism that allows passing data through the component tree without having to pass props down manually at every level.

The most important thing here is that, unlike Redux, Context API is not a state management system. Instead, it’s a dependency injection mechanism where you manage a state in a React component. We get a state management system when using it with useContext and useReducer hooks.

A great next step to learning more is to read this article by Andy Fernandez: scalablepath.com/react/context-api...

node.js.developers.kh • May 29

Can you give me some explanation to what you meant when you wrote Context is DI.

Nishant Tilve • Nov 28 '21

Also, if you need to maintain some sort of complex state for any mid-level project, you can still create your own reducer using React's Context API itself, before reaching out for redux and adding external dependencies to your project initially.

Kayeeec • Mar 30 '22 • Edited

But you might take a performance hit. Redux seems to be better performance-wise when you intend to update the shared data a lot - see stackoverflow.com/a/66972857/7677851.

If used correctly that is.

Andrew Baisden • Dec 4 '21

Redux used to be my first choice for large applications but these days I much prefer to use the Context API. Still good to know Redux though just in case and many projects and companies still require you to know it.

roggc • Jun 8

Hello, I have developed a library, react-context-slices which allows to manage state through Context easily and quickly. It has 0 boilerplate. You can define slices of Context and fetch them with a unique hook, useSlice, which acts either as a useState or useReducer hook, depending on if you defined a reducer or not for the slice of Context you are fetching.

Lohit Peesapati • Nov 28 '21

I found Redux to be easier to setup and work with than Context API. I migrated a library I was building in Redux to context API and reused most of the reducer logic, but the amount of optimization and debugging I had to do to make the same functionality work was a nightmare in Context. It made me appreciate Redux more and I switched back to save time. It was a good learning to know the specific use case and limitations of context.

Tapajyoti Bose • Nov 28 '21

I too am a huge fan of redux for most projects!

lijian • Nov 30 '21

I hate redux, It is very complicated

Aral Roca • Dec 1 '21

Try Teaful github.com/teafuljs/teaful 😊

Sayanta Bhattacharje • Jun 5 • Edited

I think Redux plays a big role when you need to develop a complex application, that requires to integrate features that have a lot of states or in our case actions. One might argue that we can use useReducer apis inside a context to handle the long and nested states, updating them when particular actions are performed, but then just like reinventing the wheel we are developing something like redux only. What I understand is both are two different ways of using the context and reducer features that React provides, we can choose which one to use.

But when there is the case of fetching data from server, I think the latest RTK (Redux Toolkit) is very far ahead as it gives a solution to integrate apis, and render data into state, which in case of context apis, we have to manually integrate it

Scott Cosentino • Sep 8 '22

There are some great benefits to using Context API. Context API works best for small projects, where large amounts of debugging isn't required. Our developers broke down a few specific use cases where Context API is the better choice.

nlaitan • Feb 11 '22

Context: Specifically designed for static data, that is not often refreshed or updated.
Redux: Works like a charm with both static and dynamic data.

I've working on a complex project only with context, I didn't see this point. Simply using getters and setters (it's the same thing that use useState) in context do all the work. Integrates very well with hooks and custom hooks and also easy to read.

Can you explain why redux it's better at this point?