Planteamiento y alcance
Un producto requiere efectos con la View Transition API para cambios de ruta en una SPA y para abrir una vista detallada de imagen. Explica la implementación y cómo manejas navegadores más antiguos, prefers-reduced-motion, datos asíncronos, foco, fallos de animación y alternativas de rendimiento.
Esto evalúa los límites de la API y la mejora progresiva, no una animación de demostración. MDN define document.startViewTransition() como el punto de entrada de actualización en el mismo documento e indica que la transición continúa después de que la devolución de llamada se completa; las transiciones entre documentos también requieren el mismo origen y @view-transition en CSS. La animación debe estar al servicio de los cambios de estado y nunca bloquear la usabilidad.
Qué está evaluando el entrevistador
Primero, ¿puedes distinguir entre transiciones en el mismo documento para SPA, con alcance de elemento y entre documentos? Segundo, ¿puedes manejar APIs no compatibles, devoluciones de llamada rechazadas, reducción de movimiento y salida de la página? Tercero, ¿puedes preservar el foco, el DOM semántico, el desplazamiento y la interacción real en lugar de ocultarlos tras una animación de instantánea?
Preguntas para aclarar antes de responder
- ¿Qué límite está en transición? ¿Una actualización del DOM en el mismo documento, un solo elemento o la navegación entre documentos?
- ¿La actualización incluye datos asíncronos? ¿Qué debe estar listo primero y cuál es la espera máxima?
- ¿Cuál es la experiencia aceptable en navegadores más antiguos? La misma actualización de estado debe funcionar sin animación.
- ¿Qué usuarios reducen o desactivan el movimiento? ¿Cómo se combinan
prefers-reduced-motiony un ajuste de la aplicación? - ¿Cómo se restaura el estado de la página? ¿Foco, desplazamiento, entrada de formularios y navegación hacia atrás?
- ¿Cuál es el presupuesto de rendimiento? ¿Alcance de la instantánea, duración, dispositivos de gama baja y transiciones concurrentes?
Una estructura de respuesta en 30 segundos
“Separaría la actualización de estado de la animación: cuando sea compatible, envolvería una actualización síncrona del DOM en startViewTransition; de lo contrario, ejecutaría la misma actualización directamente. Prepararía los datos asíncronos en la ruta o el componente, mantendría la devolución de llamada enfocada en aplicar el estado listo y observaría ready, finished y skipTransition. Usaría vistas con nombre para limitar el alcance, acortaría o desactivaría el movimiento bajo prefers-reduced-motion, restauraría el foco y el desplazamiento, y garantizaría que un fallo en la animación no pueda bloquear la interacción. Validaría tareas largas, cantidad de instantáneas, tiempo de finalización y tasa de uso de alternativas en dispositivos de gama baja.”
Análisis detallado paso a paso
Paso 1: Definir la actualización de estado y el objetivo de la animación
Nombra los dos estados que conecta la animación, como una tarjeta de lista con una página de detalle o resultados filtrados con una nueva lista, en lugar de desvanecer toda la página indiscriminadamente. La actualización debe ser correcta sin animación; la animación es una capa de mejora. Define nombres de transición permitidos y el comportamiento de respaldo para cada tipo de navegación.
Paso 2: Detectar compatibilidad y mantener un respaldo síncrono
Verifica document.startViewTransition antes de llamarlo. Los navegadores no compatibles ejecutan la misma función de actualización directamente; no dupliques la lógica de negocio. El soporte en navegadores nuevos no cubre todos los dispositivos antiguos, así que mantén una ruta de respaldo según lo requiere la guía de compatibilidad de MDN.
Paso 3: Delimitar la devolución de llamada y los datos asíncronos
updateCallback se ejecuta después de la instantánea de la vista anterior; la Promise devuelta debe cumplirse antes del siguiente fotograma. Obtén los datos antes de comenzar siempre que sea posible. Si la devolución de llamada debe esperar, establece un tiempo de espera y permite que la transición se omita. Una devolución de llamada rechazada sigue el manejo habitual de errores de negocio y no debe exponer una página actualizada a medias.
const update = () => renderState(nextState);
if (!document.startViewTransition || reduceMotion) {
update();
} else {
const transition = document.startViewTransition(update);
transition.finished.catch(() => {
// Animation failure does not roll back the completed state update.
});
}Paso 4: Limitar las instantáneas con vistas con nombre
Asigna un view-transition-name único solo a los elementos que realmente comparten una posición. Los componentes de lista repetidos no pueden compartir un mismo nombre sin ambigüedad. Para listas dinámicas, borra los nombres antiguos antes de actualizar y asigna nombres únicos estables después.
Paso 5: Implementar reducción de movimiento y comportamiento accesible
Escucha prefers-reduced-motion: reduce, establece la duración en cero o cerca de cero y mantén el cambio de estado. No ocultes el foco del teclado ni comuniques resultados únicamente mediante el color. Tras la actualización, mueve el foco al encabezado de la nueva vista o su equivalente. web.dev advierte que las animaciones de transición de vista a pantalla completa pueden incomodar a personas con trastornos vestibulares.
Paso 6: Manejar diferencias entre SPA, elementos y entre documentos
Una SPA envuelve su actualización del DOM con document.startViewTransition; una transición con alcance de elemento afecta al elemento que la llama y a sus descendientes; una navegación entre documentos requiere el mismo origen y la habilitación explícita mediante @view-transition en ambos documentos. No asumas que existe una devolución de llamada de JS en el mismo documento a lo largo del ciclo de vida del documento.
Paso 7: Diseñar rutas de omisión, concurrencia y fallo
Para clics rápidos, cancela o fusiona navegaciones obsoletas para que las transiciones no compitan por el mismo nodo. Usa skipTransition() o un tiempo de espera para finalizar una animación atascada. Una vez que se actualiza el estado de negocio, un fallo visual no debe causar envíos duplicados, solicitudes duplicadas o una reversión incorrecta.
Paso 8: Validar el rendimiento y la experiencia de usuario real
Monitorea el tiempo de inicio a fin, la tasa de omisión, las tareas largas, el CLS, el retraso de entrada y los errores en dispositivos de gama baja. Haz pruebas con listas grandes, redes lentas, trabajo asíncrono rechazado, navegación rápida hacia atrás, lectores de pantalla y reducción de movimiento. Confirma que las instantáneas y la animación nunca hagan que la interacción real espere más tiempo.
Compensaciones y límites
Compensación 1: Transición de página completa o local
Las transiciones de página completa son más sencillas pero cuestan más instantáneas y pueden interferir con el foco y el desplazamiento. Las transiciones locales requieren nombres estables y límites de componentes precisos, lo que las hace mejores para interacciones frecuentes y páginas grandes.
Compensación 2: Esperar datos o hacer la transición inmediatamente
Esperar evita la discrepancia entre el contenido antiguo y el nuevo, pero incrementa el tiempo de respuesta. Prefiere la precarga; de lo contrario, muestra un estado de carga explícito. Una transición no reemplaza la retroalimentación de carga.
Compensación 3: Animación personalizada o predeterminada del navegador
Los valores predeterminados son más seguros y fáciles de mantener. Invalida la animación de pseudoelementos solo con una semántica de navegación clara y presupuesto de verificación, y proporciona un estado estático igualmente funcional para la reducción de movimiento.
Simulacros de fallos y plan de evolución
Simulacro 1: Navegador no compatible o devolución de llamada rechazada
Actualiza directamente en un navegador no compatible, rechaza la Promise y verifica que el estado de la página siga siendo correcto. Registra solo información de diagnóstico y nunca bloquees la interacción continua.
Simulacro 2: Navegación rápida y carrera asíncrona
Haz clic en dos enlaces rápidamente mientras haces que la primera solicitud sea más lenta. Verifica que la transición obsoleta no pueda sobrescribir el estado actual, que el foco quede en la página actual y que no se envíe una solicitud de efecto secundario duplicada.
Simulacro 3: Reducción de movimiento y dispositivo de gama baja
Habilita la reducción de movimiento del sistema y ejecuta una transición de lista grande en un dispositivo con CPU limitada. Confirma que la animación esté desactivada o acortada mientras el retraso de entrada y la estabilidad del diseño se mantienen dentro del presupuesto.
Errores comunes y seguimiento
Error 1: Sin ruta de respaldo
Las APIs no compatibles deben seguir produciendo la misma actualización de DOM o de ruta. La mejora progresiva no puede supeditar el estado de negocio al éxito de la animación.
Error 2: Esperar indefinidamente a la red dentro de la devolución de llamada
Las esperas largas tras la instantánea congelan la página anterior. Prepara los datos antes o establece un tiempo de espera y omite la animación.
Error 3: Asignar un único nombre compartido a muchos elementos
Los nombres duplicados generan ambigüedad de coincidencia e instantáneas adicionales. Nombra únicamente el elemento que realmente se mueve y mantén su nombre único y estable.
Error 4: Ignorar el foco y el desplazamiento
Una transición visual finalizada no devuelve a los usuarios de teclado al lugar correcto. Restaura explícitamente el foco, el desplazamiento y el encabezado semántico.
Error 5: Tratar la reducción de movimiento como la eliminación de la funcionalidad
Los usuarios solicitan menos movimiento, no menos estado o información. Mantén la misma interacción y cambia únicamente la presentación de la animación.
Error 6: Revertir el estado de negocio cuando falla la animación
El rechazo de finished suele describir un fallo en la etapa visual. No reenvíes ni reviertas una actualización de estado que ya se completó exitosamente.