Sempre que um grupo de padrões de componentes da Web é mencionado em qualquer artigo ou comentário, acontece quase a mesma coisa: pessoas que, com freqüência, têm muito pouca ideia do que está em jogo, começam a compartilhar opiniões "especializadas". A cada vez, as discussões deslizam para o mesmo cenário, cujo nome rima com a palavra "torre". E eu gostaria muito de uma transição positiva, construtiva e para questões de aplicação prática. Neste artigo, tentarei responder imediatamente a grande maioria das perguntas típicas e refutar o máximo de equívocos comuns. Posteriormente, em uma situação difícil, será possível vencer com um link. Então vamos lá.
O básico
Componentes da Web são um conjunto de especificações modernas que consistem nos seguintes elementos básicos:
Elementos personalizados - uma capacidade nativa de criar suas próprias tags HTML, com o comportamento, a aparência e a sua própria marcação interna especificados.
DOM de sombra - separação da estrutura interna do componente com encapsulamento dos estilos internos e do restante do corpo do documento.
Modelo - uma tag especial que permite armazenar partes da marcação, aplicá-las e reutilizá-las, se necessário.
Importações HTML - a capacidade de importar blocos HTML armazenados em outros arquivos HTML
O prato de todos os itens acima pode ser temperado com variáveis CSS nativas, módulos ES nativos e envio de servidor HTTP / 2. Também existem slots, atributos personalizados, eventos personalizados e outros detalhes. Sobre eles um pouco mais tarde, quando passamos a praticar.
Sim, esses seus componentes da Web quase não são suportados em nenhum lugar.
Números secos são os melhores amigos de um engenheiro. Vamos dar uma olhada em "quase lugar nenhum" deste ângulo:
Elementos personalizados - 78,71%
DOM sombrio - 79,12%
Modelo - 89.61%
Importações de HTML - 69,16%
Como podemos ver, as tecnologias acima funcionam em navegadores para a grande maioria dos usuários. As importações de HTML estragam um pouco a imagem, mas não somos obrigados a usar o conjunto completo (prefiro módulos ES nativos para dividir tudo em blocos convenientes); mesmo individualmente, você pode encontrar muitas coisas "saborosas" nesta lista.
Eu recomendo não confiar em mim cegamente, mas seguir os links fornecidos. Lá, por exemplo, você pode ver o status atual dessas especificações e o fato de que o Custom Elements e o Shadow DOM
receberam suporte completo no Firefox, começando na versão 63 . Quando a maioria dos usuários do fox atualizar para esta versão, e esse momento chegar, os números gerais se tornarão ainda mais atraentes. Além disso, você deve ter notado o "suporte incompleto" do Custom Elements e do Shadow DOM no Safari. Um navegador da Apple não permitirá que você herde seu componente de um elemento nativo incorporado do navegador, como um botão, seleção e similares. O Safari também possui algumas nuances nos seletores de CSS ao usar o Shadow DOM. Na prática, é bem possível viver com ela e não sofrer. Aparentemente, por tradição, o Microsoft Edge é um estranho entre os navegadores modernos. Os desenvolvedores afirmam que o suporte está sendo implementado. Nós estamos esperando.
Bem, o que fazer com o resto ~ 20% dos usuários?
Polyfiles podem ser usados para apoiar esses caras. Sim, funcionará um pouco mais devagar com os polifilos, mas isso não é perceptível a olho nu. Mas para todos os outros - será mais rápido.
Tentamos há cinco anos fazer um projeto sobre o Polymer. Tudo estava terrivelmente lento.
Naqueles tempos "distantes", o rascunho do padrão (v0) era violento, cujo suporte foi implementado apenas no Chrome. Desde então, muita coisa mudou: uma nova versão do padrão, v1, foi adotada, o suporte nativo foi implementado em vários navegadores, os polifiles foram reescritos e as boas práticas foram utilizadas até o estabelecimento. O próprio polímero evoluiu de uma visualização tecnológica para uma solução completamente funcional, o que é bom de lidar.
Alguns polímeros ... Do que se trata?
O Polymer é uma biblioteca para criar componentes da web. Ele implementa suporte para todo esse "açúcar" com o qual estamos acostumados ao trabalhar com estruturas populares de front-end: ligações dinâmicas de dados, repetidores para trabalhar com matrizes, etc. No momento, a terceira versão estável já foi lançada esta biblioteca. O desenvolvimento é realizado com a participação ativa dos desenvolvedores do Chrome. O ecossistema é mantido pelo Google.
O comprimento total das barbas dos desenvolvedores é ...Quando usar componentes da web?
Se você precisar de uma biblioteca compartilhada universal de componentes da interface do usuário. Um caso na vida: um projeto no qual o aplicativo principal é escrito em React e o back office em Angular. E eu quero a mesmice e todos os tipos de reutilização da base de código. E os componentes da web são ótimos
em diferentes ecossistemas .
Se você estiver próximo do design na abordagem do navegador . Você pode criar sem recriar constantemente o aplicativo e sem dependências desnecessárias. Isso torna a prototipagem uma experiência muito agradável e permite que seu aplicativo evolua sem problemas do estado do protótipo para o estado da versão de produção. Eu amo isso.
Se você gosta do bom e velho OOP : crie uma classe herdando de um elemento HTML, implemente os recursos e os pães desejados nele e, em seguida, herda classes para componentes especializados. E agora você tem seu próprio microframework. Beleza!
Se você odeia o BEM : o Shadow DOM isola os estilos dos componentes. Não há necessidade de nomes monstruosos de várias histórias, nem de fornecer navegação para declarações em um heap CSS comum. Tudo é compactado em um componente: estilos, layout, lógica.
Se você estiver desenvolvendo aplicativos baseados no Electron. A versão atual do Chromium in Electron já suporta tudo o que você precisa. Apesar do atraso geral nas versões.
Se você deseja escrever sua estrutura / biblioteca. Os componentes da Web são uma excelente base de composição para esses experimentos.
Se você precisar de uma abordagem híbrida: implemente páginas da Web clássicas com elementos SPA : as tags personalizadas podem ser usadas com qualquer mecanismo de modelo de servidor, elas podem fazer parte da marcação geral e definir seu objetivo no momento certo. Você pode manter um equilíbrio delicado do que é renderizado no servidor e do que funciona no cliente.
Se seus usuários usam navegadores modernos. Por si só.
Se você estiver desenvolvendo o PWA : as principais plataformas móveis suportam tudo de imediato. Para um início rápido, há um
kit pwa-starter .
Se você estiver interessado em aumentar a segurança do aplicativo e uma auditoria de dependência detalhada é proibitiva para você. Tudo é simples aqui: menos dependências - menos buracos não controlados.
Se você é um otimizador maníaco e gosta de trabalhar com a API DOM : os componentes da Web fazem parte da API DOM, com todos os recursos padrão dos elementos DOM comuns.
Se você se interessou em quebrar a compatibilidade com versões anteriores das versões das bibliotecas : quando tudo se baseia no padrão incondicional, é de alguma forma mais confiável.
Quando você NÃO deve usar componentes da web
Quando os requisitos para o seu projeto, é necessário oferecer suporte a navegadores antigos e exóticos. Nesse caso, você não será invejado em geral. Minhas condolências.
Quando você desenvolve produtos simples com um ciclo de vida curto e não precisa desenvolver uma única base de código.Quando você está lidando principalmente com um código legado.Quando você e seus colegas usam apenas algo elegante e não querem saber mais nada.Por que eu preciso de tudo isso? Eu tenho React / Vue / Angular / etc, o suficiente para mim ...
Então, uma parte significativa do que o JavaScript faz em bibliotecas e estruturas populares pode ser deslocada para uma implementação de navegador de nível inferior. Por uma questão de velocidade, reduzindo a quantidade exorbitante de dependências, reduzindo a própria dependência de dependências. Pelo bem do bem.