Ask: who re-renders when this changes?
Estimated time: about 6 minutes
Context, Redux, Zustand, and other tools differ less by “global versus local” than by how they distribute updates and how precisely consumers can subscribe.
Context is a delivery mechanism
Context lets a component read a value from a distant parent without threading props through every intermediate component. Context itself does not define reducers, caching, persistence, or business rules.
React’s useContext documentation explains that consumers update when the provider supplies a changed value.
The common performance trap
A single context contains user, theme, notifications, and preferences. A notification changes, and a large subtree observes the changed context value. The first response should not be “add memo everywhere.” Ask whether one context contains values with unrelated change frequencies.
Better designs
Split contexts
Keep authentication, theme, and rapidly changing notifications separate when their consumers differ.
Keep state near consumers
Do not lift state to the app root just because it might be shared someday.
Use selectors
An external store can let a component subscribe to a slice rather than the entire store.
Measure
Use React DevTools Profiler to confirm the actual render cost before optimizing.
Context versus an external store
| Question | Context | External store |
|---|---|---|
| Primary job | Tree-wide value delivery | Shared state and subscriptions |
| Best fit | Theme, locale, auth dependencies | Broad client state and fine-grained subscriptions |
| Main risk | Overly broad updates and hidden dependencies | Global mutable complexity and unclear ownership |
Interview scenario
A dashboard has a theme, current user, live notifications, and a large data grid. The team puts all four into one Context. Changing a notification causes the grid to re-render.
Senior response: separate concerns first; keep grid data in an appropriate server-state/cache layer; split or localize contexts; then profile. Use a selector-based external store only if the measured subscription problem justifies it.
Retrieval challenge
Choose the strongest first move:
- All components re-render whenever the theme changes.
- A component consumes user name but updates whenever a large preferences object changes.
- Developers want Context because “we need global state.”
- A store has hundreds of fields and every component subscribes to the whole object.
- Profile first; then check whether the context is too broad or the provider value changes unnecessarily.
- Split the context or expose a narrower value/selector.
- Ask what kind of state it is and who needs it. Context may solve delivery, but not every state problem.
- Introduce selectors or narrower subscriptions and organize the store by domain; verify with profiling.
Interview-ready answer
“Context is good for distributing relatively stable cross-cutting dependencies. For frequently changing shared state, I care about subscription granularity. I’d split contexts or use selectors in an external store if profiling shows unnecessary work. I would not optimize by default or use a global store before establishing ownership and measuring the render cost.”
Primary reading
Read React’s useContext reference, especially the caveats about changed values and object identity.
Next lesson: Redux Toolkit, Zustand, atoms, and how to compare libraries without turning the interview into a popularity contest.