Transitions и useDeferredValue: медленный рендер делаем прерываемым, а не быстрым

Две полосы: срочная и несрочная

startTransition ничего не ускоряет, не дебаунсит и не уносит работу с главного потока. Он меняет приоритет обновлений стейта внутри своего колбэка: они становятся transitions — несрочными апдейтами, которые React рендерит в фоне, пока экран показывает последний закоммиченный UI. Срочные апдейты (печать, клики, всё необёрнутое) прерывают этот фоновый рендер: React бросает наполовину построенное work-in-progress-дерево, сначала коммитит срочный апдейт, затем перезапускает рендер transition с самого свежего стейта. Во время фонового рендера React к тому же уступает главный поток между компонентами (примерно каждые 5 мс), так что браузер может рисовать и обрабатывать события посреди рендера, а не замирать на все 280 мс.

function CatalogSearch({ products }) {
  const [text, setText] = useState("");        // срочно: отзеркаливает нажатие
  const [query, setQuery] = useState("");      // transition: питает тяжёлый список
  const [isPending, startTransition] = useTransition();

  function handleChange(e) {
    setText(e.target.value);                   // коммитится немедленно
    startTransition(() => {
      setQuery(e.target.value);                // рендерится фоном, прерываемо
    });
  }

  return (
    <>
      <input value={text} onChange={handleChange} />
      <div style={{ opacity: isPending ? 0.6 : 1 }}>
        <ProductGrid products={products} query={query} />
      </div>
    </>
  );
}

Разделение — и есть вся конструкция: рендер срочного стейта крошечный (один инпут) и коммитится за кадр-два; дорогое дерево зависит только от transition-стейта, поэтому его рендер прерываем и перезапускаем. isPending даёт честный сигнал загрузки для устаревшего, но видимого контента. Первая попытка команды из истории провалилась потому, что один стейт делал обе работы — обёртка в transition сделала несрочным и эхо инпута. Эвристика: значение, которым пользователь манипулирует напрямую, никогда не должно жить внутри transition.

useDeferredValue: откладываем значения, которыми не владеем

useTransition требует владеть вызовом setState. Часто это не так — проп приходит от родителя, роутера или библиотечного хука. useDeferredValue(value) — эквивалент для принимающей стороны: он возвращает предыдущее значение, пока фоновый ре-рендер с новым значением в полёте, позволяя держать дорогое поддерево на устаревшем значении, не трогая производителя.

function SearchResults({ query }) {           // query обновляется срочно выше
  const deferredQuery = useDeferredValue(query);
  const isStale = deferredQuery !== query;
  const grid = useMemo(
    () => <HeavyGrid query={deferredQuery} />,
    [deferredQuery]
  );
  return <div style={{ opacity: isStale ? 0.6 : 1 }}>{grid}</div>;
}

Механика: когда query меняется, React сначала срочно ре-рендерит с deferredQuery, всё ещё держащим старое значение, — этот рендер обязан быть дешёвым, поэтому дорогое поддерево мемоизировано по deferredQuery и выходит по bail-out, — а затем запускает фоновый рендер, где deferredQuery догоняет. Этот фоновый рендер — transition: прерываемый, перезапускаемый при следующем изменении. Мемоизация здесь не декоративна: без неё срочный рендер всё равно перерендерит HeavyGrid со старым значением, и вы заплатите полную цену дважды за нажатие. Выбор между ними: владеете сеттером → useTransition (плюс isPending бесплатно); получаете значение → useDeferredValue (сравнивайте значения для определения устаревания).

Transitions и Suspense: без вспышки fallback

Вторая суперспособность — то, что transitions делают с Suspense. Срочный апдейт, который приостанавливается — скажем, смена вкладки заставляет компонент бросить промис за данными, которых нет, — прячет уже видимый контент за ближайшим fallback: страница, которую вы читали, заменяется спиннером. Тот же апдейт внутри transition ведёт себя иначе: React держит на экране текущий закоммиченный UI, рендерит приостановленное дерево в фоне и коммитит только когда данные готовы. Никакой вспышки fallback; старая вкладка остаётся видимой (затемните её через isPending). Поэтому навигации роутеров в современных фреймворках по умолчанию обёрнуты в transitions — клик по ссылке не должен превращать работающую страницу в спиннер. Исключение точное: защищён только уже показанный контент. Граница Suspense, монтирующаяся впервые внутри transition, всё равно покажет свой fallback — прежнего UI, который можно удержать, не существует.

Когда transitions не делают ничего

Transitions покупают прерываемость между компонентами и применяются к работе фазы рендера. Три ситуации их обезоруживают. Один гигантский компонент: React уступает поток между рендерами компонентов и никогда — внутри одного; монолитный график, строящий 10 000 SVG-элементов в одной функции за 200 мс, блокирует полосу при любом приоритете; разбейте его на мелкие компоненты или виртуализируйте. Цена не в рендере: если тормозит синхронный filter по 100k элементов прямо в обработчике события или layout thrash в эффектах — работа происходит вне фазы рендера, которую планируют transitions. Один дешёвый коммит: если апдейт был 20-миллисекундным рендером с одним коммитом, резать нечего — обёртка не меняет ничего наблюдаемого. Transition — это подсказка планировщику, а не ускорение: суммарная работа CPU та же или чуть выше (брошенные рендеры оплачены и выброшены — такова сделка: потраченные ватты в обмен на отзывчивый ввод).