Estratégias para o encapsulation do CSS em SPAs

[felipefialho]

Boa tarde pessoal,

Tenho estudado muito sobre estratégias e técnicas para tratar CSS em SPAs, mas como é um assunto muito novo, existe pouco direcionamento sobre o tema.

Penso que as estratégias podem ser definidas em duas, podendo ou não ter diferenciação delas entre os componentes. Cada um possui vantagens e desvantagens.

Com encapsulation

Funciona like web componentes, sendo assim, você tem um isolamento total do componente e os estilos não "vazam", ficando totalmente restritos aos componentes que pertencem.

Vantagens

• Garantia que os estilos dos componentes não influenciem uns nos outros e previsibilidade no comportamento do CSS
• Os componentes por serem isolados, podem ser reutilizados em qualquer projeto.

Desvantagem

• Dificuldades de manter padrão de código e consistencia de estilo dentro do projeto
• Reescrita de código

Sem encapsulation

É o padrão que estamos acostumados, nos aproveitamos da cascata do CSS a vida toda, mas com a evolução no desenvolvimento de software, foram surgindo técnicas como BEM que visam isolar os estilos.

Vantagens

• Aproveitamento de código
• Consistencia de estilo

Desvantagens

• Dificuldade para reutilizar os componentes em outros projetos
• Imprevisibilidade de funcionamento

---

Dentro desses principios, surgiram libs como CSS Modules e Styled Components, que fazem muito sentido em grandes aplicações e facilitam o desenvolvimento de CSS consistente, mas isolado.

É um assunto bem novo e acho que vale uma discussão sobre o tema. Como mostrei, tem vantagens e desvantagens em usar essa técnica. Claro que depende do projeto, mas mesmo dentro dele, tem variações de necessidades.

Como vocês tem feito?

[waldemirflj]

@lfeh Eu estou trabalhando com aplicações 100% "componetizadas" e tive essa mesma dúvida. A solução que eu encontrei e/ou melhor me atendeu foi, criar o componente da forma mais pura possível e deixar a customização por conta do renderizador.

[fdaciuk]

Não entendi os pontos de desvantagem sobre encapsular, não consigo ver esses problemas. Poderia detalhar melhor como você vê cada uma dessas desvantagens @lfeh?

[matheusml]

Oi @lfeh

Primeiramente é bom frisar que não existe solução única pra todos os casos. O mais interessante é justamente tentar fazer isso que te motivou a criar essa thread: pesquisar antes e ver o que é melhor pro seu caso.

Segundo, vale relembrar essa outra thread aqui Quais os métodos para isolar o CSS de um componente? na qual falei tanto sobre o CSS Modules quanto sobre o styled-components.

Dito isso, tenho algumas ressalvas em relação as desvantagens abaixo:

Com encapsulation

Desvantagens

• Dificuldades de manter padrão de código e consistência de estilo dentro do projeto

Porque haveria uma dificuldade em manter o padrão de código nesse caso e não pro outro? Na minha visão nesse sentido eles são exatamente iguais. E pra ambos os casos a solução seria a mesma:

1. Um styleguide bem escrito
2. Código novo só é adicionado através de PRs

• Reescrita de código
  Reescrita de código CSS apenas. Já o código HTML e JavaScript serão muito mais reaproveitados através de componentes. Pra mim isso é uma baita vantagem.

Feitas essas ressalvas, vejo uma vantagem grande em se utilizar uma arquitetura com encapsulation, visto que as desvantagens são pequenas em relação a arquitetura concorrente.
Fora que o modelo sem encapsulation tem uma desvantagem grande: a imprevisibilidade, que pode fazer com que projetos grandes se tornem um inferno de se manter.

[rubenmarcus]

Recentemente li esse artigo, achei bem legal:
https://medium.freecodecamp.org/reducing-css-bundle-size-70-by-cutting-the-class-names-and-using-scope-isolation-625440de600b

[felipefialho]

@fdaciuk e @matheusml só detalhando essa minha visão de desvantagens. Primeiro, como disse, estou apenas levantando pontos, então minha visão é bem pessoal e rasa 😂

Atualmente uso um arquivo de variáveis globais do Stylus, que contém todas as especificações do projeto. Essas variáveis e padrões são compartilhadas entre os componentes do projeto.

Partindo do principio de utilizar componentes isolados, eles não deveriam ter dependências de um arquivo de variáveis global. Isso é simples e natural, pois é a forma que desenvolvo a anos.

Então, para componentes isolados, tenho uma quebra de paradigma, que acho sensacional alias, mas é mais custosa para desenvolvimento para pessoas que estão muito enraizadas na forma antiga.

---

Pelo que observei, o correto seria criar diversos módulos de espaçamentos, cores, etc, que virariam dependências desse componente isolado e então ajudariam a manter o padrão visual. To certo?

[raphaelfabeni]

Boa galera! Discussão bem legal!
Tenho uma opinião parecida com a do @lfeh. E claro, depende muito, principalmente, de como vai estar o seu processo build. Se você tiver componentes totalmente fechados e que não se relacionam, ter essa encapsulação é muito legal. Entra bastante até em uma idéia que gosto, que é a de um componente se adaptar em qualquer realidade (principalmente em relação a responsividade e relação com estilos herdados). De qualquer forma, o principal ponto que vejo é o de, caso você precise reescrever algo, ir para um caminho onde, você tenha esse estilo mais geral e, que mesmo usando encapsulação, seja possível importar todas essas regras, sem gerar código duplicado.

:)

[douglasgimli]

Eu escrevi a umas semanas atrás um post abordando uma estratégia mista, com PostCSS, ITCSS e CSS Modules:

CSS Architecture with ReactJS

A ideia geral do post gira em torno do encapsulation, mas propondo uma arquitetura em que o desenvolvedor ainda consiga abstrair estilos para reaproveitar em múltiplos componentes, e isso tudo dentro de uma organização maior permitindo que o projeto cresça em número de desenvolvedores e componentes.

[eduardojmatos]

Up, pra acompanhar a thread.

Meus dois centavos aqui é só o fato de termos estratégias que façam a componentização no CSS ser o máximo isolada pra isso ocorrer sem problemas no JavaScript.

O ponto é que, as ferramentas que temos já possibilitam gerar escopo pra esses componentes, independente do que você usar em dev mode (seja BEM, seja ITCSS, etc.).

Inclusive eu tinha lido sobre esse tipo de abordagem nesse artigo https://medium.freecodecamp.org/reducing-css-bundle-size-70-by-cutting-the-class-names-and-using-scope-isolation-625440de600b que o @rubenmarcus citou logo acima. É bem bacana a forma que foi feita essa transformação em "módulos".

Agora, te indicar uma arquitetura que seja isolada a esse ponto... Difícil pensar numa. Mas todas tem alguma dependência de arquivos de configuração, como fontes, cores, espaçamentos e medidas em geral. Por isso que no Sass ou Stylus eu acho que tudo continua igual (ou pelo menos parecido). Suas ferramentas que vão compilar pra production que deveriam fazer esse processo de modularização.