The Rendering Phase and DOM Commit

React's work cycle has two main phases: the render phase and the commit phase. During the render phase, React calls your component functions and builds a virtual representation of the UI (the fiber tree). During the commit phase, React applies the changes from the fiber tree to the real DOM.

In React 18 Concurrent Mode, the render phase can be paused, interrupted, or restarted. React may call your component function multiple times before committing anything. This is why component functions must be pure — they cannot have side effects, because the function might run more than once per visible update.

Unlike the render phase, the commit phase is always synchronous and runs to completion. React cannot be interrupted while committing DOM changes. This ensures the DOM is never left in a partially updated state. Users always see a fully consistent UI after each commit.

The commit phase has three sub-phases: before mutation (class component getSnapshotBeforeUpdate runs here to read DOM values before changes), mutation (React inserts, updates, and removes DOM nodes), and layout (synchronous effects fire here, specifically useLayoutEffect and class component componentDidMount/componentDidUpdate).

useEffect is a passive effect, meaning it is not run during the commit phase. After the commit phase completes and the browser has painted, React schedules passive effects asynchronously. They run after the browser has had a chance to render the updated DOM to the screen.

The browser paints between the layout phase (where useLayoutEffect runs) and the passive effects phase (where useEffect runs). This is the critical timing difference: useLayoutEffect runs before paint, and useEffect runs after paint. For effects that change visual output, this distinction matters greatly.

If a useEffect reads the DOM and updates state (for example, measuring an element and setting a size state), React will re-render and commit again. The browser paints twice: once with the initial size and once with the corrected size. Users may see a flash of the wrong size before the correction appears.

React builds a tree of "fiber" nodes internally, one per component instance. Each fiber holds the component's state, effects, and output. During the render phase, React creates a new work-in-progress fiber tree. During the commit phase, the work-in-progress tree becomes the current tree, and the old tree is recycled.

React Strict Mode intentionally calls component functions and effects twice in development to help catch side effects. Both useLayoutEffect and useEffect are mounted, unmounted, and remounted. This double invocation does not happen in production. It is designed to surface bugs where effects are not properly cleaned up.

Because the render phase can be interrupted and re-run, component functions must produce the same output for the same inputs without side effects. Mutations, subscriptions, and API calls in the function body (not in effects) will run more times than expected in Concurrent Mode, leading to bugs.

Never read DOM properties directly inside the component function body. The DOM may not yet exist (for server rendering) or may be stale (for re-renders). Always read the DOM inside useLayoutEffect (for pre-paint reads) or useEffect (for post-paint reads) where the DOM is guaranteed to be up to date.

In which sub-phase of the React commit phase does useLayoutEffect fire?

React's render phase builds the fiber tree and can be interrupted; the commit phase applies DOM changes and is always synchronous. The commit has three sub-phases: before mutation, mutation, and layout. useLayoutEffect fires in the layout phase before paint. useEffect fires as a passive effect after paint.