Render phase purity and commit phase sub-steps

A component that writes to a global counter on every render works fine with React 17. With React 18 in StrictMode, that counter doubles. The difference is not a bug — it is React telling you the render phase can replay your function, and side effects there will run more than once.

Render phase: interruptible, must be pure. The render phase walks the workInProgress tree, calls each function component, and runs reconciliation. Because React 18 can pause this phase, resume it, or discard it and start over, your component function may be called more than once for a single visible update — and a paused render may sit half-finished while the user interacts. This is why a render must be pure: no side effects, no mutating external variables, no DOM reads or writes, no network calls in the function body. A side effect in render runs an unpredictable number of times. React’s StrictMode deliberately double-invokes components in development precisely to surface impure renders early. The disciplined place for side effects is useEffect (after commit) or an event handler (outside render entirely).

Commit phase: atomic, synchronous, three sub-steps. Once the workInProgress tree is fully built, commit runs in one uninterruptible block. It has three sub-steps:

1. Before-mutation: React reads any pre-mutation state. This is where getSnapshotBeforeUpdate and the cleanup snapshot for useLayoutEffect happen.
2. Mutation: React applies every DOM change — insertions, deletions, attribute updates, text changes — driven by the effect flags it tagged onto fibers during render.
3. Layout: React runs useLayoutEffect callbacks and updates refs, synchronously, before the browser paints.

Because commit is synchronous and uninterruptible, a huge tree with thousands of mutations produces one long task — commit is the part of React you cannot time-slice, so the way to keep it short is to keep the number of mutations small (virtualisation, memoisation).

useLayoutEffect vs useEffect. The two differ in when they run relative to paint. useLayoutEffect fires synchronously in the commit phase’s layout step — after DOM mutation, before the browser paints. useEffect (a “passive effect”) fires asynchronously after paint, on a later task. The rule: anything that must run before the user sees the frame — measuring a just-mutated DOM node and adjusting layout to prevent a visible flash — belongs in useLayoutEffect. Everything else — data fetching, subscriptions, logging — belongs in useEffect, because doing it in useLayoutEffect delays paint. Overusing useLayoutEffect is a real INP regression: every layout effect is synchronous commit-phase work that pushes the paint later.