Выводи, а не храни

Если ты можешь вычислить это из существующих пропсов или состояния — это не состояние, это производное. Состояние — минимальный набор значений, которые React не может воссоздать сам: пользовательский ввод, ответы сервера, вещи со своим жизненным циклом. Всё остальное — функция от этого минимального набора. Тест — один вопрос: имея пропсы и остальное состояние, могу ли я всегда пересчитать это? Если да, ему не место в useState.

// firstName и lastName — настоящее состояние (пользователь их печатает).
// fullName — НЕТ: он всегда пересчитывается из этих двух.
const [firstName, setFirstName] = useState("Ada");
const [lastName, setLastName] = useState("Lovelace");
const fullName = `${firstName} ${lastName}`; // производное, в рендере

fullName обновляется в тот же миг, как меняется любой из вводов, потому что пересчитывается каждый рендер. Нет второго значения, которое надо держать синхронным, потому что второго значения нет вообще.

Зеркалирование одного состояния в другое через эффект создаёт два источника истины, которые расходятся. В момент, когда fullName оседает в своём useState, истина («каким должно быть имя») существует в двух местах — а эффект становится твоим хрупким обещанием держать их равными. Это обещание ломается на самых обычных путях: эффект исполняется после отрисовки, поэтому первый рендер показывает устаревшие данные (мелькание); сброс, который выставляет firstName, но затем перезаписывается, оставляет зеркало устаревшим; и ты добавил лишний рендер на каждое изменение, потому что setFullName в эффекте планирует второй проход.

// АНТИПАТТЕРН: второй источник истины, синхронизируемый вручную
const [fullName, setFullName] = useState("");
useEffect(() => {
  setFullName(`${firstName} ${lastName}`); // лишний рендер + может отставать от реальности
}, [firstName, lastName]);

Каждый баг здесь — баг синхронизации, а баги синхронизации исчезают, когда истинной должна быть лишь одна вещь. Удаление состояния удаляет весь этот класс отказа.

Отфильтрованные, отсортированные и сгруппированные списки тоже производные — считай их в рендере, не храни. Тот же рефлекс, что добавляет состояние fullName, добавляет состояние visibleTodos с эффектом, который перефильтровывает при каждом изменении todos или filter. У него тот же изъян: отфильтрованный список может отставать от реального на рендер, и ты платишь лишним рендером каждый раз, когда двигается любой из вводов. Отфильтрованный список — это f(todos, filter), так и пиши его.

// выводим во время рендера — всегда согласовано со входами
const visibleTodos = todos
  .filter((t) => filter === "all" || t.status === filter)
  .sort((a, b) => a.createdAt - b.createdAt);

Ни эффекта, ни лишнего состояния, ни лишнего рендера, и visibleTodos никогда не рассинхронизирован с todos или filter — потому что он буквально выводится из них на месте.

Оборачивай вывод в useMemo только тогда, когда он реально дорог, — и даже тогда мемоизируй работу, а не истину. Предыдущие шаги убирают эффект; они не оправдывают рефлекторное оборачивание каждой производной const в useMemo. fullName и фильтр по нескольким сотням элементов дёшевы — мемоизировать их это шум, который добавляет массив зависимостей в поддержку и не покупает ничего. useMemo — это запасной люк производительности для вывода, который по-настоящему медленный (сортировка десятков тысяч строк, тяжёлая трансформация) или который должен держать стабильную ссылку для мемоизированного потомка или зависимости эффекта.

// оправдано: вход большой, работа настоящая
const sorted = useMemo(
  () => bigList.slice().sort(expensiveComparator),
  [bigList],
);

Главное: useMemo всё ещё выводит в рендере — это тот же паттерн, просто кешированный. Это не возврат к хранению состояния. У значения по-прежнему один источник истины; ты лишь мемоизировал его вычисление.