React Context API — Complete Interview Guide

The Problem: Prop Drilling

Prop drilling happens when a piece of data needs to reach a deeply nested component, so you pass it as a prop through every layer in between — even layers that don't use it at all:

// App passes 'user' down through Layout → Sidebar → UserMenu
// Layout and Sidebar don't need user — they just relay it
function App() {
  const user = useAuth();
  return <Layout user={user} />;
}
function Layout({ user }) {
  return <Sidebar user={user} />;
}
function Sidebar({ user }) {
  return <UserMenu user={user} />;
}
function UserMenu({ user }) {
  return <span>{user.name}</span>; // finally used here
}

This is fragile — every intermediate component must be aware of data it doesn't care about. Context eliminates the middlemen.

Creating and Providing Context

// 1. Create the context — the argument is the default value
// (used only when a component has no Provider above it)
const UserContext = React.createContext(null);

// 2. Provide the value — any descendant can now read it
function App() {
  const user = useAuth();
  return (
    <UserContext.Provider value={user}>
      <Layout />    {/* no prop drilling — Layout doesn't receive user */}
    </UserContext.Provider>
  );
}

Consuming Context with useContext

// 3. Any descendant reads it directly
function UserMenu() {
  const user = useContext(UserContext); // zero props passed down
  return <span>{user.name}</span>;
}

The component subscribes to the context. Whenever the Provider's value changes, UserMenu re-renders automatically.

The Re-render Behaviour — The Most Important Thing to Understand

This is the most common source of performance bugs with Context. Every component that calls useContext(MyContext) re-renders whenever the context value changes — even if the specific data it uses didn't change.

// ❌ Performance trap: a new object is created on every App render
// Every consumer re-renders even if user and theme haven't changed
function App() {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');
  return (
    <AppContext.Provider value={{ user, theme, setUser, setTheme }}>
      <Everything />
    </AppContext.Provider>
  );
}

The value prop creates a new object every render, so every consumer thinks the context changed — even if user and theme are identical. React uses Object.is to compare context values.

Fix: Memoize the context value

// ✅ Stable object reference — consumers only re-render when user or theme changes
function App() {
  const [user, setUser] = useState(null);
  const [theme, setTheme] = useState('light');
  const value = useMemo(() => ({ user, theme, setUser, setTheme }), [user, theme]);
  return (
    <AppContext.Provider value={value}>
      <Everything />
    </AppContext.Provider>
  );
}

Better fix: Split contexts by update frequency

// Split frequently-changing from rarely-changing values
// Components that only need theme don't re-render when user changes
<UserContext.Provider value={user}>
  <ThemeContext.Provider value={theme}>
    <Everything />
  </ThemeContext.Provider>
</UserContext.Provider>

Context vs Redux / Zustand — When to Use Each

Context is often misused as a replacement for a state management library. They serve different purposes:

• Context — great for stable, rarely-changing ambient data that many components read: current user, theme, locale, feature flags. Every consumer re-renders on any change, so frequent updates hurt performance.
• Redux / Zustand — great for frequently-changing, complex global state. External stores allow components to subscribe to specific slices — a component watching cart.total doesn't re-render when user.preferences changes. They also come with devtools, time-travel debugging, and middleware.

Context is not a state management library — it's a dependency injection mechanism. The question is not "Context or Redux?" but "how often does this value change and how many components subscribe to it?"

The Default Value Trap

The default value passed to createContext(defaultValue) is used only when a component calls useContext with no matching Provider above it in the tree. It is not the initial value of the Provider. This trips up many developers:

const ThemeContext = React.createContext('light'); // default = 'light'

// This component uses 'light' because there's no Provider above it
function Orphan() {
  const theme = useContext(ThemeContext); // 'light'
  return <div>{theme}</div>;
}

// But this gets 'dark' from the Provider — the createContext default is ignored
function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Orphan /> {/* gets 'dark', not 'light' */}
    </ThemeContext.Provider>
  );
}