useEffect — это синхронизация, а не lifecycle

Синхронизация, а не lifecycle

Ментальная модель, порождающая баги, — классово-компонентная: «useEffect с [] — это componentDidMount, useEffect с deps — componentDidUpdate». Модель, порождающая корректный код, другая: эффект описывает, как держать внешнюю систему синхронизированной с текущими props и state компонента. Внешняя система — это всё за пределами вывода рендера React: сетевой запрос, WebSocket, setInterval, слушатель событий на window, SDK аналитики, сторонний виджет. Тело эффекта говорит, как начать синхронизацию; возвращаемая cleanup-функция — как её остановить. React выполняет эту пару столько раз, сколько нужно: по разу на «значения, которые читает эффект, изменились», а не по разу на воображаемую фазу жизненного цикла.

Отсюда два механических факта. Первый: эффекты выполняются после коммита — React рендерит, мутирует DOM, браузер отрисовывает, и только потом срабатывает эффект. Эффект никогда не блокирует рендер, которому принадлежит. Второй: у каждого рендера своё замыкание эффекта. Когда query равен «invoice», выполняющийся эффект захватил "invoice"; на следующем рендере с «invoices overdue» React не мутирует старый эффект — он сносит его (cleanup) и запускает совершенно новый, захвативший новое значение. Нет одного долгоживущего эффекта, «видящего» меняющиеся значения; есть последовательность короткоживущих, каждый заморожен над породившим его рендером. Баги устаревших замыканий — ровно то, что случается в борьбе с этим: когда через массив deps вы говорите React, что эффект не читает значение, которое он на самом деле читает.

Массив зависимостей, поэлементно

Массив deps — не ручка конфигурации, а декларация: «этот эффект читает вот эти реактивные значения». На каждом рендере после первого React сравнивает новый массив с предыдущим поэлементно, через Object.is. Любой элемент отличается → cleanup старого эффекта, запуск нового. Все равны → пропустить. Object.is для объектов — сравнение ссылок, поэтому такой код перезапускает эффект на каждом рендере:

function Chart({ series }) {
  // ❌ options — новая идентичность объекта на каждом рендере,
  // поэтому Object.is(prevOptions, options) всегда false —
  // эффект сносит и пересоздаёт график на каждом рендере.
  const options = { animate: true, series };

  useEffect(() => {
    const chart = mountChart(node, options);
    return () => chart.destroy();
  }, [options]);
}

Лечение — зависеть от примитивов внутри ([series]), конструировать объект внутри эффекта или мемоизировать его. Обратный провал хуже: врать линтеру. Убрать query из deps, потому что «мне нужно только на маунте», не заставляет эффект читать стабильное значение — это заставляет эффект вечно работать с query первого рендера. Правило exhaustive-deps — не стилистическая прихоть; каждое его подавление — устаревшее замыкание, ждущее кейса воспроизведения. Если вы не хотите, чтобы эффект перезапускался при изменении значения, честные ответы такие: вынести значение из компонента, сделать его ref-ом, если оно действительно нереактивно, или перестроить код так, чтобы эффект его не читал. Пустой массив [] — это утверждение «этот эффект не читает реактивных значений», а не заявка на поведение «только при маунте».

Cleanup и зачем StrictMode монтирует вас дважды

Тайминг cleanup точен, и его стоит запомнить: cleanup рендера N выполняется перед эффектом рендера N+1 и ещё раз при размонтировании. Жизнь одного экземпляра эффекта взята в скобки: установка со значениями рендера N → (позже) снос со значениями рендера N. Замыкание сноса видит старые props — и это ровно то, что нужно: сносится старая подписка, старый id комнаты, старый запрос, который надо отменить. Эффект корректен, когда установка и cleanup симметричны: connect/disconnect, subscribe/unsubscribe, start/abort. Если cleanup невозможно написать — обычно это знак, что эффект делает что-то, не являющееся синхронизацией (считает производное состояние, реагирует на «события»), и его место в другом коде.

Именно для этого существует дев-режимный двойной маунт StrictMode (режим строгих проверок React, включается обёрткой <React.StrictMode>). Начиная с React 18, StrictMode монтирует каждый компонент, выполняет эффекты, немедленно выполняет cleanup и монтирует снова. Это зонд корректности: если ваш эффект — симметричная пара установка/cleanup, лишний цикл невидим. Если двойной маунт удваивает WebSocket-соединения, дважды стреляет аналитикой или утекает interval — StrictMode не создал этот баг, он его вскрыл: тот же цикл снос/установка происходит в проде при каждой смене deps, при ремоунте во время навигации и при fast-refresh в разработке. Выключить StrictMode (команда из Hook сделала ровно это) — не починить асимметрию; это убрать единственное, что о ней сообщает.

Гонки fetch: баг, который каждый дашборд отгружает по разу

Загрузка данных в эффекте — это синхронизация с удалённой системой, а удалённая система отвечает не по порядку. Прежде чем написать fetch внутри useEffect, спроси себя: что произойдёт, если медленный ответ придёт после быстрого? Баг из Hook в коде: эффект для "invoice" стартует 900-мс запрос; deps меняются; эффект для "invoices overdue" стартует 200-мс запрос и резолвится, отрисовывая свежие результаты; затем приземляется устаревший 900-мс ответ и вызывает setResults со старыми данными. Побеждает последняя запись, а последним писал устаревший запрос. Ничего не падает, в логах пусто — просто неверные данные на экране с вероятностью, пропорциональной джиттеру сети; поэтому в проде оно всплывает, а в офисе «не воспроизводится».

Cleanup-функция — точка отмены. Два стандартных паттерна, часто вместе: ignore-флаг на замыкание и AbortController (встроенный браузерный API для отмены fetch-запросов):

useEffect(() => {
  const controller = new AbortController();
  let ignore = false; // ремень и подтяжки: страхует неотменяемые async-шаги

  fetch(`/api/search?q=${encodeURIComponent(query)}`, {
    signal: controller.signal,
  })
    .then((res) => res.json())
    .then((data) => {
      if (!ignore) setResults(data); // устаревшее замыкание проверяет СВОЙ флаг
    })
    .catch((err) => {
      if (err.name !== "AbortError") setError(err);
    });

  return () => {
    ignore = true;        // флаг этого рендера — глушатся ответы только этого эффекта
    controller.abort();   // реально отменяет сетевой запрос
  };
}, [query]);

Флаг ignore работает потому, что у каждого замыкания эффекта свой флаг: cleanup эффекта «invoice» поднимает флаг «invoice», и только ответ «invoice» его проверяет. AbortController идёт дальше — он отменяет запрос на сетевом уровне, освобождая соединение и позволяя серверу прекратить работу; отклонённый промис обязан проглатывать именно AbortError, иначе каждое нажатие клавиши логирует фантомную ошибку. Честный продакшен-ответ обычно «не пишите это руками»: query-библиотеки и лоадеры роутеров реализуют отмену, дедупликацию и кэширование поверх ровно этого механизма. Но сырую версию вы обязаны уметь написать, потому что семантика каждой обёртки — и баги каждой обёртки — сводятся к этому эффекту.