Memoizing with useMemo and useCallback

By default, changing state re-renders a component and everything below it. In most apps that is cheap and correct — React is fast enough. But occasionally a render does real work: an expensive sort, a heavy computation, or a function passed to a memoised child that resets its cache every render. The React for Beginners series reaches this chapter with a firm rule first: measure before you memoise. This chapter explains re-renders, then useMemo, useCallback and when each genuinely pays off.

What triggers a re-render

Knowing when a component runs again is half the battle:

Re-rendering is not the same as re-drawing the DOM: React recomputes the virtual tree and diffs it. The cost of an extra render is usually the component's own JavaScript — which is exactly what memoisation targets.

useMemo: cache a computed value

useMemo remembers the result of a calculation across renders and returns the cached value until one of its dependencies changes. Use it when the computation is genuinely expensive:

function ProductList({ products, category }) {
  const visible = useMemo(() => {
    console.log('filtering…');
    return products
      .filter((p) => p.category === category)
      .sort((a, b) => a.price - b.price);
  }, [products, category]);

  return <ul>{visible.map((p) => <li key={p.id}>{p.name}</li>)}</ul>;
}

Expected output: typing into an unrelated search box higher in the tree re-renders this list, but "filtering…" logs only when products or category actually changes. The calculation runs on first render and on dependency change — every other render reuses the cached array.

useCallback: cache a function

A plain function is re-created on every render. That is harmless by itself, but it matters when the reference is a dependency — of an effect, of another memo, or of a child wrapped in React.memo. useCallback returns the same function object until its deps change:

const [query, setQuery] = useState('');

// new function identity every render → memoised child re-renders anyway
const handleSearch = (value) => setQuery(value);

// cached identity → memoised child can skip re-rendering
const handleSearch = useCallback((value) => setQuery(value), []);

Expected output: with React.memo on the child, the cached version keeps its reference stable across query keystrokes — the expensive list inside the child does not re-render unless its own props change.

The three tools compared

They are layers of the same idea. React.memo on a child is pointless if the parent passes fresh function references every render — that is the pairing that makes useCallback meaningful. useMemo also serves a second purpose: keeping a value referentially stable when it appears in dependency arrays.

When not to memoise

• Trivial work — filtering fifty items costs microseconds; the memo machinery can outweigh the savings.
• Before profiling — use the React DevTools Profiler, record a real interaction, and let the numbers name the hot component.
• Every value "just in case" — memoisation adds dependency bookkeeping and stale-value risk; it is a tool, not a default.
• To fix a logic bug — an infinite loop or a stale closure is a dependency or state-ownership problem; memoising hides it.

A reasonable order of attack: simplify first (move work out of render, split components), profile, then add memoisation where the profiler points.

Correct dependencies

Both hooks take a dependency array with the same rules as useEffect: list everything you read. Omitting a dependency yields a cached value built from stale inputs — the classic "memo returns old data" bug. Let eslint-plugin-react-hooks enforce it.

// ❌ reads taxRate but hides it from React
const total = useMemo(() => items.reduce((s, i) => s + i.price, 0), [items]);

// ✅ every input listed
const total = useMemo(
  () => items.reduce((s, i) => s + i.price * (1 + taxRate), 0),
  [items, taxRate],
);

Expected output: the second version recomputes when either the items or the tax rate changes; the first silently shows an outdated total after a tax update.

Common mistakes

• Memoising everything — overhead and complexity with no measured benefit; profile first.
• Missing dependencies — cached values go stale; list every referenced value.
• useCallback without a memoised consumer — wrapping handlers no effect, memo or context reads does nothing useful.
• Expecting memo to block state updates — a child's own state still re-renders it; React.memo only guards against prop-driven renders.
• Caching cheap derivations instead of moving them — often the better fix is computing during render or extracting a smaller component.

Practice checklist

1. Add useMemo to an expensive filter and watch the console log frequency change.
2. Pass a fresh callback to a React.memo child, observe re-renders in the Profiler, then stabilise it with useCallback.
3. Profile a real interaction before and after memoising — record the numbers.
4. Write one memo with a deliberately missing dependency and observe the stale result; fix the array.
5. Find one memo you would remove after measuring, and remove it.

Reusable logic deserves reusable hooks — build some in Building Your Own Hooks.