Algo está errado com o Service Worker e você apenas deseja que seu site funcione. Então, enquanto você depura o problema, como você remove o service worker dos clientes existentes?
O ciclo de vida do service worker é um conceito que geralmente confunde os desenvolvedores. Freqüentemente, cobrimos o registro e atualização de service workers, mas negligenciamos como remover um trabalhador registrado de um site.
Não saber como cancelar o registro de um service worker de um cliente pode deixar seu site em um estado suspenso de falha.
E ninguém quer que seu aplicativo ofereça uma experiência ruim ao usuário… especialmente devido a um bug.
A menos que você possa isolar e corrigir o problema rapidamente, pode ser necessário comprar alguns hora de resolver o erro.
Remover o service worker com bugs pode ser sua melhor solução temporária. Isso deve pelo menos eliminar a causa do problema, permitindo que o site apenas funcione.
Se você criar um service worker com bugs, você deseja que ele esteja em sua máquina de desenvolvimento local, usando um servidor da web localhost. A menos que você seja um desenvolvedor perfeito, encontrará momentos em que o service worker está gravemente danificado e pode não atualizar da maneira que deseja. Felizmente, ao trabalhar localmente, você pode controlar o registro do service worker através das ferramentas do desenvolvedor.
Atualizar ao recarregar
A primeira opção é marcar a opção’atualizar ao recarregar’. Quando esta opção é selecionada, o navegador sempre carrega o arquivo do service worker da origem (servidor da web) como se o arquivo fosse alterado. Isso pode ser feito na guia Aplicativo de ferramentas. Selecione o nó Service Workers nas ferramentas de desenvolvedor do Chrome e Opera e você verá o service worker para seu site.
Selecionar esta opção deve evitar que você se sujeite ao seu serviço trabalhador não atualizará. Antes de confirmar seu código ou implantar em um servidor, você deve desmarcar esta opção e testar seu aplicativo. Ao forçar uma recarga toda vez que você pode mascarar um problema potencial que precisa ser corrigido.
Desinstalando um Service Worker manualmente
A próxima opção é cancelar manualmente o registro do Service Worker. Isso também está disponível nas ferramentas do desenvolvedor. No lado direito dos detalhes do prestador de serviço, você verá uma linha de links que acionam manualmente as ações do prestador de serviço. O último link é o link Cancelar registro.
O FireFox não tem, no momento, a opção de atualizar quando a página for recarregada.
Selecionar este link cancelará o registro do service worker. Atualizar a página iniciará o ciclo de vida do service worker do zero.
Cuidado, cancelar o registro do service worker não limpa o cache. Se você precisar limpar o cache, deve selecioná-lo na lista e excluir cada cache.
O FireFox tem a opção de cancelar o registro de um service worker em suas ferramentas de desenvolvedor. Para chegar lá, você precisa abrir a página’about: debugging # workers’. Aqui você verá todos os service workers registrados. Ao lado de cada um está um link de’cancelar registro’.
Além disso, se você tiver uma assinatura de notificação push registrada com o service worker, essa assinatura será revogada. Na próxima vez que o service worker verificar a assinatura, ele solicitará que você se inscreva.
Essas são ótimas ferramentas para os desenvolvedores gerenciarem seus processos de desenvolvimento. Mas não vai ajudar o consumidor médio.
Removendo programaticamente um service worker
Em vez de registrar um service worker, você pode substituir esse código por um código para cancelar o registro de um service worker. Lembre-se de registrar um service worker no JavaScript da sua página. Agora, em vez de registrar um service worker, você chamará unregister no objeto de registro do service worker.
(Você ainda desejará detectar o recurso para suporte ao service worker antes de executar o código a seguir.)
navigator.serviceWorker.getRegistrations (). then (function (registrations) {for (let registration of registrations) {registration.unregister ();} });
A função getRegistrations retorna uma promessa que resolve uma lista de registros de service workers.
Loop sobre esses registros e todas as funções de cancelamento de registro do objeto de registro. E pronto, seu problemático service worker não está mais registrado.
A função unregister retorna uma promessa que resolve um booleano. Se o service worker foi encontrado e cancelou o registro, ele retornará true. Se o service worker não for encontrado, retorna falso.
Se o service worker não for encontrado, isso indica que ele já não está registrado.
O service worker pode não morrer imediatamente. Se o trabalhador estiver atualmente executando qualquer tarefa para um cliente, ele será concluído antes de ser removido oficialmente.
Para que isso funcione, o consumidor precisará baixar seu script mais recente. Isso pode ser problemático se você tiver armazenado em cache o script usando o service worker. Por esse motivo, pode ser aconselhável manter o código que gerencia o registro do service worker em um arquivo pequeno e isolado, que não é adicionado ao cache do service worker. Você também pode considerar ter um tempo de Cache-Control curto para viver o valor também.
A opção final, se tudo mais falhar, é esperar. Não é a melhor resposta, mas dentro de 24 horas seu service worker atualizará.
Isso porque os service workers são projetados para ligar para casa a cada 24 horas para ver se há uma versão mais recente disponível.
Eu chamo esse recurso de mãe feliz. Mesmo que você tenha armazenado em cache o service worker usando o service worker ou tenha um cabeçalho muito longo para ativar o cabeçalho para que o arquivo do service worker seja armazenado em cache no cache do navegador, o navegador verificará o servidor 24 horas após a última atualização.
Não se preocupe, os dispositivos dos clientes não entrarão em contato com o servidor a cada 24 horas, todos os dias. A regra é, se um service worker for instanciado, por meio de um carregamento de página, notificação push, etc, e não tiver verificado se há uma atualização nas últimas 24 horas, ele verificará o servidor para uma nova versão.
Portanto, se o seu site for carregado uma vez por semana pelo cliente, ele só executará essa verificação de atualização integrada naquele momento, não todos os dias desde a última visita.
Este recurso foi adicionado à especificação do service worker como uma medida à prova de falhas. Isso significa que o pior cenário é que seu service worker está quebrado por não mais de 24 horas.
Uma rotina de remoção de self-cleaning service worker
Arthor Stolyar recentemente apontou o processo de remoção padrão não é imediato . O código mais ou menos enfileira a remoção do service worker.
Assim como registrar um service worker não assume imediatamente o controle da página de registro, a remoção deve esperar que os clientes sejam atualizados antes de cancelar o registro.
Arthur indica aos leitores um GitHub Gist onde um service worker remove a si mesmo usando o evento activate.
self.addEventListener ("activate", function (e) {self.registration.unregister ().then (function () {return self.clients.matchAll ();}).then (function (clients) {clients.forEach (client=> client.navigate (client.url));});});
A parte principal deste código é o loop por todos os clientes ativos. Conforme o código faz um loop em cada cliente, ele força o navegador a recarregar a página, o que em teoria deveria remover o service worker.
Gosto da abordagem, mas acho que pode ser um pouco falha.
Primeiro, ele assume que todos os clientes são guias do navegador.
Os clientes do Service Worker podem ser guias do navegador e na maioria dos casos serão. No entanto, um cliente do service worker é qualquer tarefa que acione um evento do service worker, como push ou sincronização.
Essas não são guias do navegador. Na verdade, há outros novos recursos sendo discutidos que também operariam de forma completamente separada do processo do navegador.
Em vez disso, quero oferecer algumas modificações ao código anterior:
self.addEventListener ("activate", function (e) {self.registration.unregister ().then (function () {return self.clients.matchAll ();} ).então (função (clientes) {clientes.paraEach (cliente=> {if (cliente.url &&"navegar"no cliente) {cliente.navegar (cliente.url))}});});
Conforme você faz um loop em cada cliente, ele verifica se pode ser recarregado antes de tentar uma navegação, o que pode lançar uma exceção.
O próximo problema que vejo com o código oferecido está executando isso no contexto de um novo service worker, que deve ser registrado primeiro. Acho que isso anula o propósito de remover um prestador de serviço.
Para remover um prestador de serviço inválido, e com isso quero dizer, remover qualquer registro de prestador de serviço, isso deve ser tratado no cliente.
Vamos voltar ao código de registro do cliente e aplicar o mesmo princípio:
navigator.serviceWorker.getRegistrations (). then (function (registros) {for (deixar o registro dos registros) {registration.unregister ().then (function () {return self.clients.matchAll ();}).then (function (clients) {clients.forEach ( cliente=> {if (client.url &&"navegar"no cliente) {client.navigate (client.url));}});}});
Agora, em vez de registrar um novo prestador de serviço, você está apenas removendo o prestador de serviço registrado e não substituindo-o por outro.
Se sua meta é substituir um service worker, então, você pode usar o evento activate para acionar uma atualização para os diferentes clientes.
Portanto, a noção de um service worker que se autodestrói pode não ser o melhor conceito para remover um service worker. Acho que o Gist foi criado mais como um exemplo de algo que poderia ser feito.
Ele demonstra alguns aspectos importantes da atualização e remoção de um service worker. Provavelmente, você precisará atualizar qualquer cliente ativo que esteja sendo controlado pelo service worker.
Isso tudo faz parte de um conceito maior de gerenciamento do ciclo de vida do service worker. Eu acho que este é um tópico muito complexo que muitas vezes é esquecido e mal compreendido. É por isso que passo uma quantidade significativa de tempo no ciclo de vida em meu curso Progressive Web Apps From Beginner to Expert .
Também gostaria de destacar o quão perturbador esse processo pode ser. Antes de recarregar automaticamente as guias do navegador, você deve notificar o usuário primeiro.
Observação: ainda não testei este código. Eu li a postagem do blog de Arthur e queria atualizar este artigo como uma resposta rápida. Como posso no dia seguinte ou depois, testarei minha proposta e atualizarei conforme necessário.
Resumo
Espero que você não precise remover um prestador de serviço, mas bugs acontecem e pode ser seu único recurso. O código e as técnicas acima devem ajudá-lo a sair do atolamento.
Para o desenvolvimento, você provavelmente deseja usar o método da ferramenta de desenvolvedor para cancelar o registro do service worker. Mas se você enviar um bug catastrófico, terá opções para ajudar seus clientes. Sempre teste seu novo prestador de serviço em um local de teste ativo antes de enviar para a produção. Certifique-se de testar em dispositivos reais também, para saber como deve ser a experiência do consumidor e verificar suas alterações ou, neste caso, o trabalhador de serviço é removido.
Você quer um conjunto muito mais detalhado de tutoriais progressivos de aplicativos da web e service workers? Acabei de lançar um novo curso, Progressive Web Apps: From Beginner to Expert .
Este curso cobre tudo que você precisa saber para tornar qualquer site um aplicativo da web progressivo. Existem tópicos para iniciantes para ajudar qualquer pessoa a começar com o desenvolvimento progressivo de aplicativos da web e service workers. Também há módulos para ensinar a você como polyfil muitos recursos PWA modernos, como offline e adicionar táticas de tela inicial.
Inscreva-se hoje e economize $ 171 no preço de $ 200. Progressive Web Apps: From Beginner to Expert is only $ 29 por um tempo limitado .
