When to memoize

The default is: don’t. Memoization has a cost on every render, and most renders are already cheap. useMemo and useCallback don’t make work disappear — they trade work for bookkeeping. Each one allocates a closure, stores a dependency array, and runs a per-render comparison to decide whether to reuse the cached value. For a value that’s cheap to recompute, that bookkeeping costs more than just recomputing it.

// pure noise: the "expensive" computation is an addition
const total = useMemo(() => price + tax, [price, tax]);

// this is faster, smaller, and clearer — just compute it
const total = price + tax;

React even re-runs the dependency comparison and keeps the closure alive on every render. You paid for a cache to avoid an a + b. The senior baseline is a plain expression; memoization is the exception you must justify, not the habit you apply.

Override 1 — identity matters because the value crosses into a React.memo’d child. React.memo skips a child’s re-render when its props are shallowly equal to last time. But a new object, array, or function literal is a brand-new reference every render, so it fails that shallow check and the memo does nothing. Stabilizing that prop’s identity is the one case where useCallback/useMemo directly enables an optimization.

const Row = React.memo(function Row({ onSelect }: { onSelect: () => void }) {
  // re-renders only when onSelect's identity changes
  return <button onClick={onSelect}>Select</button>;
});

function List({ items }: { items: Item[] }) {
  // WITHOUT useCallback: new function each render → every memo'd Row re-renders anyway
  const onSelect = useCallback(() => {/* ... */}, []);
  return items.map((i) => <Row key={i.id} onSelect={onSelect} />);
}

The keyword is and: memoize the callback and wrap the child in memo. One without the other is half a pattern — a useCallback whose consumer isn’t memoized stabilizes an identity nobody checks.

Override 2 — the value is another hook’s dependency, so its identity controls correctness, not just speed. When an object or function appears in a useEffect, useMemo, or useCallback dependency array, a fresh identity every render re-fires the effect or invalidates the cache each time. Here you memoize to keep a dependency stable, which is about behavior — runaway effects, infinite loops — not micro-perf.

// options is a new object every render → effect re-runs every render
const options = useMemo(() => ({ pageSize, sort }), [pageSize, sort]);

useEffect(() => {
  const sub = subscribe(options);
  return () => sub.unsubscribe();
}, [options]); // now re-subscribes only when pageSize/sort actually change

Often the cleaner fix is to remove the dependency (inline the literal inside the effect, or follow “you might not need an effect”) rather than memoize it. Memoize the dependency only when it genuinely must be shared across the effect boundary.

Override 3 — the computation is measurably expensive, and you measured it. Sorting ten thousand rows, parsing a large blob, running a heavy reduce on every keystroke — that’s real work worth caching across renders. The load-bearing word is measurably: you confirmed it with the Profiler or a timing, you didn’t assume it. A useMemo here skips genuine CPU work; a useMemo on a .filter over twenty items skips nothing and adds bookkeeping.

// justified: filtering+sorting 10k rows on every keystroke is real work
const visible = useMemo(
  () => rows.filter(matches(query)).sort(byName),
  [rows, query],
);

If you can’t say which computation is slow and by how much, you don’t have override 3 — you have a guess. And a guess that wraps a cheap loop in useMemo makes the component slower, not faster.