Categorias
PWA - Progressive web apps WordPress

Transformando seu site WordPress em uma PWA

Nesse post iremos ver como utilizar o plugin oficial do Google para converter seu site WordPress em uma Progressive Web App, atualmente temos uma série de plugins para converter seu site em uma PWA, os 3 principais plugins são:

Plugin PWA Google

Nesse post vamos focar no plugin mantido pelo time do Google e XWP. Esse plugin foi criado com a intenção de fazer parte do core do WordPress aos poucos, no ano passado o plugin foi utilizado no tema do WordCamp Europe Berlin. Pelo fato que o plugin tem como objetivo fazer parte do core uma vez instalado o plugin não ativa nenhum painel mas quando realizamos auditoria com Lighthouse temos o seguinte resultado:

Lighthouse usa um checklist para fazer a validação se nosso site como uma PWA

Lighthouse olha para três categorias:

  • Rápido e estável: Rápido carregamento e suporte a offline.
  • Instalável: Uso de HTTPS e uso de web app manifest
  • Otimizado: Configurações para barra de navegação customizada, design responsivo, conteúdo disponível sem a execução de JavaScript, inclusão de configuração para apple-touch-icon

O plugin gera web app manifest através da REST API uma vez que o plugin é ativado você pode conferir o endereço /wp-json/wp/v2/web-app-manifest.

Meu blog por exemplo:

{ "name": "Blog Fellyph Cintra", "start_url": "https:\/\/blog.fellyph.com.br\/", "display": "minimal-ui", "dir": "ltr", "lang": "pt-BR", "background_color": "#fafafa", "theme_color": "#fafafa", "description": "Blog sobre WordPress, JavaScript, HTML, CSS, eventos e algo mais", "icons": [ { "src": "https:\/\/blog.fellyph.com.br\/wp-content\/uploads\/2018\/11\/cropped-1796698_795991100415208_12473649_n-192x192.jpg", "sizes": "192x192", "type": "image\/jpeg" }, { "src": "https:\/\/blog.fellyph.com.br\/wp-content\/uploads\/2018\/11\/cropped-1796698_795991100415208_12473649_n.jpg", "sizes": "512x512", "type": "image\/jpeg" } ] }

As propriedades são geradas da seguinte forma:

  • name: O título do site carregada pela função get_option(‘blogname’)
  • short_name: copia do site title com no máximo 12 caracteres
  • description: descrição do site get_option(‘blogdescription’)
  • lang: idioma do site get_bloginfo(‘language’)
  • start_url: home URL via get_home_url()
  • theme_color: background customizado via get_background_color()
  • background_color: também carregado pelo background customizado
  • display: por padrão é minimal-ui
  • icons: o ícone do site via get_site_icon_url()

Para a configuração completa sem modificação no código o título do site precisa ter menos de 12 caracteres, caso contrário precisamos customizar o nosso código, em outras palavras precisamos tocar no código. Weston criador do plugin PWA também criou um mini plugin para incluir essas informações sem código:

https://gist.github.com/westonruter/dec7d190060732e29a09751ab99cc549

A Primeira vez que rodei a auditoria tive dois problemas, o primeiro era o título do menu site era maior que 12 caracteres e o segundo o ícone do meu site era inferior a 512px.

Primeira auditoria com lighthouse

Para resolver o problema do short_name inclui o plugin do Weston, ele inclui um campo extra no meu painel de configuração

Atributo short name

Após corrigir o problema com o short name o segundo problema foi referente aos ícones para isso precisamos adicionar uma PNG com mais de 512px como ícone de nossa aplicação no menu Personalizar > Identidade do site:

Atualizando ícone do site

Com o manifest.json corrigido temos a possibilidade de instalar o nosso site WordPress como na imagem a seguir:

Banner de instalação

Personalizando manifest.json

Lembrando que a ideia que esse plugin faça parte do core, muita coisa ainda pode mudar na versão de Julho de 2020 caso queiramos personalizar informações do manifest.json precisamos adicionar filtros(codificar) em nossa aplicação via tema com function.php ou criando um plugin:

add_filter( 'web_app_manifest', function( $manifest ) { $manifest['short_name'] = 'Shortness'; return $manifest; } );

Caso o seu tema não suporte ícones ou background personalizado precisamos incluir a informação, por exemplo, o theme_color:

add_filter( 'web_app_manifest', function( $manifest ) { $manifest['theme_color'] = '#0073AA'; return $manifest; } );

Versão Offline

Um dos recursos do plugin é a inclusão de template para usuários offline Erro 500, caso queira enviar uma mensagem personalizada para o usuário você pode incluir uma template com seguinte nome offline.php, 500.php ou error.php para uma mensagem mais genérica.

Versão offline padrão

Caso queira testar seu template você pode acessar o seguinte endereços:

  • https://your-site-name.com/?wp_error_template=offline;
  • https://your-site-name.com/?wp_error_template=500

Comentários Offline

Outro recurso do plugin é a possibilidade de comentários offline, o plugin utiliza Background Sync API para enviar os comentários quando o usuário recuperar a conexão.

Estratégias de Cache

O plugin utiliza WorkBox integrado com PHP para realizar abstração da implementação das estratégias de cache, para isso precisamos indicar extensões e rotas e quais estratégias serão implementadas:

  • Cache first
  • Stale while revalidate
  • Cache only
  • Network only

Para implementar estratégias de cache precisamos utilizar hooks e adiciona-los em nosso function.php

add_action( 'wp_front_service_worker', function( \WP_Service_Worker_Scripts $scripts ) { $scripts->caching_routes()->register( '/wp-content/.*\.(?:png|gif|jpg|jpeg|svg|webp)(\?.*)?$', array( 'strategy' => WP_Service_Worker_Caching_Routes::STRATEGY_CACHE_FIRST, 'cacheName' => 'images', 'plugins' => array( 'expiration' => array( 'maxEntries' => 60, 'maxAgeSeconds' => 60 * 60 * 24, ), ), ) ); } );

No código acima adicionamos uma estratégia cache first a todas as imagens dentro da pasta \wp-content\.

add_action( 'wp_front_service_worker', function( \WP_Service_Worker_Scripts $scripts ) { $scripts->precaching_routes()->register( 'https://example.com/wp-content/themes/my-theme/my-theme-image.png', array( 'revision' => get_bloginfo( 'version' ), ) ); } );

No segundo exemplo acima realizamos precaching de uma image específica em nosso tema e vinculamos uma versão para manter em cache até o plugin atualizar a versão, mais informações na página do github plugin.

Conclusão

Caso faça parte do core do WordPress isso será uma grande adição para o core do WordPress, o uso de bibliotecas externas como Workbox pode adicionar mais complexidade na incorporação desse plugin, mas o plugin é uma alternativa rápida para implementação de recursos de uma Progressive web app em nossos sites WordPres.

Vantagens

  • Fácil integração com outros plugins do Google como AMP para WordPress e Site Kit.
  • Inclusão de template para versão offline.
  • Possiblidade de comentários offline
  • API para implementação de estratégias de cache
  • Geração automática de Web App Manifest

Desvantagens

  • Necessidade de codificação para alguns recursos
  • Ausência de um painel de personalização para determinadas informações
  • Nenhuma integração para service worker

Após as configurações adicionadas corretamente temos nosso site WordPress atingindo as três metas: Rápido, estável, instalável e otimizado.

Auditoria final

Para mais posts sobre PWA acesse a página da categoria.

Categorias
PWA - Progressive web apps

Novidades da Microsoft e Apple sobre PWA

Nos meses de Maio e Junho tivemos as conferências para desenvolvedores da Microsoft Build e Apple WWDC. Nelas tivemos alguns novidades importantes para as Progressive web Apps.

Primeiramente a Microsoft reforçou sua estratégia de investir em Progressive Web Apps para desktop e o suporte do time da Microsoft ao projeto Fugu, Durante a apresentação: Building rich app experiences with Progressive Web Apps foram exibidas as novas integrações de PWA com o Windows 10 como:

  • Executando uma PWA quando o OS é inicializado
  • App Shortcuts
  • Integração com Share target
  • Associação de extensões de arquivos com PWAs
  • Associação de protocolos com PWAs
  • Proposta para personalizar a barra de título da janela da aplicação.

A seguir irei listar alguns recursos com mais detalhes.

Executando uma PWA quando o OS é inicializado

Assim como aplicações nativas também será possível definir uma PWA auto inicializar quando o usuário realiza o login no sistema operacional. Para habilitar esse recurso no Windows 10 adicionamos a seguinte propriedade em nosso manifest.json:

request_on_install: [ "runonstartup", ]

Quando requisitado a instalação o usuário terá a opção de habilitar o novo recurso como na imagem abaixo:

Esse recurso estará disponível no Edge canary em julho

Share Target API para desktop

PWAs agora podem registrar se registrar como destino de compartilhamento em aplicações desktop. A share target API já um recursos disponível on Android, agora também estará disponível para Windows 10.

App shortcuts

Confesso que é um dos recursos que estou animado para testar, app shortcuts permite criar atalhos nas ações rápidas de sua aplicação, geralmente acessado pelo ícone na barra de tarefas(Desktop) ou na home screen(Android), este recurso estará em breve disponível para Chrome/Edge para mobile/desktop como podemos ver nas imagens abaixo:

app shortcuts windows
App shortcuts android

Para adicionar shortcuts incluímos o seguinte código em nosso manifest.json:

"shortcuts": [ { "name": "Play Later", "description": "View the list of podcasts you saved for later", "url": "/play-later", "icons": [ { "src": "/icons/play-later.svg", "type": "image/svg+xml", "purpose": "any" } ] }, { "name": "Subscriptions", "description": "View the list of podcasts you listen to", "url": "/subscriptions?sort=desc" } ]

Associação de arquivos com PWA

Esse recurso permite associar sua aplicação PWA com tipos de arquivos, URLs e protocolos específicos, por exemplo dentro de seu arquivo manifest.json você irá adicionar as seguintes informações:

"file_handlers": [ { "action": "/editimage", "accept": { "image/jpg": [".jpg"] } } ]

Atualmente não conseguimos realizar isso com Windows mas na novas versões do Windows 10 será possível associar uma PWA a um tipo de arquivo. Em sua PWA você saberá quando o usuário tentar abrir um arquivo em sua aplicação com o seguinte código:

if('launchQueue' in window) { launchQueue.setConsumer(e => { let jpgFile = e.files[0]; }) }

Seguindo a mesma lógica, também conseguimos associar protocolos a PWAs, por exemplo, uma URL para enviar um email. A previsão para esse recursos são para a versão 86 do Edge.

Privacidade

Além dos recursos que listei anteriormente no Windows 10 também será possível o gerenciamento de acesso de recursos do seu app como por exemplo, Câmera e geolocalização.

WWDC 2020

WWDC é a conferência anual de desenvolvimento da Apple, nesse ano tivemos o anuncio do iOS14 e as nova versão do safari, já no lado da Apple não temos nenhum momento o uso do termo PWA parece algo proibido internamente, mas com a exclusão do termo tivemos melhorias relacionadas Progressive Web App no safari e para apps de terceiros.

Por exemplo, apps iOS anteriormente não tinham acesso na webview acesso a service worker, como a nova versão do WKWebView do iOS isso será possível. Isso ajudará apps como Chrome e Firefox iOS implementarem o suporte a recursos que dependem do service Worker.

No Safari a versão 14 temos os seguintes items:

Também foram anunciadas melhorias referentes a CSS, Web Animations, Web Components, SVG e finalmente o suporte a WebP. Durante a apresentação sobre as novidades para desenvolvedores web, também mencionaram novidades já lançadas esse ano como Clipboard Async API.

Mas Pessoalmente o anuncio mais significante da semana foi O Anuncio de Jen Simmons como Web Technologies Evangelist, ela fez um trabalho maravilhoso na Mozilla e cria um pouco de esperança que o time do webkit priorize a padronização de alguns recurso no webkit.

Mais informações sobre os anúncios do webkit/safari https://developer.apple.com/news/?id=e4u1mtfu

web.dev Live

Esse ano não tivemos o Google I/O principal conferência para desenvolvedores do Google. Mas no final do mês de junho teremos o web.dev live evento focado totalmente em conteúdo web. Teremos algumas palestras relacionadas a PWA estou bastante ansioso para esse evento ele acaba fechando o ciclo de eventos das principais Empresas de tecnologias.

web.dev Live 2020

Mais conteúdo sobre PWA acesse a página do curso.

Categorias
PWA - Progressive web apps

Armazenamento de dados no Browser

Armazenamento de dados no Browser ou client-side é algo possível por diferentes APIs, no passado tivemos o uso de Cookies agora temos localStorage, sessionStorage, IndexedDB e CacheStorage API. Sem uso de back-end ou bibliotecas externas, suporte direto do Browser.

Nesse post iremos entender a diferença entre os tipos de armazenamento de dados no Browser e quando utiliza-los.

Cookies

Por muitos e muitos anos cookies foram utilizados para persistir dados na web, com o passar dos anos esse recurso evoluiu e passou por algumas melhorias mas também criou problemas relacionados a privacidade. Nos últimos anos os principais navegadores passaram a implementar restrições ao uso de Cookies. Recentemente Chrome, Firefox e Edge implementaram restrições de uso de cookies em aplicações com domínios diferentes.

Já é público por parte do time do Chrome a descontinuação de suporte ao uso de Cookies.

LocalStorage e SessionStorage

Posso fala que é o modo mais simples de armazenamento e dados na máquina do usuário. Introduzidos no HTML5 ambas permitem o armazenamento de texto no browser do usuário com um limite de até 5MB na maioria dos Browsers

SessionStorage

Como o nome sugere permite o armazenamento de dados na sessão do usuário(aba), quando a aba for fechada os dados serão removidos. Ela pode ser utilizadas em conjunto com outras API, com o armazenamento de dados temporário

LocalStorage

Sua utilização é simples mas atualmente seu uso é pouco recomendado já que a IndexedDB disponibiliza mais recursos para armazenamento a longo prazo. Além disso a localStorage possuí suas limitações:

  • Sua execução é síncrona
  • Tem uma limitação de armazenamento 5mb
  • E não possui acesso por service workers e web workers

IndexedDB

Banco de dados não relacional(noSQL) que realiza transações assíncronas. Com a IndexedDB conseguimos armazenar objetoos e realizar consultas através de índices. Com IndexedDB conseguimos trabalhar com, objetos, texto, arquivos e blobs.

Diferente da LocalStorage a IndexedDB possui acesso por web workers e service workers, nesse caso sendo um item crucial para armazenamento de dados offline em uma progressive web app.

Umas das desvantagens da IndexedDB é a complexidade de se trabalhar com essa API, seu comportamento pode ser simplificado por libs externas além da adição de recursos extras como, Promises.

CacheStorage API

A Cache API é um sistema de armazenamento de requisições e respostas realizadas a rede. Podemos armazenar requisições realizadas durante a execução da aplicação ou podemos armazenar requisições em background somente para uso de dados.

A API foi criada para permitir que service workers realizassem cache de requisições feitas a rede para permitir respostas rápidas ou reduzir um impacto na latências de conexões de dispositivos móveis.

O que podemos armazenar com cacheStorage API?

Apenas Requisições e respostas HTTP. Entretanto essas requisições podem conter qualquer tipo de dados transferido sobre o protocolo HTTP, por exemplo:

  • Imagens
  • Páginas
  • JavaScript
  • Arquivos CSS
  • Objetos JSON

Utilizando armazenamento de dados em uma PWA

Numa recomendação geral podemos classificar da seguinte forma:

  • Para recursos da aplicação como arquivos: Cache API Storage
  • Para dados e consulta: IndexedDB

Porque não é recomendado o uso de SessionStorage ou LocalStorage para PWAs? Simplesmente pela limitação de ter acesso através de service workers mas o recurso pode se utilizado como um fallback para navegadores que não possuem suporte a Service Worker.

Quanto eu posso armazenar?

Essa informação pode variar por navegadores mas em geral estamos falando de centenas de megabytes, para uma aplicação Web é bastante.

  • Chrome permite utilizar 60% do total do espaço em disco para diferentes domínios e APIs
  • Internet Explorer 10 permite 250MB no total mas irá avisar o usuário quando a aplicação utilizar mais de 10BM
  • Firefox tem um limite de 2GB, mas você pode determinar quanto espaço você terá disponível com a StorageManager API
  • Safari irá permitir até 1GB e irá requisitar permissão ao usuário quando atingir 200MB.

Esse post serviu como uma introdução mas já tinha feito um post no canal sobre LocalStorage a alguns anos você pode conferir aqui: LocalStorage: Armazenando dados com JavaScript

Categorias
PWA - Progressive web apps Tutoriais

Geolocation API

Vamos falar sobre geolocation esse post servirá como base para o conteúdo do curso de PWA que estou rodando no meu canal. Na versão 2020 do curso iremos abordar Web APIs disponíveis para iOS e nesse primeiro posts iremos abordar a Geolocation web API.

Umas das primeiras web APIs lançadas junto com o HTML5, para termos noção esse recurso estava disponível na versão 5 do Chrome e Safari em 2010. A Geolocation API possui uma série de funções e eventos que permitem a localização do usuário através doso dados: latitude e longitude.

Relatório do “can I use”

Suporte

Esse recurso é totalmente dependente do device do usuário vimos que o recurso é presente 94% dos browsers que suporte alto. Mas a sua precisão depende que o device que possua GPS, caso contrário essa informação será gerada através de cruzamento de dados, por exemplo, rede e endereço IP. Isso significa se o device não possuir suporte essa informações não serão tão precisas.

GPS

Outro ponto importante é o consumo de bateria, para o os dispositivos móveis o acesso ao GPS causa um custo maior de processamento assim aumenta o consumo de bateria, então é importante fazer o uso consciente desse recurso.

Privacidade

Na maioria dos devices esse recurso é dependente de uma conexão HTTPS, também antes do acesso a esse recurso o browser irá requisitar permissão de acesso a Geolocalização do usuário. Como podemos ver na imagem a seguir:

Exemplo pop up de permissão da apple

Ideal caso armazene ou monitore a movimentação do usuário deixe claro o uso desse recurso. Esse recurso também só será acessado em uma aplicação que estiver rodando em um servidor web.

Código

Depois de uma introdução sobre a API agora vamos ver como utiliza-la em nossa aplicação:

navigator.geolocation.getCurrentPosition(geoSuccess, geoError); const geoSuccess = (position) => { console.log(position.coords.latitude, position.coords.longitude); }; const geoError = (error) => { console.log('Error occurred. Error code: ' + error.code); };

No código acima fazem a chamada da api dentro de navigator, podemos conferir se o browser tem suporte a geolocation verificando se o atribulo é nulo mas em 2020 a api está presente na maioria dos browsers então não vou me preocupar como esse ponto.

Chamamos a função get position responsável por requisitar a latitude e longitude do usuário. Ela recebe como parâmetro duas funções uma parar executar caso sucesso ou falha de acesso ao recurso.

Se a requisição for bem sucedida teremos a chamada da função geoSuccess com o retorno da latitude(position.coords.latitude) e longitude(position.coords.longitude). Em caso de erro teremos a chamada da função geoError com os possíveis códigos:

  • 0: erro desconhecido
  • 1: permissão negada
  • 2: erro na resposta da fonte da informação
  • 3: timed out

Essa é uma introdução ao assunto em breve estarei postando um vídeo sobre o assunto em meu canal. Qualquer dúvida deixe um comentário ou continue lendo mais tutoriais na página da categoria.

Referência: MDN Geolocation API

Veja também as aulas sobre o assunto no curso de PWA

Categorias
JavaScript PWA - Progressive web apps

Introdução a Workbox

Workbox é um conjunto de bibliotecas e módulos do node que simplifica o processo de cache de assets em nossa aplicação, assim agilizando o nosso trabalho na criação de uma Progressive Web Apps. Este tutorial será baseado na versão 4 da biblioteca. Workbox trabalha dois conceitos importantes sobre PWAs:

Performance: não espere por todos os arquivos de sua aplicação virem da internet, crie estratégias de cache para servir arquivos do armazenados em seu device.

Resiliência: Conexões móveis ou em regiões com fraca infra estrutura podem afetar a experiência do usuário, habilite sua aplicação administrar situações que a conectividade é limitada

Porquê Workbox?

Workbox é uma biblioteca reune as melhores práticas e toda a complexidade de trabalhar com service workers com por exemplo:

  • Precaching
  • Runtime caching
  • Estratégias de cache
  • Requisição de rotas
  • Background Sync
  • Ajuda no debug da aplicação

Opções de utilização

Para trabalhar com Workbox temos as seguintes alternativas:

  • Workbox CLI
  • node.js
  • webpack plugin

Lembrando que essas alternativas são independentes você deve escolher somente uma, então escolha a alternativa que melhor se adequa ao seu caso.

Workbox CLI

CLI nada mais é que uma acrônimo para Command line Interface(Interface de linha de comando) tem como objetivo trazer um grupo de comandos no terminal para possibilitar realizar uma terminada ação, seja criar novos projetos ou administrar recursos existentes. Mas tendo como foco principal reduzir o trabalho e a complexidade ao item aplicado.

Primeiro passo quando trabalhamos com um CLI é fazer sua instalação workbox-cli depende do node.js para funcionar, antes de rodar qualquer comando para o CLI precisamos instalar a versão mais recente do node.js, após a instalação do node rodamos os seguinte comando em nosso terminal:

npm install workbox-cli --global

Se tudo ocorrer bem seremos capazes de testar com o seguinte comando:

workbox --help

Se o terminal reconheceu o comando workbox sinaliza que a instalação foi bem sucedida, agora é hora de utilizar o comando:

workbox wizard

Ele irá nos dar um passo-a-passo para a configuração de nosso projeto com as seguintes perguntas:

  1. Qual é a pasta do nosso app onde se encontra a pasta em que iremos exportar nossa aplicação?
  2. Quais os tipos de arquivos em que gostaríamos de realizar o preache?
    1. svg, jpg, png, html, css, js, json
  3. Onde preferimos salvar o nosso service worker?
  4. Onde gostariamos de salvar nosso arquivo de configuração

Como podemos ver na imagem abaixo, no meu caso estou rodando a versão 4.3.1 do Workbox, versões anteriores ou futuras esse passos podem mudar um pouco mas o core sempre será quais arquivos queremos fazer o cache e qual será o nosso service worker.

Por fim ele exibe o comando necessário para gerar nosso service worker:

workbox generateSW workbox-config.js

Quando rodamos esse comando ele irá ler o arquivo de configuração gerado pelo wizard:

module.exports = { "globDirectory": "dist/", "globPatterns": [ "**/*.{svg,jpg,png,html,css,js,json}" ], "swDest": "dist/sw.js" };

Varrer e criar um cache para todos os arquivos com as extensões especificadas anteriormente. Você terá um retorno parecido com a mensagem a seguir.

The service worker was written to dist/sw.js 22 files will be precached, totalling 84.2 kB.

Esse comando será necessário toda a vezes em que alteramos os arquivos dentro de nossa aplicação, para agilizar esse processo podemos fazer uma integração com gulp ou webpack.

Gulp + workbox

Como mencionamos anteriormente podemos agilizar o processo de criação de service worker utilizando ferramentas de automatização de tarefas, basicamente vamos assistir as mudanças realizadas em nosso projeto quando algum arquivo for alterado o Gulp será responsável por gerar o nosso service worker

Instalação:

npm install workbox-build --save-dev

Exemplo

const workboxBuild = require('workbox-build'); // NOTE: Esse comando deve ser executado depois que os assets forem gerados const buildSW = () => { // assim retornamos generateSW que retorna uma Promisse return workboxBuild.generateSW({ globDirectory: 'build', globPatterns: [ '**\/*.{html,json,js,css}', ], swDest: 'build/sw.js', }); }

webpack + workbox

Para webpack também temos um plugin especifico para trabalhar com workbox ele tem suporte precaching e runtime caching. Caso ainda não conheça webpack tenho um post de introdução aqui.

Para instalação do plugin na pasta de nosso projeto onde ficar o nosso arquico package.json executamos o seguinte comando em nosso terminal:

npm install workbox-webpack-plugin --save-dev

Depois de instalado precisamos configurar o nosso webpack, dentro do arquivo de configuração do webpack adicionamos o Plugin para workbox:

// dentro do webpack.config.js: const WorkboxPlugin = require('workbox-webpack-plugin'); module.exports = {   // Outras configurações...   plugins: [     // Outros plugins...     new WorkboxPlugin.GenerateSW()   ] };

Após tudo configurado precisamos registrar nosso service worker:

<script> // verificamos se o browser suporta service worker if ('serviceWorker' in navigator) { // usamos o evento load para registrar nosso service worker window.addEventListener('load', () => { navigator.serviceWorker.register('/service-worker.js'); }); } </script>

Caso queira saber mais sobre service worker tenho um post de introdução a service worker também estou rodando um curso gratuito sobre PWA em meu canal no youtube. Qualquer dúvida só deixar um comentário e até o próximo post.