How React renders

To master React, you must understand how it renders. Most confusing React behaviour and performance issues come from misunderstanding the render cycle. This lesson builds an accurate mental model: what "rendering" really means, when it happens, and how React efficiently updates the DOM. Everything advanced builds on this.

Rendering is calling your component function

When React "renders" a component, it simply calls your component function to get the JSX it returns. Rendering is not (directly) updating the DOM — it's React asking "given the current props and state, what should this look like?":

Every render runs your function from top to bottom. So a component's body executes repeatedly — once per render. This is why you don't do side effects directly in the body (they'd run every render) and why state (not plain variables) is needed to persist values. Rendering = calling the function to compute the UI description.

Render, then commit

React rendering has two phases:

1. Render phase — React calls your components to build a virtual description of the UI (a tree of elements). This is pure computation; nothing touches the real DOM yet.
2. Commit phase — React compares the new description with the previous one and updates only the changed parts of the real DOM.

Each second, React re-renders Clock (runs the function), builds a new element tree, diffs it against the last, and updates only the number in the real DOM. This diffing (the "virtual DOM" reconciliation) is why React is efficient — it doesn't rebuild the whole page, just the differences.

What triggers a re-render

A component re-renders when:

• Its state changes (a setState call).
• Its parent re-renders (which re-renders its children by default).
• Its context value changes (later lesson).

Props changing does not, by itself, trigger a re-render — rather, a parent re-rendering (which passes new props) causes children to re-render. Understanding these triggers is key to reasoning about when your components run, and to fixing unnecessary re-renders (a major performance topic ahead).

Renders are (should be) pure

React expects rendering to be pure: given the same props and state, a component should return the same JSX, with no side effects during render (no DOM manipulation, no data mutation, no fetching in the body). Side effects go in useEffect (which runs after commit). Purity lets React call your components freely (even multiple times, or discard a render) safely — the basis of many React features.

The mistake beginners make

Thinking a "render" directly updates the DOM (it doesn't — render computes, commit updates), or that components run once (they run on every render). This misunderstanding causes bugs (side effects in the body running repeatedly) and confusion about performance. Also, doing side effects or mutations during render (breaking purity). Understand: rendering calls your function to compute UI, React diffs and commits only changes, re-renders come from state/parent/context, and render must be pure — side effects belong in effects.

Your turn

Your turn

1. Understand rendering = React calling your component function to compute the UI (it runs on EVERY render).
2. Know the two phases: render (build a virtual tree, pure) then commit (diff and update only changed DOM).
3. Know what triggers re-renders (state change, parent re-render, context) and that renders must be pure.

Key points

• Rendering means React CALLS your component function to compute UI — the body runs on every render (not once).
• Two phases: render (build a virtual element tree, purely) then commit (diff vs previous, update only changed DOM).
• Re-renders are triggered by: state changes, a parent re-rendering, or context changes.
• Renders must be PURE (same inputs → same output, no side effects) — side effects go in useEffect (after commit).