Context API Interview Questions — Hard

• Provider fiber stores context on its memoizedState/dependencies registry; consumers attach dependencies first-class lists pointing at context items.
• On update, React sets fiber.flags (PropagationNeeded-style) and walks from provider downward marking consumer fibers with an update lane - it does NOT scan the whole tree; cost is proportional to subscribers below the provider.
• During render, consumers read _currentValue via the pushed stack; nested providers shadow by push/pop ordering.
• Bailouts: memoized children WITHOUT dependency links are skipped entirely - the memo exception applies only to fibers that consume the changed context. Depth signal: mention propagateContextChange-era vs modern dependent-list traversal evolution.

---

• Because dependency invalidation bypasses props-equality bailouts: any fiber whose dependencies include the changed context re-renders even inside memo/PureComponent boundaries.
• Granularity: per-fiber consumption - a component calling useContext once subscribes to the WHOLE provided value. Engineering responses:

1. Narrow value shape (split contexts).
2. Bridge pattern: single tiny consumer passes primitives into memoized subtree.
3. Move hot values out of React state into external store + selective subscriptions (useSyncExternalStore), keeping context only for low-frequency config. Quantify with Profiler before/after - reviewers want measured blast radii.

---

Semantics: Provider reads parent theme via useContext, shallow-merges prop override, provides merged result:

function ThemeProvider({theme: override, children}) {
  const inherited = useContext(ThemeCtx);
  const value = useMemo(() => ({...inherited, ...override}), [inherited, override]);
  ...
}

Pitfalls:

• Identity churn cascades when parent object changes - merge must be memoized on stable inputs; token-level splitting (colors vs spacing) limits radius.
• Circular import of defaults - hoist to tokens module.
• SSR streaming order with nested providers resolving different locales. Reference implementations: Radix Themes / MUI cascade behaviors - cite their merge strategies.

---

Idea: keep one source of truth OUTSIDE react (plain store); context carries only the store handle + version counter; a hook uses useSyncExternalStore against that store for slices:

const StoreCtx = createContext<Store>(null!);
export function useSelector<T>(sel:(s:S)=>T):T {
  const store = useContext(StoreCtx);
  return useSyncExternalStore(store.subscribe, () => sel(store.get()), () => sel(store.initial));
}

Why this wins: context updates ONLY when identity of store changes (never), so context-driven invalidation disappears; slice precision comes from external subscription machinery with built-in tearing protection. This hybrid is exactly how Zustand-context adapters work - explaining it proves systems fluency.

---

• Tearing: within one committed tree, two reads observe different versions of the same logical value because renders interleave with external mutations mid-flight.
• Plain context backed by owner useState is TEAR-SAFE - React serializes updates through its own scheduler/lane model.
• DANGER arises bridging EXTERNAL mutable sources through context: passing store.getState() as provider value during transitions can capture mixed epochs. Tear-safe bridge rules: freeze snapshot per render pass, subscribe via useSyncExternalStore (its consistency check restarts inconsistent renders), never mutate snapshots in place.

---