Boa tarde
A história desta publicação é bastante simples e talvez familiar para muitos. A empresa desenvolve muitos produtos - no nosso caso, principalmente para um cliente. Recentemente, todas as soluções são desenvolvidas para a Web e as soluções de desktop existentes na Web são transferidas.
Nesse sentido, se havia um desejo de aumentar a velocidade do desenvolvimento e garantir a uniformidade dos produtos, foi decidido o desenvolvimento de uma base de componentes comum. Não falaremos sobre como o kit de interface do usuário foi criado e sobre longas batalhas com designers, mas quero falar sobre a implementação desta tarefa.
Na frente, temos democracia ou mesmo anarquia. As pessoas são livres para usar as soluções com as quais se sentem confortáveis. No momento, existem projetos em batalha no AngularJS, Angular, React, Vanilla e também existem projetos no Vue para uso interno. Nesse ponto, nosso olhar se voltou para os componentes da web.
Componentes da Web
Vamos dar uma rápida olhada no conceito de componentes da web. Ele se baseia no conceito de elementos personalizados, que permitem estender a classe HTMLElement criando suas próprias tags html, com lógica de negócios oculta ao usuário. Parece legal, parece bom. Vamos ver o que podemos fazer. A seguir, o código fonte é fornecido em texto datilografado.
Para criar um elemento personalizado, precisamos fazer o seguinte. Descreva a classe e registre o componente.
export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('Here I am'); } } if (!customElements.get('new-custom-element')) { customElements.define('new-custom-element', NewCustomElement); }
Além disso, conectando esse código a qualquer html (compilando-o em JS), podemos usar o componente (retornaremos a ele, de fato, se seus clientes não ousarem usar o Chrome).
Elementos personalizados também nos fornecem alguns ganchos para rastrear a vida útil dos componentes.
export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('I am created'); } connectedCallback() { console.log('Now I am in Dom'); this._render(); this._addEventListeners(); } disconnectedCallback() { console.log('I am removed now'); this._removeEventListeners(); } static get observedAttributes() { return ['date']; } attributeChangedCallback(attrName, oldVal, newVal) { switch (attrName) { case 'date': { break; } } } adoptedCallback() { } }
Também podemos gerar eventos em componentes através do método dispatchEvent
export class NewCustomElement extends HTMLElement {
O futuro chegou, disseram eles, você escreve o código uma vez e o usa em todos os lugares, eles disseram
Nós nos familiarizamos um pouco com os componentes, agora vou falar sobre os sentimentos que restaram depois de trabalhar com essa tecnologia. Em geral, no artigo
Componentes da Web no mundo real, o autor descreveu uma atitude em relação à tecnologia que se mostrou muito próxima de mim.
Vamos ver quais vantagens temos.
- Reutilizável : temos uma biblioteca realmente reutilizável. No momento, ele funciona em um projeto vanilla, conectando-se como um pacote Webpack compilado e em um projeto angular 7, conectando fontes de texto datilografado no AppModule
- Comportamento compreensível : se você seguir as melhores práticas , obteremos componentes com comportamento compreensível que podem ser facilmente integrados às estruturas existentes, por exemplo, angular, usando bananas em uma caixa, em aplicativos nativos por meio de atributos ou trabalhando com atributos que refletem propriedades.
- Estilo unificado : esta é uma repetição do ponto sobre reutilização, mas ainda assim. Agora, todos os projetos usam blocos de construção únicos para a construção da interface do usuário.
- Sinceramente, não tenho mais vantagens : conte-nos como os WebComponents o ajudaram.
A seguir, tentarei descrever coisas que provavelmente não gostei.
- Custos de mão-de-obra : os custos de desenvolvimento de componentes são incomparavelmente mais altos que o desenvolvimento de uma estrutura.
- Nomeação : os componentes competem globalmente, portanto, os nomes de classe e de marca devem ser prefixados. Dado que ainda temos bibliotecas de componentes implementadas em estruturas que foram nomeadas como <nome do componente da empresa>, tivemos que prefixar os componentes da Web duas vezes com <nome do componente da empresa wc >.
- ShadowRoot : de acordo com as práticas recomendadas, é recomendável usar o shadowRoot. No entanto, isso não é muito conveniente, pois não há possibilidade de influenciar a aparência do componente do lado de fora. E essa necessidade é frequentemente encontrada.
- Renderização : sem estruturas, é necessário esquecer a ligação e a reatividade dos dados (LitElement para ajudar, mas essa é outra dependência).
- O futuro não chegou : para manter o suporte ao usuário no nível antigo (temos o ie11 e tudo o que é mais atual), você precisa prender os polifilos, es5 é o padrão de destino, o que cria problemas adicionais.
- Os próprios polifilos : para obter tudo isso no IE, tive que atormentar bastante e tomar algumas decisões feias, pois os polycoms do componente da Web quebram algo dentro do hangar, causando um estouro da pilha de chamadas. Como resultado, tive que preencher polifilos, tendo recebido dependências extras.
Não sei que conclusão tirar disso tudo. Se a Microsoft criar um navegador baseado em cromo e parar de oferecer suporte ao IE e Edge, sim, será mais fácil respirar.
Há um benefício estranho: você pode dar o desenvolvimento de componentes da Web limpos para desenvolvedores iniciantes - deixe-os ver como estão, escreva em JS sem estruturas. Por um longo período, um colega não conseguiu entender por que a alteração na propriedade do componente não foi refletida imediatamente no DOM. Aqui estão pessoas cultivadas em estruturas. E eu sou o mesmo.