El patrón FLIP desde cero

Hay una clase de animación que el navegador no sabe hacer y que la gente intenta forzar durante años antes de descubrir que existe una técnica para ella: animar un elemento entre dos posiciones que no controlas, decididas por el motor de layout. Un elemento que pasa de una celda de un grid a otra, de un contenedor a otro, de una lista ordenada por fecha a la misma lista ordenada por precio. CSS no puede interpolar entre dos layouts porque el layout no es un valor. FLIP resuelve exactamente eso, y lo resuelve dando la vuelta al problema de una forma que, una vez la ves, resulta obvia.

Las cuatro letras

El nombre es un acrónimo de las cuatro fases, acuñado por Paul Lewis, y describe literalmente el algoritmo.

First. Mides dónde está el elemento ahora mismo. Posición, tamaño, y si hace falta rotación y otras propiedades.

Last. Aplicas el cambio real y definitivo: mueves el nodo, cambias la clase, reordenas la lista, lo que sea. El navegador recalcula el layout y el elemento salta instantáneamente a su posición final. Durante un frame, el usuario vería el salto, pero no llega a verlo porque la siguiente fase ocurre antes de pintar.

Invert. Mides dónde ha quedado, calculas la diferencia con la medida de la fase First, y aplicas una transformación que cancela exactamente esa diferencia. El elemento está en su posición final según el layout, pero se ve en su posición inicial.

Play. Animas esa transformación hasta cero. A medida que la transformación se reduce, el elemento parece viajar desde donde estaba hasta donde está.

flowchart TB
a[First mide el rectangulo inicial] --> b[Last aplica el cambio de layout real]
b --> c[Invert aplica un transform que cancela la diferencia]
c --> d[Play anima ese transform hasta cero]
d --> e[El layout final ya estaba puesto desde el paso Last]
style a fill:#89b4fa,color:#11111b
style b fill:#f9e2af,color:#11111b
style c fill:#cba6f7,color:#11111b
style d fill:#a6e3a1,color:#11111b
style e fill:#94e2d5,color:#11111b

El nodo final del diagrama es la clave de todo y merece leerse despacio. El layout definitivo se aplica al principio, no al final. Durante toda la animación, el DOM ya está en su estado final; lo único que cambia es una transformación visual. Eso significa que si el usuario interrumpe la animación, si la pestaña se congela, si algo falla a mitad, el estado real ya es el correcto. La animación es puramente decorativa sobre un estado que ya está bien.

Por qué invertir es más barato

Aquí está la razón de que FLIP exista, y no es estética: es de coste.

Animar el layout significa que en cada frame el navegador tiene que recalcular la geometría de todo lo afectado. Cambiar el width de un elemento obliga a recalcular la posición de sus hijos, la de sus hermanos siguientes, la del contenedor si su tamaño depende del contenido, y así hacia arriba. Después hay que repintar todas esas zonas. Sesenta veces por segundo.

Animar una transformación no hace nada de eso. transform y opacity son las dos propiedades que el navegador puede resolver en la fase de composición, sin volver a calcular layout ni repintar. El elemento ya está pintado en una textura; moverla o escalarla es trabajo de la GPU, y el hilo principal ni se entera.

La diferencia no es de un veinte por ciento. Es la diferencia entre una animación que se cae a veinte frames por segundo con veinte elementos y una que aguanta doscientos elementos a sesenta.

Y hay un segundo ahorro menos obvio. En FLIP, el recálculo de layout ocurre exactamente una vez, en la fase Last. Una animación de layout lo provoca en cada frame. Cambiar un coste por frame por un coste único es la misma jugada que hace un compilador cuando saca un cálculo invariante fuera de un bucle.

Hacerlo a mano

Merece la pena escribirlo una vez sin biblioteca, porque entonces entiendes qué automatiza el plugin.

function flip(elemento, cambiarLayout) {
  // First: medir el estado actual
  const primero = elemento.getBoundingClientRect();

  // Last: aplicar el cambio real
  cambiarLayout();

  // Medir el estado final
  const ultimo = elemento.getBoundingClientRect();

  // Invert: calcular la diferencia y cancelarla
  const dx = primero.left - ultimo.left;
  const dy = primero.top - ultimo.top;
  const sx = primero.width / ultimo.width;
  const sy = primero.height / ultimo.height;

  // Play: animar la transformacion hasta cero
  return elemento.animate(
    [
      { transformOrigin: "top left", transform: `translate(${dx}px, ${dy}px) scale(${sx}, ${sy})` },
      { transformOrigin: "top left", transform: "none" },
    ],
    { duration: 400, easing: "cubic-bezier(0.4, 0, 0.2, 1)" }
  );
}

// Uso: mover una tarjeta de un contenedor a otro
const tarjeta = document.querySelector(".tarjeta");
const destino = document.querySelector(".columna-derecha");

document.querySelector("#mover").addEventListener("click", () => {
  flip(tarjeta, () => destino.appendChild(tarjeta));
});

Ese código funciona pegado tal cual y hace FLIP de verdad. Fíjate en el transformOrigin: "top left": sin él, la escala se aplica desde el centro y las cuentas de la traslación dejan de cuadrar, porque getBoundingClientRect mide desde la esquina superior izquierda.

Los tres problemas que quedan

La versión manual funciona para el caso sencillo y se rompe en cuanto sales de él. Estos son los tres agujeros, y son exactamente lo que el plugin de GSAP resuelve.

Contenedores transformados. getBoundingClientRect devuelve coordenadas del viewport, ya afectadas por cualquier transformación de los ancestros. Si el contenedor de origen está escalado a 0,8 y el de destino no, la diferencia que calculas incluye ese factor y la transformación que aplicas es incorrecta. Con rotaciones el problema se vuelve intratable a mano, porque una diferencia de posición ya no se puede expresar como una traslación en los ejes del elemento.

Escalar frente a redimensionar. El código de arriba usa scale, que es barato pero deforma el contenido: si la tarjeta crece al doble, su texto también, y se ve estirado durante la animación. La alternativa es animar width y height, que no deforma pero cuesta layout. Elegir entre las dos, y poder cambiar de opinión, requiere dos implementaciones distintas.

Elementos que entran y salen. Si el cambio de layout hace aparecer un elemento nuevo, no hay medida First para él. Si hace desaparecer uno, no hay medida Last. Ambos casos son frecuentes —filtrar una lista los produce constantemente— y ninguno cabe en la función de arriba.

A eso se suman los detalles: interrupciones a mitad de animación, elementos anidados cuyas transformaciones se acumulan, y la necesidad de sacar elementos del flujo con position: absolute para que los layouts de tipo flex y grid no compriman todo mientras dura el movimiento.

// Lo mismo que la funcion manual, con el plugin
import { gsap } from "gsap";
import { Flip } from "gsap/Flip";

gsap.registerPlugin(Flip);

const estado = Flip.getState(".tarjeta");
destino.appendChild(tarjeta);
Flip.from(estado, { duration: 0.4, ease: "power2.inOut" });