Nós, o front-end, temos uma categoria de ferramentas que não resolvem os problemas que estamos enfrentando, mas afetam o processo de resolvê-los. Mude isso. A atitude em relação a essas ferramentas é muito diferente - a partir da mania no espírito de "vamos empurrar essa coisa para todo lado, é muito legal" e termina com desculpas como "se não resolver o problema de negócios, não precisaremos disso". Mas, enfim, hoje falaremos sobre o PostCSS - uma dessas ferramentas.
A onda de hype passou muito tempo; nos últimos anos, muito pouco foi dito sobre o PostCSS. Muitos iniciantes nem sabem o que é. Acho que é hora de olhar para essa ferramenta do ponto de vista do uso prático nos projetos mais comuns, onde as pessoas resolvem problemas e não brincam com as tecnologias da moda.
PostCSS vs SASS
Oh ... Aparentemente, algumas palavras sobre isso. Acho que agora um tipógrafo raro não se encontra com pré-processadores. O SASS ou o meu LESS favorito, com menos frequência, são usados tanto em projetos grandes quanto em pequenos. Alguém está tentando tirar o máximo proveito deles, alguém usa um conjunto minimalista - aninhamento, variáveis, importações. Mas, de uma maneira ou de outra, essas ferramentas ajudam com problemas de sintaxe. Eles facilitam a escrita de código.
Cerca de dois ou três anos atrás, o PostCSS era constantemente comparado aos pré-processadores. E isso é compreensível. Formalmente, usando-o, você pode fazer a mesma coisa, criar algum tipo de sintaxe que será mais conveniente que o CSS puro. Mas tudo isso causou uma massa fervente, principalmente porque todos com a ajuda do PostCSS fizeram algo diferente. Inúmeros plugins desconhecidos, milhões de combinações e, além do autor desta ou daquela configuração, ninguém entendeu como funciona e o que faz. É como o Vim ou o Emacs - você pode criar uma espaçonave com eles, mas será muito difícil ensinar outro desenvolvedor a usá-lo.
Mas se descartarmos essas comparações, o PostCSS é uma ferramenta que nos permite pegar nosso CSS e fazer algo com ele. Ninguém se preocupa em usar o SASS por causa da sintaxe e, após a montagem, cole o PostCSS e faça algo com o resultado. Eles não se contradizem.
Velho não significa ocioso
Recentemente, foi moda para nós criar combinações que podem fazer tudo o que vem à mente e seu desenvolvimento nunca para. E se não houver confirmações novas no repositório por alguns meses, tudo - podemos assumir que está desatualizado e agora usá-lo - não comemos il faut. Exagerarei, é claro, mas acho que você percebeu o quão absurdo isso às vezes acontece.
No mundo PostCSS, geralmente um plugin resolve um problema. Você pode ver elementos da filosofia Unix aqui. Uma conclusão lógica se segue - se o plug-in já está resolvendo sua tarefa, nada mais precisa ser feito com ele. Você pode encontrar plug-ins que não são atualizados há anos, mas isso não significa que eles pararam subitamente de resolver as tarefas para as quais foram criados.
Mas vamos começar ... Eu montei uma dúzia de plug-ins, que na prática mostraram sua capacidade de simplificar a vida dos designers de layout e economizar tempo durante o desenvolvimento. Mas você sempre pode adicionar algo nos comentários.
No. 1. Doiuse
https://github.com/anandthakker/doiuse
Acho que todos enfrentamos esse problema: você escreve o código, verifica o chrome - está tudo bem. Você faz o check-in FF - aprox. E então, no Safari móvel, tudo desmorona. Ou no Edge. E você senta e não entende o que está errado. Então você fica olhando o código por um longo tempo, tomando chá e, de repente, percebe-se que algumas propriedades não são suportadas em algum navegador. Você segue em frente e vê a confirmação do óbvio.
Obviamente, com a experiência, as próprias mãos lembram quais propriedades devem ser evitadas, mas tudo acontece. Você não consegue dormir o suficiente, pode haver prazos e nervos apertados, a lista de navegadores que precisam ser alterados pode mudar. E então a experiência começará a falhar. Doiuse é uma ferramenta que ajuda muito nessas situações.
O princípio de operação é simples - fornecemos a ele uma lista de navegadores e nosso CSS. O plug-in vai para o banco de dados caniuse e em tempo real nos dá a resposta que usamos do que não é suportado.
Podemos definir a lista de navegadores diretamente no package.json. Simples e conveniente. O PostCSS usa a lista de navegadores e, se você ainda não viu, é algo parecido com isto:
"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ]
Há também uma configuração do douse em que você pode forçá-lo a ignorar alguns grupos de propriedades se tiver certeza de que isso não afeta nada. Por exemplo, se você usar polyfiles ou com a perda de suporte de alguma propriedade, nada será alterado:
ignore: [ 'will-change', 'object-fit' ]
O log padrão fornecido pelo plug-in não é muito legível. Ele contém muitas informações e não é muito conveniente percebê-las. Mas isso é corrigível. Na mesma configuração, podemos fazer nossa função para criar um log.
Use console.log para descobrir como o objeto que passa o PostCSS para essa função funciona. Há muitas coisas interessantes.
Minha prática mostrou que a opção mais conveniente é exibir seletores e propriedades específicas que não são suportadas, sem especificar navegadores e linhas de código. Se o projeto usa o BEM ou alguns análogos, e o código do componente é distribuído em arquivos separados, essa abordagem permite encontrar rapidamente um local problemático sem carregar o cérebro.
onFeatureUsage(info) { const selector = info.usage.parent.selector; const property = `${info.usage.prop}: ${info.usage.value}`; let status = info.featureData.caniuseData.status.toUpperCase(); if (info.featureData.missing) { status = 'NOT SUPPORTED'.red; } else if (info.featureData.partial) { status = 'PARTIAL SUPPORT'.yellow; } console.log(`\n${status}:\n\n ${selector} {\n ${property};\n }\n`); }
Para não escrever seqüências especiais de caracteres para cores no console, você pode conectar o pacote de cores , será mais conveniente.
Ao criar, haverá algo parecido com isto no console:
NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }
No. 2. Autoprefixer
https://github.com/postcss/autoprefixer
É até embaraçoso falar sobre ele, mas muitas vezes vejo pessoas que em 2019 escrevem prefixos com as mãos e ainda asseguram aos outros que sabem exatamente quais são necessários e quais não são. Tais ações levam ao fato de que o código está cheio de vários prefixos desnecessários e se torna completamente ilegível. Isso afeta a produtividade do trabalho. Por outro lado, se você precisar do apoio de dinossauros, sempre poderá esquecer algo. Portanto, vale a pena se livrar do trabalho manual ao resolver esse problema.
O autoprefixer funciona com o mesmo banco de dados caniuse, usa a mesma lista de navegadores e pode adicionar ao CSS os prefixos realmente necessários nos navegadores especificados. Ao mesmo tempo, o próprio código fica mais limpo e o trabalho é mais rápido.
Número 3. Stylelint
https://github.com/stylelint/stylelint
Quando você imprime muito e rapidamente, mais cedo ou mais tarde você começa a cometer muitos erros sem notá-los completamente. O olho está embaçado. No caso do CSS, isso pode dar um efeito engraçado (na verdade não) quando você olha no navegador - você vê um problema com o layout. Você olha o código - ele não está lá. Você olha no navegador - é. Mas no código - não. Como resultado, você pode procurar um problema difícil por um longo período de tempo, sem perceber que acabou de entender. Para evitar isso, inventou a linter.
Stylelint é uma opção popular. Ele sabe trabalhar com a sintaxe dos principais pré-processadores, conhece as últimas tendências em CSS, pode personalizá-lo a seu gosto - as configurações são semelhantes às do eslint. Formalmente, essa ferramenta pode ser usada por si só, sem PostCSS, mas sem mencionar aqui, seria errado.
Número 4. Postcss-flexbugs-fixes
https://github.com/luisrudge/postcss-flexbugs-fixes
Ou em um sentido mais amplo, postcss-fixes , que inclui este plugin. Lentas, mas seguramente, as flexões suplantam a antiga abordagem do layout em carros alegóricos. Isso é bom, mas todos sabemos que muitos bugs estão associados a eles. Eles são descritos no repositório flexbugs . Alguns deles requerem atenção especial, mas há também alguns que são tão simples que constantemente saem da sua cabeça. Por exemplo, o IE ignora a função calc na abreviação da propriedade flex. Isso nem sempre é necessário, mas, se necessário, suas mãos podem escrever uma versão resumida e você precisa pensar por um longo tempo qual é o problema. Felizmente, isso pode ser corrigido automaticamente. O plug-in postcss-flexbugs-fixes vem ao resgate.
No exemplo do calc, ele encontrará fragmentos como este no código:
.foo { flex: 1 0 calc(1vw – 1px); }
E implante-os:
.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); }
Simples e conveniente.
No. 5. Postcss-preset-env
https://github.com/csstools/postcss-preset-env
Como estamos falando de suporte ao navegador, não será impróprio dizer sobre postcss-preset-env. Anteriormente, o cssnext desempenhava o mesmo papel. Este plugin será útil se você estiver interessado em novas tendências em CSS.
Muitas das inovações podem ser tecnicamente implementadas usando os métodos antigos; ela será simplesmente longa, detalhada e feia. O preset-env ajuda você a escrever código de uma nova maneira, economizar tempo com isso e convertê-lo para uma versão confiável antiga. Obviamente, algumas coisas, como propriedades personalizadas, não são implementadas em navegadores antigos, portanto, as fallbacks serão usadas lá.
Como você pode imaginar pelo nome do instrumento, ele se parece com o mesmo nome predefinido em Babel. Aqui, tudo é o mesmo - existem muitos conversores montados em um conjunto estável. Algumas transformações requerem conexão subseqüente de scripts polyphile no cliente, mas a maioria é implementada apenas por CSS. Tanto quanto eu entendo, para scripts Stage2 + não são necessários. De qualquer forma, não encontrei a necessidade deles. Corrija-me se eu perdi alguma coisa lá.
No. 6. Postcss-animation
https://github.com/zhouwenbin/postcss-animation
Frequentemente, ouço de pessoas diferentes (principalmente back-end que não são muito fortes em CSS) que desejam usar animações separadas do animate.css , mas considero uma má idéia conectar toda a biblioteca. É bastante lógico. Mas, como resultado, eles passam muito tempo tentando repetir essas animações por conta própria.
O plug-in postcss-animation acelera bastante esse processo. Escrevemos apenas o nome da animação, por exemplo:
.foo { animation-name: bounce; }
E ele pega a implementação do animate.css e a insere no código.
.foo { animation-name: bounce; } @keyframes bounce { from, 20%, 53%, 80%, to { animation-timing-function: cubic-bezier(0.215, 0.610, 0.355, 1.000); transform: translate3d(0,0,0); } 40%, 43% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -30px, 0); } 70% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -15px, 0); } 90% { transform: translate3d(0,-4px,0); } }
Número 7. Seletores de lista
https://github.com/davidtheclark/list-selectors
Quando você tem vários tipógrafos e muitos estilos, surge a questão da revisão de código, que seria bom, às vezes, ver com seus olhos o quadro geral com todos os seletores que temos. Saiba quais IDs são usados, se existem seletores de tags ou quão bem a metodologia aceita está sendo seguida. Isso é especialmente importante quando você verifica o código do iniciante, que pode escrever coisas estranhas que funcionarão formalmente, mas na verdade contraria os acordos aceitos (longe de qualquer lugar, esses acordos são bem fixos e há uma oportunidade de automatizar essas coisas). Percorra várias folhas de estilo para verificar a adequação dos seletores por um longo tempo. Precisamos de uma maneira de isolá-los e mostrá-los separadamente. Os seletores de lista apenas resolvem esse problema.
Assim como doiuse, este plugin permite que você use sua função para preparar informações para exibição. Você pode exibir apenas o que lhe interessa ou pintar tudo em cores diferentes. Como exemplo:
require('list-selectors').plugin((list) => { const inspect = require('util').inspect; console.log('SELECTORS:'.blue); console.log(inspect(list.selectors, { maxArrayLength: null }).blue); console.log('IDS:'.red); console.log(inspect(list.simpleSelectors.ids, { maxArrayLength: null }).red); })
Este exemplo produz uma lista longa e longa de seletores:
SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . .
Número 8. Immutable-CSS
https://github.com/johno/immutable-css
Outra coisa a observar é interromper estilos de bibliotecas de terceiros. Se conectamos algum tipo de biblioteca e depois começamos a escrever nossos próprios estilos para seletores, então no final obtemos um código confuso no qual não conseguimos entender o que veio. Isso pode levar a erros aleatórios, que levam muito tempo do nada. Quanto mais vezes redefinimos algo, mais difícil é finalmente entender o que está acontecendo, embora o problema em si que precise ser resolvido possa ser muito simples. Nessa situação, uma ferramenta chamada immutable-css pode ser útil.
Em geral, o princípio de seu trabalho é simples: ele pega arquivos com estilos; se encontra correspondências nos seletores, começa a ficar indignado:
! .button was mutated 2 times [line 93, col 1]: /css/basscss.css [line 3, col 1]: /css/custom.css [immutable-css] ! .left was mutated 2 times [line 291, col 1]: /css/basscss.css [line 4, col 1]: /css/custom.css [immutable-css]
O único problema com esta ferramenta é que ela não suporta sintaxe não CSS. Portanto, se pré-processadores forem usados no projeto, os arquivos já montados deverão ser comparados. Mas, em geral, se a tarefa é simplesmente garantir que ninguém reescreva acidentalmente os estilos de uma biblioteca de terceiros, isso não é tão importante.
No. 9. Tchau-tchau!
https://github.com/AoDev/css-byebye
Acho que todos estão familiarizados com a situação quando adicionamos gradualmente alguns componentes a um site de trabalho. Alguns deles vão imediatamente para a produção e outros ficam por um longo tempo e aguardam a sua vez (por exemplo, criamos, ainda não terminamos o back-end). Algo pode ser um experimento ou uma solução temporária para os feriados. Pode haver muitas situações, mas elas são unidas pelo fato de termos vários componentes e apenas uma pequena parte deles é usada no local de combate. Seria bom remover tudo o que não é usado da montagem atual. Isso pode reduzir significativamente seu tamanho, bem como reduzir uma dor de cabeça no futuro, quando será necessário fazer um redesenho, por exemplo, e a pergunta será: o que realmente precisa ser reescrito agora e o que não é.
Existem diferentes abordagens para esse problema. Uncss vem imediatamente à mente . Essa ferramenta detecta automaticamente quais estilos são usados nas páginas e remove os desnecessários. Mas, na prática, isso quase sempre leva ao fato de que ninguém sabe o que realmente está sendo usado e o que não é. Também duvido o tempo todo se essa ferramenta excluiu algo supérfluo. Mas esta é provavelmente a minha paranóia. Embora ...
Bye-bye é uma ferramenta mais simples que alimentamos uma lista de seletores para remover do CSS. E você pode usar expressões regulares. Se você usa o BEM ou algo assim, com um simples regular, você pode excluir um bloco com tudo o que estiver relacionado a ele. Tchau-tchau!
Essa abordagem acabou sendo bastante conveniente. Fica imediatamente claro quais estilos ainda não foram usados ou foram removidos como desnecessários, enquanto todas as fontes estão no lugar, todas as configurações em um arquivo, nada é perdido, não causa dificuldades para fazer várias montagens diferentes e, o mais importante, a solução é simples e previsível.
No. 10. Postcss-trolling
https://github.com/juanfran/postcss-trolling
Todas as ferramentas anteriores podem aumentar levemente a produtividade de seus designers de layout, mas essa fornece resultados simplesmente fenomenais. Eu recomendo.
Conclusão
O PostCSS é uma boa ajuda para um designer de layout. Se eles não são abusados, é claro. Para muitos problemas demorados, existem soluções prontas na forma de plug-ins e, embora muitas vezes não se desenvolvam e pareçam abandonadas, isso não interfere no seu uso.