Chrome 105 introduit deux nouvelles méthodes sur le NavigateEvent de l'API Navigation (introduite dans la version 102) pour améliorer les méthodes qui se sont révélées problématiques en pratique. intercept(), qui permet aux développeurs de contrôler l'état après la navigation, remplace transitionWhile(), qui s'est avéré difficile à utiliser. La méthode scroll(), qui fait défiler la page jusqu'à un ancrage spécifié dans l'URL, remplace restoreScroll(), qui ne fonctionne pas pour tous les types de navigation.
Dans cet article, je vais expliquer les problèmes liés à ces deux méthodes et comment les nouvelles méthodes les résolvent.
NavigateEvent.transitionWhile()
La méthode NavigateEvent.trasitionWhile(), introduite avec l'API Navigation dans Chrome 102, intercepte la navigation pour les transitions côté client dans les applications monopages. Son premier argument est une promesse qui signale au navigateur et aux autres parties de l'application Web qu'elle est terminée.
Cela n'a pas bien fonctionné dans la pratique. Prenons l'exemple suivant:
event.transitionWhile((async () => {
doSyncStuff();
await doAsyncStuff();
})());
Ce code est fonctionnellement équivalent au code ci-dessous. Une partie de la navigation s'exécute avant que l'API ne sache que le développeur a l'intention d'intercepter la navigation.
doSyncStuff();
event.transitionWhile((async () => {
await doAsyncStuff();
})());
Par exemple, cela peut perturber une application dans la logique de restauration du défilement, où elle capture les positions de défilement après la modification du DOM, et non avant.
Modifications apportées
Pour remplacer transitionWhile(), la spécification actuelle introduit NavigateEvent.intercept(). La nouvelle méthode utilise un gestionnaire en plus des propriétés focusReset et scrollRestoration compatibles avec transitionWhile(). Le nouveau gestionnaire s'exécute toujours après les commits de navigation, et des éléments tels que les positions de défilement ont été capturés, ce qui évite les problèmes avec transitionWhile().
La méthode transitionWhile() est toujours disponible, mais elle a été abandonnée et sera supprimée dans Chrome 108.
Utiliser intercept()
NavigateEvent.intercept() présente les mêmes restrictions que transitionWhile(), car il ne peut pas être appelé sur tous les événements de navigation. Les navigations inter-origines ne peuvent pas être interceptées, pas plus que les traversées inter-documents. Cette opération génère une DOMException de type "SecurityError".
Pour utiliser intercept(), il vous suffit de transmettre votre gestionnaire personnalisé lorsque vous l'appelez.
navigation.addEventListener("navigate", event => {
event.intercept({
async handler() {
doSyncStuff();
await doAsyncStuff();
}
});
});
NavigateEvent.scroll()
Une navigation, par exemple du haut de la page vers un ancrage (passez de /a à /a#id), est entièrement gérée par le navigateur, même dans une application monopage. Toutefois, l'accès à un ancrage sur une autre "page" (/a à /b#id), qui est simple pour les applications multipages, est plus compliqué pour les applications monopages. L'application doit intercepter la navigation vers /b#id à l'aide de NavigateEvent.transitionWhile(), puis appeler NavigateEvent.restoreScroll() pour afficher l'ancre. Comme indiqué ci-dessus, cela est actuellement difficile à faire.
Modifications apportées
Dans les applications monopages, vous pouvez désormais contrôler si le navigateur gère le défilement vers une ancre ou si c'est votre code qui s'en charge.
Utiliser scroll()
Par défaut, le navigateur tente de gérer le défilement automatiquement une fois le gestionnaire d'interception rempli. Si vous souhaitez gérer le défilement vous-même, définissez scroll sur "manual", puis appelez NavigateEvent.scroll() lorsque le navigateur doit essayer de définir la position de défilement.
navigation.addEventListener("manual", event => {
scroll: "manual",
event.intercept({
async handler() {
doSyncStuff();
// Handle scrolling earlier than by default:
event.scroll();
await doAsyncStuff();
}
});
});
La méthode restoreScroll() est toujours disponible, mais elle a été abandonnée et sera supprimée dans Chrome 108.
Conclusion
Nous espérons pouvoir mettre à jour prochainement notre article sur l'API Navigation. En attendant, la spécification de cette API contient de nombreuses informations destinées spécifiquement aux développeurs Web.