FLIP: анимация layout без layout на каждом кадре

Проблема: направление движения — изменение layout

Переупорядоченные списки, раскрывающиеся карточки, элементы, входящие в сетку, — конечное состояние действительно отличается геометрией, так что какая-то работа layout неизбежна. Наивные реализации анимируют сами layout-свойства (top, left, width, height), а это худший случай из прошлого урока, умноженный на число элементов: каждый кадр заново гоняет style, layout и paint для каждого анимируемого элемента и всего, чего касается их геометрия. Числа из Hook: layout колонки в 200 карточек стоит ~8 мс, paint ~4 мс — 12 мс из кадра в 16,7 мс при 60 Гц потрачены до всякого JS, а при 120 Гц это арифметически невозможно. Озарение за FLIP: браузеры превосходны в анимации transform, а любое движение между двумя известными прямоугольниками выражается трансформом. Так вычислите оба прямоугольника — и не анимируйте геометрию вовсе.

FLIP: First, Last, Invert, Play

First — измерить прямоугольник каждого элемента до изменения. Last — применить настоящее изменение DOM (React коммитит переупорядочивание) и измерить новые прямоугольники. Invert — для каждого элемента вычислить дельту и применить трансформ, визуально возвращающий его назад, где он был: DOM в финальном состоянии, но экран всё ещё показывает старое. Play — анимировать трансформ к identity; элемент скользит туда, где он уже находится. В React шов для Last и Invert — useLayoutEffect: он выполняется после мутации DOM, но до отрисовки, так что пользователь никогда не видит неинвертированный кадр. Все четыре шага вместе означают: layout выполняется только в конечных точках, никогда в середине; пропусти Invert — и пользователь увидит визуальный скачок ещё до начала анимации.

function reorder(nextOrder) {
  // First: измеряем каждую строку ДО того, как React закоммитит новый layout
  const first = new Map();
  refs.current.forEach((el, id) => first.set(id, el.getBoundingClientRect()));
  firstRects.current = first;
  setOrder(nextOrder);
}

useLayoutEffect(() => {
  const first = firstRects.current;
  if (!first) return;
  firstRects.current = null;
  // Last: новый layout уже в DOM, но ещё не отрисован
  refs.current.forEach((el, id) => {
    const f = first.get(id);
    if (!f) return;                              // вошедший элемент: нет First-прямоугольника
    const l = el.getBoundingClientRect();        // батч чтений — записей ещё нет
    const dx = f.left - l.left;
    const dy = f.top - l.top;
    if (dx === 0 && dy === 0) return;
    // Invert + Play: стартуем смещёнными, анимируем к identity
    el.animate(
      [{ transform: `translate(${dx}px, ${dy}px)` }, { transform: "none" }],
      { duration: 220, easing: "cubic-bezier(0.2, 0, 0, 1)" }
    );
  });
}, [order]);

На дроп это платит за layout дважды — один раз неявно, когда чтения First едут на чистом layout прошлого кадра, и один раз, когда чтения Last форсируют layout для свежезакоммиченного DOM, — а затем каждый анимированный кадр — трансформная работа, годная компоновщику. WAAPI el.animate — правильный инструмент для Play: он компонуется с остальными стилями элемента, сам прибирается и даёт finished и cancel для прерывания.

getBoundingClientRect и layout-трэшинг

getBoundingClientRect дёшев, когда layout чист, — он читает кэшированную геометрию. Дорог он ровно в одной ситуации: layout грязный (что-то записало стиль или мутировало DOM после последнего layout), и тогда браузер обязан выполнить форсированный синхронный layout прямо сейчас, чтобы ответить корректно. Перемежайте чтения и записи в цикле — и вы форсируете один layout на итерацию: заморозка из Hook на 380 мс была 200 форсированными layout в одном кадре. Дисциплина — батчирование: сначала все чтения, потом все записи. Корректно написанный FLIP батчируется естественно: First — проход чтений, коммит — один залп записей, Last — проход чтений, Invert — проход записей. Сломайте порядок (прочитать карточку, трансформировать, прочитать следующую) — сами трансформы в порядке, но чередование воскрешает трэшинг.

layoutId во Framer Motion: FLIP с автоматизированными измерениями

Проп layout и layoutId во Framer Motion — не другая технология, это FLIP, где бухгалтерию ведут за вас. На каждом рендере библиотека измеряет bounding box каждого отслеживаемого элемента, сравнивает с предыдущими измерениями и, если бокс сдвинулся или изменил размер, применяет инвертированную дельту как трансформ и проигрывает к identity. layoutId расширяет тот же трюк между компонентами: когда монтируется новый элемент с layoutId только что размонтированного, библиотека берёт rect старого элемента как First, а rect нового как Last — переход общего элемента, собранный из тех же getBoundingClientRect и transform, которые вы можете написать руками. Это знание демистифицирует режимы отказа: layout-анимации стоят проход измерений на рендер (поэтому layout навешивают на то, что двигается, а не на всё дерево), и всё, что FLIP не может подделать — перенос текста, отдельные эффекты paint, — Framer Motion тоже не может.

Искажение масштаба и контр-масштабная коррекция

Перемещение элементов — лёгкий случай: translate ничего не искажает. Изменение размера через FLIP означает анимацию scale, а scale умножает всё внутри: раскрывающаяся карточка, едущая с 320 px к 640 px ширины, в полёте визуально сжимает или растягивает своих детей — текст, аватары, рамки. Коррекция — контр-масштабирование детей: применить обратный коэффициент (1/масштаб-родителя, пересчитываемый на каждом кадре, потому что масштаб родителя меняется на каждом кадре) к обёртке детей. Framer Motion делает это автоматически для вложенных layout-элементов; рукописный FLIP обязан вести обе анимации от одних часов. У border-radius та же болезнь: радиус 12 px под scaleX(2) отрисовывается эллипсом 24 на 12 px — поэтому продакшен-FLIP либо анимирует радиус отдельно, либо принимает краткое искажение на быстрых (до ~250 мс) анимациях.

Где FLIP ломается

• Перенос текста. Если реальная ширина меняется, текст переносится по строкам на ширине назначения. FLIP показывает масштабированный — растянутый — текст в полёте, а в конце текст внезапно правильный; не существует трансформа, который переносит строки. Варианты: зафиксировать ширину контейнера текста и анимировать только бокс; кроссфейд между двумя снимками; держать анимацию настолько короткой, что растяжение читается как motion blur.
• Входящие и выходящие элементы. Только что смонтированный элемент не имеет First-прямоугольника (нечего инвертировать — дайте ему отдельную анимацию входа); размонтированный нельзя измерить для Last (его больше нет — анимациям выхода нужен живой элемент, что и делает AnimatePresence).
• Протухшее измерение. First измерили, а затем что-то ещё сдвинуло страницу (догрузилась картинка, схлопнулся баннер) до Last — дельты неверны, и элементы скользят из неправильного начала. Измеряйте как можно позже, непосредственно перед коммитом.

Числа: переупорядочивание 200 элементов, наивно против FLIP

Наивный твин на top, 200 элементов, 60 Гц: каждый кадр платит пересчёт стилей (~1,5 мс) + layout (~8 мс) + paint (~4 мс) ≈ 13,5 мс — бюджет превышен при нулевом JS, наблюдаемые ~22 fps, а при 120 Гц это невозможно даже теоретически. FLIP на том же списке: кадр дропа платит два прохода layout (чтения First едут на чистом layout прошлого кадра; чтения Last форсируют один layout ≈ 8 мс) плюс 200 вызовов el.animate (~1 мс) — один длинноватый кадр в ~10–15 мс однократно, а дальше каждый анимированный кадр — только transform: микросекунды главного потока, остальное делает компоновщик, ровные 60 fps на ноутбуке из Hook. Сделка честная: FLIP покупает покадровую свободу ценой ограниченной разовой стоимости измерений — и эта стоимость растёт с числом элементов, поэтому Framer Motion ограничивает измерения элементами с тегом layout, а не всем деревом.