setState — это запрос: снимки, очереди обновлений и автоматический батчинг

State — снимок; setState — запрос

Если ты когда-нибудь вызывал setState дважды и видел только одно обновление — причина здесь. Рендер работает с замороженной копией состояния. Когда React вызывает компонент, useState возвращает значения на момент этого рендера, и каждое созданное в нём замыкание — включая обработчики событий — захватывает эти значения навсегда. Вызов setPoints не меняет points; он и не может: points — это const в вызове функции, который уже завершился или вот-вот завершится. Что setPoints(next) делает на самом деле — добавляет обновление в очередь на fiber этого хука и планирует ре-рендер. Лишь когда следующий рендер выполнится, React свернёт очередь и выдаст компоненту новое значение.

Это весь механизм за самым частым вопросом собеседований по React. В обработчике, где count равен 0, три вызова setCount(count + 1) ставят в очередь «заменить на 1» трижды — каждая строка читала один и тот же снимок. Следующий рендер сворачивает очередь: 1, 1, 1. Итог: 1, один рендер. Ментальная модель «setState — это медленное/асинхронное присваивание» неверна важным образом: это не отложенная запись, это вообще не запись. Это запрос на будущий рендер, вычисленный из того, что вы передали — а передали вы то, что посчитали от снимка, устаревшего по построению.

Updater-функции: отправляем инструкции, а не значения

Очередь принимает два вида записей: значение-замену или updater-функцию. setPoints(p => p - cost) ставит в очередь саму функцию; на следующем рендере React сворачивает очередь по порядку, передавая каждому updater-у результат предыдущей записи. Это делает последовательность updater-ов композируемой там, где значения-замены — нет:

function Redeem({ cost, bonusCost }) {
  const [points, setPoints] = useState(500);

  function redeemCombo() {
    // Баг: обе строки читают один снимок (points = 500).
    // Очередь: [replace 400, replace 450] — побеждает второй. Результат: 450.
    setPoints(points - cost);       // cost = 100
    setPoints(points - bonusCost);  // bonusCost = 50
  }

  function redeemComboFixed() {
    // Очередь: [p => p - 100, p => p - 50], сворачивается по порядку:
    // 500 -> 400 -> 350. Результат: 350, и всё равно ровно один рендер.
    setPoints((p) => p - cost);
    setPoints((p) => p - bonusCost);
  }
}

Смешанные формы сворачиваются по тому же правилу: при count равном 0 последовательность setCount(c => c + 1), setCount(42), setCount(c => c + 1) даёт 0 → 1 → 42 → 43. Замена отбрасывает всё, что было до неё; updater-ы строятся на том, что им предшествует. Та же логика снимков объясняет протухшие замыкания вне обработчиков: интервал, созданный при монтаже, навсегда захватил count первого рендера, и setCount(count + 1) внутри него прибивает значение к 1 — а setCount(c => c + 1) читает живое состояние сворачиваемой очереди и считает правильно. Отсюда правило: любое обновление, выведенное из предыдущего состояния, обязано использовать updater-форму. Это не вопрос стиля; это единственная форма, которую очередь умеет композировать.

Автоматический батчинг: что на самом деле изменил React 18

Батчинг — это схлопывание нескольких вызовов setState в один рендер и один commit. React 17 батчил только внутри React-обработчиков событий — в стеке синтетических событий, который он контролировал. Как только код покидал этот стек, батчинг заканчивался: в .then промиса, в setTimeout, в нативном addEventListener каждый setState запускал собственный синхронный проход render-и-commit. Три setState в колбэке fetch — три полных рендера подряд; и код в дикой природе молча на это полагался, читая свежезакоммиченный DOM между двумя строками setState.

React 18 с createRoot сделал батчинг автоматическим везде: обработчики, промисы, таймауты, нативные события — все обновления одного тика встают в очередь и сбрасываются одним рендером. Прирост производительности механический: колбэк fetch, выставляющий loading, данные и пагинацию, прошёл путь от 3 проходов render+commit до 1 — на тяжёлой странице это разница между одним кадром в 40 мс и тремя. Сценарий поломки при миграции — обратная сторона: код, полагавшийся на flush-на-каждый-вызов из React 17 — измерить DOM после setState в таймауте, тест, проверяющий промежуточные рендеры, — теперь читает устаревший DOM, потому что commit происходит после завершения всего колбэка. Обновления внутри transition батчатся отдельно от срочных, но внутри каждой полосы правило то же: один сброс на батч.

flushSync: запасной выход и его счёт

Иногда DOM действительно нужен обновлённым сейчас, посреди обработчика: добавить сообщение в чат и проскроллить список к нему, сфокусировать input, который создаст следующий рендер, заполнить состояние до того, как диалог печати браузера сделает снимок страницы. flushSync(fn) выполняет обновления внутри fn и синхронно форсирует render и commit до возврата — следующая строка обработчика видит закоммиченный DOM.

import { flushSync } from "react-dom";

flushSync(() => {
  setMessages((prev) => [...prev, newMessage]);
});
// DOM закоммичен: новый <li> существует, scroll попадает в реальный узел.
listRef.current.lastChild.scrollIntoView({ behavior: "smooth" });

Счёт — ровно то, что батчинг вам экономил: каждый flushSync — полный синхронный render+commit в главном потоке, внутри вашего обработчика. Три вызова flushSync воссоздают худший случай React 17, только теперь намеренно. Он отключает батчинг для этих обновлений, блокирует обработчик до конца commit, форсирует layout раньше, чем сделал бы браузер, и может синхронно выполнить эффекты. Эвристика сеньора: flushSync — для императивных чтений DOM, обязанных видеть новое состояние — скролл, фокус, измерение, печать — и ни для чего больше. Если вы тянетесь к нему, чтобы «починить» устаревшее значение в собственной JavaScript-логике, настоящее лечение — updater-функция или локальное вычисление значения; flushSync там — пластырь за 40 мс поверх бага в четыре символа.