When is Context enough and when do you reach for Redux? What's the Context re-render pitfall?
Architectural judgment — you built shared Redux patterns for 3+ teams at Domo.
Context is a dependency-injection mechanism, not a state manager: every consumer re-renders when the provider value changes, so it fits low-frequency global values (theme, current user, locale). Redux (or Zustand/Jotai) fits high-frequency, complex, shared state that many components read/write, where you want selectors (subscribe to a SLICE, avoiding blanket re-renders), middleware, devtools, and predictable updates. Pitfall: putting fast-changing state in Context re-renders the whole subtree — split contexts or use a selector-based store. The nuance interviewers want: Context has no built-in selector, so a consumer can't subscribe to just part of the value — any change to the provider value re-renders all consumers, full stop. Mitigations are splitting into multiple contexts (e.g. separate state and dispatch, which never changes) and memoizing the value object. Modern practice also separates SERVER state from CLIENT state: React Query / RTK Query own cache, refetch, and invalidation for anything that comes from an API, leaving Redux/Zustand for genuine client state (wizard steps, selections, optimistic UI). Given your Domo background building shared Redux patterns for multiple teams, the strongest answer frames it as: Context for injection, a selector store for cross-cutting client state, a data-fetching library for server cache — three tools, three jobs.
Context: theme/auth/i18n. Redux/store: server cache, cross-team shared domain state, anything needing selectors or middleware.
// Context re-render pitfall: value is a NEW object each render
<ThemeContext.Provider value={{ theme, setTheme }}> // re-renders all consumers
// Fix: memoize the value, or split state/dispatch into two contexts
const value = React.useMemo(() => ({ theme, setTheme }), [theme]);