Aggiornamenti all'API Service Worker Cache

Jake Archibald
Jake Archibald

Mi è stato chiesto di scrivere questo post su un aggiornamento piuttosto ridotto all'API Service worker Cache. Non pensavo che giustificasse un articolo a parte, ma dopo un lungo dibattito che alla fine è arrivato a un gioco di sasso-forbici, ho perso, eccolo qui.

Vuoi ricevere informazioni sugli aggiornamenti all'implementazione di Chrome dell'API Service worker Cache?

Non ti sento! Ho detto, vuoi sapere cosa sono gli aggiornamenti all'implementazione dell'API Service worker Cache in Chrome?

Puoi continuare a leggere solo se sei salito sulla sedia e gridato "YEAHHH!". Fingere allo stesso tempo di dondolare un lazo è facoltativo, ma incoraggiato).

cache.addAll è arrivato con Chrome 46

Sì. Esatto. Cache! Aggiungi tutto! Chrome 46!

Ok, a parte il sarcasmo, questo è davvero un problema, dato che cache.addAll è l'ultima parte rimanente del polyfill "essenziali" della cache, il che significa che non è più necessario.

Ecco come funziona cache.addAll:

// when the browser sees this SW for the first time
self.addEventListener('install', function(event) {
    // wait until the following promise resolves
    event.waitUntil(
    // open/create a cache named 'mysite-static-v1'
    caches.open('mysite-static-v1').then(function(cache) {
        // fetch and add this stuff to it
        return cache.addAll([
        '/',
        '/css/styles.css',
        '/js/script.js',
        '/imgs/cat-falls-over.gif'
        ]);
    })
    );
});

addAll richiede un array di URL e li recupera e le aggiunge alla cache. Si tratta di una transazione: se il recupero o la scrittura non va a buon fine, l'intera operazione non va a buon fine e la cache viene riportata allo stato precedente. Ciò è particolarmente utile per le operazioni di installazione come indicato in precedenza, dove un singolo errore dovrebbe essere un errore complessivo.

L'esempio precedente si trova all'interno di un service worker, ma l'API cache è completamente accessibile anche dalle pagine.

Firefox già supporta questa API nella sua versione per sviluppatori, quindi verrà applicata al resto dell'implementazione del service worker.

Ma non è tutto, ci sono altri miglioramenti della cache nella pipeline...

cache.matchAll in arrivo su Chrome 47

In questo modo puoi ottenere più corrispondenze:

caches.open('mysite-static-v1').then(function(cache) {
    return cache.matchAll('/');
}).then(function(responses) {
    // …
});

Quanto sopra restituisce tutti i valori in mysite-static-v1 che corrispondono a /. La cache ti consente di avere più voci per URL se possono essere memorizzate nella cache in modo indipendente, ad esempio se hanno intestazioni Vary diverse.

Firefox già supporta questa funzionalità nella sua versione per sviluppatori, quindi verrà applicata al resto dell'implementazione del service worker.

Opzioni di query nella cache in arrivo su Chrome... a breve

Ecco un gestore di recupero abbastanza standard:

self.addEventListener('fetch', function(event) {
    event.respondWith(
    caches.match(event.request).then(function(response) {
        return response || fetch(event.request);
    })
    );
});

Se / è nella cache e riceviamo una richiesta per /, l'elemento verrà gestito dalla cache. Tuttavia, se riceviamo una richiesta per /?utm_source=blahblahwhatever che non proviene dalla cache. Puoi ovviare a questo problema ignorando la stringa di ricerca dell'URL durante la corrispondenza:

self.addEventListener('fetch', function(event) {
    event.respondWith(
    caches.match(event.request, {
        ignoreSearch: true
    }).then(function(response) {
        return response || fetch(event.request);
    })
    );
});

Ora /?utm_source=blahblahwhatever verrà abbinato alla voce per /! Le opzioni complete sono:

  • ignoreSearch: ignora la parte di ricerca dell'URL sia nell'argomento della richiesta sia nelle richieste memorizzate nella cache
  • ignoreMethod: ignora il metodo dell'argomento della richiesta, in modo che una richiesta POST possa corrispondere a una voce GET nella cache
  • ignoreVary: ignora l'intestazione variabile nelle risposte memorizzate nella cache

Firefox già supporta questa funzionalità nei suoi contenuti... ok lo sai già come funziona. Di' a Ben Kelly quanto è bravo a portare tutto su Firefox.

Se vuoi seguire l'implementazione di Chrome delle opzioni di query nella cache, consulta la pagina crbug.com/426309.

Ci vediamo la prossima volta per un altro entusiasmante capitolo di "cosa abbiamo implementato nell'API cache".