Spartan Obstacles Hoje estou muito animado para finalmente anunciar Spartan Obstacles está ao vivo!

Este é um projeto de paixão pessoal para mim e um que está muito atrasado. Comecei a brincar com o conceito da marca há mais de um ano e finalmente sinto que tenho um site de produção pronto o suficiente para anunciar.

A marca Spartan Obstacles é mais do que apenas um site, é uma coleção de conteúdo e canais de mídia que também incluem um canal do YouTube, Facebook, Twitter e Instagram.

Para completar, também lancei um novo livro, O guia do cara normal para corridas de obstáculos . O livro é o produto de ajudar outros espartanos e participantes do OCR com perguntas sobre corridas e como superar obstáculos.

Então, o que isso tem a ver com desenvolvimento web e aplicativos web progressivos?

Em termos de conteúdo, nada realmente, exceto que acredito pessoalmente que os desenvolvedores devem fazer esforços intencionais para estarem em forma e em forma. Spartan Races e corridas de obstáculos são uma ótima maneira de motivar qualquer pessoa a entrar em forma e permanecer em forma.

Um aplicativo da Web progressivo

chrome-require-https-warning-68 O site é um aplicativo da web progressivo, quero dizer, você esperaria menos de mim?

Assim como todos os PWAs, o site é servido via HTTPS. Se o seu site não usa HTTPS , você precisa parar imediatamente de ler este artigo e fazer upgrade agora!

Há também um arquivo de manifesto da web com um conjunto completo de ícones de sites.

O Service Worker

Este é o primeiro site público Eu enviei com um service worker gerado a partir de Workbox . Workbox é uma ferramenta criada pela equipe do Google Chrome para ajudar os desenvolvedores a escrever trabalhadores de serviço complexos com rapidez.

Se você me conhece, normalmente não sou fã de usar o código de outras pessoas. Estruturas grandes como Workbox quase nunca atendem aos meus requisitos e eu gasto mais tempo hackeando uma solução real do que levaria para escrevê-la do zero.

Mas esse não é o caso aqui. Especialmente porque esse JavaScript não é executado no thread de interface do usuário e, portanto, não interfere na experiência do usuário.

Então, por que o Workbox?

Eu escrevi alguns service workers complexos nos últimos dois meses de anos. Quanto mais eu escrevia esses service workers, eu verificava no Workbox e seus predecessores, sw_toolbox e sw_precache.

Achei os predecessores menos do que úteis. Era difícil adaptar essas ferramentas aos requisitos do meu aplicativo. Basicamente, eu escreveria o código de que precisava com mais eficiência do que as ferramentas poderiam gerar. Veja, eu quis dizer o que disse anteriormente.

O Workbox começou assim, mas melhorou no ano passado. Comecei a brincar com ele ao terminar meu próximo livro PWA ( leia mais ). O último capítulo apresenta diferentes ferramentas para ajudar a construir bons aplicativos da web progressivos. Workbox é a última ferramenta que demonstro.

A experiência de scaffolding é útil, mas você ainda precisa ajustar o código gerado para fazer o service worker fazer o que você precisa. O scaffolding é mais para gerar uma lista de URLs para pré-armazenar em cache com um valor de hash correspondente.

Eu gosto bastante da maneira como os funcionários do serviço Workbox lidam com o pré-cache porque é limpo e elegante. Um dos problemas mais comuns com o pré-cache do service worker é manter essas respostas atualizadas.

Eu gosto de armazenar em cache o máximo possível de páginas e ativos de site comuns no pré-cache. Mas esses arquivos serão atualizados de tempos em tempos. Então, como você mantém suas respostas de pré-cache atualizadas?

A maneira mais comum é enviar um novo service worker, para que o evento de instalação seja disparado. Eu ensino novos programadores de service workers a apenas criar um novo cache nomeado e excluir o antigo quando o novo service worker for ativado.

Esta é uma abordagem de terra arrasada e não muito eficiente, especialmente no contexto móvel.

Minha preferência foi pela manutenção de um arquivo de manifesto, especificando quais arquivos armazenar em cache e um valor de hash correspondente. Eu adicionei lógica aos meus service workers para verificar periodicamente esse arquivo de cache para ver quais arquivos precisam ser atualizados. IndexedDB é usado para persistir o manifesto para que as atualizações possam comparar os valores de hash para identificar quais URLs precisam ser atualizados.

Essa é uma boa primeira tentativa de resolver esse problema. Depois de usá-lo algumas vezes, comecei a trabalhar em algo um pouco mais sofisticado, onde verificaria o servidor sem precisar de um arquivo de manifesto separado. Ainda não aperfeiçoei essa técnica.

Felizmente, o Workbox o fez. Eu analisei como eles fazem a verificação e é muito próximo do que eu estava trabalhando. Honestamente, eles têm mais tempo e recursos para concluir a solução. E, claro, eles o tornaram grátis!

Configurando o Workbox

Você está livre para codificar diretamente na biblioteca do Workbox e precisará fazer isso para suas rotas dinâmicas. Mas, para pré-armazenamento em cache, acho mais sensato usar a ferramenta de linha de comando e módulo de construção de caixa de trabalho . A ferramenta de compilação é um módulo de nó que você pode usar como parte de seu processo de compilação e com executores de tarefas como Grunt, Gulp ou WebPack.

Em seu service worker, você precisa da seguinte linha:

  workbox.precaching.precacheAndRoute ([]); 

Isso serve como um alvo para a ferramenta de construção injetar uma nova lista de recursos para armazenar em cache com seus valores de hash correspondentes.

Eu construo/renderizo meus sites usando um script de nó personalizado, bem AWS lambdas, portanto, o módulo de construção de caixa de trabalho é perfeito. O único problema em execução dentro de uma função Lambda é a necessidade de manter uma cópia dos arquivos de origem no lambda. Não vou complicar as coisas ao lidar com isso por enquanto. Vamos nos concentrar apenas no código!

  const buildSW=()=> {//Isso retornará um retorno de Promise workboxBuild.injectManifest ({"globDirectory":"../public/www","globPatterns": ["***. *","img/**/*.*","race/**/*.*","meta/**/*.*","workbox-v3.4.1/**/*.*","sw/**/*.*","shop/**/*.*","js/libs/polyfil/*.*","font/**/*.*","sw.js","sw-generated.js"],"swSrc":'../public/src/sw-src.js',"swDest":"../public/www/sw.js"}). then (({count, size, warnings})=> {//Opcionalmente, registre quaisquer avisos e detalhes. warnings. forEach (console.warn); console.log (os arquivos `$ {count} serão pré-armazenados, totalizando $ {size} bytes`);}); } 

Aqui você pode ver a configuração injectManifest que uso para criar uma lista de arquivos para pré-armazenar em cache. O globDirectory aponta para a pasta de origem ou a localização dos arquivos do seu site. O array globPatterns é uma expressão regular que a ferramenta usa para combinar arquivos que podem ser pré-armazenados.

Você não quer pré-armazenar em cache todos os arquivos do site. Se você fizer isso, ficará com muitos megabytes de respostas em cache desnecessariamente. Lembre-se de que há uma restrição ou limite para quanto espaço você tem para respostas de cache . Aqui você pode ver o relatório gerado pela CLI indicando o quão grande todos os arquivos combinados são, demais!

too-many-files-precached

Em vez disso, você precisa limitar os arquivos a serem armazenados em cache. Esta é a propriedade globIgnores. Esta é uma matriz de expressões regulares correspondentes a arquivos explícitos, pastas e outros padrões a serem excluídos. Agora você tem apenas os arquivos de que realmente precisa.

As duas últimas propriedades informam à ferramenta onde o modelo do service worker de origem está localizado e onde o service worker final deve ser escrito.

too-many-files-precached

O resultado final é semelhante a o seguinte:

  workbox.precaching.precacheAndRoute ([{"url":"404/index.html","revisão":"2b0d50c334089f87cbbb8444b1505bcb"}, {"url":"about/index.html","revisão":"774ed84fd867b59f38c8254807ee93f4"}, {"url":"blog/index.html","revisão":"774ed84fd867b59f38c8254807ee93f4"}, {"url":"blog/indexd. {"url":"book/index.html","revisão":"a235d6e6452e8eea26c5a59f2cfa9b51"}, {"url":"contact/index.html","revisão":"1cc978f4178e0e48b8bbe1373c30df57/},...] code> 

Agora, quando você implanta os ativos finais no servidor, você tem um trabalhador de serviço novo que apenas refr arquivos esh que foram atualizados desde que foram armazenados em cache pela última vez.

Manipulando rotas dinâmicas na caixa de trabalho

O pré-cache requer um pouco mais de sutileza do que as rotas dinâmicas, o que parece contra-intuitivo. Mas o cache dinâmico é muito simples. Também é tratado pela configuração.

  workbox.routing.registerRoute (new RegExp ('/race/'), workbox.strategies.cacheFirst ({cacheName:'races', plugins: [new workbox.expiration.Plugin ({maxEntries: 40, maxAgeSeconds: 60 * 60 * 24,//1 dia})]})); 

No código de exemplo, você vê como registrar uma rota dinâmica e personalizar o cache nomeado e como a invalidação é tratada. Na verdade, existem duas maneiras de limitar por quanto tempo as respostas são armazenadas em cache, pelo número de respostas em um cache e por quanto tempo elas foram armazenadas.

A invalidação é gerenciada pelo plugin de expiração da caixa de trabalho. Não vou entrar em detalhes sobre como criar um plugin aqui, mas a arquitetura foi projetada para ser muito extensível.

Aqui, uso uma combinação de volume e tempo. Não mais do que 40 respostas e não mais do que 24 horas. Se uma solicitação for feita para uma resposta em cache e qualquer um desses limites tiver sido excedido, uma solicitação de rede é feita e a nova resposta é armazenada em cache de acordo com a estratégia desejada.

O restante do registro é o registerRoute método, que tem alguns parâmetros, uma rota ou expressão regular e uma estratégia. O exemplo é para qualquer página prefixada com'/race/', isso porque eu tenho uma página para cada Spartan Race que está por vir no site e eles estão armazenados na pasta de corrida.

A caixa de trabalho tem várias estratégias de cache embutido, aqui está a estratégia cacheFirst. É aqui que a solicitação é interceptada e o service worker verifica se há uma resposta em cache disponível. Se houver, a versão em cache será retornada. Caso contrário, a solicitação de rede é feita e a resposta armazenada em cache.

A caixa de trabalho inclui 5 estratégias comuns de armazenamento em cache:

  • Cache primeiro
  • Somente cache
  • Rede primeiro
  • Rede apenas
  • Desatualizado enquanto revalidado

Eu examino esses e cerca de 15 outros em meu curso Progressive Web App e a maioria no livro. Eu considero esses cinco a base para outras estratégias.

Na maioria das vezes, a estratégia Cache First é aquela que escolho. É claro que todo cenário precisa de avaliação para escolher a melhor estratégia. É por isso que você deseja criar caches nomeados exclusivos e atribuir regras a padrões de rota específicos. Ele permite maior flexibilidade ao criar a estratégia de cache de um aplicativo.

Resumo

O Workbox é uma biblioteca muito robusta que torna a criação de service workers muito mais fáceis. O Workbox gerencia apenas questões relacionadas ao cache, ele não possui nenhuma lógica incorporada para notificações push. Isso torna a sincronização em segundo plano muito mais fácil. Fiquei longe da sincronização em segundo plano por vários motivos, um deles são as camadas extras de complexidade que isso adiciona à sua lógica. O Workbox elimina essas complicações.

Como acontece com qualquer ferramenta poderosa, como o Workbox, encorajo você a escrever seus service workers sem o uso do Workbox quando você for novo para service workers. Eu sempre escolho a abordagem de que você precisa para ter conhecimento íntimo do que está acontecendo por trás da biblioteca ou ferramenta. Dessa forma, você pode usar e manter (solucionar problemas) a ferramenta melhor.

A documentação do Workbox é bem escrita e estruturada. Não consigo enfatizar isso o suficiente. Uma boa documentação é uma das razões pelas quais o jQuery ganhou grande popularidade há mais de 10 anos. A maioria das bibliotecas, módulos e estruturas sofrem de documentação deficiente que não apenas é difícil de seguir, mas frequentemente está fora de sincronia com a biblioteca. Eu não posso te dizer quantas vezes uma documentação ruim arruinou uma ferramenta popular para mim.

Depois de se sentir confortável com o cache do service worker, tente usar o Workbox. Eu me sinto confiante o suficiente sobre como funciona o cache do service worker, eu poderia usar meu próprio código e criar muitos códigos personalizados para cada aplicativo, mas o Workbox torna as coisas muito mais fáceis. Acho que esta é uma grande biblioteca que posso apoiar porque oferece mais do que o prometido.

Compartilhe este artigo com seus amigos!

Source link

Categories: Wordpress