Эффект-как-производное-состояние

Форма, которую надо распознавать: эффект, вся работа которого — setState из другого состояния или пропсов. Никакой подписки, никакого fetch, никакого DOM API, никакого таймера — просто один кусок состояния React, отзеркаливаемый в другой. В тот момент, как ты это видишь, эффект — кандидат на удаление.

function ProfileForm({ user }: { user: User }) {
  const [firstName, setFirstName] = useState(user.firstName);
  const [fullName, setFullName] = useState("");

  // анти-паттерн: вся работа этого эффекта — setState-из-состояния
  useEffect(() => {
    setFullName(firstName + " " + user.lastName);
  }, [firstName, user.lastName]);

  return <input value={firstName} onChange={(e) => setFirstName(e.target.value)} />;
}

fullName — не независимое состояние, оно полностью определено через firstName и user.lastName. Хранить его отдельно и ре-синхронизировать в эффекте — это и есть баг. Тест: если ты можешь записать значение как чистое выражение из пропсов и текущего состояния, оно производное, а не состояние.

Почему он неверен, механически: лишний рендер и устаревший тик. React рендерит с новым firstName, потом отрисовывает, потом запускает эффект, который вызывает setFullName, который планирует второй рендер. Между этими двумя рендерами есть кадр, где firstName — «Taylor», а fullName всё ещё читается как «Jordan Smith». На долю секунды UI внутренне противоречив — реальная, наблюдаемая вспышка устаревших данных плюс удвоенное число рендеров.

// рендер 1: firstName="Taylor", fullName="Jordan Smith"  ← устарело, отрисовано
// эффект запускается → setFullName("Taylor Smith")
// рендер 2: firstName="Taylor", fullName="Taylor Smith"  ← наконец верно

Становится хуже в тот момент, когда второе производное значение зависит от первого, потому что каждый эффект добавляет ещё один тик задержки, а массивы зависимостей начинают расходиться друг с другом. Это не придирка к производительности — это баг корректности, который вдобавок ещё и медленный.

Исправление №1 — вычисляй во время рендера. Никакого состояния, никакого эффекта. Значение, которое является чистой функцией пропсов и состояния, должно вычисляться инлайн. Нет устаревшего тика, потому что нет второго рендера: значение всегда выведено из тех входов, что породили текущий рендер.

function ProfileForm({ user }: { user: User }) {
  const [firstName, setFirstName] = useState(user.firstName);
  const fullName = firstName + " " + user.lastName; // производное, всегда свежее

  return <input value={firstName} onChange={(e) => setFirstName(e.target.value)} />;
}

Два useState стали одним, эффекта нет, и окно несогласованности ушло вместе с ним. Если бы вычисление было реально дорогим (сортировка десяти тысяч строк на каждое нажатие клавиши), ты бы обернул его в useMemo — но useMemo — это всё ещё вывод во время рендера, а не эффект. Тянись к нему только когда профилирование показывает, что стоимость реальна; для конкатенации строк и обычных фильтров чистое вычисление во время рендера корректно и дешевле, чем бухгалтерия мемоизации.

Исправление №2 — когда смена пропа должна сбросить внутреннее состояние, используй key, а не эффект. Близкий родственник анти-паттерна — «когда меняется userId, очисти черновик и выбор». Люди тянутся к эффекту, который сбрасывает несколько useState. У него та же проблема устаревшего тика, и его легко сделать частично неправильным. Вместо этого дай поддереву key, привязанный к идентичности, которая должна его сбросить, — React размонтирует и заново монтирует его, сбрасывая всё его состояние за один заход, в том же коммите.

// анти-паттерн: эффект зеркалит смену пропа в сброс состояния (устаревший тик + баги частичного сброса)
useEffect(() => { setDraft(""); setSelection(null); }, [userId]);

// исправление: смена идентичности → ремаунт → всё внутреннее состояние сбрасывается атомарно
<ProfileEditor key={userId} userId={userId} />

Подход с key масштабируется: он сбрасывает всё состояние в поддереве, включая то, что ты забыл бы сбросить руками, без лишнего рендера и без вспышки. Используй его всякий раз, когда «этот проп изменился, значит начинаем с чистого листа» — реальное намерение.