Embora o ciclo de vida do service worker garanta um processo de instalação e atualização previsível, ele pode tornar o ciclo de desenvolvimento local um pouco mais sutil.
No ciclo de desenvolvimento local típico, os desenvolvedores salvam as alterações nos arquivos em um editor de texto e, em seguida, alternam para o navegador para verificar as alterações. O processo é repetido. Quando há um service worker nesse processo, esse ciclo é basicamente o mesmo, mas pode haver diferenças entre o que o desenvolvedor espera e o que o navegador faz.
Exceções para desenvolvimento local
Em geral, as APIs do service worker só estão disponíveis em páginas exibidas por HTTPS,
mas há exceções a essa regra em que elas podem estar disponíveis por HTTP.
Uma exceção notável é para páginas exibidas em localhost, o que funciona bem para desenvolvimento local.
No entanto, é comum que os desenvolvedores especifiquem nomes do host locais além de localhost em um
arquivo de hosts.
Isso é necessário em ambientes de desenvolvimento locais quando vários projetos exigem nomes de host separados.
Nesses casos, basta provisionar um certificado autoassinado.
Uma solução alternativa mais conveniente é instruir o navegador a fazer exceções para o teste do service worker.
No Chrome, acesse chrome://flags/#unsafely-treat-insecure-origin-as-secure e especifique origens não seguras que serão tratadas como seguras.
O Firefox oferece uma maneira de testar service workers em origens não seguras usando a configuração devtools.serviceWorkers.testing.enabled em about:config.
Auxílios para desenvolvimento de service workers
O desenvolvimento local com um service worker pode levar a comportamentos aparentemente inesperados.
Por exemplo, digamos que uma estratégia somente de cache esteja em vigor para recursos estáticos sem versão ou uma página "você está off-line" pré-cache que precisa ser atualizada na recarga depois que você fizer mudanças.
Como uma versão desatualizada desses recursos é sempre veiculada por uma instância Cache,
eles parecem nunca serem atualizados.
Por isso, o service worker está fazendo apenas o que foi criado para fazer,
mas há algumas maneiras de facilitar os testes.
A maneira mais eficaz de testar um service worker é usar janelas de navegação privada, como janelas anônimas no Chrome
ou o recurso de navegação privada do Firefox.
Toda vez que você abre uma janela de navegação anônima, você começa do zero.
Não há service workers ativos nem instâncias de Cache abertas. A rotina para esse tipo de teste é:
- Abra uma janela de navegação anônima.
- Navegue até uma página que registre um service worker.
- Verifique se o service worker se comporta conforme o esperado.
- Feche a janela anônima.
- Esse processo precisa ser repetido.
Com esse processo, você está imitando fielmente o ciclo de vida do service worker.
Outras ferramentas de teste disponíveis no painel Aplicativo do Chrome DevTools podem ajudar, embora possam modificar o ciclo de vida do service worker de algumas maneiras.
O painel do aplicativo tem um subpainel chamado Service Workers, que mostra os service workers ativos para a página atual. Cada service worker ativo pode ser atualizado manualmente ou até ter o registro cancelado. Há também três botões de alternância na parte de cima que ajudam no desenvolvimento.
- Off-line simula condições off-line. Isso ajuda a testar se um service worker ativo está exibindo conteúdo off-line.
- Atualizar na atualização: quando ativado, procura novamente e substitui o service worker atual sempre que a página é recarregada.
- Ignorar para rede, quando ativado, desvia qualquer código no evento
fetchde um service worker e sempre busca conteúdo da rede.
Essas alternâncias são úteis, principalmente Ignorar para rede, que é ótimo quando você está desenvolvendo um projeto com um service worker ativo, mas também quer garantir que a experiência funcione conforme o esperado sem um service worker.
O Firefox tem um painel de aplicativos semelhante nas ferramentas para desenvolvedores, mas a funcionalidade é restrita para mostrar quais service workers estão instalados, bem como a capacidade de cancelar manualmente o registro de quaisquer service workers ativos na página atual. É igualmente útil, mas requer mais esforço manual no ciclo de desenvolvimento local.
Shift e atualizar
Ao desenvolver localmente com um service worker ativo sem a necessidade da funcionalidade fornecida pela atualização na atualização ou pelo ignorar para a rede, também é útil manter a tecla Shift pressionada e pressionar o botão "Atualizar".
Isso é chamado de atualização forçada, que ignora o cache HTTP da rede. Quando um service worker estiver ativo, uma atualização forçada também vai ignorar o service worker.
Essa funcionalidade é ótima se não houver certeza sobre se uma estratégia de armazenamento em cache específica está funcionando conforme o esperado, além de ser útil para extrair tudo da rede para comparar comportamentos com e sem um service worker. Melhor ainda, esse é um comportamento específico, então todos os navegadores compatíveis com service workers o observarão.
Como inspecionar o conteúdo do cache
Será difícil saber se uma estratégia de armazenamento em cache está funcionando conforme o esperado se não for possível inspecionar o cache.
Claro, o cache poderia ser inspecionado no código, mas esse é um processo que envolve depuradores e/ou instruções console quando uma ferramenta visual seria mais adequada para a tarefa.
O painel Application no Chrome DevTools oferece um subpainel para inspecionar o conteúdo de instâncias de Cache.
Esse subpainel facilita o desenvolvimento de service workers oferecendo funcionalidades como:
- Veja os nomes das instâncias de
Cache. - Capacidade de inspecionar o corpo da resposta dos recursos em cache e os cabeçalhos de resposta associados a eles.
- Remova um ou mais itens do cache ou exclua instâncias inteiras de
Cache.
Essa interface gráfica do usuário facilita a inspeção dos caches do service worker para ver se os itens foram adicionados, atualizados ou removidos completamente. O Firefox oferece o próprio visualizador de cache com funcionalidade semelhante, embora fique em um painel Armazenamento separado.
Como simular uma cota de armazenamento
Em sites com muitos recursos estáticos grandes (como imagens de alta resolução), é possível atingir as cotas de armazenamento. Quando isso acontece, o navegador remove itens do cache que considera desatualizados ou que valem a pena sacrificar para abrir espaço para novos recursos.
Lidar com cotas de armazenamento deve fazer parte do desenvolvimento de service workers, e o Workbox simplifica esse processo do que gerenciá-lo por conta própria. No entanto, com ou sem o Workbox, é recomendável simular uma cota de armazenamento personalizada para testar a lógica de gerenciamento de cache.
O painel "Application" no DevTools do Chrome tem um subpainel Storage que oferece informações sobre a quantidade atual de cota de armazenamento usada pela página. Ele também permite que uma cota personalizada seja especificada em megabytes. Quando em vigor, o Chrome aplica a cota de armazenamento personalizada para que ele possa ser testado.
Esse subpainel também contém o botão Limpar dados do site e uma matriz completa de caixas de seleção associadas aos itens que devem ser apagados quando o botão for clicado.
Entre esses itens estão quaisquer instâncias de Cache abertas e a capacidade de cancelar o registro de quaisquer service workers ativos que controlam a página.
Desenvolvimento mais fácil e maior produtividade
Quando os desenvolvedores estão livres, eles podem trabalhar com mais confiança e ser mais produtivos. O desenvolvimento local com um service worker pode ser variado, mas não precisa ser complicado. Com essas dicas e sugestões, o desenvolvimento com um service worker ativo deve ser muito mais transparente e previsível, resultando em uma melhor experiência do desenvolvedor.