Memoisation

What actually happens on a re-render

When a component re-renders, React re-renders all of its children by default, regardless of whether their props changed. That sounds alarming and usually is not: rendering is running a function and comparing objects, which is fast. The DOM is only touched where the output differs.

Memoisation is for the cases where that assumption breaks — a genuinely expensive calculation, or a large subtree re-rendering on every keystroke.

The three tools

useCallback(fn, deps) is exactly useMemo(() => fn, deps). It exists because that pattern is common enough to deserve a name.

memo, and why it so often does nothing

const Row = memo(function Row({ item, onSelect }) { ... });

<Row item={item} onSelect={() => select(item.id)} />   // ✗ memo defeated

memo does a shallow comparison of props. The arrow is a new function on every render, so the comparison always fails and the component re-renders anyway — now with the added cost of the comparison. The same is true of style={{ ... }}, options={[...]}, and any object built inline.

const handleSelect = useCallback((id) => select(id), [select]);
<Row item={item} onSelect={handleSelect} />              // ✓ stable

Which is the real lesson: memo is not one decision, it is a contract with every call site. Miss one prop and the whole thing is inert.

// ✗ SlowTree re-renders on every keystroke
function Page() {
  const [q, setQ] = useState("");
  return (<><input value={q} onChange={...} /><SlowTree /></>);
}

// ✓ the state moved down; SlowTree is now a sibling that never re-renders
function Page() {
  return (<><SearchBox /><SlowTree /></>);
}

Watch what re-renders

useMemo: when it is worth it

const sorted = useMemo(
  () => [...rows].sort(compare),
  [rows]
);                                // ✓ 10,000 rows, sorted on every keystroke otherwise

const total = useMemo(() => a + b, [a, b]);   // ✗ the memo costs more than the addition

useMemo is not free: it stores the value, stores the dependency array, and compares it on every render. For arithmetic and short strings the bookkeeping is more expensive than recomputing.

The second legitimate use has nothing to do with speed: referential stability. If a value goes into a dependency array or into a memoised child, memoising it stops that thing running every render.

const value = useMemo(() => ({ user, login }), [user, login]);
<AuthContext value={value}>      // ✓ or every consumer re-renders always

The rule that keeps this sane

1. Measure first. React DevTools Profiler, with "record why each component rendered" on. Find the component that is actually slow.
2. Fix the structure. Move state down, pass children, split the component. This removes the problem rather than caching it.
3. Then memoise, at the specific place the profiler pointed at.

Memoising everything as a habit makes the code harder to read, adds real overhead, and hides the one place it was needed among fifty where it was not.

Dependency arrays lie the same way here

const filtered = useMemo(
  () => rows.filter((r) => r.type === type),
  [rows]                          // ✗ type missing — stale forever
);

A missing dependency in useMemo is worse than in an effect, because it produces a wrong value rather than a skipped side effect, and it is silent.

The comparison is shallow, and you can override it

const Row = memo(Component, (prev, next) => prev.item.id === next.item.id);

Returning true means "equal, skip the render" — the opposite polarity from Array.prototype.sort's comparator, which catches people out. Custom comparators are rarely the right answer; a stable prop usually is.

The React Compiler changes the advice

React Compiler 1.0 shipped on 7 October 2025. It is a build-time plugin that reads your components and hooks, works out which values depend on which, and inserts the memoisation for you. Everything above still explains why a re-render happens; the compiler changes who writes the cache.

npm install --save-dev --save-exact babel-plugin-react-compiler@latest

What it does better than hand-written memo

function Row({ item, onSelect }) {
  if (!item.visible) return null;
  const label = formatLabel(item);          // the compiler can cache this
  return <li onClick={() => onSelect(item.id)}>{label}</li>;
}

You cannot call useMemo after an early return — it would break the rules of hooks. The compiler is not a hook, so it can memoise conditionally, after the return null, and it caches the inline arrow too. That is the category of optimisation manual memoisation could never reach.

What to do with the useMemo you already wrote

The React team's own guidance is to leave existing memoisation in place, or remove it only with testing, because deleting a useMemo can change what the compiler outputs. For new code, rely on the compiler and keep useMemo/useCallback as an escape hatch for the few places you need exact control — a value that must stay referentially stable for an effect dependency, for example.

Opting in and out, one function at a time

function LegacyChart() {
  "use no memo";                            // skip this one until it is fixed
  ...
}

function Checkout() {
  "use memo";                               // compile this one in annotation mode
  ...
}

Either directive can also sit at the top of a module to cover every function in the file. Treat "use no memo" as a temporary marker with a ticket behind it, not a permanent setting.

The compiler needs code that follows the rules

It assumes components are pure and props and state are not mutated. Code that breaks those rules either gets skipped or behaves differently once cached. The recommended config of eslint-plugin-react-hooks now carries compiler-powered rules that catch exactly those patterns:

// eslint.config.js
import reactHooks from "eslint-plugin-react-hooks";
export default [reactHooks.configs.flat.recommended];