The Work Loop and Interruptibility

## The question behind the question "Why did React rewrite the reconciler as Fiber?" is really "why can't you pause a recursive algorithm in JavaScript?" Everything else follows from that. ## What the stack reconciler did The pre-React-16 reconciler processed an update by recursing: to reconcile a component, it computed that component's output and then called itself for each child, and each of those calls did the same. The traversal was elegant, and its bookkeeping was implicit — the engine's call stack was the record of which node was being processed and which parents were waiting for it to return. That implicitness is the whole problem. The JavaScript call stack is owned by the engine. There is no API to capture the current stack, discard it, and later restore it; there is no way to say "return to the browser now and come back into the middle of this recursion." And because JavaScript runs each task to completion, nothing can interrupt the recursion from outside either. So an update to a large tree was an all-or-nothing block of synchronous work: once React entered, the browser got the thread back only when React was finished. On a big tree that is a dropped frame, and a keystroke typed during it waits. Notice that this is a structural limitation, not a tuning problem. Adding priorities or a scheduler to the old reconciler would not have helped, because there was still no way to stop. ## What Fiber changed Fiber's core idea is to stop using the call stack as the data structure and build an explicit one instead. A fiber is an ordinary JavaScript object on the heap that holds what a stack frame would have held: which component or host element it represents, its pending props and state, its position relative to its parent, child and sibling, and how much work is left to do on it. With that in place, reconciliation stops being recursion and becomes a loop: ```js // Conceptual shape of React's concurrent work loop. while (workInProgress !== null && !shouldYield()) { workInProgress = performUnitOfWork(workInProgress); } ``` `workInProgress` is a variable React owns pointing at the next fiber to process. Each iteration does the work for exactly one fiber and returns the next one. Between iterations React calls `shouldYield()`, which asks the scheduler whether the current slice of the frame is used up. When the answer is yes, React does not freeze — it returns from the loop normally, so the JavaScript stack unwinds completely and the browser is free to run input handlers, layout and paint. React schedules a callback to continue (the scheduler uses a message channel to obtain a fresh task rather than a clamped timer), and when that callback runs, the loop starts again from the same `workInProgress` value. Nothing was lost, because nothing important was ever on the call stack. ## Why this is the enabling change, not the feature Fiber by itself does not make anything faster; a full render still does the same work, and yielding adds a little overhead. What it buys is the *ability to stop*, and everything in modern React that depends on stopping is built on top of it: interrupting a long render when input arrives, abandoning a render that has been superseded, and rendering some updates at lower urgency than others. It is worth being precise in an interview: Fiber made the render phase interruptible. The commit — the part that mutates the DOM — is still one synchronous block, because there the work is not disposable. ## The granularity that remains The unit React can stop between is one fiber, which for a function component means one call of your component function. React cannot stop inside that call, again because of run-to-completion. So the architecture converts "one huge indivisible block" into "many small indivisible blocks" — a huge improvement when cost is spread across a tree, and no improvement at all when a single component does something enormous. ## A common wrong answer Candidates often say the old reconciler was slow and Fiber made diffing faster, or that Fiber introduced the virtual DOM. Neither is right. The diffing heuristics are largely the same; the virtual DOM predates Fiber. What changed is where the traversal state lives, and therefore who controls when React gives the thread back.