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:

Render phase ("figure out UI")

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

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.