Este codelab mostra como registrar um service worker na sua Web e usar o Chrome DevTools para observar o comportamento dele. Ela também aborda algumas técnicas de depuração que podem ser úteis ao lidar com service workers.
Conhecer o projeto de exemplo
Os arquivos do projeto de exemplo mais relevantes para este codelab são:
register-sw.jscomeça em branco, mas contém o código usado para registrar o service worker. Ele já está sendo carregado por uma tag<script>dentro doindex.htmldo projeto.service-worker.jstambém está vazio. É o arquivo que conterá o service worker deste projeto.
Adicione o código de registro do service worker
Um service worker (mesmo um vazio, como o arquivo service-worker.js atual)
não será usado, a menos que seja
registrado
primeiro. Você pode fazer isso por meio de uma chamada para:
navigator.serviceWorker.register(
'/service-worker.js'
)
no arquivo register-sw.js.
Antes de adicionar esse código, há alguns pontos a serem considerados do Compute Engine.
Primeiro, nem todo navegador
oferece suporte a
service workers. Isso é particularmente verdadeiro para versões mais antigas de navegadores que
não são atualizadas automaticamente. Portanto, é uma prática recomendada chamar
navigator.serviceWorker.register() condicionalmente, depois de verificar se
navigator.serviceWorker tem suporte.
Segundo, quando você registra um service worker, o navegador executa o código
service-worker.js e pode começar a fazer o download de URLs para preenchimento
caches, dependendo do código no seu service worker
install
e
activate
manipuladores de eventos.
Executar códigos adicionais e fazer o download de recursos pode usar
recursos valiosos que o navegador poderia usar para exibir a imagem atual
página da Web. Para evitar essa interferência, é recomendável adiar
registrar um service worker até que o navegador termine de renderizar o
página atual. Uma maneira conveniente de aproximar isso é esperar até que o
evento window.load seja acionado.
Juntando esses dois pontos, adicione este service worker de uso geral
ao arquivo register-sw.js:
if ('serviceWorker' in navigator) {
window.addEventListener('load', () => {
navigator.serviceWorker.register('/service-worker.js');
});
}
Adicionar um código de geração de registros do service worker
O arquivo service-worker.js é onde toda a lógica do seu service worker
implementação normalmente seguiria. Usaria uma combinação do service worker
eventos do ciclo de vida,
as
API Cache Storage,
e conhecimento sobre o tráfego de rede do seu app da Web para criar
service worker, pronto para lidar com todas as solicitações do seu app da Web.
Mas isso é tudo para aprender depois. Nesse ponto, o foco é observar vários eventos de service workers e aprender a usar o DevTools para depurar o estado do seu service worker.
Para isso, adicione o código abaixo a service-worker.js, que vai registrar
mensagens ao console do DevTools em resposta a vários eventos (mas não fazem muito
caso contrário):
self.addEventListener('install', (event) => {
console.log('Inside the install handler:', event);
});
self.addEventListener('activate', (event) => {
console.log('Inside the activate handler:', event);
});
self.addEventListener(fetch, (event) => {
console.log('Inside the fetch handler:', event);
});
Conheça o painel "Service Workers" no DevTools
Agora que você adicionou o código a register-sw.js e service-worker.js
é hora de visitar a versão ativa do seu projeto de amostra e observar
o service worker em ação.
- Para visualizar o site, pressione Ver app. Em seguida, pressione
Tela cheia
- Pressione "Control+Shift+J" (ou "Command+Option+J" no Mac) para abrir o DevTools.
- Clique na guia Console.
Você vai encontrar algo parecido com as seguintes mensagens de registro: mostrando que o service worker foi instalado e ativado:
Em seguida, acesse a guia Aplicativos e selecione o painel Service Workers. Será exibido um resultado parecido com este:
Isso permite que você saiba que há um service worker com um URL de origem de
service-worker.js, para o app da Web solar-donkey.glitch.me, que está atualmente
ativado e em execução. Ele também informa que, no momento, há um cliente (aberto
) que está sendo controlada pelo service worker.
É possível usar os links nesse painel, como Unregister ou stop, para fazer
alterações no service worker registrado no momento para fins de depuração.
Acione o fluxo de atualização do service worker
Um dos principais conceitos a serem entendidos ao desenvolver com service workers é a ideia de um fluxo de atualização.
Depois que os usuários visitarem um app da Web que registra um worker de serviço, eles vão receber
o código da cópia atual de service-worker.js instalada no
navegador local. Mas o que acontece quando você atualiza a versão
service-worker.js armazenado no seu servidor da Web?
Quando um visitante recorrente retorna a um URL que está no escopo de um service worker,
o navegador solicita automaticamente os últimos service-worker.js e
verifique se há alterações. Se algo no script do service worker for diferente,
o novo service worker vai ter a chance de instalar, ativar
e, eventualmente, assumir o controle.
Para simular esse fluxo de atualização, volte ao editor de código do projeto e faça qualquer alteração no código. Uma mudança rápida é para substituir
self.addEventListener('install', (event) => {
console.log('Inside the install handler:', event);
});
com
self.addEventListener('install', (event) => {
console.log('Inside the UPDATED install handler:', event);
});
Depois de fazer essa mudança, volte para a versão ativa do app de exemplo e atualize a página com a guia DevTools Application ainda aberta. Aparecerá algo como:
Isso mostra que há duas versões do seu service worker instaladas neste
ponto A versão anterior, que já foi ativada, está em execução e no
o controle da página atual. A versão atualizada do service worker está listada
logo abaixo. Está no
estado waiting,
e continuará esperando até que todas as guias abertas controladas pelo
os service workers antigos são fechados.
Esse comportamento padrão garante que, se o novo
o service worker tem uma diferença fundamental de comportamento em relação ao antigo, como
Gerenciador fetch que responde com recursos incompatíveis com versões mais antigas
do seu app da Web. Ela não terá efeito até que o usuário encerre todas as
instâncias anteriores do seu app da Web.
Resumindo
Agora você deve estar confortável com o processo de registro de um service worker e observar o comportamento de um service worker usando o DevTools do Chrome.
Agora você está em uma boa posição para começar a implementar estratégias de armazenamento em cache e todas o que ajudará seu app da Web a carregar de maneira confiável rápido.