Blogged Answers: Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux)
utterances-bot opened this issue · comments
Blogged Answers: Why React Context is Not a "State Management" Tool (and Why It Doesn't Replace Redux) · Mark's Dev Blog
Nice write up as always, just wanted to say thanks for providing quality answers at Reactiflux!(and also first time discovering comment section...)
One thing that is not clear to me.If context is ment to be used in low frequency updates as Sebastian says, and React-Redux uses context under the hood how it overcome this pitfall and being able to deliver high frequency updates?
@gadi246 : as covered in the linked post React, Redux, and Context Behavior, the difference is that React-Redux passes down the Redux store instance via context. Individual components call store.subscribe() to listen to Redux state updates, instead of doing const reduxState = useContext(ReactReduxContext). So, it's a completely different update approach, with different behavior.
Also see my post The History and Implementation of React-Redux for details on how it works internally.
such a great post. thanks for sharing :)
Absolutely concise and explanatory! Thank you
Hello.
Can you please have a look at this lib I built: https://www.npmjs.com/package/react-simple-reducer
It uses useReducer and ContextApi together.
I'm using it in production and I'm happy about it, mostly because of the lack of boilerplate and the typescript helpers.
Many thanks for this post, detailed examples, and links to outside articles. Especially Dan Abramov's (co-author of Redux) You Might Not Need Redux post.
I wanted to suggest that codebase or team size should not inform a need for Redux. In the item listed under the TLDR; reasons you may want to use Redux:
The app has a medium or large-sized codebase, and might be worked on by many people
This is in fact a reason to focus on the most simple and clear solutions that meets the application's needs regardless of app or team size.
Thanks for the detailed article. Recently, I've tried react-query library and realized that almost all my redux data is coming from the server. Eventually, I understood that I don't need redux or any other state management library at all. It removed tons of boilerplate code and struggle. Maybe it worth mentioning in the "Choosing the Right Tool" part.
@Kontsedal: fwiw, I wasn't trying to compare Redux or Context with any other tools (ie, MobX, XState, React Query, Apollo, etc) - just Context + useReducer and Redux.
Note that we do have a new "RTK Query" library available in alpha that is basically equivalent to React Query, but built on top of Redux Toolkit. Once it's ready, the APIs will be merged back into Redux Toolkit itself. You might want to try that out and see how well it works for you.
@markerikson That a great news, thanks for sharing
Thanks for sharing
This is legendary! Thanks for your effort and the clarification
Great Post !! Thanks for sharing
thanks, i'm still starting in front-end-dev and it was very useful for me
great post. thanks for sharing. ^o^
Great post. A lot of food for thought here. Thanks for writing!
redux for the nice debug tool, a must for complex project!
This is a really great description of the two tools, but I am unsure why you are hung up on people saying "I use context for state management" knowing that they are using it in conjunction with useState or useReducer, but you easily slide past the fact that you cannot use redux by itself without additional tooling.
one of the best articles i've read recently on ANY topic - very well written, clear, accurate and concise. thank you.
You CAN use the Context API (useContext and useReducer) as a state management system, especially in smaller/solo projects. I prefer it coming from Redux Saga and React Recoil, since I can "manage values" myself and have no need for the extra features. If I did, I would lean towards using React Recoil which is also built by Facebook.
Even for larger applications there are ways you can divide the application into smaller module applications, all rendered separately on the same page, foregoing the need for monolithic redux state management anyways.
I would say for most people just trying to get a simple global state management system going, just use the Context API and work on hooking up the application with a store that has context, reducers, actions, etc. Example: https://github.com/stefanbobrowski/Template
My comment last time was deleted for what ever reason. My thinking I am tying to spam the post.
However, I wrote Redux replacement that you may be interested in trying. I won't post it here unless you are interested. Don't want to get deleted again.
This is amazing bro. thanks for everything. I understand better now
Thanks... The concept is more clearer now..
excellent article
excellent article. Cheers!
This does not cover the use case of an app that heavily data-driven and uses one of the ReactQuery or Apollo GraphQL (with react hooks) solutions.
From my experience and in my opinion, if an app uses RQ or Apollo GQL, then these are the central state management systems for the app.
Because the state is essentially the data on the backend and browser cache.
All the components hooked to the state via useQuery hooks and react to the changes in the state.
Sure there still can be some unrelated state values to be managed, but I'd argue those can be addressed by Context + useState/useReducer.
Why would the app like that need another state management solution like Redux?
And by extension, as most of the apps are essentially just like I described, why would one go with Redux instead of the ReactQuery or similar solution in the first place? Apart from being tied to react only, I don't see benefits of Redux here.
I am currently trying to understand what's market view on this and would appreciate author's opinion on this topic.
@benderillo : that's exactly the point I made in https://changelog.com/posts/when-and-when-not-to-reach-for-redux .
If the only thing you are using Redux for is caching server state, and you choose to use a different tool to manage that caching...
well then yes, you probably don't need Redux at that point because you just chose a different tool for that same use case.
as most of the apps are essentially just like I described
This is the part I would disagree with. Sure, there are plenty of CRUD apps out there, but there are many apps that aren't just basic CRUD.
Also, I'll point out that Redux Toolkit comes with RTK Query, which is a full-blown purpose built data fetching and caching solution, built on top of standard Redux patterns like thunks and reducers, and with a number of unique features (streaming updates, ability to handle fetch results in other parts of the Redux store, OpenAPI/GraphQL codegen, etc). So, it's entirely possible to use RTK Query for all the server state caching in an app, even if you don't have any other major client-side state beyond that.
If you haven't seen RTK Query yet, please see these resources:
@benderillo : that's exactly the point I made in https://changelog.com/posts/when-and-when-not-to-reach-for-redux .
If the only thing you are using Redux for is caching server state, and you choose to use a different tool to manage that caching...
well then yes, you probably don't need Redux at that point because you just chose a different tool for that same use case.
as most of the apps are essentially just like I described
This is the part I would disagree with. Sure, there are plenty of CRUD apps out there, but there are many apps that aren't just basic CRUD.
Also, I'll point out that Redux Toolkit comes with RTK Query, which is a full-blown purpose built data fetching and caching solution, built on top of standard Redux patterns like thunks and reducers, and with a number of unique features (streaming updates, ability to handle fetch results in other parts of the Redux store, OpenAPI/GraphQL codegen, etc). So, it's entirely possible to use RTK Query for all the server state caching in an app, even if you don't have any other major client-side state beyond that.
If you haven't seen RTK Query yet, please see these resources:
Thanks for the answer! Really appreciated!
Indeed, I have discovered RTK Query right after I left the comment :)
So it completes the picture for me. My conclusion then being if I am with Redux already then should be really looking into RTK Query for managing server-side state.
And when starting from scratch, if most of the state is server-side then it is a personal preference then whether going Redux Toolkit + RTK Query or Context/useReducer and React Query/SWR or whatnot.