Eseguire il debug di un service worker è complesso. Hai a che fare con il ciclo di vita, gli aggiornamenti, le cache e l'interazione tra tutti questi aspetti. Fortunatamente, proprio come Workbox semplifica lo sviluppo dei service worker, rende anche più semplice il debug attraverso la sua registrazione informativa. In questa pagina parleremo di alcuni degli strumenti di debug disponibili, di come funziona il logging di Workbox e di come può essere configurato.
Strumenti per la risoluzione dei problemi disponibili
Nel browser sono disponibili molti strumenti per eseguire il debug e la risoluzione dei problemi durante lo sviluppo di un service worker. Di seguito sono riportate alcune risorse per iniziare a utilizzare il browser che preferisci.
Chrome ed Edge
Chrome (e le versioni recenti di Edge basate sul motore Blink) dispongono di un solido set di strumenti per sviluppatori. Alcuni di questi strumenti, in particolare in DevTools di Chrome, sono stati toccati in precedenza in questa documentazione, ma c'è ancora molto da scoprire:
- Eseguire il debug delle app web progressive
- Esaminare l'attività di rete in Chrome DevTools
- Video: Debug dei service worker in Chrome
- Codelab: debug dei service worker
Firefox
Gli utenti di Firefox possono fare riferimento alle seguenti risorse:
- Debug dei service worker utilizzando il riquadro dell'applicazione degli strumenti per sviluppatori di Firefox
- Video: Debug dei worker di servizio in Firefox
Safari
Safari attualmente dispone di un insieme più limitato di strumenti per sviluppatori per il debug dei service worker. Puoi scoprire di più in merito con queste risorse:
Logging della casella di lavoro
Un miglioramento chiave dell'esperienza degli sviluppatori offerto da Workbox è la registrazione informativa. Quando il logging è abilitato, Workbox registra quasi tutte le sue attività in modo distintivo e funzionale.
Le build di sviluppo di Workbox attivano il logging per impostazione predefinita, mentre quelle di produzione lo disattivano. Esistono diversi passaggi per passare dalle build di sviluppo a quelle di produzione, a seconda che tu stia creando un bundle Workbox personalizzato o utilizzando una copia pre-bundle tramite workbox-sw
.
Con o senza bundler
I bundle sono strumenti che recuperano il codice dai singoli moduli e creano un output JavaScript pronto per essere eseguito nel browser. Quando usi un bundler, puoi anche usare un plug-in Workbox specifico del bundler che aiuta con la precaching, come workbox-webpack-plugin
, oppure potresti semplicemente raggruppare la logica di memorizzazione nella cache del runtime Workbox. In ogni caso, il logging di Workbox viene influenzato dall'impostazione di una modalità di produzione nella configurazione del bundler:
- Nel webpack, l'opzione di configurazione di
mode
può essere impostata su'production'
o'development'
.workbox-webpack-plugin
utilizzerà il logging di produzione o di sviluppo in Workbox in base a questo valore. - Per l'aggregazione,
rollup-plugin-workbox
accetta un'opzione di configurazione dimode
che influisce anche sull'eventuale registrazione di dati da parte di Workbox nella console. Se utilizzi la funzionalità Rollup senza il plug-in specifico per Workbox, devi configurare@rollup/plugin-replace
in modo da sostituireprocess.env.NODE_ENV
con'development'
o'production'
.
Supponi che il comportamento di logging predefinito debba essere sostituito in fase di sviluppo. In questo caso, il plug-in Workbox appropriato per il tuo bundler dovrebbe consentirti di impostare come hardcoded una preferenza per il debug dei log nella relativa configurazione. Ad esempio, potresti disattivare il logging in Workbox tramite l'opzione mode
di workbox-webpack-plugin
per il metodo GenerateSW
.
Senza un bundler
I bundle sono un'ottima soluzione, ma non tutti i progetti ne hanno bisogno. Se ti trovi in una situazione in cui vuoi aggiungere Workbox a un progetto che non utilizza un bundler, workbox-sw
è la soluzione.
Il modulo workbox-sw
semplifica il caricamento di altri moduli di Workbox (ad es. workbox-routing
, workbox-precaching
e così via) da una CDN. Il caricamento dei bundle di sviluppo o di produzione dipende dall'URL utilizzato per accedere alla tua app web. Per impostazione predefinita, workbox-sw
carica la versione di sviluppo di Workbox se l'app web è in esecuzione su http://localhost
e la versione di produzione in tutti gli altri casi.
Puoi eseguire l'override del comportamento predefinito chiamando il metodo setConfig
di Workbox per impostare l'opzione debug
su true
:
// Load workbox-sw from a CDN
importScripts('https://storage.googleapis.com/workbox-cdn/releases/6.2.0/workbox-sw.js');
// This must come before any other workbox.* methods.
workbox.setConfig({
debug: true
});
// Now use workbox.routing.*, workbox.precaching.*, etc.
Disattiva il logging nelle build di sviluppo in qualsiasi flusso di lavoro
Indipendentemente dal fatto che utilizzi un bundler o meno, puoi disattivare tutte le operazioni di logging nelle build di sviluppo assegnando true
a una variabile self.__WB_DISABLE_DEV_LOGS
speciale nel service worker:
//
self.__WB_DISABLE_DEV_LOGS = true;
// The rest of your Workbox service worker code goes here
Un vantaggio di questo approccio è che è completamente indipendente dalla configurazione del bundler e funzionerà sia che tu utilizzi direttamente workbox-sw
sia che dipenda da un bundler per pacchettizzare il tuo service worker basato su Workbox per te.
Ulteriori informazioni
Se ancora non riesci a capire cosa sta succedendo in un service worker che presenta errori e il logging non è sufficiente, prova a pubblicare una domanda su Stack Overflow con il tag workbox
. Se non riesci a trovare una risposta nell'elenco, invia una segnalazione su GitHub (dopo aver letto le linee guida per i contributi). Questo non solo consente a un vasto pubblico di sviluppatori di leggere e rispondere alle tue domande, ma la risposta alla tua domanda potrebbe essere d'aiuto a chi si trova in futuro nella stessa situazione.