Como você se livra do código CSS não utilizado? Parte 2

Hoje publicamos a segunda parte da tradução do material sobre a luta contra o código CSS não utilizado.



→ A primeira parte

Pós-processamento CSS

Suponha que em algum projeto o CSS seja escrito usando Less ou Sass e, em seguida, um pós-processador seja usado para compilar o código existente no CSS comum. Nesse projeto, provavelmente, existe um sistema automático para se livrar do CSS não utilizado, que inicia após o pré-processamento do CSS. Isso pode ser assim:

1. Sass.
2. PostCSS / sistema de prefixo automático.
3. Removendo CSS não utilizado.
4. Código CSS pronto para produção.

Isso, por um lado, faz sentido e, por outro, parece um pouco estranho aos meus olhos. O ponto é que, com essa abordagem, o código-fonte que contém comandos de estilização não é corrigido, com base no qual o código CSS resultante é criado, o que também inclui CSS não utilizado. Em vez disso, CSS desnecessário é simplesmente removido no final do processo de compilação. Suspeito que em JavaScript, ao implementar o algoritmo de agitação de árvores, algo semelhante tenha sido feito há algum tempo. Ou seja, esse tratamento com CSS não é novidade. Mas, para mim, tudo isso parece errado, já que a base de código CSS é algo que se pode dizer que está na superfície dos projetos da web. Essa abordagem quase leva os desenvolvedores a escrever CSS de forma descuidada, a inserir tudo no código-fonte CSS. E a verdade é que o sistema se livrará de CSS desnecessário automaticamente. Mas isso priva completamente os desenvolvedores do desejo de entender exatamente como seus designs são estilizados, como exatamente CSS é usado neles.

Purgecss

PurgeCSS é outro projeto que visa combater CSS não utilizado. Embora isso não esteja diretamente relacionado às capacidades deste projeto, eu gosto disso porque sua documentação explica claramente suas diferenças em relação aos concorrentes. Acima, já fornecemos um fragmento de uma comparação entre PurgeCSS e PurifyCSS. E aqui está outro trecho da documentação do PurgeCSS dedicado ao PurifyCSS. O ponto é que o principal problema do PurifyCSS é a baixa modularidade desse projeto. No entanto, esse é o principal ponto forte do PurifyCSS. Como já mencionado, o PurifyCSS considera que as palavras CSS são todas as palavras encontradas nos arquivos. Essa abordagem está repleta de erros. Mas o PurifyCSS resolve esse problema, tornando possível criar funções de extrator. Essa função pega o conteúdo de um arquivo e extrai dele uma lista de seletores CSS usados ​​nele. Isso permite que você resolva muito bem o problema de se livrar do código CSS não utilizado.

O projeto PurgeCSS agora se parece com um participante importante no mercado de limpeza de código CSS. Muitos usam, muitos escrevem sobre isso.

• Aqui está o material sobre como usar o PurgeCSS, especialmente ao trabalhar com o Bootstrap.
• Neste artigo, você pode aprender que o PurgeCSS não removerá seletores em circunstâncias incomuns usando listas de permissões.
• Aqui você pode aprender sobre como o PurgeCSS é usado em conjunto com os scripts npm e com o PostCSS.
• Ele fala sobre como o PurgeCSS funciona com o Tailwind.

Apesar do PurgeCSS precisar de ajustes especiais para trabalhar com o Tailwind, parece que essas duas ferramentas estão perfeitamente combinadas. De fato, mesmo na documentação do Tailwind , você pode encontrar uma recomendação para compartilhá-los. E o PurgeCSS possui uma ferramenta de linha de comando para aplicá-la no processo de construção de projetos.

Acho que a essência disso se resume ao seguinte: Tailwind cria um grande arquivo CSS cheio de seletores auxiliares. Mas não se supõe que todos esses seletores serão usados ​​no projeto. O desenvolvedor os utiliza para resolver todos os problemas de estilizar seu código HTML e, em seguida, o PurgeCSS analisa esse código HTML e remove seletores desnecessários, formando o CSS pronto para produção.

É verdade que o PurgeCSS ainda precisa ser informado sobre cada arquivo HTML e JavaScript usado no site. Em outras palavras, você precisa configurar independentemente tudo o que está relacionado a recursos externos e levar em consideração o fato de que os dados que chegam a certos armazenamentos no projeto provavelmente não podem ser analisados ​​durante a montagem do projeto. Como resultado, o uso do PurgeCSS na montagem de projetos envolve uma quantidade considerável de trabalho manual.

Minha abordagem favorita para se livrar do CSS não utilizado

O que eu mais gosto é a seguinte abordagem para remover CSS desnecessário. Isso significa que haveria alguém na equipe de desenvolvimento do projeto muito familiarizado com o código CSS deste projeto. Essa pessoa deve estar ciente dos problemas atuais com os estilos e resolvê-los gradualmente. Talvez essa seja uma visão desatualizada da situação que pertence a uma pessoa que deve acompanhar os tempos. Mas para mim, de qualquer forma, parece a abordagem mais prática. Considerando que a tarefa que estamos considerando é tão difícil de resolver, acho que a resposta ao desafio que essa tarefa apresenta aos desenvolvedores pode ser um trabalho árduo. A resposta é uma compreensão do problema e sua solução gradual. Um desenvolvedor front-end que esteja familiarizado com o projeto e saiba o que é usado e o que não é, pode resolver esse problema.

Eu vi uma abordagem extrema para descobrir se um seletor de site é usado. O bloco CSS usou um design como background-image: url(/is-this-being-used.gif?selector); . Após a aplicação, os logs do servidor eram verificados periodicamente para descobrir se foi feita uma solicitação para receber a imagem correspondente. Se houve tal solicitação, o bloco CSS sob investigação é usado. Caso contrário, não será utilizado.

Mas talvez minha ferramenta favorita no kit de ferramentas CSS explorer não utilizado seja a que será discutida na próxima seção.

Estudo de projetos por regressão visual

Esse método consiste no fato de o desenvolvedor tirar o maior número possível de capturas de tela do site. Eles fazem cópias das telas das páginas mais importantes e dessas páginas cuja aparência depende do estado do aplicativo. As capturas de tela são feitas em diferentes navegadores, com diferentes tamanhos de tela. Essas capturas de tela são criadas com base nos materiais da ramificação master do repositório do projeto.

Antes de mesclar qualquer outra ramificação com a ramificação master , novas capturas de tela são criadas com base nos materiais da nova ramificação e comparadas com as feitas para a ramificação master . Obviamente, isso não é feito manualmente, mas por meio de programação.

A rigor, aqui está um vídeo em que é mostrado.

Deve-se notar que muito já foi dito sobre o tema das ferramentas para o estudo da regressão visual, mas o autor deste vídeo é a única pessoa que explicou tudo de maneira muito inteligível. Você não precisa apenas tirar screenshots; você precisa compará-los e procurar diferenças entre eles. É preciso não apenas encontrar diferenças; você precisa aceitá-los ou rejeitá-los. Além disso, é necessário que a adoção ou aprovação de mudanças afete o processo de mesclagem de ramificações nos repositórios. Além disso, o desenvolvedor deve poder configurar o navegador antes de tirar uma cópia da tela e a capacidade de automatizar o trabalho com as capturas de tela capturadas.

CSS atômico e CSS-JS

Tenho certeza de que muitos dos leitores deste material podem dizer: "Não tenho CSS não utilizado, pois as ferramentas que utilizo geram exatamente o código necessário e nada mais".

Se assim for, então isso é simplesmente maravilhoso.

Talvez estejamos falando sobre Atomizer . Talvez seja uma ferramenta Tachyons , cujos resultados são passados ​​pelo UnCSS e estão sendo cuidadosos. Talvez - essa é uma combinação do Tailwind + PurgeCSS , que agora é amplamente ouvido.

Talvez - eles ainda trabalhem com estilos de alguma forma. Se alguém vincula estreitamente componentes e estilos JavaScript, digamos, como ao usar React e Emotion, ou mesmo aplica apenas módulos CSS a qualquer coisa, uma das vantagens de tais abordagens CSS-in-JS é uma redução no volume de CSS não utilizado em projetos concluídos. Além disso, como muitos projetos baseados em JavaScript usam o algoritmo de agitação de árvores e a técnica de divisão de código, esses projetos não só terão CSS menos desnecessário. No decorrer de seu trabalho, apenas o necessário em cada situação específica será carregado. Mas, é claro, existem desvantagens em tais abordagens para trabalhar com CSS.

Sumário

Vamos agora pensar em como evitar a aparência de código CSS desnecessário em nossos projetos futuros. Acredito que o futuro do estilo é a separação entre estilos globais e estilos aplicados a componentes individuais. A maioria dos estilos é limitada ao escopo dos componentes, mas existem estilos globais que podem ser usados ​​para explorar a natureza em cascata do CSS. Por exemplo, pode ser algo como configurações tipográficas padrão globais.

Se a maioria dos estilos é limitada pelo escopo dos componentes, acho que os estilos desnecessários têm menos probabilidade de penetrar nos projetos concluídos, já que é fácil para um desenvolvedor se aprofundar nos relacionamentos entre pequenos e estreitamente relacionados fragmentos de HTML e CSS. E quando o componente é removido do projeto ou desenvolvido, a estilização sai do projeto ou se desenvolve com ele. Como resultado, os assemblies CSS são criados com base nos componentes realmente usados ​​no projeto.

A tecnologia CSS-in-JS está se movendo naturalmente nessa direção. Ao aplicar essas tecnologias, os estilos são vinculados aos componentes. E esta é a coisa mais importante neste caso. Mas vincular estilos a componentes é opcional. Eu gosto da abordagem universal, que envolve o uso de módulos CSS . O objetivo é quase completamente separar o escopo dos estilos e não força o desenvolvedor a usar nenhuma estrutura JavaScript específica.

Talvez todas as opções acima pareçam algo teórico ou distante das reais necessidades dos desenvolvedores da web. Você só tem um site que usa o Bootstrap e gostaria de reduzir o tamanho do CSS que os usuários deste site carregam. Nesse caso, aconselho que você use o código-fonte do Bootstrap em vez de sua compilação padrão. Esse código-fonte foi escrito usando SCSS e consiste em muitos plug-ins. Isso significa que, se você não precisar de algumas partes do Bootstrap, poderá simplesmente desativar os módulos correspondentes.


Removendo módulos suspensos, distintivos e trilhas de navegação do Bootstrap antes de criar um projeto

Desejo a todos boa sorte na difícil luta com códigos CSS desnecessários.

Caros leitores! Como você lida com o código CSS não utilizado que entra em produção?