App web progressive: utilizzare Workbox

1. Ti diamo il benvenuto

In questo lab, prenderai un sito web con un service worker esistente e lo convertirai in modo che utilizzi Workbox. Questo è il secondo di una serie di codelab complementari per il workshop sulle app web progressive. Il codelab precedente era Going Offline. Questa serie contiene altri sei codelab.

Obiettivi didattici

  • Convertire un service worker esistente per utilizzare Workbox
  • Aggiungere un fallback offline a una PWA

Che cosa devi sapere

  • HTML e JavaScript di base

Che cosa ti serve

2. Configurazione

Inizia clonando o scaricando il codice iniziale necessario per completare questo codelab:

Se cloni il repository, assicurati di trovarti nel ramo pwa03--workbox. Il file zip contiene anche il codice per questo ramo.

Questo codebase richiede Node.js 14 o versioni successive. Una volta disponibile il codice, esegui npm ci dalla riga di comando nella cartella del codice per installare tutte le dipendenze necessarie. Poi, esegui npm start per avviare il server di sviluppo per il codelab.

Il file README.md del codice sorgente fornisce una spiegazione per tutti i file distribuiti. Inoltre, i seguenti sono i file esistenti chiave con cui lavorerai durante questo codelab:

File delle chiavi

  • service-worker.js - File service worker dell'applicazione
  • offline.html - HTML offline da utilizzare quando una pagina non è disponibile

3. Esegui la migrazione a Workbox

Se esaminiamo il service worker esistente, il precaricamento può essere suddiviso in due passaggi:

  • Memorizzare nella cache i file pertinenti durante l'installazione del service worker
  • Pubblica di nuovo questi file con una strategia Solo cache

Il file index.html e la route / hanno ancora senso per la prememorizzazione nella cache, poiché il codice HTML di questa app web non cambierà molto, ma gli altri file, come CSS e JavaScript, potrebbero cambiare e non vogliamo dover eseguire l'intero ciclo di vita del service worker ogni volta che lo fanno. Inoltre, il service worker attuale tiene conto solo di un sottoinsieme di CSS e JavaScript, mentre vogliamo che siano coperti tutti. La memorizzazione nella cache di questi elementi con una strategia Stale While Revalidate ha più senso: una risposta rapida che può essere aggiornata in background in base alle esigenze.

Rivisita del precaricamento

Durante la migrazione a Workbox, non è necessario conservare il codice esistente, quindi elimina tutto ciò che si trova in service-worker.js. Nel lab precedente, abbiamo configurato questo service worker per la compilazione, in modo da poter utilizzare le importazioni ESModule qui per importare Workbox dai relativi moduli NPM. Iniziamo rivedendo il precaricamento. In service-worker.js, aggiungi il seguente codice:

import { warmStrategyCache } from 'workbox-recipes';
import { CacheFirst } from 'workbox-strategies';
import { registerRoute } from 'workbox-routing';
import { CacheableResponsePlugin } from 'workbox-cacheable-response';
import { ExpirationPlugin } from 'workbox-expiration';

// Set up page cache
const pageCache = new CacheFirst({
  cacheName: 'page-cache',
  plugins: [
    new CacheableResponsePlugin({
      statuses: [0, 200],
    }),
    new ExpirationPlugin({
      maxAgeSeconds: 30 * 24 * 60 * 60,
    }),
  ],
});

warmStrategyCache({
  urls: ['/index.html', '/'],
  strategy: pageCache,
});

registerRoute(({ request }) => request.mode === 'navigate', pageCache);

Spiegazione

Per configurare il precaricamento per /index.html e /, sono disponibili cinque moduli da cui estrarre i dati. Anche se può sembrare molto, questo codice è molto più potente di quello scritto in precedenza.

Inizia configurando una nuova strategia di memorizzazione nella cache Cache First, scelta al posto di una strategia Cache Only per consentire l'aggiunta di altre pagine alla cache in base alle esigenze. Viene assegnato un nome, page-cache. Le strategie di Workbox possono utilizzare una serie di plug-in che possono influire sul ciclo di vita del salvataggio e del recupero dei contenuti dalla cache. In questo caso, vengono utilizzati due plug-in, Cacheable Response e Expiration, per garantire che vengano memorizzate nella cache solo le risposte del server valide e che ogni elemento nella cache venga eliminato dopo 30 giorni.

Successivamente, la cache della strategia viene preriscaldata con /index.html e / utilizzando la ricetta di Workbox per il preriscaldamento della cache della strategia. Questi elementi verranno aggiunti a questa cache durante l'evento di installazione del service worker.

Infine, viene registrato un nuovo percorso. Qualsiasi richiesta di navigazione di una pagina verrà gestita da questa strategia Cache First, recuperando i dati dalla cache o dalla rete e memorizzando nella cache la risposta.

Memorizzazione nella cache degli asset

Ora che il pre-caching delle route è stato risolto, è il momento di implementare nuovamente la memorizzazione nella cache per gli asset del sito, ovvero CSS e JavaScript. Per farlo, aggiungi prima StaleWhileRevalidate all'importazione di workbox-strategies, poi aggiungi il seguente codice in fondo al service worker:

// Set up asset cache
registerRoute(
  ({ request }) => ['style', 'script', 'worker'].includes(request.destination),
  new StaleWhileRevalidate({
    cacheName: 'asset-cache',
    plugins: [
      new CacheableResponsePlugin({
        statuses: [0, 200],
      }),
    ],
  }),
);

Spiegazione

Questo percorso inizia determinando se il tipo di richiesta è uno stile, uno script o un worker, corrispondente a CSS, JavaScript o Web Worker. In questo caso, utilizza una strategia Stale While Revalidate, tentando di pubblicare prima dalla cache e ricorrendo alla rete se non è disponibile, mentre tenta di aggiornare la versione nella cache dalla rete, se possibile. Come la strategia di pagina, questa strategia memorizzerà nella cache solo le risposte valide.

4. Aggiungere un elemento di riserva offline

Con la migrazione del service worker originale a Workbox, c'è un'altra cosa da fare per evitare che la PWA si arresti in modo anomalo quando è offline: aggiungere un fallback offline.

I fallback offline possono essere impostati per qualsiasi elemento che potrebbe non essere disponibile offline: pagine, caratteri, CSS, JavaScript, immagini e così via. Come minimo, deve essere impostato un fallback di pagina per tutte le PWA, in modo che se un utente passa a una pagina non presente nella cache, rimanga nel contesto dell'app.

Le ricette di Workbox forniscono una ricetta di riserva offline che può essere utilizzata proprio per questo scopo. Per utilizzarlo, aggiungi prima offlineFallback all'importazione di workbox-recipes, poi aggiungi il seguente codice alla fine del service worker:

// Set up offline fallback
offlineFallback({
  pageFallback: '/offline.html',
});

Spiegazione

La ricetta di riserva offline configura una strategia Solo cache che viene preriscaldata con i fallback forniti. Successivamente, configura un gestore di intercettazione predefinito di Workbox, intercettando eventuali richieste di routing non riuscite (se non è presente nulla nella cache e non è possibile raggiungere qualcosa sulla rete), estraendo i contenuti dei file pertinenti dalla cache e restituendoli come contenuti finché la richiesta continua a non riuscire.

5. Complimenti!

Hai imparato a utilizzare Workbox per configurare le strategie di memorizzazione nella cache per le route e fornire fallback offline per la tua PWA.

Il prossimo codelab della serie è IndexedDB.