What a React Render Actually Is

Most React developers say "the component re-renders" without a precise picture of what that means. By the end of this lesson you'll have one: you'll know exactly what happens when React "renders," how that differs from updating the screen, and you'll watch the difference happen in a running app. This is the mental model every later topic — hooks, state, performance — is built on.

What you need to know

The word "render" is overloaded. Pin it down: a render is React calling your component function. That's it. It is not the browser drawing pixels. Confusing these two is the root of most fuzzy React reasoning.

React puts a component on screen in three steps (React docs — Render and Commit):

1. Trigger — something asks for a render.
2. Render — React calls your component to figure out what to show.
3. Commit — React applies the result to the DOM.

Then, and only then, the browser paints the updated DOM to the screen.

Step 1 — Trigger. There are exactly two reasons a render happens (docs):

• The initial render, when your app first mounts.
• A state update. "Updating your component's state automatically queues a render." Props changing, or a parent re-rendering, do their work through this same machinery — but the trigger is always one of these two.

Step 2 — Render. React calls your function. Whatever JSX you return is a description of the UI, not the UI itself. Rendering is recursive: if your component returns other components, React calls those too, "and so on… until there are no more nested components" (docs). (That recursion is the whole story of why children re-render — we'll pull that apart in Lesson 2.)

Because React may call your component whenever it wants — and, in development, twice — rendering must be a pure calculation: "Given the same inputs, a component should always return the same JSX," and it "should not change any objects or variables that existed before rendering" (React docs — Keeping Components Pure). Don't mutate, don't fetch, don't console.count into shared state during render. Purity is the contract that makes the three-step model safe.

Step 3 — Commit. Now React touches the real DOM — and here's the part worth burning in: "React only changes the DOM nodes if there's a difference between renders." On a re-render it "applies the minimal necessary operations… to make the DOM match the latest rendering output" (docs). Your function may run and return a whole tree of JSX, yet React might change a single text node. Rendering always happens; committing to the DOM often barely happens.

That gap — function runs fully, DOM changes minimally — is the thing we're about to see directly.

Do it

You need a running React app. Fastest local path:

npm create vite@latest render-lab -- --template react
cd render-lab
npm install
npm run dev

(Or drop the component into a fresh StackBlitz React if you'd rather not install anything.)

Replace src/App.jsx with this and open the browser console:

import { useState } from 'react';

export default function App() {
  console.log('🔵 App function ran (a render)');

  const [count, setCount] = useState(0);

  return (
    <div style={{ fontFamily: 'sans-serif', padding: 24 }}>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>Increment</button>

      {/* Uncontrolled input: React never manages its value. */}
      <input placeholder="type here, THEN click Increment" />
    </div>
  );
}

Do these two experiments, watching the console and the input:

Experiment A — the render log. On load, how many times does 🔵 App function ran print? You'll likely see it twice. That's not a bug: in development, Strict Mode calls your component twice on purpose to surface impurities (Keeping Components Pure). The fact that running your component twice is safe is the purity contract in action. (In a production build it runs once.)

Experiment B — render vs. commit. Type some text into the input — but do not press Enter. Now click Increment a few times.

• The console logs 🔵 App function ran on every click → the function re-ran: a render happened every time.
• Count: updates → React committed a change to that text node.
• Your typed text stays put. You never stored it in state, yet a full re-render didn't wipe it.

That last point is the whole lesson in one observation. Each click re-ran App, producing a brand-new JSX description that includes the <input>. Yet the text survived because, in the commit step, React saw the input's DOM node was unchanged and left it — and its live value — completely alone. Render recomputed everything; commit touched only the count.

Check yourself

Answer from memory first, then verify by running or re-reading. Effortful recall now is what makes this stick.

1. Define, in one sentence each: a render and a commit. Which one always happens on a state update, and which one might do nothing?

2. Predict the console. Starting from the code above, you click Increment exactly 3 times (production build, no Strict Mode). How many times does 🔵 App function ran print in total, counting the initial render?

   • a) 1
   • b) 3
   • c) 4
   • d) 7

3. Spot the violation. Which line breaks the rule that rendering must be pure — and therefore is unsafe for React to call twice?

   • a) const [count, setCount] = useState(0);
   • b) window.scrollCount = window.scrollCount + 1;
   • c) return <p>Count: {count}</p>;
   • d) const doubled = count * 2;

Go deeper

Read this next (primary source): React docs — Render and Commit. It's short, and it's the canonical statement of the model you just watched in action. Follow it with Keeping Components Pure to cement why the render step must be side-effect-free.

Coming in Lesson 2: we take the recursive-render fact — "if a component returns other components, React renders those too" — and use it to answer the question that trips up most working React devs: when a parent re-renders, which children re-render, and why doesn't changing props have anything to do with it?