How React Works

The 30-second version

You've built a page or two with ReactReactA JavaScript library for building user interfaces from components: you describe what the UI should look like for the current data, and React updates the DOM to match.. You've also probably hit one of these: you sort a list and the text you typed jumps into the wrong row; or you add a console.log and discover a component ran 300 times while you typed one word. Both make sense once you know what React actually does between setState and the screen.

People write this as UI = f(state): the screen is a function of the data. You never write "find the third <li> and change its text". You write a function that returns the whole list, and React works out the edits for you.

Here's the smallest example. Each click asks React for a new render; React calls Counter again, sees that only the number changed, and updates one text node.

import { useState } from "react";

export function Counter() {
  const [count, setCount] = useState(0);         // ← data this component remembers
  return (
    <button onClick={() => setCount(count + 1)}>  {/* ← asks React for a re-render */}
      Clicked {count} times
    </button>
  );
}

The rest of this topic opens up each box of the diagram: what an element is (§02), the two phases (§03), how the comparison works (§04–05), why components re-render and how to stop it (§06–07), and what React 18 and 19 changed (§08–11). For the hooks themselves in depth, read React Hooks, Honestly next.

Components, elements and instances

Most confusion about React comes from mixing up three words. Using the film set from §01:

Two <Counter /> on a page are one component, two instances (two separate counts), and a fresh pair of elements on every render.

JSX is just function calls

Browsers can't run JSXJSXHTML-like syntax inside JavaScript (<Button onClick={save}>Save</Button>) that a build tool turns into ordinary function calls creating React elements.. Your build tool rewrites every tag into a call to a function from react/jsx-runtime, and that call returns an element. Pick an example below. The compiled code is what this site's own build tool (Vite 8) produces, and the object on the right was created by React 19 in your browser just now.

<h1 className="title">Hello, {name}</h1>

import { jsxs as _jsxs } from "react/jsx-runtime";

_jsxs("h1", {
  className: "title",
  children: ["Hello, ", name]
});

{
  $$typeof: Symbol(react.transitional.element),
  type: "h1",
  key: null,
  props: {
    className: "title",
    children: [
      "Hello, ",
      "Ada"
    ]
  }
}

Three things to notice:

1. type is either a string or your function. A lowercase tag ("h1", "div") means "a built-in DOM element". A capitalized name means "call this component". That's why components must start with a capital letter: <greeting /> would be treated as an unknown HTML tag.
2. Creating an element doesn't run your component. <Greeting name="Ada" /> only records "Greeting, with these props". React decides when (and whether) to call Greeting.
3. key isn't a prop. It's stored next to props, for React's own use. We'll see why in §05.

Elements are cheap, disposable descriptions

An element is a few fields in an object. Making thousands of them costs microseconds, and nothing on the page changes when you do. They're also treated as ImmutableImmutableCan't be changed after it's created. To “change” an immutable value you make a new one. Immutable objects can be shared freely, because nobody can modify them under you.: in development buildsDevelopment vs production buildA development build (what npm run dev serves) includes extra checks and readable warnings (and, under StrictMode, deliberately runs some code twice to expose bugs), so it runs much slower. A production build (npm run build) strips all of that; it's what real users get. React freezes them (Object.isFrozen(element) is true; we checked with React 19.3), so code that tries to edit one fails loudly. To "change" an element you render again and return a new one.

That's the trick behind the whole library: describing the UI is cheap, so React lets you re-describe all of it on every change, and only pays for the real DOM work where the description actually differs.

State belongs to instances, not to functions

When Counter runs, useState doesn't keep the number inside the function (a function's local variables vanish when it returns). React keeps it in the instance for that spot in the tree, and hands it back on the next call. Internally React calls these instance records fibersFiberReact's internal object for one instance in the tree: it records the component type, props, state, effects and links to parent, child and sibling. The tree of fibers is what React compares against..

So far: your function returns a tree of elements. Next, what React does with that tree, and when the page actually changes.

Render, then commit

Step through one click on a counter. Keep an eye on which column changes.

1function Counter() {
2  const [count, setCount] = useState(0);
3  useEffect(() => {
4    document.title = `Clicked ${count} times`;
5  });
6  return (
7    <button onClick={() => setCount(count + 1)}>
8      Clicked <Label n={count} />
9    </button>
10  );
11}
12 
13function Label({ n }) {
14  return <b>{n}</b>;
15}

The same thing, for real

That walkthrough is a drawing. Here is the same component running live, with a timestamped log. Click it a few times.

What the log proves, every time:

1. setCount doesn't change count. Right after calling it, the handler still sees the old value. The new value only exists in the next render (§08 explains why).
2. During render, the DOM still shows the old value. Label runs while the page still says the old number. The DOM changes later, in the commit.
3. useLayoutEffect sees the new DOM, and runs before the browser paints. useEffect runs after it.

Rendering must be pure

Because the render phase is just a calculation, React treats it as one. It may call your component more than once for one update (StrictMode does it on purpose, §09), call it and throw the result away (concurrent rendering, §10), or skip calling it entirely (§07). That's only safe if your component is a pure functionPure functionA function that, given the same inputs, always returns the same result and changes nothing outside itself (no network calls, no writing to variables it doesn't own). React expects rendering to be pure. of its props and state.

function Profile({ user }) {
  document.title = user.name;          // touches the page during render
  fetch(`/api/seen/${user.id}`);       // may fire 2× or for a render that's never shown
  return <h1>{user.name}</h1>;
}

function Profile({ user }) {
  const title = user.name.trim();      // pure calculation: fine
  useEffect(() => {
    document.title = title;            // after the commit
  }, [title]);
  return <h1>{title}</h1>;
}

A Side effectSide effectAnything an operation changes in the outside world besides returning a value: a row written, a card charged, an email sent. Side effects are what make repeating a request dangerous. is anything that changes the world outside the return value: the DOM, the network, a variable outside the component, the console. Event handlers and effects are where they belong. Rendering is for deciding what the UI should look like.

Reconciliation: comparing two trees

After a render, React holds two trees of elements: last time's and this time's. ReconciliationReconciliation (React)React comparing the elements your components just returned with the ones from the previous render, to decide what to keep, update, create or destroy. is the job of turning the difference into DOM operations.

Two words we'll use a lot from here on: React mounts a component when it creates a new instance (and its DOM) at a spot, and unmounts it when it removes that instance, throwing away its state.

A perfect "smallest number of edits between two trees" algorithm is far too slow for UI work (it grows roughly with the cube of the number of nodes). So React uses two simple rules that are fast (one pass over the tree) and right almost all the time:

1. Elements of different types produce different trees. If a div became a section, or <Counter> became <Timer>, React doesn't look inside. It removes the old subtree and builds the new one.
2. Within a list of children, a key says which item is which. Without keys, React goes by position (§05).

Walk through one comparison

1function Profile({ user, editing }) {
2  return (
3    <div className="card">
4      <h2>{user.name}</h2>
5      <Counter />
6      {editing ? <form>…</form> : <p>{user.bio}</p>}
7    </div>
8  );
9}

At each position React asks one question first: is the type the same?

Try it: same position, different type

{fancy
  ? <TapCounter label="fancy" />
  : <TapCounter label="plain" />}

{wrap
  ? <section><TapCounter /></section>
  : <div><TapCounter /></div>}

<TapCounter key={person}
            label={person} />

Case B is the one that bites in real apps. Code like this looks harmless:

function Layout({ isMobile }) {
  if (isMobile) {
    return <div className="stack"><SearchBox /></div>;
  }
  return <main className="grid"><SearchBox /></main>;   // ← different type than <div>
}

Rotate a phone, isMobile flips, the wrapper type changes, and the user's half-typed search disappears. Keep the same element type and change its props instead:

function Layout({ isMobile }) {
  return (
    <div className={isMobile ? "stack" : "grid"}>   {/* ← same type in both cases */}
      <SearchBox />
    </div>
  );
}

What "position" means

Position is the path from the root: "the second child of the first child of App". A conditional that sometimes renders nothing keeps the positions after it stable, because false/null still occupy a slot:

<div>
  {showBanner && <Banner />}   {/* slot 0: Banner or false */}
  <Form />                     {/* slot 1: always Form, so its state survives */}
</div>

That's why toggling the banner doesn't reset the form. React compares slot 1 with slot 1, whatever happened in slot 0.

Keys: telling React who is who

In a list, "position" is a bad way to identify things. Sort the list and every item changes position. React needs another way to say "Apple's row is still Apple's row", and that's the keykey (React)A special prop (key="…") that tells React which item is which in a list, so it can match old and new items by identity instead of by position. It is not passed to your component..

Watch the bug happen

Each row below has two kinds of state: the text box is an uncontrolled inputUncontrolled inputA form field that keeps its own value in the DOM, like plain HTML. React may give it a starting value (defaultValue) and reads it when needed, typically on submit with FormData or a ref. (its text lives in the DOM element), and the ★ is React state (useState) inside the row. Each row also remembers which fruit it was created for. Start with key={index}.

{items.map((item, index) => (
  <FruitRow key={index} item={item} />
))}

Here's the "Add to top" case with index keys, written out:

React did exactly what it was told: it compared key 0 with key 0. The fruit names are props, so they updated. The typed text and the ★ belong to the row instances, which didn't move. The data and the state are now out of sync, and nothing warns you.

With key={item.id} the same action reads: "key 4 is new → create it and insert it at the top; keys 1, 2, 3 are the same items in the same order → leave them alone". One DOM insert, and every row keeps its own text.

Rules for keys

// ✓ ids from the data
{todos.map((todo) => <TodoRow key={todo.id} todo={todo} />)}

// ✓ no id? make one ONCE, when the item is created, not during render
const addTodo = (text) =>
  setTodos((ts) => [...ts, { id: crypto.randomUUID(), text }]);

Keys outside lists: resetting state on purpose

A key works on any element, not just list items. Changing it tells React "this is a different thing now", so React throws away the old instance and builds a fresh one with fresh state. That's case C from §04, and it's the cleanest way to reset a form when the thing it edits changes:

function ContactPage({ contact }) {
  // A new contact id → a fresh EditForm with empty fields, no stale draft from the last contact.
  return <EditForm key={contact.id} contact={contact} />;
}

The alternative, an effect that watches contact.id and clears every field, renders the stale form first and then corrects it. The key version never shows stale data.

Why a component re-renders

Notice what's missing: "its props changed". Props are just the arguments a parent passes. They can only change because the parent rendered again, and when the parent renders again, React calls all its children again by default, whether their props changed or not.

In the film set: when the script for a scene changes, the director re-sketches that scene and every shot inside it, without first checking whether each inner shot's notes changed. Re-sketching is cheap, and checking costs time too.

Watch the three reasons

Each box below is a real component with a live count of its renders. Try each control and predict which boxes will flash before you click.

What you should see:

Two of those deserve a closer look.

memo(Card) re-renders anyway. Its parent passes style={{ color: "white" }}, and that { … } creates a brand-new object on every render. memo compares props with Object.is, and two different objects are never the same valueSame value (Object.is)How React compares props and state: numbers and strings compare by value, but objects, arrays and functions compare by identity. {a: 1} is never the same as another {a: 1} created later., even with identical contents. More in §07.

The Sidebar never re-renders, although it sits inside App and isn't wrapped in memo. It's passed in as childrenchildren propWhatever you put between a component's opening and closing tags (<Card>…</Card>) arrives as props.children. It's an element (or several) created by the parent that wrote the JSX.:

function Page() {
  return (
    <App>
      <Sidebar />   {/* ← this element is created here, by Page */}
    </App>
  );
}

function App({ children }) {
  const [text, setText] = useState("");   // typing changes App's state…
  return <div>{/* …input… */}{children}</div>;  // …but `children` is the same element object as before
}

When App re-renders, it returns children — the same element object Page created last time. React sees an identical element and skips it. Only Page re-rendering would make a new one. This is the cheapest optimization in React: move the state down, or pass the slow part in from above, and the slow part stops re-rendering.

Context, up close

ContextContext (React)A way to pass a value to every component below a Provider without threading it through props at each level. Components read it with useContext (or use() in React 19) and re-render when it changes. In React 19 you can write <MyContext value={…}> instead of <MyContext.Provider value={…}>. lets a value skip the props chain: a Provider high up, useContext anywhere below. The cost: every component that reads a context re-renders when its value changes, wherever it sits and whatever memo says. React decides "changed" with Object.is on the value prop.

The classic mistake is one context holding everything:

const AppContext = createContext(null);

function AppProvider({ children }) {
  const [theme, setTheme] = useState("dark");
  const [user, setUser] = useState(null);
  return (
    <AppContext.Provider value={{ theme, user, setTheme, setUser }}>  {/* ← new object every render */}
      {children}
    </AppContext.Provider>
  );
}

Changing theme produces a new value object, so a component that only shows the user's name re-renders too. Try it: all three children below are wrapped in memo, so only a context can re-render them.

Three fixes, from simplest:

1. Split contexts by how often things change together: ThemeContext, UserContext. A consumer subscribes only to what it reads. (The "split" toggle above.)
2. Memoize the value with useMemo(() => ({ theme, user }), [theme, user]), so that a re-render of the provider for some other reason doesn't create a new object. This doesn't help when theme itself changes — that's what splitting is for.
3. Use a store with selectorsSelectorA small function that picks out just the part of a shared store a component needs (state => state.user.name), so the component re-renders only when that part changes. when many components each need a small slice of frequently changing data. That's a state-management question, covered in State Management.

Skipping work with memo — and measuring it

By default a parent re-render re-renders every child (§06). React.memoReact.memoA wrapper (memo(Component)) that makes React skip re-rendering that component when its parent re-renders, as long as every prop is the same value (Object.is) as last time. adds a check in front of one component: for each prop, is the new value the same valueSame value (Object.is)How React compares props and state: numbers and strings compare by value, but objects, arrays and functions compare by identity. {a: 1} is never the same as another {a: 1} created later. as before (Object.is)? If every prop passes, React reuses last time's result and skips that whole subtree.

import { memo } from "react";

function Row({ item }) {
  return <li>{item.name}</li>;
}

export const MemoRow = memo(Row);   // ← same component, plus a props check in front

The 300-renders-per-keystroke component, measured

Here's the opening puzzle from §01: a parent with a text box, and a list of rows that don't even use the text. Every keystroke re-renders the parent, so every row re-renders. Try both sizes and both versions; the numbers are measured live in your browser.

Our measurements with this exact widget, in a production build of this site in headless Chromium on this machine (median of 30 keystrokes, two runs; render + commit only):

So yes, typing ran the row function 300 times per keystroke. And it cost about half a millisecond, out of a Frame budgetFrame budgetAt 60 frames per second each frame gets about 16.7 ms for JavaScript, style, layout, paint and compositing. Go over it and animations stutter (“jank”). of about 16.7 ms. Those 300 renders were never the problem. With 3,000 rows memo saves 2–3 ms per keystroke: real, but still small.

Notice that memo(Row) isn't free either: the parent still creates 3,000 elements and React still compares each one's props, about 1 ms here. memo starts to matter when each skipped render does real work (big subtrees, heavy calculations, charts) and the parent re-renders often.

Why memo silently stops working

memo only helps if the props are the same value from one render to the next. Three common ways they aren't:

function List({ items }) {
  return items.map((item) => (
    <MemoRow
      key={item.id}
      item={item}
      style={{ padding: 4 }}           // new object each render
      onSelect={() => select(item.id)} // new function each render
    >
      <Icon />                         {/* new element each render */}
    </MemoRow>
  ));
}

const rowStyle = { padding: 4 };       // created once, outside
const icon = <Icon />;                 // an element made once, outside

function List({ items }) {
  const [selectedId, setSelectedId] = useState(null);
  return items.map((item) => (
    <MemoRow
      key={item.id}
      item={item}
      style={rowStyle}
      icon={icon}                      // MemoRow renders {icon}
      onSelect={setSelectedId}         // a state setter is the same function every render
    />                                 // MemoRow calls onSelect(item.id)
  ));
}

Cheaper than memo: change the shape

Before reaching for memo, try the two moves from §06. They need no comparisons at all:

1. Move state down. If only the search box needs query, put useState in a small SearchBox component. Typing then re-renders SearchBox, not the page.
2. Lift content up. Pass the expensive part in as children from a component that doesn't re-render, so the element object stays the same.

Batching: setState is a request

Each render sees a snapshot

Inside one render, count is a plain constant. Your event handler is a ClosureClosureA function that remembers the variables around where it was created, even after that outer function has returned. Both Go and JS have them. created during that render, so it sees that render's count forever. Calling setCount doesn't reach back and change it:

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

  function handleClick() {
    setCount(count + 1);   // "set it to 0 + 1"
    setCount(count + 1);   // "set it to 0 + 1" again
    setCount(count + 1);   // and again
    console.log(count);    // 0 — this render's value never changes
  }
  // After the click: ONE render, and count is 1, not 3.
  return <button onClick={handleClick}>{count}</button>;
}

To build on the previous update, pass an updater functionUpdater functionPassing a function to a state setter, like setCount(c => c + 1). React calls it with the latest queued value, so several updates in a row stack up correctly.. React queues the functions and runs them in order, each receiving the result of the one before:

setCount((c) => c + 1);   // 0 → 1
setCount((c) => c + 1);   // 1 → 2
setCount((c) => c + 1);   // 2 → 3   — one render, count is 3

Try every case

setCount(count + 1);
setCount(count + 1);
setCount(count + 1);

What we measured with React 19.3 (and what you should see):

The setTimeout and await rows are new since React 18 ("automatic batching"). Before that, React only batched inside its own event handlers, so the same two lines inside a timer caused two renders. If you read older blog posts, that's why they disagree.

The escape hatch: flushSync

Occasionally you need the DOM updated now, before the next line runs: for example, to scroll to an item you just added.

import { useRef, useState } from "react";
import { flushSync } from "react-dom";

function Chat() {
  const [messages, setMessages] = useState([]);
  const listRef = useRef(null);              // ← React will put the <ul> DOM node in listRef.current

  function addMessage(text) {
    flushSync(() => {
      setMessages((ms) => [...ms, { id: crypto.randomUUID(), text }]);   // render + commit happen inside this call
    });
    listRef.current.lastElementChild.scrollIntoView();   // the new <li> is in the DOM now
  }

  return (
    <ul ref={listRef}>
      {messages.map((m) => <li key={m.id}>{m.text}</li>)}
    </ul>
  );
}

flushSyncflushSyncA react-dom function that forces React to process the updates inside it immediately, render and commit, before the next line runs. An escape hatch that defeats batching; rarely needed. forces a synchronous render and commit, defeating batching. It's rare and costs performance; most code never needs it.

StrictMode: why everything runs twice in dev

Almost every new React project (Vite's template included) wraps the app in <StrictMode>. Then a console.log in a component prints twice, or an effect fetches twice, and people assume React is broken. It's a test, run on every render, that catches two real bugs early.

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";

createRoot(document.getElementById("root")).render(
  <StrictMode>     {/* ← development checks for everything inside */}
    <App />
  </StrictMode>
);

Check 1: rendering twice catches impure components

§03 said render must be purePure functionA function that, given the same inputs, always returns the same result and changes nothing outside itself (no network calls, no writing to variables it doesn't own). React expects rendering to be pure., because React may call your function more than once. StrictModeStrictMode (React)A development-only wrapper (<StrictMode>) that calls your components twice and mounts effects twice to expose impure rendering and missing cleanups. It does nothing in a production build. makes that happen every time, so impurity shows up while you're developing instead of as a rare bug in production:

let nextId = 0;

function Comment({ text }) {
  const id = nextId++;    // ← changes a variable outside the component: impure
  return <p id={`c${id}`}>{text}</p>;
}
// Every render takes a new id, so the same comment's id changes whenever it re-renders.
// StrictMode makes that obvious from the first render: the ids jump by 2.

React uses only one of the two results, so a pure component behaves exactly the same. (If the doubled console.log lines bother you, the React DevTools browser extension has a setting to dim or hide logs from the second call.)

Check 2: mount, unmount, mount catches missing cleanups

When a component first mountsMount / unmountMount: a component appears on the page for the first time and React creates its state. Unmount: it is removed, and its state and effects are thrown away., StrictMode runs its effects: setup → cleanup → setup. If your effect subscribes to something and the cleanup doesn't unsubscribe, you'll now see two subscriptions, for example two chat messages arriving for every one sent. The fix is always the same: return a cleanup that undoes the setup.

useEffect(() => {
  const id = setInterval(tick, 1000);
  // nothing returned: the interval runs forever,
  // and StrictMode leaves you with two
}, []);

useEffect(() => {
  const id = setInterval(tick, 1000);
  return () => clearInterval(id);   // ← undo exactly what setup did
}, []);

Why simulate an unmount at all? Because real apps unmount and remount components all the time: navigating away and back, a list item scrolling out and in, and React's <Activity> component (part of React 19.3, which this site uses), which hides a part of the UI and restores it later with its state kept. An effect that survives setup → cleanup → setup is ready for all of them.

Concurrent rendering and transitions

Before React 18, once a render started it ran to the end. JavaScript has one Main threadMain threadThe single browser thread that runs your JavaScript and also does style, layout and most painting. While it's busy with a long task, the page can't respond to clicks or update., so a 120 ms render meant 120 ms in which the browser couldn't paint your keystroke. Concurrent renderingConcurrent renderingReact's ability to prepare a render in small slices, pause to let the browser handle input, and throw a half-done render away if newer data arrives. Still one thread; it's about interruption, not parallelism. doesn't add threads. It makes the render phase pausable, which is safe precisely because rendering is pure (§03): nothing has touched the DOM yet, so stopping halfway leaves no mess.

You opt in per update: transitions

React can't guess which updates may wait. By default every update is urgent. You mark the non-urgent ones as a TransitionTransition (React)A state update marked as non-urgent with startTransition or useTransition. React may delay or interrupt rendering it so urgent updates, like typing, stay fast.:

import { useState, useTransition } from "react";

function Search() {
  const [text, setText] = useState("");     // what's in the box: urgent
  const [query, setQuery] = useState("");   // what the slow list filters by: can wait
  const [isPending, startTransition] = useTransition();

  function onChange(e) {
    setText(e.target.value);                // ← urgent: the box must show the keystroke now
    startTransition(() => {
      setQuery(e.target.value);             // ← non-urgent: render the list when there's time
    });
  }

  return (
    <>
      <input value={text} onChange={onChange} />
      <div style={{ opacity: isPending ? 0.5 : 1 }}>
        <SlowList query={query} />          {/* wrapped in memo, so it only re-renders when query changes */}
      </div>
    </>
  );
}

Feel the difference. Type a word quickly in each mode:

Our measurements, with the same list on a stand-alone page (production build, headless Chromium on this machine, 10 keystrokes typed 20 ms apart). On this site's full page the urgent version measured slower still, around 200 ms:

With the urgent version, every keystroke waits for a full list render, and the keystrokes queue up behind each other. With the transition, React commits the text box immediately, starts the list render, and abandons it whenever a newer keystroke arrives. While you keep typing, the intermediate lists are thrown away; a list is committed once you pause long enough for one to finish.

The same idea without owning the setter: useDeferredValue

If the value comes from props and you can't wrap its setter, useDeferredValue gives you a copy that "lags behind" during urgent updates:

function Results({ query }) {
  const deferredQuery = useDeferredValue(query);   // ← old value first, then the new one in the background
  return <SlowList query={deferredQuery} />;        // SlowList is memo'd, so the urgent render skips it
}

What concurrency does not do

• It doesn't make slow components faster. The list still takes about 125 ms of CPU to render; it just stops blocking typing. Fix genuinely slow renders with §07 or by rendering less (pagination, virtualized listsList virtualization (windowing)Rendering only the rows of a long list that are currently visible (plus a few extra), and swapping them as the user scrolls, so 10,000 items cost about as much as 20.).
• It doesn't help work outside React's render phase: a slow event handler or a heavy useEffect still blocks the thread.
• It isn't parallelism. Everything still runs on the one main thread, in slices. (Why one thread: Async / Await → the event loop.)

In production: profiling, the compiler, and VDOM costs

Step 1: profile a real interaction

The React ProfilerReact ProfilerA tab in the React Developer Tools browser extension (and a <Profiler> component) that records each commit: which components rendered, how long each took, and why. lives in the React Developer Tools browser extension (it adds "Components" and "Profiler" tabs to DevToolsDevToolsThe developer tools built into browsers (F12): inspect elements, see network requests, profile performance, debug JavaScript, check accessibility.). The workflow:

1. Open the Profiler tab, press record, do the slow thing (type in the search box, open the menu), stop.
2. You get one bar per commit. Pick the tall ones. Each shows a Flame graphFlame graphA chart of a profile: each bar is a function, its width shows how much time (or memory) it accounts for, and the functions it calls are stacked on top of it. Wide bars are where to look first. of the components that rendered in that commit and how long each took. Grey ones didn't render.
3. In the Profiler's settings, turn on recording why each component rendered. Selecting a component then shows the reason: "Hook 1 changed", "Props changed: (style)", "The parent component rendered". These map directly onto the three reasons from §06.
4. The Components tab settings can also highlight updates when components render, flashing them on the page like the demos in this topic.

The same numbers are available in code through the <Profiler> component, handy for logging render times from automated tests:

import { Profiler } from "react";

function onRender(id, phase, actualDuration, baseDuration) {
  // phase: "mount" | "update" | "nested-update"
  // actualDuration: ms spent rendering this commit (memo'd parts skipped)
  // baseDuration:   ms a full re-render of the subtree would take, with no skipping
  console.log(id, phase, actualDuration.toFixed(1), baseDuration.toFixed(1));
}

<Profiler id="ProductList" onRender={onRender}>
  <ProductList />
</Profiler>

Step 2: let the React Compiler memoize for you

Getting memo, useMemo and useCallback right everywhere (§07) is tedious and easy to break. The React CompilerReact CompilerA build-time tool (babel-plugin-react-compiler) that rewrites your components to cache values and elements automatically, so you need far fewer manual memo / useMemo / useCallback calls. is a build-time plugin that does it automatically. Version 1.0.0 of babel-plugin-react-compiler is the current release on npm (checked October 2026), and React 19 ships the small runtime it needs (react/compiler-runtime). This site doesn't use it; here is its real output for a small component:

export function List({ rows, query }) {
  const visible = rows.filter((r) => r.name.includes(query));
  return (
    <ul>
      {visible.map((r) => <Row key={r.id} row={r} />)}
    </ul>
  );
}

export function List(t0) {
  const $ = _c(7);                 // a per-instance cache with 7 slots
  const { rows, query } = t0;
  let t1;
  if ($[0] !== query || $[1] !== rows) {
    // …filter and map, only when an input changed…
    $[0] = query; $[1] = rows; $[2] = t1;
  } else {
    t1 = $[2];                     // ← reuse last time's elements
  }
  let t2;
  if ($[5] !== t1) {
    t2 = _jsx("ul", { children: t1 });
    $[5] = t1; $[6] = t2;
  } else {
    t2 = $[6];                     // ← return the SAME element object
  }
  return t2;
}

When rows and query haven't changed, List returns the same element object as last time. That's the "children" trick from §06 applied automatically: React sees an identical element and skips the whole subtree, with no memo call written by hand. The compiler relies on your components following the rules (pure render, no mutating props or state); when it spots code that breaks them, it leaves that component as it was instead of guessing. Adoption details: React Hooks, Honestly.

Step 3: know when the virtual DOM is overhead

Reconciliation is work on top of the DOM changes: render the components, then compare the trees, then patch. That pays off when you can't easily tell what changed. It's pure overhead when you already know exactly what changed, and that happens in a few places:

Some other frameworks (Solid and Svelte, for example) skip the diff entirely by tracking at build or run time exactly which DOM node each piece of state feeds. React chose the simpler model of "re-run the function and compare", and is closing the cost gap with the compiler instead.

Pitfalls

Every one of these comes straight from a rule earlier in the topic. If something in your app "acts weird", check this list first.

const add = (item) => {
  items.push(item);   // ✕ same array object, just changed
  setItems(items);    // same object (Object.is) → React bails out: nothing is committed
};
const addFixed = (item) => setItems((xs) => [...xs, item]);   // ✓ a new array

function Profile({ user }) {
  const [name, setName] = useState("");
  setName(user.name);   // ✕ every render asks for another render
  return <h1>{name}</h1>;
}

Check yourself: predict what React does

Commit to an answer before you click. If you miss one, go back to the live demo for that rule and make it happen in front of you.

function Counter() {
  const [count, setCount] = useState(0);
  function handleClick() {
    setCount(count + 1);
    setCount(count + 1);
    console.log(count);
  }
  return <button onClick={handleClick}>{count}</button>;
}
// the user clicks once

function App() {
  const [n, setN] = useState(0);
  return (
    <>
      <button onClick={() => setN(n + 1)}>{n}</button>
      <Header />            {/* takes no props */}
      <Footer year={2026} />
    </>
  );
}

function Page({ compact }) {
  return compact
    ? <div><SearchBox /></div>
    : <main><SearchBox /></main>;
}

Cheat sheet