The Reconciler Loop

The reconciler is the object that remembers the last tree, so a re-render has something to compare against.

Scheduling, not calling

A naive setState re-renders immediately, so a handler that updates three pieces of state renders three times. Real frameworks mark the tree dirty and render once, later.

That is batching in miniature: many writes, one render.

Render phase and commit phase

The loop splits cleanly in two, and the split is what everything else is built on:

Render builds the new tree and computes the diff. It touches no DOM and may be abandoned, so it must be free of side effects.

Commit applies the DOM operations. It cannot be interrupted, and only after it finishes is the DOM real enough to measure or subscribe to - which is why useEffect fires here and never during render.

Fiber

React 16 rewrote the render phase around Fiber: a linked list of work units instead of a recursive walk. A list can be paused between nodes, so React can render a chunk, hand the main thread back to the browser, and resume - which is what makes concurrent rendering, time slicing and Suspense possible at all.

Doing less work

• React.memo skips a component whose props are shallowly equal.
• useMemo / useCallback keep a value or function stable so that a memoised child actually sees equal props.
• Server Components go further: they render on the server and their code never enters the client bundle, so the reconciler never sees them.

Each of these is a bailout from the loop above. None of them changes it.