Rendering and Reconciliation

1What "Rendering" Means in React

"Rendering" is React calling your component functions to find out what they want the UI to look like right now. It does not mean "writing to the DOM" — that's a separate, later step called committing (see section 5 and the "React fundamentals" topic's Under the Hood section). A component can render many times without a single DOM node changing, if the output happens to be identical to last time.

function Clock({ time }: { time: string }) {
  console.log("Clock rendering"); // this runs on EVERY render, even if time is unchanged
  return <p>{time}</p>;
}

2What Triggers a Render

Three things cause React to render a component:

1. State changes (useState/useReducer setter called) on that component or an ancestor.
2. Props changes — usually because the parent re-rendered and passed new values.
3. Context changes — a Provider whose value changed re-renders every consuming descendant (see "UseContext").

Note: a parent re-rendering, by default, re-renders every child in its subtree, regardless of whether that child's own props actually changed — React re-runs the child function again to find out what it returns, then diffs the result. ("Performance optimization" covers React.memo, which changes this default.)

3Reconciliation: Comparing Old and New Trees

Every render produces a brand-new tree of React elements (plain objects). Reconciliation is the algorithm React uses to compare this new tree against the previous one and figure out the minimal set of real DOM operations needed to update the screen to match.

A naive tree-diff algorithm is O(n³) for arbitrary trees — far too slow for UI updates. React's reconciler instead uses a set of heuristics that make the comparison O(n), at the cost of being not-perfectly-optimal in some edge cases (documented as trade-offs, not bugs):

Heuristic 1: Different element types → tear down and rebuild

// Before:
<div><Counter /></div>
// After:
<span><Counter /></span>

Because the root element type changed (div → span), React doesn't try to patch the div into a span. It destroys the old div subtree entirely (including unmounting Counter — losing its state) and builds a brand-new span subtree from scratch. Changing an element's type at a given position is always a full remount of everything below it.

Heuristic 2: Same element type → keep the DOM node, diff the attributes

// Before:
<div className="a" title="old" />
// After:
<div className="b" title="old" />

Same type (div) at the same position → React keeps the existing DOM node and only patches the attributes that actually differ (className here) — title is left untouched since it's identical.

Heuristic 3: Lists are matched by key, not by position

// Before: [{id: "a"}, {id: "b"}]
// After:  [{id: "c"}, {id: "a"}, {id: "b"}]
<ul>{items.map((item) => <li key={item.id}>{item.text}</li>)}</ul>

Without keys, React would compare position-by-position and think every single item changed (since index 0 went from "a" to "c", index 1 from "b" to "a", etc.), causing three DOM updates. With stable keys, React recognizes "a" and "b" as the same items that simply moved, and only inserts one new node ("c") — a single DOM operation instead of three.

4Why Array Index as key Is Usually Wrong

{items.map((item, index) => <TodoItem key={index} {...item} />)}

If items only ever grows at the end and never reorders/removes from the middle, index keys are harmless. But the moment an item is removed or reordered, every subsequent item's key (its index) shifts, and React — matching by key — thinks each of those items is the same component with new props, rather than a different item. Any local state those components hold (an open <details>, an in-progress text input) ends up attached to the wrong data.

// safe: a stable id that travels WITH the data, not with its position
{items.map((item) => <TodoItem key={item.id} {...item} />)}

5Render Phase vs Commit Phase, Revisited

Reconciliation (the diffing described above) happens during the render phase — it produces a list of effects (DOM operations to perform, lifecycle/effect callbacks to run) attached to fibers, but performs no actual mutations yet. The commit phase then walks that effect list and applies every mutation to the real DOM in one synchronous pass. This split is why reconciliation itself can be paused/abandoned by React's scheduler without any visible half-updated UI — nothing user-visible has happened until commit runs.

⚠️ Common Pitfalls

1. Using key={index} on a list that reorders, filters, or deletes — the key names the slot rather than the item, so React reuses the previous occupant's fiber (and its memoizedState) for a different piece of data. Uncontrolled inputs, scroll positions, and open/closed toggles all end up attached to the wrong row.
2. Using key={Math.random()} to "fix" key warnings — a fresh key every render means no old fiber ever matches, so every item is unmounted and recreated on every render: maximum DOM churn, total state loss, and effects re-firing constantly. It silences the warning by making the problem as bad as it can be.
3. Putting the key on the wrong element — the key must be on the element returned directly by the .map() callback. Putting it on an inner child (<><li key={id}/></> or on the root of a wrapper's JSX) leaves the mapped element unkeyed and the whole array falls back to index matching.
4. Assuming a re-render means the DOM was written to — reconciliation frequently concludes "nothing to do" and emits no flags at all; the component function still ran. Profiling "re-renders" and "DOM mutations" are two different measurements.
5. Conditionally changing element type in a fixed slot (cond ? <div>{x}</div> : <section>{x}</section>) — the type mismatch deletes the fiber and every descendant fiber, remounting the entire subtree each time the condition flips. Rendering the same type with a different className avoids the teardown entirely.
6. Expecting the diff to detect a subtree that moved to a new parent — matching only ever happens among siblings under the same parent fiber. Move a node to a different parent and it is a delete plus an insert, with full state loss, no matter how stable the key is.

📋 Quick Reference

render  = call component functions, build new element objects, diff → set flags
commit  = walk flagged fibers, apply DOM mutations, run effects

Matching rules (siblings only, never across parents):
  key differs             → delete old fiber, create new one
  key same, type differs  → delete old fiber + its siblings, create new
  key same, type same     → reuse fiber, reuse DOM node, patch changed props only
  no key given            → key falls back to the array index

Move detection:
  oldIndex <  lastPlacedIndex  → flag Placement (DOM insertBefore at commit)
  oldIndex >= lastPlacedIndex  → lastPlacedIndex = oldIndex, no DOM move

key={item.id}      ✅ identifies the item
key={index}        ⚠️  identifies the slot — safe only for append-only lists
key={Math.random()} ❌ never matches: full remount every render

1Why React Rewrote Its Reconciler Around Fiber

Before React 16, reconciliation walked the element tree recursively with the plain JS call stack — once started, a render could not be paused, because there was no way to save "where you were" in a native call stack and resume later. A large tree could block the main thread for tens of milliseconds, dropping frames and freezing input. React 16 introduced Fiber: reconciliation re-implemented as an explicit, resumable data structure and a work loop that processes it unit-by-unit, so React itself controls when to pause, yield to the browser, and resume — instead of the JS call stack controlling that implicitly.

2The Fiber Node

A fiber is a plain JS object, one per component instance / host (DOM) element, that acts as both a unit of work and a persistent record of that instance across renders. Simplified shape:

Fiber {
  type: Function | string        // the component function, or "div"/"span"/etc.
  key: string | null
  stateNode: Instance | null     // the actual DOM node, or class instance

  child: Fiber | null            // first child
  sibling: Fiber | null          // next sibling
  return: Fiber | null           // parent ("return" because it's where to go
                                  //  when this fiber's work is done)

  pendingProps: any              // props for the render in progress
  memoizedProps: any             // props from the last completed render
  memoizedState: any             // hooks linked list (see "State" topic)

  alternate: Fiber | null        // pointer to the OTHER tree's version of this fiber
  flags: number                  // bitmask: what effects to apply on commit
  lanes: number                  // bitmask: priority of pending work
}

Fibers link via child/sibling/return instead of a children array — this lets the work loop walk the entire tree with simple pointer-following (depth-first: go to child, then sibling, then back up via return) without recursion, which is what makes pausing/resuming possible: the "call stack" is just these pointers, stored on the heap, not the JS engine's real stack.

3Double Buffering: Two Trees, Not One

React keeps two fiber trees alive at once:

• current tree — what's actually on screen right now.
• work-in-progress (WIP) tree — being built/updated for the next render, node by node, reusing as much of the current tree's fiber objects as it can (cloning only what actually needs new pendingProps).

Each fiber's alternate pointer links it to its counterpart in the other tree. When the WIP tree finishes and commits, React simply flips a single pointer (FiberRoot.current) to point at the WIP tree — it becomes the new "current" tree, and the old current tree becomes available to reuse as the next WIP tree. This is called double buffering, the same technique used in graphics rendering to avoid ever showing a half-drawn frame: the screen only ever reflects one complete, finished tree, never a tree that's partway through being built.

4The Work Loop and the Scheduler

React's work loop processes one fiber at a time:

while (workInProgress !== null && !shouldYieldToBrowser()) {
  workInProgress = performUnitOfWork(workInProgress);
}

shouldYieldToBrowser() is what makes this cooperative and interruptible: after each fiber, React checks whether it has used up its time slice (roughly 5ms, tuned to fit inside a frame budget) and, if so, returns control to the browser so it can handle input, paint, etc., then resumes the loop later where it left off. This is the mechanical basis for React's concurrent features — startTransition, useDeferredValue — which mark certain updates as low priority so urgent work (like text you're actively typing) can interrupt and go first.

lanes (a bitmask on each fiber and each update) is how React tracks priority — a setState from a click handler gets a different lane than one wrapped in startTransition, and the scheduler picks which lanes' work to process first when there's contention. This entire lane/priority system is invisible if you never touch concurrent APIs — by default, updates are processed essentially synchronously in priority order — but it's the reason those APIs are even possible without a separate reconciler.

5Effect Tags and the Commit Phase

During the render phase, as React processes each fiber, it doesn't touch the DOM — it sets bits on that fiber's flags field (e.g. Placement, Update, Deletion) recording what will need to happen to the corresponding real DOM node. After the whole WIP tree finishes, the commit phase walks the fibers carrying non-zero flags (React tracks this as a subtree-completion list, so it doesn't have to re-walk fibers with no work) and performs the actual appendChild/removeChild/attribute updates synchronously, then flips the current pointer as described above, then runs layout effects, then (after the browser paints) passive effects.

update = {
  lane: requestUpdateLane(fiber),   // priority bucket for this update
  action: 5 | (prev) => prev + 1,   // the value or updater function
  eagerState: null,
  hasEagerState: false,
  next: <the next update in the ring>
}

⚠️ Common Pitfalls

1. Assuming reconciliation always finds the theoretically minimal diff — it uses O(n) heuristics (type + key matching), not a true minimal tree-edit-distance algorithm; certain restructurings (e.g. moving a subtree to a completely different parent) are not detected as a "move" and get torn down/rebuilt instead.
2. Changing a component's element type conditionally in the same position (condition ? <div/> : <span/> in the same JSX slot) — causes a full unmount/remount of everything below it every time the condition flips, including losing all descendant state.
3. Confusing "re-render" with "DOM update" — a component re-rendering (its function running again) does not necessarily mean the DOM changes; reconciliation may find the output identical and skip the commit for that subtree's unaffected nodes.
4. Not realizing a parent's re-render cascades to all children by default — every child in the subtree gets its function called again unless memoized (see "Performance optimization"); this is expensive work-phase cost even when no DOM changes result.
5. Reading state right after calling its setter — the setter only queued an update object; the count binding in the current scope is a const captured by this render's closure and can never change. Read the new value in the next render, or compute it locally before you call the setter.
6. Reaching for flushSync to make a value "available immediately" — it forces a synchronous render and commit, defeating batching, and if you call it inside a lifecycle or effect React warns and may still defer. It is for DOM measurement between two updates, nothing else.
7. Assuming setState with an equal value is always free — the eager bailout only applies when the hook's queue is empty; inside a batch that already queued an update, an identical value still schedules a render (React usually bails out one level later, after re-rendering the component but before touching children).
8. Mutating state and calling the setter with the same reference — items.push(x); setItems(items) passes a reference that is Object.is-equal to the current state, so the eager bailout can drop the update entirely and nothing renders. Always produce a new array/object.

📋 Quick Reference

setCount(c => c + 1) x3  → 3 update objects, replayed in order  → +3
setCount(count + 1)  x3  → 3 update objects, same captured value → +1

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

✅ Check yourself

Source: react_rendering_and_reconciliation_theory_1.md, react_rendering_and_reconciliation_theory_2.md · generated by tools/build_lessons.py