How React Rendering Works

Reviewed & published by Brayan K

Rendering is the process where React calls your component to build a virtual DOM description, diffs it against the previous one (reconciliation), and commits only the differences to the real DOM. A re-render runs your function again, but it does not automatically touch the page — only changed nodes are updated.

Part of the free React course at LearnCodingFast — hands-on lessons with worked examples and the output they print, plus practice exercises and a quick quiz.

What You'll Learn

• The render phase vs the commit phase
• What triggers a re-render (state, props, parent)
• How the virtual DOM diff works
• What reconciliation does and why keys matter
• Why a re-render is not the same as a DOM update
• How React bails out to skip needless work

1️⃣ Render Phase vs Commit Phase

Rendering happens in two phases. In the render phase, React calls your component to build a new virtual-DOM tree — this must be pure and has no DOM side effects. In the commit phase, React applies the diff to the real DOM and runs effects. The render is cheap; the commit is where the costly DOM work happens, and React keeps it minimal.

function Counter({ count }) {
  // RENDER phase: just return a description. No DOM here.
  return <p>Count: {count}</p>;
}
// COMMIT phase (React does this): updates only the text node
// that changed from "Count: 0" to "Count: 1".

// RENDER = build a description (cheap). COMMIT = touch the DOM (costly).
// React only commits the DIFFERENCES between the old and new description.
function render(state) {
  return { text: "Count: " + state.count };   // a virtual-DOM "snapshot"
}

const before = render({ count: 0 });
const after  = render({ count: 1 });

console.log(before.text);                       // Count: 0
console.log(after.text);                        // Count: 1
console.log(before.text === after.text);        // false -> COMMIT this change

2️⃣ What Triggers a Re-render & the Diff

A component re-renders when its state changes (via a setter), when its props change, or when its parent re-renders. React then runs reconciliation: it compares the new virtual DOM to the old one node by node and computes the smallest set of real changes. Inside lists, stable keys let React match items across renders instead of rebuilding them.

function List({ items }) {
  return (
    <ul>
      {items.map(item => (
        <li key={item.id}>{item.text}</li>    
      ))}
    </ul>
  );
}
// On re-render React diffs by key: unchanged <li>s are reused,
// only added/removed/changed ones are committed.

// DIFFING: compare two snapshots, return only what changed.
function diff(prev, next) {
  const changes = [];
  for (const key in next) {
    if (prev[key] !== next[key]) changes.push(key + ": " + prev[key] + " -> " + next[key]);
  }
  return changes;
}

const prev = { title: "Hi", count: 0, color: "red" };
const next = { title: "Hi", count: 1, color: "red" };

console.log(diff(prev, next));   // [ "count: 0 -> 1" ]  <- only count is committed
console.log(diff(prev, prev));   // []  <- nothing changed, DOM untouched

Your turn — decide commit vs skip:

// 🎯 YOUR TURN — fill in each ___ then press "Try it Yourself".
// A re-render produces a NEW snapshot, but React BAILS OUT when the
// new value equals the old one (Object.is comparison).
// 1) Compare with === to decide if a commit is needed.
// 2) Return "commit" or "skip".

function willCommit(prevValue, nextValue) {
  return prevValue ___ nextValue ? "skip" : ___;  // 👉 ===   and   "commit"
}

console.log(willCommit(5, 5));      // skip
console.log(willCommit(5, 6));      // commit
console.log(willCommit("a", "a"));  // skip

// ✅ Expected output:
//    skip
//    commit
//    skip

3️⃣ Re-render ≠ DOM Update, and Bailing Out

A re-render is just React re-running your function and re-diffing — it is usually cheap. If the produced tree matches the previous one, no DOM is touched. React also bails out: if you set state to a value equal to the current one (by Object.is), it can skip the work entirely. For expensive subtrees, React.memo, useMemo, and useCallback help skip re-renders — but profile before optimizing.

// Bail-out: setting the SAME value skips the re-render.
function handleClick() {
  setCount(c => c);   // returns the same value -> React may bail out
}

// Skip re-rendering an expensive child whose props did not change:
const ExpensiveList = React.memo(function ExpensiveList({ items }) {
  return <List items={items} />;
});

🧩 Reorder Challenge

These steps describe React's pipeline from a state change to the screen. Put them in the right order:

A.   Diff the new tree against the previous one (reconcile)
B.   A state setter is called, scheduling an update
C.   Commit only the differences to the real DOM
D.   Run your component to build a new virtual DOM
E.   Run effects (useEffect) after paint

Common Errors (and the fix)

• "My change does not show up." — You mutated a variable instead of calling a state setter. React only re-renders on state/props changes.
• List items jump or lose input. — Using array index as key. Use a stable, unique id so reconciliation matches items.
• Premature memo everywhere. — Memoizing cheap components adds overhead. Profile first; most re-renders are fine.
• Side effects in render. — Fetching or writing the DOM during render breaks purity. Put it in useEffect.

📋 Quick Reference

🧠 Quick Recall

1. Name the three things that trigger a re-render.

A state update, a change in received props, or the parent re-rendering.

2. Does every re-render update the DOM?

No. Only the diff is committed; if the new tree matches the old one, the DOM is untouched.

3. What do keys help React do?

Match list items across renders during reconciliation so it reuses unchanged ones instead of rebuilding.

Mini-Challenge: Count the Commits

A series of state updates arrives over time. A commit happens only when the new value differs from the last committed one. Count the commits and check your output.

// 🎯 MINI-CHALLENGE: count how many re-renders actually touch the DOM
//
// You are given a list of state updates. A render "commits" only when the
// new count differs from the previous one.
// 1. Walk the updates, tracking the previous committed count.
// 2. Count how many updates cause a real DOM commit.
// 3. console.log the number of commits.
//
// ✅ Expected output:
//    3

const updates = [0, 0, 1, 1, 2, 5, 5];  // setState calls over time

// your code here

🎉 Lesson Complete

• ✅ Render builds a virtual DOM; commit updates the real one
• ✅ Re-renders come from state, props, or a parent
• ✅ Reconciliation diffs trees and commits only changes
• ✅ A re-render is not automatically a DOM update — React bails out when it can

Practice quiz

Continue this course

• Previous: useState in Depth
• Next: Immutable State Updates — Update arrays and objects without mutation so React actually re-renders
• Quick reference: React cheat sheet

Frequently asked questions

Does a re-render always update the DOM?

No. A re-render runs your component function and produces a new virtual DOM. React diffs it against the previous one; only the differences are committed to the real DOM. If nothing changed, the DOM is untouched.

What triggers a re-render?

Three things: a state update via a setter, a change in the props a component receives, or its parent re-rendering. Changing a plain variable does not — React must know via state.

What is reconciliation?

Reconciliation is the diffing step where React compares the new virtual DOM tree to the previous one, decides the minimal set of changes, and applies them. Keys help it match list items correctly.

How can I stop unnecessary re-renders?

Bail out with React.memo for components, useMemo/useCallback for derived values and functions, and stable keys for lists. But measure first — most re-renders are cheap.

Related lessons

• Fragments & Multiple Elements