Очистка эффектов и устаревшие замыкания

Что эффект запустил, то его очистка должна остановить — return-функция не декоративное украшение. React вызывает очистку перед повторным запуском эффекта (потому что сменилась зависимость) и ещё раз при размонтировании. Если её пропустить, старая подписка, интервал или слушатель продолжают работать рядом с новыми. Ментальная модель: установка и очистка идут парами, и в любой момент ровно одна подписка должна быть живой.

useEffect(() => {
  const socket = createConnection(roomId);
  socket.connect();
  return () => socket.disconnect(); // парная к connect
}, [roomId]);

Когда roomId меняется, React запускает очистку для старой комнаты, затем установку для новой. Убери return — и каждая смена комнаты течёт ещё одним открытым соединением, и каждое соединение всё ещё шлёт свои обработчики в компонент, который уже ушёл дальше.

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

function Poller({ onTick }: { onTick: (n: number) => void }) {
  const [count, setCount] = useState(0);
  useEffect(() => {
    const id = setInterval(() => {
      // БАГ: `count` заморожен на 0 — это замыкание создано на
      // первом рендере, а [] не даёт React сделать свежее.
      setCount(count + 1); // всегда 0 + 1 → застрял на 1
    }, 1000);
    return () => clearInterval(id);
  }, []); // лжёт: эффект читает `count`, но не перечисляет его
  return <p>{count}</p>;
}

Интервал работает вечно, но вечно вычисляет 0 + 1. Замыкание — это корректная семантика React; ложь — в зависимостях.

Чини устаревшее замыкание, убирая зависимость, а не пряча её: функциональным обновлением или ref для значений, которые ты только читаешь. Интервалу на самом деле не нужно текущее значение count — ему нужно инкрементировать то, какой count сейчас самый свежий. Функциональное обновление выражает именно это, и теперь эффект не читает никакого состояния, так что [] честен.

useEffect(() => {
  const id = setInterval(() => {
    setCount((c) => c + 1); // React сам подаёт свежее значение
  }, 1000);
  return () => clearInterval(id);
}, []); // теперь честно — эффект не замыкается ни над чем реактивным

Когда внутри долгоживущего колбэка нужно именно прочитать свежее значение (а не просто преобразовать его) — скажем, свежайший пропс onTick, — запиши его в ref и читай ref.current, чтобы интервал никогда не пересоздавался, но всегда видел сегодняшнее значение:

const onTickRef = useRef(onTick);
useEffect(() => { onTickRef.current = onTick; }); // каждый рендер держим свежим
useEffect(() => {
  const id = setInterval(() => onTickRef.current(Date.now()), 1000);
  return () => clearInterval(id);
}, []); // интервал создан один раз; ref мостит к свежайшему пропсу

Fetch — тоже подписка: отменяй летящий запрос в очистке через AbortController, иначе быстрые зависимости устроят гонку с медленными ответами. Когда зависимость меняется быстрее, чем отвечает сеть, в полёте два запроса, и более медленный может разрешиться последним, перезаписав корректные данные. Очистка прерывает устаревший запрос, чтобы зафиксироваться смог только текущий.

useEffect(() => {
  const ctrl = new AbortController();
  fetch(`/api/users/${userId}`, { signal: ctrl.signal })
    .then((r) => r.json())
    .then(setUser)
    .catch((err) => {
      if (err.name !== "AbortError") setError(err); // игнорируем свой же abort
    });
  return () => ctrl.abort(); // отменяем устаревший запрос при смене userId/размонтировании
}, [userId]);

Без abort переключение userId с 1 → 2 → 3 может оставить ответ пользователя 1 фиксирующимся после пользователя 3, и setUser, срабатывающий после размонтирования. Abort закрывает обе дыры — утечку и гонку — одной строкой.