Não me “importo” em usar Web Components com PUG, afinal, ninguém disse que não podia ;)

Web Components and PUG logos

Hoje vamos conversar sobre duas coisas que sou pessoalmente apaixonado: Web Components e HTML Template Engines. Vou apresentar uma abordagem diferente para compor nossas páginas utilizando apenas três das quatro especificações que compõem um Web Component.

Relembrando

Mesmo que seja improvável você estar lendo isso sem saber ou nunca ter ouvido falar sobre Web Components, não custa deixar algumas referências para você entender melhor caso tenha alguma duvida. Se você acha que Web components morreram e nada disso é real, recomendo fortemente que leia meu último artigo sobre o assunto.

Nos livrando da primeira camada de imports

Usar Import gera requests que são lentos :(

Vamos começar jogando a verdade na cara, falando que você não precisa das quatro especificações (imports, custom elements, templates e shadow dom) para criar um Web Component.

Pense que estamos falando do processo de criar um componente, não de utilizá-lo. A partir dessa ideia podemos descartar o import, uma vez que ele serve basicamente para importar nossos componentes para dentro das paginas.

Temos como boa prática subdividir um componente grande em componentes menores, seguindo Atomic Design por exemplo, nesse contexto podemos usar o import dentro do componente para esse fim, mas essa seria uma outra camada do componente que muitas vezes não precisamos conhecer, afinal, se nosso objetivo é criar componentes reutilizáveis, o mínimo que se espera é que alguém possa usa-lo sem precisar entrar nele para modificar algo interno.

Um bom componente tem uma API externa bem documentada que permite a utilização sem que o desenvolvedor final precise saber o que tem dentro.

Porque não usar import para adicionar nossos componentes à pagina?

Em um mundo cruel onde o HTTP/2 não é realidade para todos, fazer dezenas de requests para importar todos os nossos componentes não parece uma boa ideia quando falamos de performance e principalmente quando levamos o First Render da página a sério.

Claro que depois do primeiro carregamento, se você fez seu trabalho direitinho, não precisaríamos nos preocupar mais com requests, uma vez que o Service Worker maroto está trabalhando em segundo plano baixando e cacheando tudo antes mesmo de precisarmos.

De qualquer forma precisamos de nossos componentes para fazer o primeiro carregamento da página, nesse contexto fazer diversos request com import não parece legal.

Solucionando o problema do First Render

Adicionar os componentes durante o Build elimina os requests e torna o First Render mais rápido :)

Para solucionar isso e outras coisas que fazem parte da vida, temos opções como o Vulcanize, que por sua vez pega nossos imports e através de um processo de Build injeta nosso componente direto na página sem precisarmos fazer o request. Em teoria usar o Vulcanize parece lindo, mas as vezes você não quer injetar todos os imports de uma vez ou fica complicado adicionar mais uma camada ao processo de build.

Falando em processo de build, é bem provável que seu projeto tenha algo do gênero, e que você use algo para facilitar sua vida na hora de escrever o Markup, digo Markup e não HTML porque hoje em dia quase ninguém escreve HTML realmente puro, ou temos algum processo de build antes ou manipulamos tudo com Virtual DOM.

Minha proposta é aproveitar esse processo que já temos para trabalhar com Web componentes de forma integrada sem depender de imports ou uma camada adicional no processo de Build. Para me ajudar nessa tarefa vou usar o template engine mais fofo de todos. “vem aqui PUG, vem garoto”.

Usando PUG para importar e utilizar Web componentes

Caso não esteja familiarizado com PUG ou outros template engines para HTML, separei um link para você de familiarizar antes de continuar a leitura.

Agora que entendemos as regras do jogo, podemos jogar. Nesse ponto basta fazer o include de nosso Web Componente através do próprio PUG fazendo com que ele esteja disponível no HTML, simples né.

include ./components/my-webcomponent.html

Lembrando que se necessário, podemos fazer os imports seguindo a especificação de imports normalmente, basta escrever com a syntax do PUG.

link(rel=”import” href=”components/my-webcomponent.html”)

Falando em syntax, já podemos usar nosso Web Componente como uma Tag normal através do PUG, afinal não deixa de ser uma TAG como qualquer outra.

Cuidado com as boas práticas

Ao usar Web Componentes de terceiros, fique alerta para suas dependências! Geralmente os Web Components reutilizáveis e distribuídos (comumente via Bower) são feitos para serem importando de dentro de bower_components, um problema que o Vulcanize resolve, mas que simplesmente jogar o componente na página sem pensar nos Paths que você pode estar quebrando como as dependências que o componente certamente tem dentro da bower_components. Para solucionar essa questão você precisa projetar sua estrutura de pastas de forma que os paths não quebrem, é possível manipular isso com o próprio bower, mas para não me extender muito, essa dica fica para um próximo artigo :)

Conclusão

A opção apresentada aqui é meio doida rs, na verdade nunca vi ninguém utilizar Web Components dessa forma, muito menos combinar com PUG (com excessão da Simone Amorim, que usa Polymer, PUG e Vulcanize em seu site pessoal.).

Sendo bem sincero esse artigo é mais uma troca de ideias com vocês sobre o que estou usando hoje no meu dia-a-dia, fiquem à vontade para me chamar de louco e comentar a baixo o que acharam, ficaria muito feliz em saber a opinião de vocês sobre esse novo (sim novo) mundo onde os Web componentes podem a qualquer momento dominar a Terra.

Quer saber mais sobre o universo de Web Components?

Para ficar por dentro do que está rolando e ter acesso a várias dicas descoladas, basta conferir os links:

Até a próxima ❤