Estilo e CSS

Cascading Style Sheets (CSS) é uma linguagem para determinar centralmente a apresentação de um documento em vez da formatação codificada para texto e objetos. O recurso em cascata da linguagem foi projetado para controlar as prioridades entre os estilos usando a herança. Quando você trabalha em microfront-ends e cria uma estratégia para gerenciar dependências, o recurso em cascata da linguagem pode ser um desafio.

Por exemplo, dois microfrontends coexistem na mesma página, cada um definindo seu próprio estilo para o elemento HTML. body Se cada um buscar seu próprio arquivo CSS e anexá-lo ao DOM usando uma style tag, o arquivo CSS substituirá o primeiro se ambos tiverem definição para elementos HTML, nomes de classes ou IDs de elementos comuns. Existem diferentes estratégias para lidar com esses problemas, dependendo da estratégia de dependência que você escolher para gerenciar estilos.

Atualmente, a abordagem mais popular para equilibrar desempenho, consistência e experiência do desenvolvedor consiste em desenvolver e manter um sistema de design.

Sistemas de design ‒ Uma abordagem de compartilhar algo

Essa abordagem usa um sistema para compartilhar estilos quando apropriado, ao mesmo tempo em que oferece suporte a divergências ocasionais para equilibrar consistência, desempenho e experiência do desenvolvedor. Um sistema de design é uma coleção de componentes reutilizáveis, guiados por padrões claros. O desenvolvimento do sistema de design geralmente é conduzido por uma equipe com contribuições e contribuições de várias equipes. Em termos práticos, um sistema de design é uma forma de compartilhar elementos de baixo nível que podem ser exportados como uma JavaScript biblioteca. Os desenvolvedores de microfront-end podem usar a biblioteca como uma dependência para criar interfaces simples, compondo recursos pré-fabricados disponíveis e como ponto de partida para criar novas interfaces.

Considere o exemplo de um microfrontend que precisa de um formulário. A experiência típica do desenvolvedor consiste em usar componentes pré-fabricados disponíveis no sistema de design para compor caixas de texto, botões, listas suspensas e outros elementos da interface do usuário. O desenvolvedor não precisa escrever nenhum estilo para os componentes reais, apenas para ver como eles se parecem juntos. O sistema a ser construído e lançado pode usar o webpack Module Federation ou uma abordagem semelhante para declarar o sistema de design como uma dependência externa, de forma que a lógica do formulário seja empacotada sem incluir o sistema de design.

Vários microfront-ends podem então fazer o mesmo para cuidar de preocupações compartilhadas. Quando as equipes desenvolvem novos componentes que podem ser compartilhados entre vários microfront-ends, esses componentes são adicionados ao sistema de design após atingirem a maturidade.

A principal vantagem da abordagem do sistema de design é o alto nível de consistência. Embora os microfront-ends possam escrever estilos e, ocasionalmente, substituir os do sistema de design, há muito pouca necessidade disso. Os principais elementos de baixo nível não mudam com frequência e oferecem funcionalidades básicas que podem ser estendidas por padrão. Outra vantagem é o desempenho. Com uma boa estratégia para criar e lançar, você pode produzir pacotes compartilhados mínimos que são instrumentados pelo shell do aplicativo. Você pode melhorar ainda mais quando vários pacotes específicos de microfront-end são carregados de forma assíncrona sob demanda, com espaço mínimo em termos de largura de banda de rede. Por último, mas não menos importante, a experiência do desenvolvedor é ideal porque as pessoas podem se concentrar na criação de interfaces avançadas sem reinventar a roda (como escrever JavaScript e CSS toda vez que um botão precisa ser adicionado a uma página).

A desvantagem é que um sistema de design de qualquer tipo é uma dependência, portanto, ele deve ser mantido e, às vezes, atualizado. Se vários microfront-ends exigirem uma nova versão de uma dependência compartilhada, você poderá usar uma das seguintes opções:

• Um mecanismo de orquestração que pode, ocasionalmente, buscar várias versões dessa dependência compartilhada sem conflitos

• Uma estratégia compartilhada para fazer com que todos os dependentes usem uma nova versão

Por exemplo, se todos os microfrontends dependerem da versão 3.0 de um sistema de design e houver uma nova versão chamada 3.1 para ser usada de forma compartilhada, você poderá implementar sinalizadores de recursos para que todos os microfrontends migrem com risco mínimo. Para obter mais informações, consulte a seção Sinalizadores de recursos. Outra desvantagem potencial é que os sistemas de design geralmente abordam mais do que estilo. Eles também incluem JavaScript práticas e ferramentas. Esses aspectos exigem chegar a um consenso por meio de debate e colaboração.

Implementar um sistema de design é um bom investimento a longo prazo. É uma abordagem popular e deve ser considerada por qualquer pessoa que trabalhe em uma arquitetura de front-end complexa. Normalmente, exige que engenheiros de front-end e equipes de produto e design colaborem e definam mecanismos para interagir uns com os outros. É importante agendar um horário para alcançar o estado desejado. Também é importante ter o patrocínio da liderança para que as pessoas possam criar algo confiável, bem mantido e com bom desempenho a longo prazo.

CSS totalmente encapsulado ‒ Uma abordagem de não compartilhar nada

Cada microfrontend usa convenções e ferramentas para superar o recurso de cascata do CSS. Um exemplo é garantir que o estilo de cada elemento esteja sempre associado a um nome de classe em vez do ID do elemento, e que os nomes das classes sejam sempre exclusivos. Dessa forma, tudo é direcionado para microfront-ends individuais e o risco de conflitos indesejados é minimizado. O shell do aplicativo normalmente é responsável por carregar os estilos dos micro-front-ends depois que eles são carregados no DOM, embora algumas ferramentas agrupem os estilos usando. JavaScript

A principal vantagem de não compartilhar nada é o risco reduzido de introduzir conflitos entre microfront-ends. Outra vantagem é a experiência do desenvolvedor. Cada microfrontend não compartilha nada com outros microfrontends. Liberar e testar isoladamente é mais simples e rápido.

A principal desvantagem da abordagem de não compartilhar nada é a potencial falta de consistência. Não há nenhum sistema para avaliar a consistência. Mesmo que a meta seja duplicar o que é compartilhado, isso se torna um desafio equilibrar a velocidade de lançamento e a colaboração. Uma mitigação comum é criar ferramentas para medir a consistência. Por exemplo, você pode criar um sistema para fazer capturas de tela automatizadas de vários microfront-ends renderizados em uma página com um navegador sem cabeçalho. Em seguida, você pode revisar manualmente as capturas de tela antes do lançamento. No entanto, isso requer disciplina e governança. Para obter mais informações, consulte a seção Equilibrando autonomia com alinhamento.

Dependendo do caso de uso, outra desvantagem potencial é o desempenho. Se uma grande quantidade de estilo for usada por todos os microfront-ends, o cliente deverá baixar muitos códigos duplicados. Isso afetará negativamente a experiência do usuário.

Essa abordagem de não compartilhar nada deve ser considerada somente para arquiteturas de microfront-end que envolvem apenas algumas equipes ou microfront-ends que podem tolerar baixa consistência. Também pode ser uma etapa inicial natural enquanto uma organização está trabalhando em um sistema de design.

CSS global compartilhado ‒ Uma abordagem de compartilhamento total

Com essa abordagem, todo o código relacionado ao estilo é armazenado em um repositório central onde os colaboradores escrevem CSS para todos os microfrontends trabalhando em arquivos CSS ou usando pré-processadores como o Sass. Quando as alterações são feitas, um sistema de compilação cria um único pacote CSS que pode ser hospedado em uma CDN e incluído em cada microfrontend pelo shell do aplicativo. Os desenvolvedores de microfront-end podem projetar e criar seus aplicativos executando seu código por meio de um shell de aplicativo hospedado localmente.

Além da vantagem óbvia de reduzir o risco de conflitos entre microfront-ends, as vantagens dessa abordagem são consistência e desempenho. No entanto, desacoplar estilos da marcação e da lógica torna mais difícil para os desenvolvedores entenderem como os estilos são usados, como podem evoluir e como podem ser descontinuados. Por exemplo, pode ser mais rápido introduzir um novo nome de classe do que aprender sobre a classe existente e as consequências da edição de suas propriedades. As desvantagens de criar um novo nome de classe são o crescimento do tamanho do pacote, que afeta o desempenho, e a possível introdução de inconsistências na experiência do usuário.

Embora um CSS global compartilhado possa ser o ponto de partida de uma monolith-to-micro-frontends migração, raramente é benéfico para arquiteturas de microfront-end que envolvem mais de uma ou duas equipes colaborando juntas. Recomendamos investir em um sistema de design o mais rápido possível e implementar uma abordagem de não compartilhar nada enquanto o sistema de design estiver em desenvolvimento.