Ebenezer Don Full-stack software engineer with a passion for building meaningful products that ease the lives of users.

React Hooks vs. Redux: Do Hooks and Context replace Redux?

6 min read 1953

Hooks Redux Context API

Editor’s note: This article was last updated 15 June 2022 to reflect changes made in React v18.

Redux Toolkit reduces the amount of complexity of introducing Redux into our application. However, by using the React Context API in addition to the useContext and useReducer Hooks, which were introduced in React v16.8, we can implement robust state management and avoid prop drilling without the need to import additional libraries.

At best, this makes it an imperfect solution for state management in React applications. And yet, far too many React developers default to Redux for state management without considering other alternatives.

In this tutorial, we’ll introduce you to the React Context API for state management and explain how React Hooks and the Context API can replace Redux.

We’ll cover the following:

If you’re more of a visual learner, the video below describes the React Context API and offers some reasons why you should replace Redux with React Hooks and Context.

What is state management in React?

To handle data between disconnected components in React, developers use prop drilling.

There is no global state that components can access. Therefore, if you want to pass data from a top-level component to, for instance, a fifth-level component, you’ll have to pass the data as a prop on each level of the tree until you get to your desired component.

This results in writing a ton of extra code, and giving components properties that they will never use also affects their architectural design.

To solve this problem, we need to provide a global state that all components could access, no matter how deeply nested they are.

By solving this problem, Redux, an open source JavaScript library for managing application state, became the go-to solution for React developers.

Redux vs. React Hooks and the Context API

To some extent, Redux works well for state management in React applications and has a few advantages. However, its verbosity makes it really difficult to learn, and the extra code needed to get it working can introduce a lot of unnecessary complexity.

On the other hand, with React Hooks and the useContext API, there is no need to install external libraries or add a bunch of files and folders to make our app work. This makes it a much simpler, more straightforward approach to handling global state management in React applications.

Let’s take a closer look at Redux, React Hooks, and the Context API to see how they work, what challenges developers face when using these tools, and how using React Hooks and Context can help you overcome some common issues associated with Redux.

What is Redux?

According to the Redux documentation, Redux is a predictable state container for JavaScript applications that helps us to write applications that behave consistently, run in different environments, and are easy to test.

One disadvantage of prop drilling is that it requires us to write a considerable amount of extra code to access data from a top-level component. With Redux, this disadvantage becomes more severe since it requires additional code to set up a global state. Redux requires three main building parts to function: actions, reducers, and store.


Actions are objects that are used to send data to the Redux store. They typically have two properties: a type property for describing what the action does and a payload property that contains the information that should be changed in the app state:

// action.js
const reduxAction = payload => {
  return {
    type: 'action description',

export default reduxAction;

The type is usually in all caps with its words separated by underscores. For example, SIGNUP_USER or DELETE_USER_DATA.


Reducers are pure functions that implement the action’s behavior. They take the current application state, perform an action, and then return a new state:

const reducer = (state, action) => {
  const { type, payload } = action;
    case "action type":
      return {
        ["action description"]: payload
      return state;

export default reducer;


The application’s state is housed in the store. There is only one store in any Redux application:

import { createStore } from 'redux'

const store = createStore(componentName);

Since our application can only have one Redux store, to create a single root reducer for all our components, we’ll need the combineReducers method from Redux. With the considerable amount of code required to set up Redux, imagine what our codebase would look like when we have multiple components to work with.

Even though Redux solves our state management problem, it is really time-consuming to use, has a difficult learning curve, and introduces a whole new layer of complexity to our application.

Fortunately, the React Context API solves this problem. When combined with React Hooks, we have a state management solution that is less time-consuming to set up, has an easier learning curve, and requires minimal code.

What is the React Context API?

The new Context API was introduced in React v16.3. React Context enables you to share data that can be considered global for a tree of React components, like the current authenticated user, theme, or preferred language.

According to the React documentation, Context provides a way to pass data through the component tree without having to pass props down manually at every level. Essentially, the React Context API is React’s way of managing state in multiple components that are not directly connected.

To create a context, we’ll use the createContext method from React, which accepts a parameter for its default value:

import React, {createContext} from 'react';

const newContext = createContext({ color: 'black' });

The createContext method returns an object with a Provider and a Consumer component:

const { Provider, Consumer } = newContext;

The Provider component makes the state available to all child components, no matter how deeply nested they are within the component hierarchy. The Provider component receives a value prop, which is where we’ll pass our current value:

<Provider value={color: 'blue'}>

The Consumer, as its name implies, consumes the data from the Provider without any need for prop drilling:

  {value => <span>{value}</span>}}

Without Hooks, the Context API might not seem like much when compared to Redux. But, when combined with the useReducer Hook, we have a solution that finally solves the state management problem in React.

What are React Hooks?

Hooks are a type of function that enable the execution of custom code in a base code. Hooks are essentially special functions that allow us to hook into React’s core features.

React Hooks provide an alternative to writing class-based components by allowing us to easily handle state management from functional components.

More great articles from LogRocket:

The useContext Hook

You may have noticed that when describing the React Context API, we needed to wrap our content in a Consumer component, then pass a function as a child so that we could access or consume our state.

Doing so introduces unnecessary component nesting and increases the complexity of our code. The useContext Hook makes things a lot cleaner and more straightforward. To access our state with the useContext Hook, we simply need to call it with our created context as its argument:

const newContext = React.createContext({ color: 'black' });

const value = useContext(newContext);

console.log(value); // this will return { color: 'black' }

Now, instead of wrapping our content in a Consumer component, we can simply access our state through the value variable.

The useReducer Hook

The useReducer Hook came with React v16.8. Just like the reduce() method in JavaScript, the useReducer Hook receives two values as its argument, a reducer function and an initial state. Then, it returns a new state:

const [state, dispatch] = useReducer((state, action) => {
  const { type } = action;
  switch(action) {
    case 'action description':
      const newState = // do something with the action
      return newState;
      throw new Error()
}, []);

In the code block above, we’ve defined our state and a corresponding method, dispatch, to handle it. When we call the dispatch method, the useReducer()Hook will perform an action based on the type that our method receives in its action argument:

return (
  <button onClick={() =>
    dispatch({ type: 'action type'})}>

How to use the useReducer Hook with React Context

Setting up our store

Now that we know how the Context API and the useReducer Hook work individually, let’s see what happens when we combine them to get the ideal global state management solution for our application.

We’ll create our global state in a store.js file:

// store.js
import React, {createContext, useReducer} from 'react';

const initialState = {};
const store = createContext(initialState);
const { Provider } = store;

const StateProvider = ( { children } ) => {
  const [state, dispatch] = useReducer((state, action) => {
    switch(action.type) {
      case 'action description':
        const newState = // do something with the action
        return newState;
        throw new Error();
  }, initialState);

  return <Provider value={{ state, dispatch }}>{children}</Provider>;

export { store, StateProvider }

In our store.js file, we used the createContext() method from React to create a new context.

Remember that the createContext() method returns an object with a Provider and Consumer component. This time, we’ll only use the Provider component and the useContext Hook when we need to access our state.

Notice how we used the useReducer Hook in our StateProvider. When we need to manipulate our state, we’ll call the dispatch method and pass in an object with the desired type as its argument.

In our StateProvider, we returned our Provider component with a value prop of state and dispatch from the useReducer Hook.

Accessing state globally

To access our state globally, we’ll need to wrap our root <App/>component in our StoreProvider before rendering it in our ReactDOM.render()function:

// root index.js file
import { createRoot } from "react-dom/client";
import App from './App';
import { StateProvider } from './store.js';

const rootElement = document.getElementById("root");
const root = createRoot(rootElement);

    <App />

Now, our store context can be accessed from any component in the component tree. To do so, we’ll import the useContext Hook from React and the store from our ./store.js file:

// exampleComponent.js
import React, { useContext } from 'react';
import { store } from './store.js';

const ExampleComponent = () => {
  const globalState = useContext(store);
  console.log(globalState); // this will return { color: red }

Adding and removing data from state

We’ve seen how we can access our global state. To add and remove data from our state, we’ll need the dispatch method from our store context. We only need to call the dispatch method and pass in an object with type as its parameter, the action description as defined in our StateProvider component:

// exampleComponent.js
import React, { useContext } from 'react';
import { store } from './store.js';

const ExampleComponent = () => {
  const globalState = useContext(store);
  const { dispatch } = globalState;

  dispatch({ type: 'action description' })


In this tutorial, we explored the differences between using Redux for state management in React apps and using the React Context API along with the useContext Hook and the useReducer Hook. When we use Redux for state management, we have to deal with prop drilling, meaning we have to write a lot of extra code just to get our application started. By using Context to nest components within components, all the functionality from the parent component is available in the child components.

I hope you enjoyed this article, and be sure to leave a comment if you have any questions.

Get setup with LogRocket's modern React error tracking in minutes:

  1. Visit https://logrocket.com/signup/ to get an app ID.
  2. Install LogRocket via NPM or script tag. LogRocket.init() must be called client-side, not server-side.
  3. $ npm i --save logrocket 

    // Code:

    import LogRocket from 'logrocket';
    Add to your HTML:

    <script src="https://cdn.lr-ingest.com/LogRocket.min.js"></script>
    <script>window.LogRocket && window.LogRocket.init('app/id');</script>
  4. (Optional) Install plugins for deeper integrations with your stack:
    • Redux middleware
    • ngrx middleware
    • Vuex plugin
Get started now
Ebenezer Don Full-stack software engineer with a passion for building meaningful products that ease the lives of users.

46 Replies to “React Hooks vs. Redux: Do Hooks and Context replace…”

  1. Ebenezer, this is a most excellent primer on using these relatively new technologies! For the past few months, I’ve had a steep learning curve on using Hooks and Context in the most effective way possible. Me and my colleagues now have some pretty good patterns working for us but are always trying to improve.

    Follow-up article suggestion: Show the community how to write tests for each of the entities you’ve mentioned, namely Context and Reducers. This is something I’m working through now and there doesn’t seem to be many articles on the subject.

  2. The global / lifted up state with useContext + useState/useReduce combo is possible way, but be aware about the performance problems – the whole app (down from provider lever) is re-rendered on every state change. Have a look into Hookstate – supercharged useState which allows to lift the state up to global space, is as simple as useState itself and has got incredible performance – https://github.com/avkonst/hookstate (disclaimer: I am a maintainer)

  3. Andrew, I’d like your advice on something: My colleagues and I have been having a debate about whether to have one global instance of the Context state (or Hookstate) or whether to have multiple smaller instances of the state where there is no need to share the state between different parts of an app.

    Interested in your thoughts on this!

  4. There is the best practice in software engineering: “local (more isolated) variable is better than global (more accessible)”. Applying it to react state, the most local is per component state. The next level is the state lifted up to the parent component, when multiple peer / same level components need to share access to the same state (typical case is multi-field forms). The next level is the state per root component or global state when multiple components in different branches of DOM hierarchy need access to the same state. So, lift your state up when you need it but do not open more than you need it. It will give you more maintainable software. Hookstate allows me to lift up and down easily when I need it.

    The usual practice in software engineering can be said as something like “use different variables to hold not related data”. It means it is OK to have multiple global state variables or multiple local variables. For example, I keep user account state and app settings configurable by a user in two separate variables, although both are usually global as require sharing across the whole app. Hookstate helps me with this too.

  5. Thanks, Andrew. I’ve always followed the same practice as well. This is why, for each of 3 modal forms I’ve built, each has their own Context. One downside of this is that the child forms (Add Vehicle and Add User) inside the first 2 modal forms are both used in the 3rd modal form as well. This has resulted in some duplicate code in the Contexts, Reducers, and Actions but we have definitely achieved code separation.

  6. I wonder why there is a need to pass the reducer (useReducer results).. why not just pass the functions and variables to providers vulue, so there is NO need to use dispatch function when calling state change. Use useState, and pass the results to the provider, so on the consumer components just call the function that alter the state. If there is some heavy logic before altering the state why not wrap it on function first before passing. My point is whats the benefit of calling

    dispatch(“UPDATE_USER”,true) where as you can directly call

    updateUser(true) function without the ceremony of useReducer hooks

  7. Nice article so far. I got confused by the code snippet in `Setting up our store`. Turned out the code snippet is scrollable. I noticed that by accident. Was pretty confusing..

  8. Is it just me that thinks this is the same amount of boilerplate?

    Without any of the features that make redux worth using.

  9. Great article. Apparently the only difference between the two(when trying to decide which to use), is that Redux can handle frequent state changes while Context API cannot.

  10. Nice @ how blog post completely missed that Redux is a few lines of code, uses context internally, and has dev tools + you don’t need to dumpster dive in codebases (along with time travel, a very simple pattern, middleware, consistent interfaces, selectors, immutability and much lower likelihood to miss render waste, without diving into debugger, etc). TLDR: don’t MVC or work on teams, just wing it and live in debugger/memorize all your code111

  11. I would only agree with you if it’s for a small web application not being planned to scale, otherwise I strongly disagree. You lose A LOT of things by not using Redux, not just “few advantages” as you mentioned. A lot of optimization under the hood is done by Redux through serialization & the connect HOC.

    Please read this:


  12. Agree with anon. If you end up with a store and reducer, why not use redux in the first place? With the new redux hooks API, the usage is way simpler and the boilerplate is light. Add caching to selectors and you get awesome perfs.

  13. @Ebenezer: Same question here + 1 more,

    1. How do I use this inside a class component (as by Tiago)
    2. After updating the state from inside the sub-components, the state should be returned back and GUI refreshed as well?

    -> -> -> Show Logged in as Yes or No based on a boolean in the store.

    I put a button in the Header component to update the loggedIn to true, when I click the button, the reducer gets executed properly but the Text in header (expected Logged In to change from No to Yes) does not change.

    Can you please help?



  14. Hi Shailendra, Hooks can’t be used directly in a class component, although, the React Context API can be used with class based components. Yomi did a good job explaining the React Context API with class-based examples: https://blog.logrocket.com/how-and-when-to-use-reacts-new-context-api-b584e41b2704/

    For your second question, can you confirm that you’re using the useContext Hook to access your store? Also if you could share a code snippet or screenshot, that would be helpful.

    – Ebenezer

  15. Hi Ebenezer,

    Yes, I’m using useContext in the header.js to consume the User state.

    import { Actions, store } from “../store/UserCtx”;

    const Header = () => {
    const User = useContext(store);
    const changeState = () => {
    console.log(“Changing state”, User);

    Logged in : {User.state.loggedIn?’Yes’:’No’}



  16. Is it possible to use this pattern with multiple roots? For example many mini apps in a legacy project?





    I do not believe so as each StateProvider have it’s own store that is not shared or am I wrong?

  17. Context api used badly is as bad as using global state. Re-usability goes out of the window. Cascading the props down more than one level is well known anti-pattern and should be avoided. If you use redux that way no wonder that it creates layers of complexity. And believe me so will Context API.
    Hooks (and context) are here predominantly to look after local component state. In that case you do not want to place component logic on application store as it has nothing to do with application logic. e.g. typeahead component which has relatively complex but still independent local logic and local state.

  18. Redux/Context is only needed if you want to up your game and pass props from Parent to Child rather than using regular props system to pass from Parent to nth Child. Context system will always be direct no matter how big your application is. It’s worth a shot to check it out. It is a lot more advanced. However, learning advanced methods won’t hurt. If anyone wants to check out my application where I used it in react-native here’s the link:

    To find context go to src/context and check it out how I used it with api calls.


  19. Couldn’t you just separate out useState for each instance then only rerender specific components when that specific instance of state in changed? Instance is probably the wrong word

  20. All the downsides you listed to Redux are quite elegantly solved in Redux-Toolkit. Boilerplate reduced so much it’s less LOC than a context-based solution.

    Redux isn’t overly complex. It’s the simple flux pattern. If you use the RTK you can separate out “slices” of your store just like you would in context EXCEPT you get the out-of-the box performance benefits, debugging, time travel, middleware (like sagas and thunks) and you CLEANLY separate your business logic from your UI state.

    One of the main problems I see is people approaching solutions with the idea of simplicity. That’s all well and good, if your app is truly simple. However, this is not usually the case. We build complex applications in the real world and ESPECIALLY if we don’t control the API we need a good state management solution for our business data. This is where Redux shines.

    It’s opinionated with a great architecture: flux.
    Using the Redux-Toolkit will net you LESS CODE (yes read that again) LESS CODE that a similar implementation in Context.
    AND you get debugging, time-travel, middleware, performance, etc, etc right out of the box.

    Before you write any more articles, go use the Redux Toolkit. Seriously. You need to right now if you still think that Redux is full of boilerplate. That was true a few years ago, but boy has it changed.

  21. Thanks for explaining things in clarity! 🙂

    These methods can be a good alternative, but the complexity of these codes looks like that of the React-Redux method taught in my bootcamp. For example, the code lines of useReducer look almost the same as Redux reducer, at least to a beginner like me.

    Also… Hooks are not covered in my bootcamp. Oops! >_<

  22. I have almost most of my app with context api. but as I notice the more you rely on context the more your codes are hard to manage and hard to refactor. so I prefer Redux because it make the app state scalable. but for some part of my app I prefer context api. like managing permissions or localization

  23. This is a fantastic article Ebenezer, it certainly opens up a lot of possibilities, especially around not having to rely on a 3rd party for global state management. It cemented knowledge around those specific hooks for me as well.

    I’ve got some feedback on the article:

    – You mention “The useReducer Hook came with React 16.7.0”, but according to the React official docs, it came in 16.8

    – You also mention “the useReducer Hook receives two values as its argument” which is correct, but the next sentence isn’t; “— in this case, the current state and an action”. The arguments for the useReducer hook are the reducer function and an initial state. The arguments to the reducer are the values you described.

    I found it funny and ironic that the Log Rocket plug advertises that you can “debug your Redux apps”, when this article advocates to not use Redux, lol.

    Again, thanks for writing this intellectually stimulating piece.

  24. Hi Kes, thanks for the feedback. I explained the arguments for the useReducer hooks incorrectly and the React version was probably a misinformation. The React docs is a lot richer now. I’ll ask for these to be updated.

    If I were to rewrite the entire article at the moment, I would add more of Redux advantages and why it might still be a good option with its recent updates. So, not entirely against Redux anymore.

    Thanks for taking your time to read!

  25. I tried using React Context as a global state manager and it ended badly. Context is re-rendering eveyrthing on it’s path. Long story short I had to rewrite the entire project and by doing it I saw the possibility to create my own state manager. I would really appreciate some support https://www.npmjs.com/package/store-me

    1. But why write your own state manager?

      Reinventing the wheel (and getting burned) by jumping on the “Context/Hooks is better than Redux” bandwagon should have taught you a lesson – use a proven solution, i.e. Redux, rather than saving a couple of minutes by not having to “npm install redux” and not having to set up a store and a root reducer.

      The whole “Context/Hooks is better than Redux” thing is a fad – the core concepts that you use with Context/Hooks are exactly THE SAME as what you use with Redux.

  26. The value used in the context is two completely different things. At first it’s the global state object, and then it’s an object with state and dispatch properties. That was extremely confusing.

    And to the people who say just to use Redux: you are creating your own implementation. You are gaining full control and understanding of your state flow for a few extra lines of code. It’s an extremely small price to pay.

  27. I love this article, it explains these hooks very clearly and gives very good example code.
    … but there is an accident error in the sample code snippet, which is really hard to find.

    const app = (


    the above app is assigned to a literal JSX expression, not a function component,

    the right one shoud be:

    const app = () => (


    otherwise, the ReactDom.render wont render it.


  28. REDUX SUX! There’s way too much wiring effort and repetition involved! Many people have forgotten the DRY (Don’t Repeast Yourself) principle! Do less with more!

    1. How then, please do share the wisdom with us?

      What I see here (Context/Hooks) is for all means and purposes exactly the same as what you’d do with Redux, namely:

      – define a Store
      – define a Reducer
      – define Actions
      – use “dispatch”

      and so on …

      In what way is this different or “better” than Redux then? I say it’s a fad, the emperor has no clothes, lol … let’s just establish that obvious fact, before descending into vacuous Redux-bashing.

  29. I have the same problem with this article as I have with the numerous other “Hooks and Context is better than Redux” articles: it’s misleading, and arguably not true, and I’ll explain why I think so.

    So let me quote the following blanket statement that I encountered in the article:

    “Its verbosity makes it really difficult to learn, and the extra code needed to get it working can introduce a lot of unnecessary complexity”

    That’s highly subjective, and in my opinion not true, because:

    – Redux introduces the concept of immutable state – Context and Hooks ALSO uses immutable state
    – Redux introduces Actions and Dispatch – Context and Hooks ALSO uses Actions and Dispatch
    – Redux introduces the concept of Reducers – Context and Hooks ALSO uses Reducers

    In other words, the learning curve of Redux and Context/Hooks are largely the same, because the core concepts that need to be mastered are the same!

    There are just two things that Redux requires, which Context/Hooks doesn’t: setting up the Store, and setting up the Root Reducer. Now guess what – any React dev who’s serious about using Redux should be using Redux Toolkit, and if you use Redux Toolkit then setting up the Store and the Root Reducer become trivially simple.

    Redux also seems to always get bashed for its “boiler plate” or “verbosity”. That’s also not holding water, because with Context/Hooks you’re ALSO writing these “verbose” actions and reducers – same same … and, guess what (here we go again) – if you use Redux with Redux Toolkit you can cut out the largest part of that boiler plate. Does Context/Hooks come with similar tooling?

    Finally, there’s a big risk with Context/Hooks – if not implemented correctly, it can result in unnecessary component re-renders. Redux comes with a “connect” function which is highly optimized in preventing unnecessary component re-renders, and reproducing this same functionality with Context/Hooks is not a simple thing to do.

    So to summarize, my “contrary” advice in case you have an app that’s a bit more than tiny and trivial, and which needs global state management, then don’t try to reinvent the wheel, just go with Redux from the start, because:

    – the three core concepts are identical anyway (hence 90% of the learning curve is identical)
    – works out of the box, no need to waste time reinventing the wheel
    – optimized to prevent unnecessary component re-renders
    – Redux Toolkit cuts out most of the boilerplate (which you’d have with Context/Hooks as well anyway)

    And finally – suppose you start with Context/Hooks because it’s “simple” (at least they make you believe so), and as your app grows you find that you’d really be served better by Redux – now you need to rewrite a lot of code … not necessary if you just install Redux right away (and use it in virtually the same way as you would with Context/Hooks).

  30. Do not use context API as state management. It is very poor with performance and very verbose. The issue with hooks are the following:
    – It is verbose, you need to wrap every component under the context provider
    – If you wrap the root app then any change in state re-renders the entire react tree
    – ever change to the context will make any component wrapped to re-render

    Context is not meant for state management. If you try to use it as such, at the moment you apps start having some more complex iterations, and 2-3 level nested component that need states, you will find the need to replace it.
    To date the best library for state management, in my experience, is redux for react.

  31. “react-context-slices” solves once for all the problem of state management with Context API. It allows you to define slices of Context. In this way only components consuming the state value of a slice will update. And it’s 0 boilerplate/verbose.

Leave a Reply