Why is Fiber's render phase interruptible but commit is not?

What's really being asked

This question tests whether you understand the separation of concerns in the Fiber reconciliation algorithm between calculating changes and applying them. Specifically it checks if you know that React maintains a workInProgress tree during the render phase and only applies side-effects like DOM updates and lifecycle methods during the commit phase.

The full answer

Four things in order. First define the render phase as the work loop that traverses the fiber tree compares children updates props and builds out the workInProgress tree without touching the visible UI. Second define the commit phase as the stage where React flushes side-effects including pre-mutation lifecycle methods DOM mutations and post-mutation lifecycle methods like refs. Third explain that render is safe to interrupt because all work happens on the invisible workInProgress tree since no host environment mutations have occurred partial work can be discarded and restarted from the current tree. Fourth explain that commit is not safe to interrupt because it performs synchronous DOM updates and runs lifecycle methods that must complete atomically to keep the UI consistent with the internal state.

The mistakes people make

Saying that render mutates the DOM directly or that both phases can be interrupted. Another red flag is describing the render phase as only calling the render method without mentioning the work loop the comparison of children or the construction of the workInProgress tree. Claiming that commit is where React calculates props or diffs children is also incorrect because those activities belong to render.

What usually comes next

An interviewer might ask how the effects list is used to optimize the commit phase or what happens to the workInProgress tree after commit completes. They might also ask how Fiber handles different element types such as class components versus host components during the render phase or how the algorithm uses the linked list structure to enable the work loop to be broken into chunks.

A concrete example

Consider the sample ClickCounter component from the article. When setState increments count the render phase performs work by retrieving and comparing the children of ClickCounter updating props for the span element and building a workInProgress tree that reflects the new count value. None of this touches the browser DOM. Only during commit does React update the actual span text node and run any associated lifecycle methods which is why pausing mid-commit would leave the counter text partially updated and the component state inconsistent.