Context and prop drilling

Prop drilling is passing a prop through components that do not use it, only so a deeply nested one can. Three levels of theme={theme} is annoying; it also couples every intermediate component to data it does not care about.

There are two fixes, and the first one is often overlooked:

• Composition. If a middle component only forwards something, let it accept children and have the top component render the deep one directly: <Layout><Avatar user={user} /></Layout>. No intermediate component touches user.
• Context. For values many components at different depths need — the theme, the signed-in user, the locale — publish the value once and let any descendant read it.

const ThemeContext = createContext("light");   // the default

function App() {
  return (
    <ThemeContext value="dark">                  {/* React 19 */}
      <Toolbar />
    </ThemeContext>
  );
}

function Button() {
  const theme = useContext(ThemeContext);        // "dark"
  return <button className={theme}>OK</button>;
}

In React 19 the context object itself is the provider (<ThemeContext value=…>); <ThemeContext.Provider> still works. React 19 also adds the use API: use(ThemeContext) reads context like useContext, but unlike a hook it may be called inside a condition or a loop (still only while a component or hook is rendering).

How a component finds its value

useContext looks up the tree for the nearest provider of that context and returns its value. Providers nest; the closest one wins, and it only covers its own subtree. The default passed to createContext is used only when there is no provider above at all — a provider whose value is null or undefined still provides that value.

1const ThemeContext = { defaultValue: "light" };2 3// Walk the tree with a stack of active providers, like React does.4// A node's own read looks above it; its provider covers its children.5function render(node, stack, out) {6  if (node.reads) {7    out.push(`${node.name}: ${stack.length ? stack[stack.length - 1] : ThemeContext.defaultValue}`);8  }9  const pushed = node.provides !== undefined;10  if (pushed) stack.push(node.provides);11  for (const child of node.children ?? []) render(child, stack, out);12  if (pushed) stack.pop();13  return out;14}15 16export function run() {17  const tree = {18    name: "App",19    children: [20      { name: "Header", reads: true },21      {22        name: "DarkSection",23        provides: "dark",24        children: [25          { name: "Button", reads: true },26          { name: "Inverted", provides: "light", children: [{ name: "Badge", reads: true }] },27          { name: "Nothing", provides: null, children: [{ name: "Icon", reads: true }] },28        ],29      },30      { name: "Footer", reads: true },31    ],32  };33  return render(tree, [], []);34}

When consumers re-render

When a provider renders with a value that is different by Object.is, every component reading that context re-renders — even if a parent in between is wrapped in memo. The trap is an inline object:

<AuthContext value={{ user, logout }}>   {/* a new object every render */}

Every render of the component holding the provider creates a new object, so every consumer re-renders, whether user changed or not:

1export function run() {2  const user = { name: "Ada" };3  const logout = () => {};4  let consumerRenders = { inline: 0, memoised: 0 };5  let prevInline, prevMemo;6  let memoCache = null;7 8  for (let render = 0; render < 3; render++) {9    // Inline: <AuthContext value={{ user, logout }}>10    const inline = { user, logout };11    if (!Object.is(inline, prevInline)) consumerRenders.inline++;12    prevInline = inline;13 14    // Memoised: useMemo(() => ({ user, logout }), [user, logout])15    if (!memoCache || memoCache.user !== user || memoCache.logout !== logout) {16      memoCache = { user, logout, value: { user, logout } };17    }18    if (!Object.is(memoCache.value, prevMemo)) consumerRenders.memoised++;19    prevMemo = memoCache.value;20  }21  return consumerRenders;22}

Memoise the value (useMemo(() => ({ user, logout }), [user, logout]) with logout from useCallback), or split rarely-changing and often-changing values into separate contexts so a reader only subscribes to what it uses.

Common mistakes

• Reaching for context to avoid two levels of props. Passing props is explicit and easy to trace; composition with children often removes the drilling without any global value.
• An inline object or array as the provider value. It is a new object on every render, as the second example counts, so every consumer re-renders every time.
• Expecting the default value under a provider with null. The default only applies when there is no provider; null is a value.
• Reading context in the same component that renders the provider. useContext looks above the component, so it does not see a provider the component itself returns.

What interviewers ask

• What problem does context solve, and what is the alternative? — Passing data to many components at different depths without drilling; composition through children is the first thing to try.
• Which value does useContext return with nested providers? — The value of the closest provider above the component; the default only when there is none.
• Why can context cause performance problems? — Every consumer re-renders when the value changes by identity; memoise the value or split the context.