Context Re-render Lab
Compare a naive context provider with a colocated, split-context version and count the wasted renders.
What you'll learn
- Observe every consumer re-rendering on a single value change
- Apply context splitting and state colocation
Interactive laboratory
Controls
Counters are real React rendersComponent tree
one provider · action #0Header
UserDisplay · Render #1
user = ada · last rendered during action #0
ThemePanel
ThemeDisplay · Render #1
theme = dark · last rendered during action #0
NotificationPanel
NotificationDisplay · Render #1
count = 0 · last rendered during action #0
Counters reset when the strategy changes, because the subtree is remounted. In development React StrictMode renders components twice, so counts move in steps of two; the ratio between strategies is what matters.
- Total renders
- 0
- User / Theme
- 0 / 0
- Notifications
- 0
- Off-domain renders
- 0
What happened?
Run an action to record renders. The structural nodes (Header, ThemePanel, NotificationPanel) are memoized, so only context consumers can re-render.
With one provider, the value object is recreated on every state change, so every consumer of that context re-renders - even the ones reading an unchanged field.
Switch strategy and repeat the same actions to compare.
Why it happened
Any change to a context value re-renders every consumer, regardless of which field changed.
The fix is structural: colocate state, or split contexts by update frequency.
Key takeaways
- Context is a broadcast, not a subscription with selectors
- Splitting state by change frequency removes most wasted work
Tags
- react
- context
- state colocation