No início desta semana, lancei o aplicativo da Web progressivo do Philly Code Camp . Expliquei como o aplicativo funciona em um alto nível, mas hoje quero revisar como o service worker é estruturado.
Para ser um aplicativo da web progressivo (PWA), um site deve ser seguro, ter um arquivo de manifesto da web válido e, o mais importante, registrar um service worker . Usar HTTPS e ter um arquivo de manifesto da web válido são recursos bastante simples que podem ser adicionados em uma hora, na maioria dos casos.
Mas um funcionário de serviço bom , é uma coisa totalmente diferente.
Recentemente, tenho lançado um quadro de novos aplicativos da web progressivos e simples, apenas para mostrar como é simples fazer um PWA. Mas nenhum desses aplicativos, até agora, realmente usou um serviceWorker em todos os seus recursos.
O service worker do Philly Code Camp começa a mostrar como você pode usar um service worker para construir uma rica experiência de usuário front-end com nada além de tecnologias da Web.
Confira o artigo irmão sobre como a experiência de Adicionar à tela inicial/instalar PWA funciona
const version="1.01", preCache="PRECACHE-"+ version, dynamicCache="DYNAMIC-"+ versão, cacheList=["/","img/phillydotnet.png","js/app/app.js","js/app/sessions.js","js/libs/localforage.min.js","js/libs/mustache.min.js","js/libs/utils.js","css/libs/bootstrap.min.css","css/libs/fontawesome-all.css","css/app/site.css","css/webfonts/fa-solid-900.woff2","api/philly-cc-schedule.json","html/app-shell.html","templates/session-list-item. html","templates/session.html"];
As próximas duas declarações de variáveis são os nomes de nossos caches, um pré-cache e um cache dinâmico. Ambos têm seu nome principal, mas também acrescento o valor da versão. Isso torna o gerenciamento de caches muito mais simples, como você verá quando revisar o evento activate.
A última constante é uma matriz de URLs que devem ser pré-armazenados em cache quando o service worker é registrado pela primeira vez. Para o site Philly Code Camp, são todas as dependências de ativos, como JavaScript, CSS e imagens.
Eu armazenei em cache a página inicial e três arquivos HTML de modelo. Explicarei esses arquivos mais adiante neste artigo.
Eventos de ciclo de vida do Service Worker
A próxima seção é o que chamo de eventos de ciclo de vida, instalar e ativar.
O evento de instalação é acionado quando um service worker é registrado pela primeira vez. O ciclo de vida do service worker é um tópico muito complexo e abrangente para este artigo. Tenho cerca de duas horas de conteúdo neste tópico em meu curso progressivo de aplicativo da web.
self.addEventListener ("install", evento=> {self.skipWaiting (); caches.open (preCache).then (function (cache) {cache.addAll (cacheList);}); });
Normalmente há duas coisas que você faz em um manipulador de eventos de instalação do service worker: chame skipWaiting se quiser que o service worker se torne imediatamente ativo e pré-armazene em cache os ativos do aplicativo.
Eu faço ambos neste manipulador de parcelas. Você deve ter cuidado ao usar skipWaiting porque você pode interromper a experiência do seu aplicativo da web progressivo se a atualização do service worker for drasticamente diferente da versão anterior.
Para pré-armazenar em cache os ativos e disponibilizá-los imediatamente, você simplesmente precisa abrir uma referência ao seu cache de pré-cache e, em seguida, passe o array definido na seção constante para o método at all. Este método cuidará de buscar esses ativos e colocá-los no pré-cache.
A segunda fase do registro de um service worker é quando ele realmente se torna ativo. Um novo service worker não se torna imediatamente ativo porque pode interromper a experiência do usuário.
Portanto, o evento activate será acionado quando o service worker se tornar vitalício.
self.addEventListener ("activate", event=> {event.waitUntil (caches.keys (). then (cacheNames=> {cacheNames.forEach (value=> {if (value.indexOf (version) <0) {caches.delete (value);}}); console.log ("service worker ativado"); return;}));});
Novamente, há muitas coisas que você pode fazer neste evento, mas a tarefa mais comum é limpar caches antigos. É aqui que o valor da versão entra em jogo.
No service worker, eu faço um loop por todos os caches nomeados e verifico se eles contêm o número da versão atual. Do contrário, excluo os caches anteriores.
Esta é uma maneira de garantir que você não tenha respostas antigas e obsoletas em cache. Isso também significa que você não fica sem espaço para armazenar ativos em cache para seu aplicativo.
A invalidação de cache é um tópico muito complexo. Eu escrevi um artigo para o planeta de Perth em dezembro passado repassando alguns conceitos aqui. Recomendo que você leia se quiser saber mais sobre o tópico.
O manipulador de eventos Fetch
O manipulador de eventos fetch do service worker dispara sempre que houver uma solicitação de rede endereçável recursos ou um arquivo do servidor.
O evento recebe um objeto de evento que possui uma propriedade de solicitação. Você pode usar este objeto de solicitação para ver se há uma resposta em cache disponível.
self.addEventListener ("fetch", event=> {event.respondWith (caches.match (event.request).then (function (response) {if (response) {return response;} return fetch (event.request).then (response=> {if (response.ok ) {//Não tenho ideia de por que as solicitações de extensões do Chrome são passadas pelo SW//mas não gosto das mensagens de erro no console;) if (event.request.url.indexOf ("chrome-extension")===-1) {let copy=response.clone ();//se não estava no cache, deve ser adicionado ao cache dinâmico caches.open (dynamicCache).then (cache=> {cache.put ( event.request, copy);});} retornar resposta;}}). catch (err=> {if (err.message==="Falha ao buscar") {if (event.request.url.indexOf ("sessão")>-1) {return renderSession (event);}}});})); });
Para fazer isso chame o método de correspondência do objeto caches, passando o objeto request. Este método irá percorrer todos os caches nomeados e ver se há uma resposta em cache para esta solicitação específica.
Se houver uma resposta, ela retornará.
Você deve verificar para veja se o objeto de resposta existe e, em caso afirmativo, devolva-o ao cliente.
Para o aplicativo da web progressivo Philly Code Camp, escolhi usar um cache primeiro e, em seguida, o padrão de resposta de fallback da rede. Isso significa que estou examinando o cache primeiro e, se não houver nada no cache, faço uma solicitação ao servidor. Se estiver off-line, verificarei se posso renderizar localmente ou não.
Se não houver resposta, uma nova solicitação de busca é feita. O objeto de solicitação é passado para o método fetch e a solicitação de rede é iniciada.
Quando isso retorna, você deve ter um objeto de resposta. Se a solicitação foi boa, o que significa que tem um status de 200, que também é representado pela propriedade response.okay, você pode processá-la.
A primeira coisa que quero fazer é ter certeza de que armazenei essa resposta em cache para que eu não precise acessar a rede na próxima vez. Para fazer isso, você precisa clonar o objeto de resposta. Você não pode usar um objeto de resposta mais de uma vez.
Então, coloco em cache o objeto de resposta clonado no cache dinâmico. Para fazer isso, você abre uma referência ao cache dinâmico e, em seguida, passa o objeto de solicitação e a cópia de resposta para o método put.
Agora, há uma resposta em cache para essa solicitação.
Como observação lateral, aprendi a adicionar uma verificação para ver se a solicitação faz parte de uma solicitação de extensão do Chrome. Se for, não armazeno em cache a resposta. Não sei por que o Chrome tenta fazer isso, porque as extensões devem ser executadas em um processo separado. Mas se você não fizer isso, verá exceções estranhas acontecendo.
Manuseio off-line
O que é realmente legal sobre esse service worker em particular é como eu lido com o modo off-line.
Para a página inicial do aplicativo, nada realmente muda porque tudo é pré-armazenado em cache. Se você notou que um dos ativos que garanti que fosse pré-cache, foi todo o cronograma do acampamento de código.
O cronograma é um objeto Jason que o torna fácil de manipular localmente. Eu demonstrei isso mostrando como faço pesquisa e filtragem facetada. Mas, como toda a programação é local, também posso renderizar dinamicamente páginas de sessões individuais.
Mas para fazer isso, eu também precisava fazer o pré-cache do shell do aplicativo e do modelo de detalhes da sessão.
Se o dispositivo estiver off-line em uma solicitação à rede, uma exceção será lançada. É por isso que há um manipulador de eventos catch no service worker. Mas eu só tenho lógica para processar dinamicamente uma página de detalhes da sessão. Portanto, verifico o URL da solicitação para ver se uma solicitação foi feita para uma sessão. Nesse caso, aciono a lógica para renderizar a sessão dentro do service worker.
Se você assistir ao vídeo sobre como funciona o script de criação do aplicativo, essencialmente extraí essa lógica e coloquei-a no service worker.
function renderSession (event) {let slug=getSlug (event.request.url), appShell="", sessionTemplate=""; return getAppShell ().then (html=> {appShell=html;}).then (()=> {return getSessionTemplate ().then (html=> {sessionTemplate=html;});}). then (()=> {let sessionShell=appShell.replace ("<% template%>", sessionTemplate); return getSessionBySlug (slug).then ((session)=> {let sessionPage=Mustache.render (sessionShell, sessão);//make resposta personalizada let response=new Response (sessionPage, {headers: {'content-type':'text/html'}}), copy=response.clone (); caches.open (dynamicCache).then (cache=> { cache.put (event.request, copy);}); resposta de retorno;});}); };
A função renderSession faz várias coisas: carrega o shell do aplicativo e os modelos de sessão e, em seguida, solicita os detalhes da sessão. Depois de recuperar todos os três arquivos, ele usa o bigode para renderizar o HTML que compõe a página inteira.
Depois que as páginas renderizadas, elas são armazenadas em cache e retornadas ao cliente. Eu uso a mesma lógica como se viesse da rede, clone a resposta e armazene em cache essa versão.
A grande diferença aqui é que eu crio um objeto de resposta personalizado. Esta é uma das coisas legais sobre a API de busca, você pode criar objetos personalizados de solicitação e resposta.
Ao armazenar em cache a resposta renderizada na próxima vez que esta sessão for solicitada, ela virá do cache e não precisará ser acessada a rede ou a renderizada dinamicamente. Mesmo se o dispositivo ficar online novamente, a resposta em cache desse processo estará disponível.
Resumindo
Todo esse rápido explicador do funcionário de serviço do Philly Code Camp foi muito útil e inspirador.
Os prestadores de serviço são um tópico extremamente amplo para cobrir. E embora eu tenha tocado em alguns conceitos intermediários e avançados no service workers, de forma alguma demonstra toda a amplitude dos service workers.
Meu O curso Progressive Web App de iniciante a especialista tem pelo menos 12 horas de treinamento em vídeo sobre o desenvolvimento de service workers. Mais será postado nas próximas semanas.
Lidar com o ciclo de vida do service worker e as estratégias de cache adequadas para seu aplicativo pode ser muito complexo e requer um desenvolvedor muito treinado para executar corretamente.
Você deve ser capaz de usar o service worker do Philly Code Camp como um ponto de partida decente para muitas aplicações. Apenas saiba que a personalidade do seu aplicativo pode ditar um caminho ligeiramente diferente.
Se você deseja aprender como fazer o desenvolvimento de service workers, eu o encorajo a se registrar no meu curso progressivo de aplicativo da web. Você pode se inscrever agora por apenas US $ 29 e economizar cento e 71 no preço de tabela normal.
O Philly Code Camp PWA O código-fonte está no GitHub .
Os service workers são uma grande superpotência que torna a web um ótimo lugar para construir experiências avançadas de front-end. Um prestador de serviço bem executado pode ser a chave para separar seu site da concorrência. Isso também pode tornar sua empresa mais lucrativa e produtiva, pois seus aplicativos são executados de forma mais limpa e rápida.
