Memoization: memo, useMemo & useCallback

A component re-renders often. If it recomputes something expensive every time — sorting a big list, filtering, a heavy calculation — you pay that cost on every render, even when the inputs didn't change.

useMemo(factory, deps) runs the factory on the first render and caches the result. On later renders it hands back the cached value, and runs the factory again only when a value in deps has changed (compared with Object.is).

function Report({ rows, query }) {
  // ❌ re-sorts on every render, even when `rows` didn't change:
  //    const sorted = rows.slice().sort(bySize);

  // ✅ re-sorts only when `rows` changes:
  const sorted = useMemo(() => rows.slice().sort(bySize), [rows]);

  return <Table rows={sorted} />;
}

Rule of thumb: reach for useMemo when the computation is genuinely expensive — or when you need the result to keep a stable reference across renders.

By default, when a parent re-renders, all its children re-render too. React.memo wraps a component so it skips re-rendering when its props are shallow-equal to last time (Object.is on each prop).

const Row = memo(function Row({ label }) {
  return <li>{label}</li>;
});

The catch is referential identity. memo compares references, not contents. An inline object, array, or function is created fresh on every parent render, so it's a new reference every time — and memo's shallow check fails:

function List({ items }) {
  return items.map((it) => (
    // ❌ new arrow + new object each render → Row re-renders every time
    <Row key={it.id} label={it.label} onClick={() => pick(it)} style={{ padding: 4 }} />
  ));
}

memo only pays off when the props you pass are stable. For primitive props (strings, numbers, booleans) that's automatic. For objects and functions, you have to stabilize the reference yourself — that's what useMemo and useCallback are for.

A memo child that takes a function prop re-renders on every parent update if the function is defined inline, because the arrow gets a new identity each render. useCallback(fn, deps) returns the same function reference until a dep changes, so the child's shallow prop check passes and it skips the re-render.

const Child = memo(function Child({ onSave }) {
  console.log("Child render");
  return <button onClick={onSave}>Save</button>;
});

function Form() {
  const [draft, setDraft] = useState("");
  const [count, setCount] = useState(0);

  // ✅ stable across renders; recreated only if `draft` changes
  const onSave = useCallback(() => api.save(draft), [draft]);

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Child onSave={onSave} /> {/* skips re-render when only `count` changes */}
    </>
  );
}

Bumping count re-renders Form, but onSave keeps its identity, so memo skips Child. Note the deps: because the closure reads draft, it must be a dep — otherwise onSave would save a stale draft.

react.dev's simplified model: useCallback(fn, deps) behaves like useMemo(() => fn, deps) — one caches a function, the other caches a value.

When memoization buys nothing

react.dev names the cases where it pays off:

• a calculation that is noticeably slow (measure it: around 1ms or more) and whose inputs rarely change;
• a value or function passed to a memo child;
• a value or function used as another Hook's dependency (an Effect's, say).

Anywhere else it skips nothing. The comparison itself is cheap — react.dev calls over-memoizing "no significant harm" — but it isn't free in other ways: the code is harder to read, every dep array is one more thing to keep correct (a missing dep is a stale-value bug), and a single always-new prop silently turns the whole chain into dead weight. Wrap a child in memo and stabilize its object and function props, or do neither.