There's also a big piece that people who see useContext/useReducer as a replacement for Redux usually miss: server side rendering.
The Redux store lives outside of the React component tree and has a getState() method to capture the state of the store and deliver in the SSR payload. With useContext/useReducer, the state lives in the lifecycle of a top-level component. Unless you build something equivalent to Redux's store anyway, you're not going to be able to easily get a snapshot of its state out of that component. Unless, I suppose, that component itself knows to put its own payload in a <script> tag in its render() on the server only (in which case you'd still get a hydration mismatch).
It's important to note that there _are_ differences in how `useContext+useReducer` behave vs how (React-)Redux works, especially around when and how components will re-render:
That's fine, you can use React's Context API and reducers just like Redux, for which the useContext and useReducer hooks exist. Then it's just like Redux, inject a Provider and Consumer and you're good to go.
I see people ask on a literal daily basis "does Context replace Redux?". So, I was trying to make a few points in that post, mostly clarifying common misconceptions, because the question itself is rooted in some major misunderstandings about what these tools even _do_ in the first place:
- that Context doesn't "manage" anything by itself, and definitely not "state"
- That there are significant technical differences between the combo of `useReducer` + `useContext` and Redux/React-Redux, in terms of render performance, data access, and usage patterns.
- That this means there are also different use cases for those tools as well.
I wouldn't use Redux to maintain state for a form or isolated chunk of the app, I'd use context + `useReducer`. On the flip side, if I do have "global" state, I would pretty quickly switch over to putting it in Redux instead.
I find that using Context+useReducer is similar, but in the end you wind up with a lot of useContext and/or overlapping usage of different context/providers that the general single redux context is often better overall. Not to mention, that you still have to deal with the action generation and state in the scope of context, which gets even more messy with different Context usage in practice.
At least that's been my own experience. I don't fault people for going different routes, I just find that the boilerplate kind of fades into the background after it's established.
Came here for this. When the author made me realize that a lot of our global state is just a client side cache of our server side state and we can apply a longstanding http caching standard (SWR) to manage it, it was as big of an aha moment for me as when I was originally introduced to redux.
Speaking of redux, I'm a huge fan but React ships with a useReducer hook now - thanks in no small part, I'm sure, to the author of redux working on the react core team.
These days, I'm all about reactQuery + react's native useReducer via the hooks and context api. described beautifully by Kent Dodds here: https://kentcdodds.com/blog/how-to-use-react-context-effecti...
I feel like these state management libraries have largely served their purpose in establishing some agreed upon conventions that are now just baked in to React and other libs.
Context is a useful tool, but its only purpose is to make value accessible to deeply nested components. It's not even a state management tool - you have to manage whatever state you want to put into that context, by yourself.
The useState and useReducer hooks start to resemble Redux a bit more when used together with context, but they definitely do not replace Redux.
The implication behind “we don’t use Redux, we use hooks” is that they’re using React’s Context API directly as a “store”. A component at the top level has some state, probably using the useReducer hook, that state is passed down using a Context Provider, and child components can access the data with useContext.
You can DIY a Redux imitation with hooks pretty easily but making it as performant as Redux is harder.
With the useReducer hook a lot of these differences have gone away. The important difference is that redux will use global state. It's use of the Context API makes components less portable.
Redux has it's place, I think it's structure can be nice at times, but you pay for it. This app is not anywhere near the size where I would consider using Redux though.
> Most rendering is outside the scope of state management and it doesn't matter whether you use providers or redux to manage it.
It does matter - a Context at the top of your app will trigger a full re-render on every change. Redux and other state management solutions specifically avoid using Context, and the new React 18 useSyncExternalStore hook was added for this very reason.
Thanks for sharing. I think you touch on some of the more powerful features of Redux (middleware, selectors, pass by reference instead of value, etc.)
But IMHO a lot of that is overkill when your only goal is global state. Context solves that problem very nicely (in conjunction with state and reducer, yes, but context is the big piece there). Prop drilling was a major hurdle to global state management. But redux introduces its own overhead (Flux architecture, actions and dispatches, etc.) that are unnecessarily complicated for simple state sharing.
I feel like the article spends a lot of time differentiating the specifics of use Context vs state vs reducers, but it kinda misses the bigger point... that using those is often enough and can remove redux, leaving you with more readable and less overengineered code. Redux might be the right choice for really complex states, but it's a pain to work with day to day. Context makes it super simple by comparison.
You can hoist useReducer out to context and end up with essentially a very lightweight redux. I’ve had some success with that in smaller apps. For something large or long term I’d probably avoid that approach though.
"If you're only using Redux to avoid passing down props, context could replace Redux - but then you probably didn't need Redux in the first place. Context also doesn't give you anything like the Redux DevTools, the ability to trace your state updates, middleware to add centralized application logic, and other powerful capabilities that Redux enables."
These days in reactland, you can easily get app-wide state using useContext (which is much MUCH simpler to work with than Redux). It's just a global store (well, or you can limit it to a certain part of the tree) that any child or sibling can read/write to at will.
But just like you said, it can be a footgun if you're not careful.
I feel this is because many people confuse Redux (or flux) with React itself.
Or the more general problem of not knowing the difference between store state, local component state, and component instance state (the actual JS object's properties.)
The new Unstated library leveraging the next Context API is a nice balance I find for state management. It basically just mirrors Reacts setState style update system. Although you do lose the single source of truth pro of Redux.
I don't like how this article moves the goal posts of whether redux fits our use case or not. It has some valid arguments (dev tools) but the overhead of the boilerplate and tooling around redux is just not worth it IMO.
Much better to break your app state into various custom hooks that leverage Context API and the `useReducer` hook.
The Redux store lives outside of the React component tree and has a getState() method to capture the state of the store and deliver in the SSR payload. With useContext/useReducer, the state lives in the lifecycle of a top-level component. Unless you build something equivalent to Redux's store anyway, you're not going to be able to easily get a snapshot of its state out of that component. Unless, I suppose, that component itself knows to put its own payload in a <script> tag in its render() on the server only (in which case you'd still get a hydration mismatch).
reply