> Don't use Context, unless it's literally for if the user is logged in. Everything else should use some kind of 3rd party library (Mobx, Redux, Recoil, Zustand) that uses subscriptions to circumvent React's extremely slow and outdated way of rendering. Alternative: Use react-query for most date fetching / global state.
Most rendering is outside the scope of state management and it doesn't matter whether you use providers or redux to manage it.
Personally I find the hooks for context a MILLION times easier to work with than redux was. Redux has introduced a lot of unnecessary complexity to several apps I've worked with. There was a time when it was the best choice but no longer, in my opinion.
> Decoupling logic from components: 100% never do this. Ever.
Disagree. "Dumb" components are often ideal and work great with testing libraries.
Just to check, have you had a chance to try out Redux Toolkit? We specifically designed it to eliminate the previous "boilerplate" concerns with legacy Redux patterns:
If other options do work better for you, great! I've just seen that many people's opinions of Redux are based on outdated info that doesn't match how "modern Redux" looks and is used today.
Acemarke, I know you're fighting the good fight with Redux Toolkit. I personally use it for truly global state with React Native. It's unfortunate the Redux name has a bad connotation for some as RTK is really good. And for some reason Context became something that developers thought was actually usable. Not sure what happened.
Eh, there was entirely valid reasons for the backlash :)
Redux _was_ overused in the first couple years. The original patterns _were_ very boilerplate-y. There _are_ a lot of other good tools for varying use cases that overlap with things that people have used Redux for: Context for prop drilling, React Query / Apollo for data fetching, Zustand/Jotai/Mobx/five-million-other-libs for state management.
Redux will never be the "must use this" lib again the way it was there for a couple years.
And that's a _good_ thing, because folks should take time to think about what problems they actually need to solve in their apps and pick the tools that work best for those problems.
But it's also true that Redux _is_ still a useful tool, and that RTK has addressed the pain points in using Redux. So, still very much a viable choice today, and the positive feedback we get on RTK daily shows that.
Really, the bigger issue today is that a lot of folks don't seem to understand the technical differences, tradeoffs, and intended use cases between a lot of these tools.
I wrote an extensive post describing the differences between Context and Redux to try to help with that:
I've also been trying to start up a community-driven site to list common tools for various use cases (state management, styling, build tools, data fetching, etc), to act as a resource to help clarify this sort of confusion:
Sadly I haven't had time to push it forward myself due to all the other responsibilities and tasks on my todo list, but hopefully at some point we can get enough info filled in for it to be a real resources that we can point people to.
No, RTK is a wrapper around just Redux patterns, not React.
- store setup: `configureStore` creates a store with a good default config in one function call
- Reducers: `createSlice` lets you define case reducers as functions in an object, write "mutating" syntax for immutable updates with Immer, and auto-generates the action creators for each reducer
- Data fetching: `createAsyncThunk` abstracts the standard "dispatch actions before and after an async request" pattern
- RTK Query: completely abstracts the _entire_ data fetching and caching process, adds cache entry lifecycles, auto-generates React hooks for use in components
The only React-related bits in RTK are the auto-generated React hooks for RTK Query endpoints. Everything else is "here's all the same kinds of logic you've always written for Redux, but with 1/4 the code and good default behaviors".
> 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.
As I understand it, only components that read from context render when state changes. If you want/need more granular control, you have Memo at your fingertips.
Further, the entire point of global state is you only put the stuff in there that might actually require child components get re rendered. If you're shoving everything into global state or using context when you don't need it you're doing a lot of things wrong and it's likely you'd abuse redux as well.
People use context as a global data store which is fine if you limit global data to "things that a lot of components need to read, but very few get to write to" which is what it should be. Dark mode preferences are the canonical example.
Global state is the road to insanity in ant react app. Prefer props in all cases.
Most rendering is outside the scope of state management and it doesn't matter whether you use providers or redux to manage it.
Personally I find the hooks for context a MILLION times easier to work with than redux was. Redux has introduced a lot of unnecessary complexity to several apps I've worked with. There was a time when it was the best choice but no longer, in my opinion.
> Decoupling logic from components: 100% never do this. Ever.
Disagree. "Dumb" components are often ideal and work great with testing libraries.