React Rendering: The Mental Model

30‑second interview answer

In React, rendering means React calls your components to compute what the UI should look like for the current props/state. React then reconciles the new result with the previous one to figure out the minimum set of changes, and finally commits those changes to the DOM. A re-render doesn’t automatically mean the DOM changed—it means React re-ran your component function.

The mental model (keep it simple)

Think of React as a two-step system:

1. Render phase ("figure out UI")

• React calls your components.
• You return JSX (a description of UI).
• React builds a tree of elements.

2. Commit phase ("apply changes")

• React updates the DOM where needed.
• Effects (useEffect) are scheduled after commit.

If you can explain these two phases clearly, you’ll sound senior.

What triggers a render?

A component can render because:

• Its state changed (setState, useReducer).
• Its props changed (parent re-rendered and passed new props).
• Its context changed (a context provider value changed).
• A parent rendered (even if props are the same, unless memoization prevents it).

Important: parent renders ≠ child DOM updates

Parent rendering causes children to be called again by default, but React can skip work in some cases (e.g., React.memo, stable props, etc.).

Re-render vs DOM update (the interview trap)

Re-render: React calls your component function again.

DOM update: React actually changes real DOM nodes.

Example:

function Counter() {
  console.log('render');
  const [count, setCount] = React.useState(0);
 
  return (
    <button onClick={() => setCount(count)}>No-op update</button>
  );
}

• Clicking may still cause a render attempt, but React can bail out if state is unchanged.
• Even if React renders, it may detect no changes and commit nothing.

Reconciliation: how React decides what changed

At a high level:

• React compares the previous element tree with the next element tree.
• It uses type and key to decide whether to:
  • update an existing node, or
  • destroy and recreate it.

Why keys matter

Keys are how React keeps identity stable in a list. Without stable keys, React may reuse the wrong component instance and you get weird UI bugs.

(You’ll cover this in the “Keys in lists” lesson.)

Batching: why multiple state updates can be one render

React often batches state updates to reduce renders.

setCount(c => c + 1);
setCount(c => c + 1);

In modern React, this can become one render with a final value of +2.

Common mistakes interviewers test

1) Doing side effects in render

Render should be pure. Don’t fetch, don’t mutate globals, don’t do analytics.

Use effects:

React.useEffect(() => {
  // fetch or subscribe here
}, []);

2) Confusing useEffect timing

• useEffect runs after the DOM is updated.
• useLayoutEffect runs earlier (before paint) and can block paint.

3) Assuming React.memo "stops re-renders"

It can skip re-rendering if props are referentially equal. If you pass new object/function props each render, memo won’t help.

Mini Q&A (practice)

Q1: If a parent re-renders, do all children re-render?

• By default, yes—React calls them again. But React may skip in some cases (memoization) and may skip DOM updates if output is the same.

Q2: What is reconciliation?

• The diffing process between previous and next element trees.

Q3: Where do effects run?

• After commit (useEffect).

Summary checklist

• I can explain render vs commit.
• I can say “re-render ≠ DOM update.”
• I can list render triggers (state/props/context/parent).
• I understand reconciliation at a high level.