2023-06-23
2576
#react#redux
Ebenezer Don
10305
Jun 23, 2023 ⋅ 9 min read

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

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

Recent posts:

Using CRDTs To Build Collaborative Rust Web Applications

Using CRDTs to build collaborative Rust web applications

CRDTs, or conflict-free replicated data types, is a concept that underlies applications facing the issue of data replication across a […]

Mario Zupan
Feb 23, 2024 ⋅ 15 min read
Guide to Using TensorFlow in Rust

Guide to using TensorFlow in Rust

We explore the fusion of TensorFlow and Rust, delving into how we can integrate these two technologies to build and train a neural network.

Rosario De Chiara
Feb 22, 2024 ⋅ 8 min read
Using Signaldb With React

Using SignalDB with React: A complete guide

SignalDB enables automatic data synchronization between your components and a local in-memory or persistent database.

Antonello Zanini
Feb 20, 2024 ⋅ 6 min read
Guide To Next Js Layouts And Nested Layouts

A guide to Next.js layouts and nested layouts

Understanding how layouts, nested layouts, and custom layouts work in Next.js is crucial for building complex, user-friendly projects.

Ibadehin Mojeed
Feb 19, 2024 ⋅ 12 min read
View all posts

48 Replies to "React Hooks vs. Redux: Do Hooks and Context replace Redux?"

  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:

    https://blog.isquaredsoftware.com/2018/03/redux-not-dead-yet/
    https://www.reddit.com/r/reactjs/comments/bqf5ot/can_anyone_tell_me_why_hooks_have_exploded/eo6fe6e/?context=10000

  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?

    Regards,

    SG

  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);
    dispatch(Actions.LOGIN);
    };
    ….
    ….

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

    Cheers!

    SG

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

    ReactDOM.render(

    ,
    document.getElementById(‘component’)
    );

    ReactDOM.render(

    ,
    document.getElementById(‘anotherComponent’)
    );

    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.

    https://github.com/graysonm23/Native-Blog

  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.

    FYI.

  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.

  32. lol, useReducer + Context = Redux Lite
    why should i swap redux for an inferior version of itself?

Leave a Reply