When is Context a good state solution and when not?

Question

Accepted Answer

React's **Context API** lets you share a value with a whole component subtree without prop drilling. It's great for **low-frequency, widely-shared** data — but it's *not* a full state-management solution and has a re-render pitfall for frequently-changing state. ## When Context shines ```jsx const ThemeContext = createContext("light"); function App() { const [theme, setTheme] = useState("light"); return ( {/* any descendant can read theme — no prop drilling */} ); } ``` ```text Good fits (data that's read widely but changes rarely): ✓ Theme (dark/light) ✓ Current user / auth ✓ Locale / i18n ✓ App-wide config or feature flags ``` ## The pitfall: every consumer re-renders on ANY change ```jsx // ❌ a context value that changes often re-renders ALL consumers const AppContext = createContext(); // value = { user, cart, notifications, ...everything } // → updating ONE field re-renders EVERY component using the context ``` When the context value changes, **all** components consuming that context re-render — regardless of whether they use the part that changed. For frequently-updating state, this causes performance problems. Context has no built-in selective subscription. ## Mitigations and the alternative ```text ✓ Split into multiple focused contexts (ThemeContext, UserContext separately) ✓ Memoize the value object (useMemo) so it doesn't change identity needlessly ✗ But for high-frequency or large shared state → use a real store ``` State libraries (Zustand, Redux, Jotai) solve the re-render problem with **selective subscriptions** — components subscribe only to the slices they use and re-render only when those change: ```js const count = useStore(s => s.count); // re-renders ONLY when count changes ``` ## Context isn't a state manager ```text Context = a TRANSPORT mechanism (passes a value down), NOT state management itself. You still need useState/useReducer to hold the state; Context just distributes it. ``` ## Why it matters Knowing Context's sweet spot — and its limits — prevents two common mistakes: prop-drilling things that should be in Context, and putting high-frequency state in Context (causing app-wide re-renders). The rule: Context for **rarely-changing, widely-shared** values (theme, user, locale); a dedicated store with selective subscriptions for **frequently-changing or large** shared state. Understanding that Context distributes state but doesn't manage it clarifies when it's enough and when you need more.