Когда мемоизировать

По умолчанию — не надо. Мемоизация стоит дорого на каждом рендере, а большинство рендеров и так дешёвые. useMemo и useCallback не заставляют работу исчезнуть — они меняют работу на учёт. Каждый из них выделяет замыкание, хранит массив зависимостей и запускает на каждом рендере сравнение, чтобы решить, переиспользовать ли кэшированное значение. Для значения, дешёвого в пересчёте, этот учёт стоит дороже, чем просто пересчитать его.

// чистый шум: «дорогое» вычисление — это сложение
const total = useMemo(() => price + tax, [price, tax]);

// так быстрее, меньше и понятнее — просто вычисли
const total = price + tax;

React даже заново прогоняет сравнение зависимостей и держит замыкание живым на каждом рендере. Ты заплатил за кэш, чтобы избежать a + b. Senior-база — это обычное выражение; мемоизация — исключение, которое ты обязан оправдать, а не привычка, которую ты применяешь.

Переопределение 1 — идентичность важна, потому что значение переходит в React.memo-ребёнка. React.memo пропускает повторный рендер ребёнка, когда его пропсы поверхностно равны прошлому разу. Но новый объект, массив или функция-литерал — это совершенно новая ссылка на каждом рендере, так что она проваливает поверхностную проверку, и memo ничего не делает. Стабилизация идентичности этого пропса — единственный случай, когда useCallback/useMemo напрямую включает оптимизацию.

const Row = React.memo(function Row({ onSelect }: { onSelect: () => void }) {
  // перерисовывается только когда идентичность onSelect меняется
  return <button onClick={onSelect}>Select</button>;
});

function List({ items }: { items: Item[] }) {
  // БЕЗ useCallback: новая функция на каждом рендере → каждый memo'd Row перерисовывается всё равно
  const onSelect = useCallback(() => {/* ... */}, []);
  return items.map((i) => <Row key={i.id} onSelect={onSelect} />);
}

Ключевое слово — и: мемоизируй колбэк и оборачивай ребёнка в memo. Одно без другого — половина паттерна: useCallback, чей потребитель не мемоизирован, стабилизирует идентичность, которую никто не проверяет.

Переопределение 2 — значение является зависимостью другого хука, так что его идентичность управляет корректностью, а не только скоростью. Когда объект или функция появляется в массиве зависимостей useEffect, useMemo или useCallback, свежая идентичность на каждом рендере заново запускает эффект или инвалидирует кэш каждый раз. Здесь ты мемоизируешь, чтобы держать зависимость стабильной, и это про поведение — разбегающиеся эффекты, бесконечные циклы, — а не про микро-перф.

// options — новый объект на каждом рендере → эффект перезапускается каждый рендер
const options = useMemo(() => ({ pageSize, sort }), [pageSize, sort]);

useEffect(() => {
  const sub = subscribe(options);
  return () => sub.unsubscribe();
}, [options]); // теперь переподписывается только когда pageSize/sort реально меняются

Часто более чистый фикс — убрать зависимость (заинлайнить литерал внутрь эффекта или следовать «возможно, тебе не нужен эффект»), а не мемоизировать её. Мемоизируй зависимость только когда она действительно должна разделяться через границу эффекта.

Переопределение 3 — вычисление измеримо дорогое, и ты его измерил. Сортировка десяти тысяч строк, парсинг большого блоба, тяжёлый reduce на каждое нажатие клавиши — это настоящая работа, которую стоит кэшировать между рендерами. Несущее слово — измеримо: ты подтвердил это Profiler’ом или замером, ты не предположил. useMemo здесь пропускает настоящую работу CPU; useMemo на .filter по двадцати элементам не пропускает ничего и добавляет учёт.

// оправдано: фильтрация+сортировка 10k строк на каждое нажатие — настоящая работа
const visible = useMemo(
  () => rows.filter(matches(query)).sort(byName),
  [rows, query],
);

Если ты не можешь сказать, какое вычисление медленное и насколько, у тебя нет переопределения 3 — у тебя догадка. А догадка, оборачивающая дешёвый цикл в useMemo, делает компонент медленнее, а не быстрее.