Depurar um service worker é difícil. Você está lidando com o ciclo de vida, as atualizações, os caches e a interação entre todas essas coisas. Felizmente, assim como o Workbox facilita o desenvolvimento de service workers, ele também facilita a depuração com a geração de registros informativos. Esta página fala sobre algumas das ferramentas de depuração disponíveis, como a geração de registros do Workbox funciona e como ela pode ser configurada.
Ferramentas de solução de problemas disponíveis
Há muitas ferramentas disponíveis no navegador para depuração e solução de problemas durante o desenvolvimento de um service worker. Veja alguns recursos para começar a usar o navegador de sua preferência.
Chrome e Edge
O Chrome e as versões recentes do Edge com base no Blink Engine têm um conjunto robusto de ferramentas para desenvolvedores. Algumas dessas ferramentas, especificamente no DevTools do Chrome, foram abordadas anteriormente nesta documentação, mas há mais para descobrir:
- Depurar Progressive Web Apps
- Inspecionar atividades de rede no Chrome DevTools
- Vídeo: Como depurar service workers no Chrome
- Codelab: Como depurar service workers
Firefox
Os usuários do Firefox podem consultar os seguintes recursos:
- Como depurar service workers usando o painel do aplicativo Firefox Devtools
- Vídeo: Como depurar service workers no Firefox (em inglês)
Safari
Atualmente, o Safari tem um conjunto mais limitado de ferramentas para desenvolvedores para depurar service workers. Saiba mais sobre eles com estes recursos:
- Funcionários à sua disposição
- Vídeo: Como depurar service workers no Safari (em inglês).
Geração de registros da caixa de trabalho
Uma melhoria importante na experiência do desenvolvedor oferecida pelo Workbox é a geração de registros informativa. Quando a geração de registros é ativada, o Workbox registra quase todas as atividades de maneira distinta e funcional.
Os builds de desenvolvimento do Workbox ativam a geração de registros por padrão, enquanto os builds de produção a desativam. Há diferentes etapas para alternar entre os builds de desenvolvimento e de produção, dependendo se você está criando um pacote personalizado do Workbox ou usando uma cópia pré-agrupada via workbox-sw
.
Com ou sem um bundler
Bundlers são ferramentas que pegam código de módulos individuais e criam uma saída JavaScript pronta para ser executada no navegador. Ao usar um bundler, você também pode usar um plug-in Workbox específico do bundler para ajudar no pré-armazenamento em cache, como o workbox-webpack-plugin
, ou talvez você esteja agrupando a lógica de armazenamento em cache do ambiente de execução do Workbox. De qualquer forma, a geração de registros do Workbox é influenciada pela definição de um modo de produção na configuração do bundler:
- No webpack, a opção de configuração
mode
pode ser definida como'production'
ou'development'
.workbox-webpack-plugin
usará a geração de registros de produção ou desenvolvimento no Workbox com base nesse valor. - Para o Rollup, o
rollup-plugin-workbox
aceita uma opção de configuraçãomode
que também afeta se o Workbox faz registros no console. Se você estiver usando o Rollup sem o plug-in específico do Workbox, será necessário configurar o@rollup/plugin-replace
para substituirprocess.env.NODE_ENV
por'development'
ou'production'
.
Suponha que o comportamento padrão de geração de registros precise ser modificado no desenvolvimento. Nesse caso, o plug-in do Workbox apropriado para seu bundler deve permitir que você fixe no código uma preferência para registros de depuração na configuração. Por exemplo, você pode desativar a geração de registros no Workbox com a opção mode
do workbox-webpack-plugin
para o método GenerateSW
.
Sem um bundler
Embora os bundlers sejam bons, nem todos os projetos precisam deles. Se você quiser adicionar o Workbox a um projeto que não usa um bundler, workbox-sw
é a melhor opção.
O módulo workbox-sw
simplifica o carregamento de outros módulos do Workbox (por exemplo, workbox-routing
, workbox-precaching
etc.) de uma CDN. O carregamento dos pacotes de desenvolvimento ou produção depende do URL usado para acessar seu app da Web. Por padrão, o workbox-sw
carrega a versão de desenvolvimento do Workbox se o app da Web estiver sendo executado em http://localhost
e a versão de produção sempre.
É possível substituir o comportamento padrão chamando o método setConfig
do Workbox para definir a opção debug
como 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.
Desativar a geração de registros em builds de desenvolvimento em qualquer fluxo de trabalho
Usando ou não um bundler, você pode desativar toda a geração de registros em builds de desenvolvimento atribuindo true
a uma variável self.__WB_DISABLE_DEV_LOGS
especial no service worker:
//
self.__WB_DISABLE_DEV_LOGS = true;
// The rest of your Workbox service worker code goes here
Uma vantagem dessa abordagem é que ela é totalmente independente da configuração do bundler e funciona independentemente de você usar o workbox-sw
diretamente ou depender de um bundler para empacotar o service worker com tecnologia do Workbox para você.
Mais informações
Se você ainda tiver dificuldade para descobrir o que está acontecendo em um service worker com bugs e a geração de registros não for suficiente, poste uma pergunta no Stack Overflow com a tag workbox
. Se você não encontrar uma resposta, registre um problema no GitHub (depois de ler as diretrizes de contribuição). Com isso, um grande público de desenvolvedores não só pode ler e responder às suas perguntas, mas também pode ajudar alguém na mesma situação mais tarde.