Conceptos erróneos sobre las transiciones de vistas

La API de View Transition es un cambio radical en el desarrollo web. Ya sea que tu sitio web tenga una o varias páginas, esta potente API te permite crear transiciones fluidas entre vistas, lo que genera experiencias similares a las nativas que cautivan a los usuarios. Actualmente, está disponible en Chrome, y las mismas transiciones de vista de documentos pronto estarán disponibles en Safari.

Cada vez más personas comienzan a analizar la API de View Transition, por lo que es hora de desmitificar algunos conceptos erróneos.

Error de concepto 1: La API de View Transition toma capturas de pantalla

Cuando se ejecuta una transición de vista, la API toma instantáneas del estado anterior y nuevo del contenido. Luego, estas instantáneas se animan, como se detalla en la sección "Cómo funcionan estas transiciones" de la documentación.

Si bien puedes usar el término captura de pantalla para la instantánea anterior, la nueva instantánea no es una captura de pantalla, sino una representación en vivo del nodo. Piensa en él como un elemento reemplazado.

::view-transition
└─ ::view-transition-group(root)
   └─ ::view-transition-image-pair(root)
      ├─ ::view-transition-old(root) 👈 Screenshot
      └─ ::view-transition-new(root) 👈 Live representation

Gracias a este aspecto en vivo, funcionan demos como esta: el video, que proviene de la nueva instantánea, sigue reproduciéndose mientras se produce la transición de vista.

Video en reproducción que participa en una transición de vista Demostración mínima. Fuente.

La lógica y el CSS que se usan para esto se detallan en nuestra documentación.

Error de concepto 2: Capturar más de un elemento genera que se ejecuten varias transiciones de vista.

Cuando captures varios elementos, el proceso de creación de instantáneas capturará todos los estados nuevos y anteriores. Cuando capturas un .box además del elemento :root, obtienes este pseudoárbol:

::view-transition
└─ ::view-transition-group(root)
|  └─ ::view-transition-image-pair(root)
|     ├─ ::view-transition-old(root)
|     └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
   └─ ::view-transition-image-pair(box)
      ├─ ::view-transition-old(box)
      └─ ::view-transition-new(box)

Si bien este árbol contiene varios pares de instantáneas, solo se ejecuta una sola transición de vista.

Actualmente, Chrome se limita a ejecutar una transición de vista por documento al mismo tiempo. Haz clic rápidamente en esta demostración para iniciar una nueva transición de vista. Notarás que la transición en curso se salta al final cuando comienza una nueva.

Error de concepto 3: No puedes implementar transiciones de vista debido a la compatibilidad con el navegador

Muchos desarrolladores se preocupan porque no pueden implementar transiciones de vistas porque solo son compatibles con Chrome. La buena noticia es que Safari está trabajando en esto y lo incluirá en la próxima versión de Safari 18.

Sin embargo, no dejes que la compatibilidad irregular con los navegadores te impida implementar transiciones de vista hoy mismo. Las transiciones de vista son el material perfecto para la mejora progresiva. En la documentación original, se comparte un método para agregar esta metodología a tu código.

function handleClick(e) {
    // Fallback for browsers that don't support this API:
    if (!document.startViewTransition) {
        updateTheDOMSomehow();
        return;
    }

    // With a View Transition:
    document.startViewTransition(() => updateTheDOMSomehow());
}

Si tu navegador admite transiciones de vista del mismo documento, obtendrás la versión enriquecida y animada. Si no es así, obtendrás la experiencia actual. Con el tiempo, a medida que más y más navegadores admitan transiciones de vista, más usuarios podrán experimentar esta versión enriquecida, todo de forma automática.

Lo mismo se aplica a las transiciones de vista entre documentos. Los navegadores que no los admitan ignorarán la habilitación de CSS cuando analicen las hojas de estilo.

Este enfoque se implementó correctamente en el comercio electrónico, como se detalló en este caso de éxito.

Error de concepto 4: Las transiciones de vista interrumpen la renderización incremental

Hay afirmaciones de que las transiciones de vista interrumpen la renderización incremental. Esto no es cierto: las transiciones de vista entre documentos se especificaron para no romper este aspecto fundamental de la Web.

Los navegadores comienzan a renderizar una página cuando tienen “suficiente” contenido. En la mayoría de los navegadores, esto ocurre después de cargar todos los editores de estilo en <head>, analizar todo el código JavaScript que bloquea la renderización en <head> y cargar suficiente lenguaje de marcado. Las transiciones de vista entre documentos no cambian esto: el contenido necesario para el primer procesamiento de imagen con contenido no se altera. Después de esta primera renderización, el navegador puede renderizar de forma incremental el contenido recibido recientemente.

Puedes bloquear la renderización hasta que un elemento determinado esté presente en el DOM. Esto es conveniente en situaciones en las que deseas asegurarte de que los elementos que participan en la transición de la vista estén presentes en la página nueva.

Para ello, usa esta etiqueta de vínculo:

<link rel="expect" blocking="render" href="#elementId">

Esto anula las heurísticas del navegador que se usan para decidir cuándo realizar la primera renderización: la primera renderización se retrasa hasta que el elemento especificado esté presente en el árbol del DOM.

Este bloqueo manual tiene algunas protecciones integradas. Por ejemplo, cuando se ve la etiqueta de cierre </html>, pero no se vio el elemento de bloqueo, la renderización ya no se bloqueará. Además, puedes agregar tu propia lógica de tiempo de espera, que quita el atributo de bloqueo en cualquier momento.

Es evidente que el bloqueo del procesamiento se debe usar con precaución. El impacto de bloquear la renderización debe evaluarse caso por caso. De forma predeterminada, evita usar blocking=render, a menos que puedas medir y evaluar de forma activa el impacto que tiene en tus usuarios, midiendo el impacto en tus métricas de rendimiento.

Error de concepto 5: El proceso de creación de instantáneas es lento o costoso

Mientras la API de View Transition prepara la vista nueva y obtiene sus instantáneas, el usuario puede ver la vista anterior. Por este motivo, el usuario puede ver la página anterior un poco más tiempo que sin transiciones de vista. Sin embargo, esta demora es insignificante, en realidad solo unos pocos fotogramas. En Chrome, el impacto de pageswap, por ejemplo, es de dos fotogramas inactivos como máximo: uno para ejecutar la lógica y un fotograma adicional para garantizar que las instantáneas se hayan compuesto y almacenado en caché.

Además, los datos de las instantáneas se toman directamente del compositor, por lo que no hay pasos adicionales de diseño o repintado que se deban realizar para obtener los datos de la instantánea.

Error adicional: Es la API de View Transitions

Cuando se habla de transiciones de vistas, a menudo se hace referencia a la "API de View Transitions". Incorrecto. La API se llama "API de View Transition" (ten en cuenta que "Transition" está en singular).

El error proviene de algunos artículos, incluidas nuestras propias documentos sobre DCC, en los que se usa el término incorrecto.

El truco para recordar el nombre correcto es usar la (una) API de View Transition para crear (una o más) transiciones de vista.