View Transitions и жесты: снапшоты, пружины и перехват значений на лету

startViewTransition: машина снапшотов

До появления этого API анимация между двумя принципиально разными состояниями страницы требовала удерживать старый и новый DOM живыми одновременно — та самая сложность в духе AnimatePresence, из-за которой анимационный код становился хрупким. document.startViewTransition(callback) решает это иначе: он выполняет фиксированный протокол. Браузер захватывает старое состояние — статический снимок страницы плюс отдельный снимок каждого элемента с view-transition-name. Затем выполняет ваш колбэк, который обязан реально мутировать DOM (и может вернуть promise, который браузер дождётся). Когда колбэк завершился, браузер захватывает новое состояние, строит дерево псевдоэлементов поверх страницы — ::view-transition в корне, и на каждое имя ::view-transition-group, содержащий ::view-transition-image-pair с ::view-transition-old (статический битмап) и ::view-transition-new (живое представление нового контента) — и анимирует между ними. По умолчанию — кроссфейд для корня плюс интерполяция позиции и размера для каждой именованной группы; всё настраивается обычными CSS-анимациями на псевдоэлементы, потому что это всё, чем они являются: элементы, которыми владеет браузер и которые стилизуете вы.

Контракт именования важен: view-transition-name обязан быть уникальным среди захваченных элементов в каждом состоянии — дубликат заставляет переход пропуститься (promise ready отклоняется), классический баг, когда все карточки списка получают view-transition-name: card из одного CSS-правила. И API по умолчанию работает в пределах документа; кросс-документные MPA-переходы включаются CSS-правилом @view-transition { navigation: auto; } на обеих same-origin-страницах — именно это позволяет снапшотным переходам работать, даже когда старый документ уничтожается посреди навигации.

Шов React: flushSync — или видимых изменений не будет

Браузер снимает «новое», когда колбэк завершился. Обновления состояния React ставятся в очередь, а не выполняются синхронно — отсюда канонический баг интеграции:

import { flushSync } from "react-dom";

function navigate(next) {
  if (!document.startViewTransition) {
    setRoute(next);                    // мягкая деградация: без анимации
    return;
  }
  document.startViewTransition(() => {
    // DOM обязан быть в НОВОМ состоянии, когда этот колбэк вернётся.
    // Голый setRoute(next) ставит обновление в очередь: колбэк возвращается
    // с неизменённым DOM, браузер снимает old === new, а настоящий коммит
    // приходит ПОСЛЕ перехода — фейд в тот же кадр, затем скачок.
    flushSync(() => setRoute(next));
  });
}

flushSync заставляет React отрендерить и закоммитить синхронно внутри колбэка — ровно то место, где цена синхронного коммита — суть, а не запах. Компонент <ViewTransition> в React 19 оборачивает эту машинерию декларативно: активируется на переходах, запущенных через startTransition, интегрируется с раскрытиями Suspense и сшивает общие элементы по имени. Честный статус: он живёт только в экспериментальном канале (react@experimental), не в стабильном React 19 — на стабильном канале сегодня продакшен-паттерн — это шов startViewTransition + flushSync выше, и он достаточно мал, чтобы владеть им самим.

Жесты: одна модель указателя, три дисциплины

События указателя объединили мышь, тач и перо в один поток: pointerdown, pointermove, pointerup, каждое несёт pointerId. Структурный инструмент — setPointerCapture(pointerId): элемент продолжает получать поток, даже когда палец покидает его границы — без бухгалтерии слушателей на document, без потерянных перетаскиваний, когда указатель обгоняет шит. Вокруг этого — три дисциплины, отделяющие 60 fps от 12 из Hook:

function onPointerDown(e) {
  sheet.setPointerCapture(e.pointerId);
  running.current?.cancel();                       // перехват: убить пружину на лету
  const m = new DOMMatrixReadOnly(getComputedStyle(sheet).transform);
  grabOffset.current = m.m42 - e.clientY;          // продолжить от ТЕКУЩЕГО значения
  maxTravel.current = sheet.offsetHeight;          // читать layout ОДИН раз, здесь
}

function onPointerMove(e) {
  latestY.current = e.clientY;                     // только сохранить — никаких чтений layout
  raf.current ??= requestAnimationFrame(() => {
    raf.current = null;                            // одна запись на кадр, не на событие
    sheet.style.transform = `translateY(${clamp(latestY.current + grabOffset.current)}px)`;
  });
}

Дисциплина первая — батчируйте записи через rAF. pointermove стреляет с частотой ввода, которая на современных дигитайзерах превышает частоту кадров; запись стилей на каждое событие — невидимая дублирующая работа, а время обработчика напрямую задерживает следующий кадр. Сохраняйте последнюю позицию; пишите раз на кадр. Дисциплина вторая — никаких чтений layout в move-обработчиках. offsetHeight на каждый move из Hook — форсированный синхронный layout, умноженный на частоту событий; измеряйте всё на pointerdown и кэшируйте. Дисциплина третья — объявляйте намерение браузеру. touch-action: none на ручке перетаскивания говорит браузеру, что жест ваш, и он не выжидает, не имели ли вы в виду скролл; везде остальном оставьте скролл компоновщику и держите слушатели passive, чтобы он там и оставался.

Отпускание и прерывание: значением владеет палец

На pointerup вычислите скорость отпускания по последним move-сэмплам и передайте значение пружине или инерции — WAAPI со сгенерированными keyframes или rAF-пружина, если нужно живое перенацеливание. Жёсткое правило — прерывание: новый pointerdown во время анимации обязан перехватить значение на лету — прочитать текущий трансформ (через getComputedStyle и DOMMatrixReadOnly или из собственного состояния пружины), отменить анимацию и начать перетаскивание ровно с этого значения. Обе соблазнительные альтернативы читаются как дефекты: ожидание finished заставляет поверхность игнорировать касающийся палец («сломано» из Hook), а старт от цели анимации телепортирует шит под большим пальцем пользователя. Прямая манипуляция переворачивает обычный контракт UI: для кнопок ввод — это запрос; для перетаскиваемой поверхности ввод — это владение.

Тач-бюджеты: постмортем 12 fps в цифрах

Прокрутим Hook с числами. pointermove ~120 событий/с на дигитайзере, ~2 события на кадр при 60 Гц. Каждый обработчик: запись height (инвалидирует layout), затем чтение offsetHeight — форсированный синхронный layout, 5–8 мс на среднем SoC. Два события на кадр ≈ 10–16 мс форсированного layout, плюс style/paint, которые пачкает само изменение высоты, ≈ бюджет сорван каждый кадр: 12 fps. Исправленный обработчик: одна rAF-батченная запись transform на кадр (микросекунды), ноль чтений layout после pointerdown, touch-action: none, чтобы браузер не гадал о намерении скролла. То же железо, 60 fps — дело никогда не было в телефоне. Две финальные заметки: getCoalescedEvents() отдаёт полный след слитых move-событий, если нужна чернильная точность без обработчика на каждое событие; и prefers-reduced-motion распространяется и на анимации отпускания жестов — снап вместо пружины для тех, кто это попросил.