Gli sviluppatori che utilizzano i service worker e l'API Cache Storage dovrebbero prestare attenzione a due piccole modifiche che verranno implementate in Chrome 71. Entrambe le modifiche allineano l'implementazione di Chrome alle specifiche e agli altri browser.
Divieto di importazione asincrone importScripts()
importScripts()
indica allo script del service worker principale di mettere in pausa l'esecuzione attuale, scaricare codice aggiuntivo da
un determinato URL ed eseguirlo fino al completamento nell'ambito globale corrente. Al termine,
l'esecuzione dello script del service worker principale riprende. importScripts()
è utile quando vuoi suddividere lo script del service worker principale in parti più piccole per motivi organizzativi oppure quando devi estrarre codice di terze parti per aggiungere funzionalità al service worker.
I browser tentano di mitigare i possibili problemi di prestazioni del "download ed esecuzione di codice sincrono" memorizzando automaticamente nella cache tutto ciò che viene importato tramite importScripts()
, il che significa che dopo il download iniziale, l'esecuzione del codice importato è molto ridotta.
Affinché questo comando funzioni, tuttavia, il browser deve sapere che non ci sarà codice "a sorpresa " importato nel service worker dopo l'installazione iniziale.
In base alla specifica dei service worker, la chiamata a importScripts()
dovrebbe funzionare solo durante l'esecuzione sincrona dello script del service worker di primo livello o, se necessario, in modo asincrono all'interno del gestore install
.
Prima di Chrome 71, funzionava una chiamata a importScripts()
in modo asincrono al di fuori del gestore install
. A partire da Chrome 71, queste chiamate generano un'eccezione di runtime (a meno che lo stesso URL non sia stato precedentemente importato in un gestore install
), che corrisponde al comportamento degli altri browser.
Anziché utilizzare questo codice:
// This only works in Chrome 70 and below.
self.addEventListener('fetch', event => {
importScripts('my-fetch-logic.js');
event.respondWith(self.customFetchLogic(event));
});
Il codice del service worker dovrebbe essere simile al seguente:
// 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));
});
Ritiro degli URL ripetuti passati a cache.addAll()
Se utilizzi l'API Cache Storage insieme a un service worker, è prevista un'altra piccola modifica in
Chrome 71 per allinearsi alle specifiche pertinenti. Quando lo stesso URL viene trasmesso più volte a una singola chiamata a cache.addAll()
, la specifica indica che la promessa restituita dalla chiamata deve essere rifiutata.
Prima di Chrome 71, questo non veniva rilevato e gli URL duplicati venivano effettivamente ignorati.
![Uno screenshot del messaggio di avviso nella console di Chrome](https://developer.chrome.google.cn/static/blog/tweeks-to-addAll-importScripts/image/a-screenshot-the-warning-46bead1fd2604.png?authuser=5&hl=it)
Questo logging è un preludio a Chrome 72, dove, invece di un semplice avviso registrato, gli URL duplicati porteranno a un rifiuto da parte di cache.addAll()
. Se chiami cache.addAll()
nell'ambito di una catena di promesse
passata a
InstallEvent.waitUntil()
,
come prassi comune, questo rifiuto potrebbe causare la mancata installazione del service worker.
Ecco come potresti riscontrare dei problemi:
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))
);
});
Questa limitazione si applica solo agli URL effettivi trasmessi a cache.addAll()
e la memorizzazione nella cache di quelle
che finiscono per essere due risposte equivalenti con URL diversi, come '/'
e '/index.html'
,
non attiverà un rifiuto.
Testare l'implementazione del service worker su larga scala
Al momento i Service worker sono implementati in modo ampio nei principali browser"evergreen". Se testi regolarmente la tua app web progressiva su diversi browser o se hai un elevato numero di utenti che non utilizzano Chrome, è probabile che tu abbia già rilevato l'incoerenza e aggiornato il codice. Ma se non avessi notato questo comportamento in altri browser, volevamo segnalarlo prima di cambiare il comportamento di Chrome.