Risoluzione dei problemi e logging

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:

Firefox

Gli utenti di Firefox possono fare riferimento alle seguenti risorse:

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.

Uno screenshot dei messaggi di logging di Workbox nella console dei DevTools di Chrome. I messaggi di logging vengono distinti dai normali log della console con un badge di Workbox. Ogni messaggio può essere espanso per ottenere ulteriori informazioni di debug.

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 di mode 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 sostituire process.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.