Architecture

Elements vs. components vs. instances, the Fiber reconciler, renderers, and the interruptible scheduler.

Path: architecture

Third-party documentation. This is independently authored analysis of the public React codebase — not the official docs, and not reviewed or endorsed by the React team.

Architecture

React's implementation separates three concerns that are easy to conflate from the outside.

Elements, components, instances

An element is a plain, immutable description object () — what JSX compiles to. A component is the function that produces elements. An instance is the runtime identity React maintains for a placed component (its state, refs, DOM nodes). Elements are cheap and thrown away every render; instances persist and are what reconciliation protects.

The Fiber reconciler

Fiber is the reconciler's internal data structure: one fiber node per instance, linked child/sibling/return pointers forming a persistent linked list mirroring the tree. Each render pass builds a "work-in-progress" tree of fibers, compares it against the committed current tree, and computes the minimal set of mutations — inserts, updates, deletions, moves keyed by list keys — before committing them in one synchronous pass.

Renderers

The reconciler is host-agnostic: it hands a finalized mutation list to a renderer. react-dom translates mutations into DOM API calls; react-native into mobile views. This split is why the component model survives unchanged across platforms.

The scheduler

Render work is split into fiber-by-fiber units that can be paused between them. The scheduler prioritizes work lanes — user input outranks transitions, which outrank background refreshes — so a slow re-render can yield to typing without dropping frames. Commit phases remain synchronous by design: visible updates never tear mid-paint.

System Diagram

Component rendering model
01Components
02Props + state
03Fiber tree
04Reconciliation
05DOM renderer

Updates flow through the Fiber tree before the renderer commits DOM changes.