Les développeurs qui utilisent des service workers et l'API Cache Storage doivent être à l'affût de deux types de petites modifications déployées dans Chrome 71. Ces deux modifications permettent une mise en œuvre plus cohérente spécifications et à d'autres navigateurs.
Interdire la méthode importScripts() asynchrone
importScripts()
demande au script de votre service worker principal de suspendre son exécution actuelle, de télécharger du code supplémentaire depuis
une URL donnée et l'exécuter jusqu'au bout dans le champ d'application global actuel. Une fois que c'est fait,
le script du service worker principal reprend l'exécution. importScripts() est utile lorsque
Vous souhaitez décomposer le script de votre service worker principal en plusieurs parties pour des raisons organisationnelles, ou
pour ajouter des fonctionnalités à votre service worker.
Les navigateurs tentent d'atténuer les éventuels problèmes de performances liés au "téléchargement et à l'exécution d'instructions
de code" en mettant automatiquement en cache tout ce qui est récupéré via importScripts(), ce qui signifie qu'après l'événement
téléchargement initial, l'exécution du code importé
implique très peu de frais généraux.
Pour que cela fonctionne, le navigateur doit savoir qu'il n'y aura pas de "surprise" code importé
dans le service worker après l'appel initial
l'installation.
Conformément à la spécification des service workers,
L'appel de importScripts() est censé ne fonctionner que lors de l'exécution synchrone des appels de
script service worker ou, si nécessaire, de manière asynchrone dans le gestionnaire install.
Avant Chrome 71, appeler importScripts() de manière asynchrone en dehors du gestionnaire install entraînait
travail. À partir de Chrome 71, ces appels
générer une exception d'exécution (sauf si la même URL a déjà été importée dans un gestionnaire install) ;
correspondant au comportement des autres navigateurs.
Au lieu d'utiliser un code comme celui-ci:
// This only works in Chrome 70 and below.
self.addEventListener('fetch', event => {
importScripts('my-fetch-logic.js');
event.respondWith(self.customFetchLogic(event));
});
Le code de votre service worker doit se présenter comme suit:
// Move the importScripts() to the top-level scope.
// (Alternatively, import the same URL in the install handler.)
importScripts('my-fetch-logic.js');
self.addEventListener('fetch', event => {
event.respondWith(self.customFetchLogic(event));
});
Abandon des URL répétées transmises à cache.addAll()
Si vous utilisez l'API Cache Storage en même temps qu'un service worker, une autre légère modification est à noter
Chrome 71 pour qu'il soit conforme à la spécification correspondante. Lorsque la même URL est
transmis à plusieurs reprises à un même appel
cache.addAll(), le
indique que la promesse renvoyée par l'appel doit rejeter.
Dans les versions antérieures à Chrome 71, cette URL n'était pas détectée et les URL en double étaient ignorées.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">Cette journalisation est un prélude à Chrome 72, où au lieu d'un simple avertissement, les URL en double
entraîner le refus de cache.addAll(). Si vous appelez cache.addAll() dans le cadre d'une chaîne de promesses
transmis à
InstallEvent.waitUntil(),
comme il est courant, ce refus peut entraîner l'échec de l'installation de votre service worker.
Voici comment vous pourriez rencontrer des problèmes:
const urlsToCache = [
'/index.html',
'/main.css',
'/app.js',
'/index.html', // Oops! This is listed twice and should be removed.
];
self.addEventListener('install', event => {
event.waitUntil(
caches.open('my-cache').then(cache => cache.addAll(urlsToCache))
);
});
Cette restriction ne s'applique qu'aux URL transmises à cache.addAll() et à la mise en cache
deviennent deux réponses équivalentes qui ont des URL différentes, comme '/' et '/index.html',
ne déclenche pas de rejet.
Tester largement l'implémentation de vos service workers
Les service workers sont largement implémentés parmi tous les principaux "intemporels" navigateurs à l'adresse à ce stade. Si vous testez régulièrement votre progressive web app sur plusieurs navigateurs ou si vous qu'un grand nombre d'utilisateurs n'utilisent pas Chrome, vous avez probablement déjà l'incohérence et a mis à jour votre code. Mais si vous ne l'avez pas remarqué, dans d'autres navigateurs, nous voulions attirer l'attention sur ce changement avant de modifier le comportement de Chrome.