What is React Fiber, and how does it enable concurrent rendering in React?

Question

Accepted Answer

React Fiber is the reconciliation engine introduced in React 16. It changed how React processes updates, and understanding it explains why modern React can stay responsive under load.

Before Fiber, reconciliation was recursive and synchronous. Once React started walking the component tree, it could not stop until it reached the bottom. On a large tree, that work blocked the main thread, so user input, animations, and paints were all delayed. The user saw a frozen interface.

Fiber restructured this work into a linked list of units called fibers. Each fiber represents one component and holds pointers to its child, its sibling, and its parent. Because the tree is a list rather than a call stack, React can process one unit, check whether it still has time in the current frame, and either continue or yield control back to the browser. Work becomes interruptible.

Reconciliation happens in two phases. The render phase builds the work-in-progress tree and computes what changed. It is interruptible, can be paused, resumed, or thrown away entirely, and must stay side-effect free. That is exactly why the render phase can run twice in StrictMode, and why putting a mutation there is a bug. The commit phase then applies the computed changes to the DOM. It is synchronous and cannot be interrupted, because a half-applied DOM would be visibly broken.

This split is what makes concurrent features possible. With useTransition you mark an update as non-urgent, so React can keep a typed character responsive while a heavy filtered list re-renders in the background. useDeferredValue lets a value lag behind so expensive children re-render at lower priority. Suspense can show a fallback while data resolves without blocking the rest of the page.

The practical consequences matter more than the internals. Keep render functions pure, since React may discard and restart work. Do not rely on a render running exactly once. Do not read layout in render; read it in useLayoutEffect during commit. And remember that Fiber makes an application feel faster by scheduling work better, not by making that work cheaper. If a component is genuinely slow, concurrency hides the symptom but memoisation, virtualisation, or less work is still the actual fix.