Lesson 7 of 80

Context

Q: What problem does React Context actually solve, and what's the real performance tradeoff of using it?

A strong answer covers: Solves prop drilling — a value is read by any descendant without threading it through every intermediate component; Every component calling useContext for a given context re-renders whenever that context's value reference changes, regardless of which part of the value it reads; Splitting one large context into several narrower ones limits which consumers re-render on a given change.

How a value gets read by any descendant without threading it through every component in between — and the re-render cost that comes with it.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 4

What's the closest vanilla-JS equivalent to "a value read via Context, without being explicitly passed down"?

A value exported from a shared module that any file can import directlyA value passed as a parameter through every intermediate functionA value only accessible through the browser's global window object

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Context

What interviewers actually ask about this, and what a strong answer has to cover.

What problem does React Context actually solve, and what's the real performance tradeoff of using it?

A strong answer covers

Solves prop drilling — a value is read by any descendant without threading it through every intermediate component
Every component calling useContext for a given context re-renders whenever that context's value reference changes, regardless of which part of the value it reads
Splitting one large context into several narrower ones limits which consumers re-render on a given change

Likely follow-ups

If the Provider's value is a new object literal built inline on every render, what does that cost every consumer?
What is the default value passed to createContext actually for — is it a loading-state fallback?
Does Context reduce how much of the tree needs to reconcile, or is the mechanism something else entirely?
If you removed React Context entirely, what's the simplest vanilla-JS pattern that lets deeply nested code read a shared value without it being passed down explicitly?

Practice these with the AI interviewer →

The plain-language idea

From the props lesson: prop drilling means passing a value through components that don't use it, just so a descendant further down can. Context is React's answer — a value provided once, high in the tree, that any descendant can read directly with useContext, skipping every layer in between.

const ThemeContext = createContext(null);

function App() {
  return (
    <ThemeContext.Provider value={{ color: "dark" }}>
      <Toolbar />
    </ThemeContext.Provider>
  );
}

function Toolbar() {
  return <Button />; // doesn't need to know about theme at all
}

function Button() {
  const theme = useContext(ThemeContext);
  return <button className={theme.color}>Click</button>;
}

Toolbar never touches theme — it doesn't even know ThemeContext exists. Button, several layers down, reads it directly.

Context: skipping every layer in betweenStep 1 of 3

<ThemeContext.Provider value={{ color: 'dark' }}> wraps the tree, high up.

See it in a real thing: the re-render cost

<ThemeContext.Provider value={{ color: "dark", updatedAt: Date.now() }}>

If this value is a fresh object literal built inline on every render of the Provider, every single component that calls useContext(ThemeContext) re-renders on every one of those renders — even a component that only ever reads theme.color and doesn't care about updatedAt at all. Context subscribes to changes in the value's reference, not to which specific field a consumer actually reads.

What people usually miss

Watch out

Every consumer re-renders on any change to the provided value, not just consumers that use the part that changed. This is exactly why apps split one big context into several narrower ones (a separate ThemeContext and UserContext instead of one combined AppContext) — a component reading only UserContext won't re-render when just the theme changes.
Context doesn't skip reconciliation for the whole subtree. Only the components that actually call useContext for that context re-render because of a value change — everything else renders (or doesn't) exactly as it normally would.
A new object literal as the Provider's value on every render defeats any memoization downstream, the same referential-equality issue from the props lesson — useMemo the value object if it's expensive to recompute or has many consumers.
Context isn't a general state-management replacement. It solves reading a value without drilling; it doesn't add anything to how that value changes, which is usually still plain useState or a reducer living above the Provider.

Why this matters in interviews

"What problem does Context actually solve, and what does it cost?" checks that you see it as a targeted fix for prop drilling with a specific re-render tradeoff — not a free, magic global-state feature, which is the most common misconception about it.