useDeferredValue и transitions: приоритет — это второй рендер

Честная механика: два рендера, а не один отложенный

Когда значение, переданное в useDeferredValue, меняется, React не ждёт, чтобы отрендерить один раз. Он делает вот что, по порядку:

1. Срочный ререндер со СТАРЫМ отложенным значением. Компонент перерисовывается немедленно, чтобы срочная часть обновления — контролируемый input, отзывающийся на нажатие, — закоммитилась сразу. useDeferredValue(query) в этом проходе всё ещё возвращает предыдущий запрос.
2. Фоновый ререндер с НОВЫМ значением. Затем React планирует второй рендер, где отложенное значение догоняет. Этот рендер идёт с приоритетом transition: он прерываем. Если посреди него прилетает ещё одно нажатие, React бросает недостроенную фоновую работу и перезапускает её с самым свежим значением — промежуточные значения пропускаются и никогда не коммитятся.

Итого одно нажатие стоит двух рендеров всего, что читает компонент с отложенным значением. Это осознанная цена. Выгода существует только тогда, когда срочный рендер почти бесплатен, — и тут возвращается контракт из урока про мемоизацию:

const deferredQuery = useDeferredValue(query);

// ❌ срочный рендер всё равно перерисовывает тяжёлую таблицу — отсрочка ничего не даёт
<HugeTable query={deferredQuery} />

// ✅ memo + неизменённый проп в срочном проходе = bailout; платит только фоновый рендер
const HugeTable = memo(function HugeTable({ query }) { /* 80ms of rows */ });

В срочном проходе deferredQuery не изменился с прошлого рендера — поэтому мемоизированная HugeTable срезается через поверхностное сравнение props, и срочный рендер стоит микросекунды. Без memo срочный проход перерисовывает 80 мс таблицы со старым запросом — чистые потери. Это самый частый способ, которым useDeferredValue «не работает» в продакшен-коде.

Не debounce: без фиксированной задержки, адаптируется к устройству

Debounce и useDeferredValue лечат пересекающиеся симптомы разной механикой, и разница измерима:

• Debounce выбирает константу. 250 мс означает, что каждый пользователь ждёт 250 мс после последнего нажатия: на M3 MacBook, где рендер занимает 12 мс, вы навязали 238 мс искусственной задержки; на бюджетном Android, где рендер 400 мс, ожидание — 250 мс плюс блокирующий 400-миллисекундный рендер, замораживающий input посреди набора.
• У useDeferredValue нет таймера. Фоновый рендер стартует, как только React свободен. На быстрой машине он успевает между нажатиями — результаты ощущаются мгновенными, искусственной задержки нет. На медленном устройстве каждое нажатие прерывает ещё идущий фоновый рендер, React перезапускается с последним значением, и список просто отстаёт, пока input остаётся отзывчивым: лаг автоматически равен тому, что устройство может себе позволить, без констант для подбора.

Честная граница: отсрочка помогает только стоимости рендера. Она не умеет ограничивать частоту сетевых запросов — отложенное значение в итоге меняется раз на нажатие, и если ваш fetch завязан на него, сервер всё равно получает запрос на каждое нажатие (просто чуть позже). Debounce/throttle остаются правильным инструментом, когда дорогая вещь — сетевой вызов или нагрузка на сервер, и они сочетаются: дебаунсим запрос, откладываем рендер.

Lanes: что на самом деле значит «срочно»

Под капотом React планирует работу в lanes — корзинах приоритетов. Дискретные события ввода (keydown, click) рендерятся в синхронной полосе: они обязаны закоммититься до следующей отрисовки браузера, потому что контролируемый input, не отозвавшийся символом в следующем кадре, читается как сломанная клавиатура. Это и есть определение срочности — пользователь только что выразил намерение, и UI обязан подтвердить его сейчас. Transitions (startTransition, useTransition и фоновая половина useDeferredValue) рендерятся в transition-полосах: прерываемые, бросаемые, перезапускаемые.

Прерывание — это перезапуск с нуля, а не пауза с продолжением: когда срочное обновление прилетает посреди transition, React выбрасывает частично построенное дерево и рендерит заново со свежим состоянием. Эта работа теряется по замыслу — вот почему рендер-функции обязаны быть чистыми и без побочных эффектов: transition-рендер может выполниться и быть выброшенным сколько угодно раз, прежде чем один из них закоммитится. Это же означает, что длинный transition на медленном устройстве может быть заморен голодом быстрым машинистом: каждое нажатие убивает предыдущий фоновый рендер, и результаты появляются только в паузах набора — ровно тот UX, который и нужен: кадры тратятся на input, а не на список, который никто не читает посреди очереди нажатий.

Числа: почему это история про INP

INP — Interaction to Next Paint — оценивает худшую задержку между взаимодействием и следующим кадром; до 200 мс — «хорошо», выше 500 мс — «плохо», и это полевая метрика Core Web Vitals, измеряемая на реальных устройствах ваших пользователей. Синхронный 350-миллисекундный рендер списка внутри обработчика нажатия и есть INP 350+ мс на каждое нажатие — следующего кадра нет, пока рендер не закоммитится. Расщепление этой работы через useDeferredValue уносит 350 мс в прерываемый фоновый рендер и оставляет срочный коммит в единицах миллисекунд: INP падает до стоимости дешёвого прохода. Поэтому же «у меня на машине быстро» не работает как тест: ценность отсрочки максимальна ровно на тех устройствах, на которых вы не разрабатываете, где фоновый рендер прерывается десятки раз. Профилируйте с 6x-троттлингом CPU; после релиза смотрите полевой INP.

useTransition против useDeferredValue: какая ручка

Машинерия одна, различие — во владении состоянием. useTransition — когда setState ваш: вы оборачиваете обновление (startTransition(() => setQuery(q))) и бесплатно получаете isPending. useDeferredValue — когда вы получаете значение, которым не управляете: prop, значение контекста, чужое состояние — и хотите отстающую копию для дорогого поддерева. Сравнение двух значений (query !== deferredQuery) даёт тот же pending-сигнал. Если вы откладываете значение, чей setState написали тремя строками выше, transition — более чистая запись того же намерения.