React Context Interview Questions

What problem does Context solve?

Prop drilling. When a value is needed by a component five levels down, every component in between has to accept and forward a prop it does not use. Context lets a provider publish a value and any descendant read it directly with `useContext`, skipping the intermediate layers entirely. That is the whole feature — it is about delivery, not about ownership.

The default value passed to `createContext` is used only when a consumer has no matching provider above it. That makes it useful for tests and Storybook, but it also means a typo in your provider placement fails silently with the default rather than throwing — which is why the custom-hook guard below is worth adopting as a habit.

Why does every consumer re-render when the value changes?

Because Context propagates by reference identity and has no way to compare parts of the value. When the provider's `value` prop is not identical to the previous render's, React re-renders every component that calls `useContext` for that context — regardless of whether the specific field they read actually changed. `React.memo` does not help, because the update reaches consumers through the context subscription rather than through props.

There are two separate problems tangled together in that snippet, and being able to pull them apart is the answer that scores. The first is that the object literal creates a new reference on every render, so consumers re-render even when nothing they care about changed. The second is that one context is carrying two unrelated concerns, so even a correctly memoised value would still notify everybody when either half moved.

A quick way to prove the re-render behaviour to yourself, and a good thing to describe in an interview, is to add a console log to each consumer and open React DevTools with "Highlight updates when components render" switched on. Change one field and watch every consumer flash. That two-minute experiment is what turns this from a rule you repeat into a behaviour you have actually observed, and interviewers can hear the difference.

How do you memoise the context value?

Wrap the value in `useMemo` with the state it depends on. That fixes the first problem: the provider can re-render for unrelated reasons without handing consumers a new reference. Setter functions from `useState` and `dispatch` from `useReducer` are already stable, so they do not need to be in the dependency array — though including them is harmless and keeps the linter quiet.

A cheaper alternative that people forget: if the provider component does nothing except hold state and render `children`, the children passed to it are created by its parent and stay referentially stable across the provider's own re-renders. So a provider whose only job is state often does not re-render its subtree at all — the subtree is the same element object. That is worth mentioning because it explains why some providers appear not to have the problem.

Be careful with one common variation of this advice, though. Memoising the value fixes references but does nothing about the breadth of the notification — if the memo dependency changes, every consumer still re-renders. Candidates sometimes present `useMemo` as a complete answer to context performance and get caught by the follow-up. It solves the accidental updates; the split-context pattern below is what solves the unnecessary ones.

What is the split-context pattern?

Memoising fixes stale references but not the second problem: components that only dispatch still re-render when the state changes. The fix is to publish state and dispatch through two separate contexts. Because `dispatch` and `useState` setters never change identity, the dispatch context's value is constant — so components that only write never re-render when the state moves.

The same idea extends further: split by domain, not just by read and write. A theme context, an auth context and a cart context are three providers with three independent update frequencies, and a component that reads only the theme should never be woken by a cart change. Multiple small contexts are almost always better than one large one, and saying so preempts the performance follow-up.

How do you write a safe custom hook for a context?

Export a hook rather than the context object. It gives you one place to throw a useful error when the provider is missing, it keeps the context private to its module, and it means consumers never import `useContext` and the context separately. This is the pattern nearly every library uses, and reaching for it unprompted reads as production experience.

A small caveat on the custom-hook pattern: throwing is right for a context that is genuinely required, and wrong for one with a sensible default. An optional analytics context that quietly no-ops without a provider is easier to work with than one that crashes a page in a Storybook story. Decide which kind you are building, and make the default value say so.

When is Context the wrong tool?

Context is a poor fit for values that change many times a second, because every change notifies every consumer with no way to opt out. Form field state, mouse position, scroll offset, and anything animating should not live in context. It is also the wrong tool for server data — caching, refetching, deduping and invalidation are exactly what React Query and SWR provide and exactly what context does not.

• →Theme, locale, feature flags, current user — ideal for context; they change rarely.
• →Form state — keep it local, or use a form library; context re-renders on every keystroke.
• →Server data — React Query or SWR, which give you caching and invalidation for free.
• →High-churn global state — Zustand or Redux, which support selective subscription.
• →Two or three levels of prop drilling — just pass the prop; context is not free to read.

That last point is worth defending, because the instinct after learning context is to eliminate every repeated prop. Explicit props make a component's dependencies visible in its signature and its tests trivial to write; a context has to be found, mocked and provided. Reach for it when the value is genuinely global to a subtree and the drilling is genuinely painful — not at the first sign of a prop passed twice.

One more reason to prefer a custom hook: it gives you somewhere to add behaviour later without touching every call site. Logging, a development-only warning when the value is read outside an expected subtree, or a narrowed return type that hides internal fields all become one-line changes inside the hook. Exporting the raw context object forecloses all of that, because every consumer has already reached past you.

Can you use Context with Server Components?

Not in a Server Component itself. Context requires a runtime and a component tree that exists in the browser, so `createContext` and `useContext` are client-only — calling them in a Server Component is an error. The pattern is to create the provider in a file marked `"use client"`, then render it high in the tree and pass server-rendered content through it as children.

How do you test a component that uses Context?

Render it inside the real provider rather than mocking the hook. Mocking `useContext` couples the test to the implementation and stops catching genuine integration bugs; wrapping the component in the actual provider with a controlled initial state tests the thing you ship. A small custom render helper that applies your providers keeps this from becoming boilerplate in every file.

If the provider needs its own data, extract the state logic — usually a reducer — and test that as a pure function separately. That gives you fast, exhaustive coverage of the transitions and leaves the component tests to check that the right thing appears on screen. It is the same argument as testing a reducer outside React, and it is one reason `useReducer` pairs so naturally with context.