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 (
_currentValuepush/pop). - On change, React marks fibers with
dependenciespointing 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:
- Narrow consumption: move
useContextinto small bridge components that pass plain props into memoized heavy children. - Split read/write contexts so action-only components never subscribe to state changes.
- 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:
- Synchronous placeholder + effect upgrade (flash risk).
- Suspense-integrated resource throwing promise (needs boundary).
- 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