Comment utiliser l'API View Transitions ? Du hello world aux cas complexes.

Vous avez peut-être entendu parler des View Transitions ? C’est la nouvelle API dans les navigateurs qui, avec une ligne de CSS et une ligne de JS promet d’animer vos transitions de manière performante.

Des démos assez chouettes sont déjà disponibles notamment autour de l’écosystème Astro. Par exemple avec :

• 

  Playlists
  (Code source)

• 

  Music Library
  (Code source)

En ce qui nous concerne, on va se concentrer sur un cas : passer d’une liste contenant plusieurs articles imagés à une pleine page qui reprend la même image dans son header.

C’est assez classique, mais cela représente plusieurs difficultés :

• Comment s’assurer que l’animation de l’image se fasse correctement dans les deux sens ?
• Comment éviter de dégrader les performances en n’animant que ce qui est nécessaire ?
• Les dimensions entre la vue liste et la vue pleine page sont assez différentes : comment faire pour que l’animation soit tout de même fluide ?
• Comment éviter des flashs pendant le chargement de l’image pleine page ?

💡 Attention ce n’est pour l’instant disponible que sur les navigateurs basés sur Chromium. Mais les autres navigateurs ont donné leur accord sur l’API et vont donc l’implémenter dans les années à venir. De plus, cet article se concentrera uniquement sur les animations déclenchées en JavaScript. Nous ne nous attarderont pas sur le cas des Multi Pages Applications (MPAs) qui ne sont pas encore sorties du mode expérimental dans Chromium.

Présentation de l’API View Transition §

Avant de rentrer dans le cœur du sujet, prenons un exemple sans animation :

Essentiellement, il s’agit du code suivant :

input.addEventListener('change', () => {
	element.classList.toggle('active');
});

Par le passé, si j’avais voulu l’animer, j’aurais dû jouer sur des propriétés CSS, manipuler des positions, et peut-être utiliser des techniques comme les animations FLIP pour m’assurer que ce soit performant.

Mais grâce à la nouvelle API des View Transitions, si je veux l’animer, je n’ai qu’une seule chose à faire : entourer le code qui active la modification de style par document.startViewTransition.

input.addEventListener('change', () => {
+	document.startViewTransition(() => {
		element.classList.toggle('active');
+	});
})

💡 Attention toutefois, document.startViewTransition n’est pas disponible partout. Veillez donc à vérifier son existence afin de ne pas casser tous les autres navigateurs :

input.addEventListener('change', () => {
+	if ('startViewTransition' in document) {
		 document.startViewTransition(() => {
			 element.classList.toggle('active');
		 });
+	} else {
+		 element.classList.toggle('active');
+	}
})

Une fois ceci fait, vous obtiendrez le résultat suivant :

Avec ce petit changement de code, on a maintenant un crossfade entre les deux états, autrement dit l’état précédent disparaît pendant que le nouvel état apparaît. En effet, document.startViewTransition dit essentiellement au navigateur de :

1. Prendre un screenshot de la page avant
2. Prendre un screenshot de la page après
3. Animer la transition entre les deux

Mais animer l’opacité n’est pas toujours le mieux. Heureusement, il est possible d’indiquer au navigateur comment animer la transition.

Notamment, plutôt que de faire un screenshot de la page entière, on peut lui dire d’animer uniquement une petite partie. Dans notre cas, on ne veut animer que l’Element.

Pour cela, il nous faut ajouter une propriété CSS :

.element {
	view-transition-name: element-id;
}

Vous pouvez lui donner n’importe quelle valeur. L’essentiel est que cet id soit unique sur votre page.

Ainsi, dès cet instant, le navigateur sait que l’élément ne disparaît pas mais est simplement déplacé. Alors il va faire sa magie noir et le déplacer. 🎉

💡 Accessibilité : Gardez en tête toutefois que des animations de la sorte peuvent donner la nausée à toute une partie de vos utilisateurices (par exemple celles et ceux atteint de troubles vestibulaires).

A ce titre, il est préférable de désactiver les animations de transition quand la préférence “reduced motion” est activée dans le navigateur.

Cela peut être fait de manière globale avec ces quelques lignes de CSS. AInsi, je vous conseille de l’ajouter dans vos reset dès aujourd’hui, plutôt que de l’oublier demain.

@media (prefers-reduced-motion: reduce) {
	* {
		view-transition-name: unset !important;
	}
}

Faire fonctionner document.startViewTransition dans un framework JS §

➡️ Si vous vous en moquez des frameworks JS, RDV à la section suivante. 😘

L’exemple ci-dessus est un exemple qui fonctionne en Vanilla JS. Cela dit, gardez en tête qu’il peut y avoir quelques subtilités en fonction du framework que vous utilisez. En effet, la plupart des frameworks font une tâche d’optimisation pour vous : quand vous mettez à jour votre state, il ne met pas à jour directement votre DOM. Il attend un petit peu pour faire toutes les modifications d’un coup. La conséquence, c’est que cette mise à jour vient trop tard et donc l’animation échoue.

L’astuce est donc de faire en sorte que la mise à jour soit synchrone ou, à défaut, d’attendre qu’elle soit finie.

document.startViewTransition en React §

En React, pour faire une mise à jour synchrone, vous pouvez importer la méthode flushSync et entourer votre changement d’état par celle-ci.

+import { flushSync } from 'react-dom';

const [status, setStatus] = useState('closed');

function open() {
+	if ('startViewTransition' in document) {
+		document.startViewTransition(() => {
+			flushSync(() => {
+				 setStatus('opened');
+			});
+		});
+	} else {
		 setStatus('opened');
+	}
}

document.startViewTransition en Vue.js §

Si vous modifiez la valeur d’une ref, le DOM sera mis à jour de manière synchrone. Vous pouvez donc utiliser document.startViewTransition sans plus de cérémonie.

+import { tick } from 'svelte';
const status = ref('closed');

function open() {
+	if ('startViewTransition' in document) {
+		document.startViewTransition(() => {
+			 status.value = 'opened';
+		});
+	} else {
		 status.value = 'opened';
+	}
}

document.startViewTransition en Svelte §

En Svelte, la mise à jour est nécessairement asynchrone. Donc plutôt que de changer de mode, l’astuce est d’attendre la fin de la mise à jour asynchrone pour déclencher la transition. Pour cela, on va transformer le callback de startViewTransition pour qu’il soit asynchrone et await tick() pour être sûr que la mise à jour est terminée.

let status = 'closed';

function open() {
+	if ('startViewTransition' in document) {
+		document.startViewTransition(async () => {
+			setStatus('opened');
+			await tick();
+		});
+	} else {
		 setStatus('opened');
+	}
}

Utiliser les View Transitions dans un cas complexe (vue liste vers vue page) §

Si je ne vous ai pas encore achevé avec mes explications, nous avons maintenant les bases de l’API des View Transitions. Mais, vous vous en doutez, on peut rapidement tomber dans des cas plus complexes. Pour mieux comprendre la magie qui se cache derrière les View Transitions, nous allons donc essayer d’animer la transition d’une liste vers un bandeau de header.

Cliquez sur un des chiffres ci-dessous pour simuler la vue page :

L’exemple est plus compliqué parce que :

1. ce n’est pas juste un ajout de classe, la structure complète du DOM change. En effet, on passe d’un <button> quand on est dans la vue liste, à un <h4> quand on est sur la nouvelle page
2. selon où on clique, on ne veut pas animer tous les éléments (si je clique sur 4, il ne faudrait pas que le 1 s’anime)
3. la taille de l’élément change afin de simuler le comportement d’une bannière en haut de page

Voyons donc comment gérer ces différentes problématiques pour obtenir une animation aux petits oignons.

Comment faire la transition lorsqu’il y a un changement de DOM ? §

Un peu plus haut, je vous disais que l’API fonctionnait en prenant un screenshot avant, un screenshot après, puis fait une transition entre les deux. De fait, cela veut dire que c’est compatible même si le DOM change complètement entre avant et après.

La seule chose à bien prendre en compte, c’est de s’assurer que la propriété CSS view-transition-name est présente avant ET après, et que son ID soit stable.

Ici, si je veux faire la transition de l’élément 4 de la liste, vers le header 4, il va donc falloir que je fasse en sorte que :

.element--4 {
	view-transition-name: element-id;
}

.header {
	view-transition-name: element-id;
}

Mais ça ouvre le problème que je dois avoir un id différent pour chacun des éléments de la liste. Sinon, le navigateur ne saura pas quel screenshot prendre avant de faire la transition.

D’ailleurs, il vous préviendra dans votre console en affichant le message d’erreur : Unexpected duplicate view-transition-name: <name>.

Le premier réflexe est donc de gérer cela en créant autant de view-transition-name différents qu’il y a d’éléments dans votre liste:

<!-- ⚠️ ne pas faire ça -->

<!-- Dans la vue liste -->
<button style="view-transition-name: element-1">1</button>
<button style="view-transition-name: element-2">2</button>
<button style="view-transition-name: element-3">3</button>
<button style="view-transition-name: element-4">4</button>

<!-- Dans la vue page -->
<header style="view-transition-name: element-4">4</header>

Mais cela a pour inconvénient que ça surcharge le travail du navigateur. Notamment, dans la phase avant, le navigateur va être obligé de prendre un screenshot de tous les éléments qui ont une view-transition-name. Si vous n’en avez que quelques uns sur votre site, ça peut le faire. Mais quand vous aurez adopté cette technique plus largement pour animer beaucoup de transitions, cela va commencer à surcharger votre navigateur et risque d’allonger le temps de vos interactions.

Notamment, j’ai fait quelques tests et dès 25 view-transition-name, sur des périphériques pas très puissants, on dépasse les 100ms de latence entre le click et le début de l’animation. Donc à l’intéraction on commence à ressentir un petit lag. Dès 200 éléments, on constate des lags pendant l’animation, même si l’animation est un simple fade.

Il est donc important d’ajouter des view-transition-name uniquement quand vous en avez besoin, c’est-à-dire juste avant le début de l’animation :

/**
 * @var {number} item
 */
function selectItem(item) {
+	const button = document.querySelector(`#item-${item}`)
+	button.style.setProperty('view-transition-name', 'element');

	document.startViewTransition(async () => {
		goToPage(item);
	});
}

Et de s’assurer que le header, une fois la page ouverte, ait bien la view-transition-name aussi.

.header {
	view-transition-name: element;
}

Attention toutefois, cela gère l’animation dans un sens uniquement : quand vous partez de la page pour revenir à la liste, il faut aussi penser à ajouter la view-transition-name sur le bouton.

/**
 * @var {number} currentItem the id of the displayed header
 */
function unselectItem(currentItem) {
	document.startViewTransition(async () => {
		goToList();

+		const button = document.querySelector(`#item-${currentItem}`)
+		button.style.setProperty('view-transition-name', 'element');
	});
}

Et grâce à ça vous obtenez cette animation :

C’est mieux, mais ce n’est pas encore tout à fait ça. Dans la section suivante, nous allons voir comment améliorer la transition pour éviter ce sentiment de flash, particulièrement visible sur desktop.

💡 Cependant, avant ça, je veux faire un petit laïus sur les frameworks JS, parce qu'il n'est pas forcément évident de voir comment traduire le code JS ci-dessus dans le framework de votre choix.

Cliquez ici pour afficher expliquer comment gérer les View Transitions en React (adaptable aux autres frameworks :))

Si vous essayez de manipuler directement le DOM, React ne va pas être content parce qu’il ne sera plus synchronisé avec le contenu du DOM. Vous finirez juste par avoir une erreur et une page blanche. On va donc plutôt se reposer sur le système de rendu classique. Pour cela, nous allons donc utiliser des states.

Les points qu’il faut retenir sont :

• pour pouvoir correctement animer l’animation de retour il vous faut stocker quelque part l’id de l’item d’origine. Ca peut être dans un state, dans la session ou dans l’URL. A vous d’implémenter les propriétés props.select, props.unselect et props.previousItem. Le piste la plus directe serait de faire un composant parent qui possède un useState.
• pour pouvoir ajouter un view-transition-name juste avant de déclencher l’animation, vous pouvez séparer votre handler d’événement en 2 étapes : un premier flush/render qui ajoute la view-transition-name, une deuxième qui déclenche la startViewTransition.
• dans cet exemple, je pars du principe que vous n’utilisez pas de router externe. Si vous en utilisez un, sachez que Remix supporte les View Transitions, TanStack Router semble pouvoir le faire grâce au hook useNavigate, mais qu’il n’est pour l’instant pas possible de le faire en Next.js.

Voici ce que ça donnerait avec du vrai code :

/**
 * @var {number} props.item
 * @var {(item: number) => void} props.unselect pour revenir à la vue liste
 */
function Page(props) {
	function close(item: number) {
		if ('startViewTransition' in document) {
			document.startViewTransition(() => {
				flushSync(() => {
					props.unselect(item);
				});
			});
		} else {
			props.unselect(item);
		}
	}

	return (
		<div>
			<h4 className="header">{item}</h4>
			<button onClick={close}>
				Revenir à la liste
			</button>
		</div>
	);
}

/**
 * @var {number[]} props.list
 * @var {number|null} props.previousItem récupéré depuis le props.unselect de la Page
 * @var {(item: number) => void} props.select pour aller à la vue page
 */
function List(props) {
	// Si on vient d'une Page, on aura le paramètre passé à props.unselect qui
	// sera disponible.
	// En le passant ensuite via props.previousItem, c'est ce qui nous permet
	// de s'assurer qu'on va bien animer le retour à la liste, et c'est pour
	// cette raison qu'on n'initialise pas toujours le state à `null`
	const [itemWithViewTransitionName, setItemWithTransitionName]
		= useState(previousItem);

	function open(item: number) {
		if ('startViewTransition' in document) {
			// Avant de déclencher l'animation on met à jour le state pour que le
			// bouton concerné récupère la bonne propriété CSS view-transition-name
			flushSync(() => {
				setItemWithTransitionName(item);
			});

			// Puis seulement on déclenche l'animation
			document.startViewTransition(() => {
				flushSync(() => {
					props.select(item)
				});
			});
		} else {
			props.select(item)
		}
	}

	return (
		<ul>
			{list.map((item) => (
				<li key={item}>
					<button
						style={
							itemWithViewTransitionName === item
								? { viewTransitionName: 'element' }
								: undefined
						}
						onClick={() => open(item)}
					>
						{item}
					</button>
				</li>
			))}
		</ul>
	);
}

Comment faire la View Transition quand l’élément change de taille ? §

Voyons maintenant plus en détail pourquoi l’animation ne paraît pas fluide. Pour cela, nous allons utiliser l’onglet Animations dans les DevTools de Chrome (vu que l’API des View Transitions n’existe pas ailleurs pour le moment).

Voir comment utiliser l'onglet Animations

1. Cliquer sur “Customize and control DevTools”
2. Cliquer sur “More tools”
3. Choisir l’outil “Animations”

Cela vous donner accès à ce panneau, sur lequel nous allons appuyer sur “Pause all”.

Dans les faits, cela bloque les prochaines animations qui pourraient advenir dans la page. Ainsi, vous pouvez aller cliquer sur notre exemple de transition et constater qu’une nouvelle timeline est apparue dans la boîte d’animations.

En cliquant dessus, on va voir toutes les animations qui sont en cours d’execution mais avec un temps bloqué à 0. Vous pouvez alors déplacer le petit losange rouge afin de jouer petit à petit l’animation.

Ainsi, si on inspecte l’animation en milieu d’exécution, on constate que cela ressemble à ceci :

Il y a bien une transition avec les screen avant/après, mais les tailles ne sont pas cohérentes. Le screenshot qui vient de la vue liste devient très grand. Il est beaucoup plus haut qu’il ne le devrait.

Heureusement pour nous, on peut le corriger.

Notamment, pendant l’inspection de l’animation, si on utilise l’outil pour cibler un élément du DOM, ça va nous amener tout en haut de l’onglet “Elements” où on verra des ::view-transition-group, ::view-transition-old, ::view-transition-new, etc.

En fait, ce sont des pseudo éléments qui n’existent que le temps de l’animation. On peut imaginer ça comme la structure du DOM qui permet d’afficher les screenshots avant, après, et orchestrer la transition entre les deux.

En les inspectant, on se rend compte qu’on peut vraiment les imaginer comme des tags HTML avec des images auxquels on a donné des propriétés CSS, des animations avec des @keyframes, etc.

Ce que ça veut dire, c’est que si le navigateur a mal positionné ces images, on peut ajouter des propriétés CSS pour corriger ça. Notamment, on va souvent avoir besoin de corriger les tailles, les object-fit, les positions, etc.

Dans notre cas, il faudrait que pendant la transition, le screenshot de l’état après, représenté par le pseudo élément ::view-transition-new(<name>) (où <name> est la valeur de la propriété CSS view-transition-name), soit de la taille de la petite boîte violette plutôt que la grande boîte verte.

Ce qui nous donnerait le code CSS suivant :

/* J'active ces changements sur le screenshot avant (view-transition-old)
ET sur le screenshot après (view-transition-new) parce qu'il faut que
l'animation fonctionne de la même façon à l'ouverture et à la fermeture. */
html::view-transition-old(element),
html::view-transition-new(element) {
	/* `block-size` et `inline-size` peuvent être compris comme
	height & width.
	Dans cet exemple, on les unset parce qu'on ne veut pas qu'il y
	ait de transformation de taille, mais uniquement un
	déplacement/agrandissement de la zone visible. */
	block-size: unset;
	inline-size: unset;

	/* Par défaut les pseudo éléments sont déjà positionnés en absolu,
	mais ferrés en haut à gauche. Dans notre cas, on veut que ce soit
	centré, donc on utilise la bonne vieille méthode du 50% - 50% */
	top: 50%;
	left: 50%;
	translate: -50% -50%;

	/* Par défaut les transitions ont un fade-in et un fade-out pour
	s'assurer d'avoir une transition fluide entre des éléments qui changent
	de couleur ou de contenu. Ici, on sait que seul la fenêtre de visibilité
	change. Donc on peut désactiver cette animation. */
	animation-name: unset;
}

Cependant, si on ne fait que ça, il nous reste un problème : effectivement, l’élément n’est plus trop petit, mais on a perdu l’agrandissement. Le nouveau screenshot est toujours visible.

Pour cela, on va s’aider de la totalité de la structure des ::view-transition-xxx. Notamment, on peut voir que ::view-transition-old et ::view-transition-new sont entourés par un ::view-transition-image-pair qui, lui, est toujours à la bonne taille.

Ne me demandez pas pourquoi sur le screen ci-dessus, ça affiche ::view-transition-group, c’est bien le ::view-transition-image-pair que je survole dans le DOM 😅

Donc pour s’assurer que les images à l’intérieur ne dépassent jamais celui-ci, quel est le CSS qu’on ajoute ?

html::view-transition-image-pair(element) {
	overflow: hidden;
}

Et voilà 🎉 Notre liste s’anime parfaitement à l’ouverture et à la fermeture d’une page. 👏

Pour aller plus loin §

Voici quelques cas que vous pourriez essayer de creuser/implémenter pour vérifier que vous avez bien assimiler toutes ces notions.

Pourquoi est-ce qu'à l'animation de mon image, j'ai un flash blanc disgracieux ? (Cliquez pour voir la réponse)

Si vous cliquez sur le bouton "Agrandir" avec un réseau qui est suffisamment lent, l'animation n'aura pas le comportement que vous espérez : la première version de l'image (petite) fera un fade out, puis pendant quelques (milli)secondes, il ne s'affichera rien, et enfin, quand la nouvelle image (grande) aurai fini de se charger, elle apparaîtra aussi sec.

Toggle zoom

Arrêter la demo

Dès que vous commencerez à manipuler des images dans les View Transitions, ce comportement arrivera. En effet, vous avez des contraintes très différentes entre vos différentes pages. Par exemple, sur une vue liste, il vous faudra peut être une image en 300x300 et sur la vue pleine page, il vous faudra du 1920x600 sur desktop.

Dans la plupart des démos que j'ai vu passer, le partie pris est de charger une image suffisamment grande pour que ce soit la même URL d'image sur la liste ET sur la page.

C'est désastreux pour l'expérience de navigation si vous n'avez pas une connexion fibrée parce que votre liste mettra trop de temps à se charger.

A la place, vous avez deux options :

• Vous pouvez précharger l'image quand vous anticipez que la prochaine action risque d'être l'ouverture de la page (par exemple : si on a un mouseover ou un focus sur desktop, ou si on a un IntersectionObserver suffisamment long sur mobile). Ainsi, le preload permet d'ajouter la grande image en cache et donc de l'avoir à disposition au moment où on déclenche la transition. La probabilité pour que la grande image n'ait pas le temps d'être téléchargée est beaucoup plus faible, et la plupart des personnes n'auront pas de flash.

• Ou bien, toujours commencer par afficher la page avec la petite image. Ainsi, pendant la transition, c'est exactement la même image qui est affichée (la petite), et pendant que la transition se joue, vous commencez à télécharger la grande image afin de l'afficher qu'à partir du moment où vous avez fini de la télécharger. Voici, ci-dessous, ce que ça donnerait :

  Toggle zoom

  

  Arrêter la demo

  function selectItem(item) {
  	document.startViewTransition(async () => {
  		// La fonction goToPage doit bien faire attention
  		// à afficher la page avec comme source la petite image
  		goToPage(item);
  
  		const src = await loadImage(`/image/item/${item}/big`)
          // Une fois seulement que la grande image a été téléchargée
          // (et donc mise en cache), alors on vient l'utiliser
          // dans la page.
          replacePageImageWith(src);
  	});
  }
  
  /**
   * Essaye de télécharger une image et résout la promesse
   * dès que celle-ci a fini de se télécharger
   */
  async function loadImage(src: string) {
      return new Promise((resolve, reject) => {
          const img = document.createElement('img');
          img.addEventListener('load', () => {
              resolve(src);
          });
          img.addEventListener('error', (error) => {
              reject(error);
          });
  
          img.src = src;
  
          // L'image peut avoir déjà été téléchargée.
          // Dans ce cas, l'event `load` n'est pas
          // déclenché. Il faut donc vérifier cela
          // manuellement.
          if (img.complete) {
              resolve(src);
          }
      });
  }
  

  Sauf si vous avez des yeux bioniques, je suis prêt à parier que dans une navigation normale, vous ne remarquerez pas la différence. Mais dans le cas d’un réseau lent, ça fera toute la différence.

const viewTransition = document.startViewTransition(() => ...);

await viewTransition.updateCallbackDone;

Conclusion §

Avec tout ça, vous devriez être paré pour animer tout ce qui vous passe sous la main 😁

Cela dit, cette API reste particulièrement adaptée quand vous voulez passer un élément d’un point A à un point B. C’est pour ça qu’on parle de transition. Elle permet notamment de gérer des cas complexes où le DOM change complètement.

Mais si vous avez une solution simple en CSS que vous arrivez à gérer avec des @keyframes classiques, des propriétés transition, qui restent performantes, let’s go ! N’oubliez pas tout ce que vous avez déjà pu utiliser par le passé.

Si par contre, vous vous demandez jusqu’où on peut pousser cet API et vous avez envie de faire des tests et des expériences, simples ou compliquées, j’aimerais beaucoup en entendre parler.

La suite pour cette API est son activation dans un contexte de MPA (la page se recharge complètement). C’est aujourd’hui encore sous feature flag dans Chrome et j’ai personnellement été confronté à quelques éléments bloquants. Mais dès que ça se débloque, je vous en parle 👀

En tout cas, si ce genre de contenus vous plait ou que vous aimez lire des trucs sur le web, la webperf ou le front de manière général, n’hésitez pas à me suivre sur les réseaux sociaux (Mastodon, LinkedIn ou Twitter) et à me dire ce que je devrais améliorer pour la suite.

Prenez soin de vous, et à très vite 🫶