Browser & Frontend Runtime
React fiber: multiple-choice review
Crux Multiple-choice synthesis across the fiber unit — render vs commit, the double-buffer tree, reconciliation keys, lanes and time-slicing, bailout, and tearing.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. None is a definition to recite — each mirrors a decision you make in a real performance incident, where the render phase, the commit phase, keys, lanes, and the bailout all interact.
Goal
Confirm you can connect the reconciler’s two phases, the fiber double-buffer, reconciliation identity, the lane scheduler, and the bailout mechanism — the synthesis the individual lessons built toward.
Quiz
Completed
A component increments a module-level counter in its function body. It worked in React 17; in React 18 StrictMode the counter is double what you expect, and in production under load it occasionally triple-counts. What is the root cause?
Heads-up React's reconciler runs on the single main thread — there is no second thread racing. The non-determinism comes from the render phase being replayable, not from concurrency across threads.
Heads-up StrictMode runs only in development and is intentionally double-invoking to expose the impure render. Removing it hides the symptom; the impure side effect is still wrong under concurrent rendering in production.
Heads-up useState would not fix a side effect that fires during render; the fix is to stop performing the effect in the function body at all. Render must be pure regardless of where the value is stored.
Quiz
Completed
A render is 30 ms in when a higher-priority keystroke arrives. React abandons the in-progress workInProgress tree and starts over. Why does discarding the half-built tree cost nothing visible?
Heads-up There is no rollback transaction. The cost is zero because nothing was applied — commit, not render, is what touches the DOM, and commit never started.
Heads-up The alternate pointer links each fiber to its twin for cheap cloning and bailout — it is not an undo log. There are no mutations to undo because the render phase produces no DOM changes.
Heads-up The user never sees workInProgress. Only the current tree is painted, and it stays consistent because the abandoned tree is purely in-memory.
Quiz
Completed
A list renders with key={index}. A checkbox checked on the third row stays checked on the wrong row after the first row is deleted, yet the text labels are all correct. What explains the split behaviour?
Heads-up State was not lost — it was preserved on the wrong fiber. The fibers stayed in place; only the data they were paired with shifted, because index keys are positional.
Heads-up Commit order is correct and deterministic. The mismatch happened earlier, in reconciliation, where index keys made React pair fibers with the wrong items.
Heads-up With stable identity keys the checkbox tracks its item correctly across deletes. The bug is specific to index-as-key, not a general property of checkboxes.
Quiz
Completed
A search input filters a 5,000-row list. Typing is janky. You wrap the filtered-list setState in startTransition. Typing now feels instant — but why does the list itself not freeze the page when it finally renders?
Heads-up There is no background thread — React renders on the main thread. startTransition lowers the update's priority so it is interruptible and time-sliced, not parallelised.
Heads-up startTransition does not debounce; the filter still runs. It changes the update's priority lane so the render yields to urgent input, rather than reducing how often it fires.
Heads-up Time-slicing applies to the render phase, not commit. Commit is always atomic and uninterruptible; what startTransition makes interruptible is the render work, not the commit.
Quiz
Completed
A child wrapped in React.memo re-renders on every parent render. The Profiler reason is 'props changed', but the prop's contents are identical each time. What is happening?
Heads-up React.memo's default comparison is shallow Object.is per prop, not deep. It is reporting a real referential difference: the prop is a new object each render even though its contents match.
Heads-up Hooks do not disable memo. memo gates whether the render-phase entry happens at all; once a render proceeds the component's hooks run normally. The defeat is an unstable prop reference.
Heads-up React.memo is active in development. The re-render is genuine and caused by referential inequality of a prop, not by memo being disabled.
Quiz
Completed
An external store drives a dashboard. After enabling concurrent features, you occasionally see the header showing one total while a sibling panel shows a different total in the same frame. Which mechanism is at fault and what fixes it?
Heads-up A stale closure produces a consistently old value, not two different values in one frame. The hallmark of tearing is internal inconsistency within a single commit, caused by a store mutating between render slices.
Heads-up useMemo caches a computed value within one component; it does nothing about an external store changing mid-render across the tree. The concurrency-safe integration point is useSyncExternalStore.
Heads-up React-internal state cannot tear, because React controls exactly when it changes. Tearing arises only with external stores React does not control — which is precisely what useSyncExternalStore exists to make safe.
Recap
The unit’s through-line is one machine seen from six angles: render computes the diff (interruptible, must be pure) and commit applies it (atomic); the fiber double-buffer makes interruption free; reconciliation keys bind state to identity, not position; lanes and time-slicing keep urgent input ahead of expensive work; the bailout — gated by Object.is referential stability — keeps large trees cheap; and useSyncExternalStore keeps external stores from tearing under concurrent rendering. Every production symptom here resolves back to one of those six levers.