Context vs Redux

Context vs Redux

A classic React interview question asks you to compare the built-in React Context API against external global state managers like Redux or Zustand.

Candidates often mistakenly state that “Context replaces Redux.” This is technically incorrect and demonstrates a misunderstanding of what Context actually is.

What is Context?

The React Context API is NOT a state management tool.

Context is a Dependency Injection mechanism. Its sole purpose is to “teleport” values deep down the component tree without having to manually pass them through props at every level (Prop Drilling).

Context itself does not manage state, track changes, or update values. You usually have to pair Context with the useState or useReducer hook for the data to actually be considered “state.”

The Problem with Context

When the value provided to a <Context.Provider value={value}> changes, React will instantly force every single component that consumes that context via useContext to re-render.

If you store a massive object in Context { user, theme, sidebarOpen, notifications }, and you only update sidebarOpen, every component that cares about the user or theme will still be forced to re-render.

Because of this, Context is terrible for high-frequency state updates.

When to use Context:

• Low-frequency updates that affect the whole app.
• Examples: Current Theme (Light/Dark), Current Locale/Language, Authenticated User Session.

What is Redux (or Zustand)?

Redux (and modern alternatives like Zustand) are true State Management libraries.

They maintain their own internal store outside of the React tree. Components “subscribe” to specific pieces of that store using “Selectors”.

If you update the sidebarOpen value in a Redux store, only the component that specifically selected state.sidebarOpen will re-render. The component listening to state.user will completely ignore the update.

When to use Redux/Zustand:

• High-frequency, complex state updates.
• Deeply nested, shared data that many unrelated components need to read and write.
• When you need to heavily optimize rendering performance and prevent unnecessary re-renders.

The Modern Middle Ground

Historically, developers put everything (including API data) into Redux.

Today, the standard architecture looks like this:

1. Server State (API Data): Managed by React Query or Apollo (bypasses Redux completely).
2. Local UI State: Managed by useState.
3. App-wide Settings: Managed by Context API (Theme, Language).
4. Complex Global Client State: Managed by Zustand or Redux Toolkit.

Interview Questions

Q: In a system design interview, how do you justify choosing Context over Redux for a new app?
A: Context is built-in, requires zero third-party dependencies, and is perfect for low-frequency updates like User Authentication or Theme. Redux requires significant boilerplate and bundle size, and should be strictly reserved for high-frequency, complex global state where granular re-rendering optimizations are mathematically necessary.