D
DevPrepSystematic Prep
CONTEXT API · MEDIUM CODEX

Context API Interview Questions — Medium

Real-world mechanisms, state management, edge cases, performance trade-offs, and practical coding.

20 Theory Questions5 Free Model Answers
THEORY QUESTIONS & SOLUTIONSShowing 5 of 20 questions
Q1How does useContext subscription actually work internally?
  • Each context object holds a registry of consumers; Providers register themselves on a global stack during render (_currentValue push/pop).
  • On change, React marks fibers with dependencies pointing at changed contexts and walks consumers from that provider down — propagation cost scales with consumer count below the provider, not tree size.
  • Consumers read via stack discipline: nearest provider wins. Implication: placing providers HIGH multiplies traversal; colocate providers as deep as their audience allows.

Q2Why doesn't memo() protect children from context updates — and what patterns isolate them?
  • memo compares PROPS only; useContext reads bypass props entirely, forcing re-render on value identity change. Isolation patterns:
  1. Narrow consumption: move useContext into small bridge components that pass plain props into memoized heavy children.
  2. Split read/write contexts so action-only components never subscribe to state changes.
  3. Multiple domain contexts sized by change frequency. Rule to state plainly: render isolation from context comes ONLY from subscription narrowing.

Q3Design the split-context Provider for an auth domain end-to-end.
const AuthStateCtx = createContext<AuthState|null>(null);
const AuthDispatchCtx = createContext<AuthDispatch|null>(null);

function AuthProvider({children}) {
  const [state, dispatch] = useReducer(authReducer, null, initFromStorage);
  const dispatchStable = useMemo(() => ({
    signIn: u => dispatch({type:'signIn', user:u}),
    signOut: () => dispatch({type:'signOut'}),
  }), []);
  return (
    <AuthStateCtx.Provider value={state}>
      <AuthDispatchCtx.Provider value={dispatchStable}>{children}</AuthDispatchCtx.Provider>
    </AuthStateCtx.Provider>
  );
}

Points to narrate: stable actions object avoids new identities; state changes re-render only State consumers; persistence handled in effects keyed off state transitions.


Q4What is the "render-prop alternative" and when does it beat useContext?

Render props expose values as ARGUMENTS: <Auth>{({user}) => ...}</Auth> — explicit dataflow per usage site. Beats hooks when:

  • You need MULTIPLE instances of the same logic simultaneously (two independent draft editors) — hooks bind one instance per position in tree.
  • TypeScript generics flow naturally per-usage. Costs: nesting pyramids, no mid-component access without restructuring. Modern verdict: default to hooks+context; reach for render props where instance multiplicity matters (virtualizers, drag contexts exposing slots).

Q5How do you implement context that lazily initializes expensive values?
const [value] = useState(() => buildExpensiveTheme());

Lazy initializer runs once per provider mount — not every render. For async bootstrap:

  1. Synchronous placeholder + effect upgrade (flash risk).
  2. Suspense-integrated resource throwing promise (needs boundary).
  3. Gate rendering: provider computes readiness flag; renders splash until ready — simplest robust SSR-friendly choice. Never compute heavy objects inline in value={} — recreates per render even if discarded.

Unlock the remaining 15 Context API (Medium) questions

You've completed the 5 free sample questions. Get unrestricted lifetime access to every question, model answer, implementation challenge, and all 27+ technologies for a single payment.

₹399 India / $9 International · One-time settlement · Zero subscription

CROSS-DIFFICULTY NAVIGATION

Continue Preparing Context API

Context API Interview Questions (Medium) | DevPrep | DevPrep