Introdução

É irrefutável que, cada vez mais o termo PWA vem se estabelecendo no mercado, segundo dados do Google Trends a busca pelo termo “Progressive Web Apps” vem ganhando cada vez mais consultas.

 

image _1_.png

 

Para uma aplicação ser considerada como PWA, há diversas características que esta deve possuir, como experiências offlines, reengajamento de usuários, responsivos, rápidos, sem necessidade de instalação entre outras características. Neste artigo abordaremos a criação de uma estrutura offline, a qual exige o uso de Service Workers.

Service Worker é um script que roda no background da sua aplicação sem a necessidade da interação do usuário ou do funcionamento de uma página da web. Ele permite o armazenamento de dados em cache os entregando quando um usuário estiver offline ou em uma conexão de baixa qualidade.

Definindo uma estrutura offline

Primeiramente é necessário definir a navegação offline, quais informações seriam importantes exibir quando o usuário não possui internet ou em uma rede lenta? Dado que isso foi definido, temos nossa estrutura de páginas offline.

Nessa estrutura, consideremos uma página a qual importa recursos como arquivos de estilos, javascripts, imagens... Se precisamos disponibilizar essa página offline, então precisamos cachear todos esses recursos no cache do navegador, além disso, é claro que precisaremos cachear também o HTML da página em questão.

image _2_.png

 

Caso a estrutura offline seja simples e somente com conteúdos fixos, a estrutura toda pode ser processada no front-end. Entretanto, podem ser definidas páginas que, por exemplo, possuam imagens as quais são recuperadas via cadastro de conteúdo. Dado que a internet seria necessário para recuperar tais imagens, então é indispensável o cacheamento da mesma para visualização offline. 
 
Problema: Como realizar a atualização dos arquivos a serem cacheados? Para ter uma solução com essas características podemos realizar a montagem da estrutura da seguinte forma:
 
Passo a passo da solução
 
Crie um layout file chamado service-work
 
...
self.addEventListener('install', function(event) {
    event.waitUntil(caches.open(currentCache.offline).then(function(cache) {
        return cache.addAll([
         <page:dummy page:holder="imagesToCache">
         <page:dummy page:interface="true" >
         </page:dummy>
         </page:dummy>
         '/vendor/jquery.min.js',
         '/vendor/vue.min.js',
         '/fonts/fonts.css',
         '/css/main.css',
         offlineUrl])
    }).catch(function(error) {
        console.log(error)
    }))
});
...
 
Estamos considerando somente o evento de instalação o qual está definindo os arquivos a serem cacheados. Este HTML será exatamente o service work com um holder de interface que deve gerar os recursos dinâmicos. Logo, cada estilo presente nesta interface deveria gerar algo como:
'a.png', 'b.jpg',
 
Vale ressaltar novamente que os arquivos gerados dinamicamente aqui devem ser os mesmos utilizados nas páginas offlines. 
 
unnamed.png
 
Crie uma página na estrutura e a chame de Service Work. Essa página deve possuir um arquivo de layout com o criado no passo acima. Além disso deve ter as seguintes property bags
lumis.portal.page.cache.queueId: servicework
lumis.portal.url.extension.html: js
lumis.portal.url.pathProcessing.referencetype: ROOT
 
A fila de cache separada serve para manter este arquivo sempre disponível nos arquivos públicos e pode ser criada da seguinte forma:
unnamed _1_.png
 
unnamed _2_.png
 

Lembre que é necessário apagar o web-resource do service work para que esta nova associação com a fila de cache seja atualizada. A propriedade  lumis.portal.url.extension.html serve intuitivamente para forçar a geração do arquivo como um javascript. Já a propriedade  lumis.portal.url.pathProcessing.referencetype é utilizada para forçar o caminho correto das imagens no apache durante a geração do cache do service work.

 

Estamos quase no final, entretanto caso seu service work contenha caracteres especiais, você notará que o LumisPortal irá gerar o cache deste arquivo com quebra de caracteres especiais, por exemplo se houver '&' este será substituído por '&amp;'. Como o código não está envolvido com uma tag <script> a geração do cache está considerando tudo como HTML. Para que este comportamento não ocorra, deve-se forçar a página em questão não executar o JSOUP, uma das formas de contorno é adicionando a seguinte property bag na página service work:

lumis.portal.url.pathProcessing.type: REGULAR_EXPRESSION

 

Caso o projeto utilize uma instância do serviço de injetor de HTML, a página irá ignorar a propriedade acima e executará o JSOUP. Outra property bag deve ser adicionada:

lumis.service.htmlinjector.ignore: true