Esta postagem é uma resposta detalhada às perguntas desta conversa no Twitter . O autor do original, Sunil Pye, é o autor da relativamente popular biblioteca de glamour e trabalha como desenvolvedor no Facebook.
Como o Javascript é mais conveniente que o CSS? Como escrever CSS dentro de JS o torna mais suportado?
Ficarei feliz em falar sobre esse tópico. Devo dizer imediatamente que as soluções CSS-in-JS têm custos indiretos, mas geralmente esse preço é justificado pelas vantagens que elas trazem. Às vezes, eles podem ser úteis, mas também isso não significa que o CSS-in-JS deva ser usado sempre e em qualquer lugar.
Portanto, o mais importante em CSS-in-JS (cij) são os seletores de CSS. A maior vantagem do cij é que os computadores podem gerar esses seletores automaticamente. Convenções como OOCSS, etc. em princípio, eles são bons, mas são baseados em seletores manuscritos, difíceis de garantir exclusividade no espaço para nome comum, porque sempre há uma chance de interseção. Se isso não acontecer agora, poderá ocorrer após três anos, quando sua equipe crescer e as circunstâncias mudarem. Essa situação é exacerbada usando bibliotecas de terceiros. A limitação do escopo dos seletores de CSS também pode ser alcançada usando os módulos CSS , que são populares precisamente para esta oportunidade.
No entanto, com todas essas abordagens, os seletores são muito difíceis de analisar estaticamente e descobrir quais estão quebradas (ou contêm erros de digitação), o que significa que elas terão que ser verificadas manualmente no processo de revisão de código, o que reduzirá a eficácia do comando. Devemos usar a ajuda dos computadores e não confiar na integridade e na perfeição das pessoas (porque não é assim). O CSS-in-JS torna possível automatizar a geração de seletores e identificadores exclusivos.
Além disso, o controle aprimorado sobre os seletores de CSS abre novas possibilidades que antes não eram facilmente acessíveis. Por exemplo, podemos simplesmente implementar a extração crítica de CSS combinando blocos HTML com os estilos de que eles precisam, para que possamos carregar apenas 1-2 Kb de CSS na página, o que é necessário para a exibição inicial da página. Sem qualquer tempo de execução! Estruturas como Gatsby e Next usam ativamente isso para melhorar os indicadores de desempenho em projetos baseados neles. Eles incorporam CSS crítico diretamente no HTML para download simplesmente porque pesa tão pouco que seria melhor do que uma solicitação extra bloqueando o carregamento da página. Isso reduz bastante o tempo de renderização da página inicial. Além disso, também contribui para resolver os problemas de tamanho Javascript para download! Os benefícios vêm da aplicação de CSS crítico, bem como do uso de import() dinâmica import() , divisão de código e remoção de código não utilizado. (Em contraste com os arquivos de estilo Legacy, sempre crescentes, nos quais os desenvolvedores adicionam apenas um novo código, com medo de tocar no existente. Há um pouco de análise sobre este tópico .)
Uma situação semelhante com a implementação de temas. Você sabia que as variáveis CSS , mesmo sendo uma coisa muito interessante, não foram para os casos de uso para os quais foram originalmente planejadas, e tudo porque os métodos de fallback para navegadores antigos eram muito complicados ou inferiores? Isso significa que eles geralmente são usados como constantes globais, mas muito raramente como variáveis cujo valor é determinado dinamicamente no navegador. Ter um tempo de execução CSS CSS significa que você pode passar valores de JS para estilos, tornando isso possível.
De fato, você vai gostar: você pode finalmente usar honestamente variáveis CSS em todos os navegadores, ou seja, recursos nativos sem tempo de execução nos navegadores que as suportam e um tempo de execução especial para navegadores mais antigos. (Escrevi mais sobre isso aqui e, se entendi corretamente, essa é a única biblioteca que conseguiu isso).
Em uma situação complexa do SPA com vários componentes e carregamento assíncrono de recursos, como scripts e estilos, você não pode garantir a ordem exata dos estilos de carregamento; portanto, é necessário criar algum tipo de solução de tempo de execução para garantir a ordem dos estilos ou apenas usar !important se você se ater a algum tipo de metodologia CSS . Por exemplo, você tem um elemento com class=“ab” , mas as classes a e b definidas em arquivos de estilo diferentes, então você não pode ter certeza da forma final do bloco se não tiver uma ordem de sequência clara dos arquivos de estilo. A base de código do Facebook contém milhares de usos do !important , mesmo que o código tenha sido escrito por programadores qualificados usando os princípios do SOLID e boa interação com a equipe de design.
Isso geralmente se refere ao tratamento de CSS como se fosse Javascript - já que há 10 anos já estávamos resolvendo problemas semelhantes para JS - as bibliotecas e módulos se registravam no espaço de nomes global ( $ e similares) e tínhamos que ter bastante cuidado com a ordem de conexão scripts em HTML. Mas não ficamos presos ali para sempre - agora usamos módulos e os sistemas de montagem os costuram em uma ordem correta garantida. Isso é simples e transparente para nós.
Observando projetos reais, notei também que você ainda pode usar abordagens arquiteturais tradicionais (como OOCSS ou SMACSS etc.) no mundo do CSS-in-JS - os elementos dessas arquiteturas são representados aqui por objetos JS, em vez dos blocos seletores + estilos. Eu adoto essa abordagem e ela funciona bem para mim. Aqui você pode ler mais sobre isso.
Também estou ciente das desvantagens do CSS-in-JS. De fato, é exatamente por isso que não existe uma biblioteca “canônica” que represente CSS-in-JS - é um espectro de soluções diferentes, de CSS estático baunilha, por um lado, a bibliotecas totalmente dinâmicas, como componentes estilizados, por outro. Pré-processadores como SASS ou LESS podem parecer perpendiculares a esse espectro, porque teoricamente podem ser usados por qualquer uma dessas bibliotecas, a critério de seus autores. Cada uma dessas bibliotecas tem suas desvantagens - algumas estão envolvidas na extração de estilos no estágio de montagem, para que não haja despesas no tempo de execução, outras focadas na correção ou conveniência dos desenvolvedores, outras focadas na implementação efetiva de animações complexas e assim por diante. Essa diversidade é uma reação natural à necessidade de diferentes soluções para diferentes tarefas de trabalho, em um setor de rápido crescimento. E isso acontece não apenas com as bibliotecas - os desenvolvedores de padrões da Web (ShadowDOM e outros) também tentam resolver esses problemas, mas sua solução também apresenta desvantagens, a menor das quais é que elas ainda não estão disponíveis em todos os lugares, o que a torna inaceitável para uso. em muitas equipes.
Eu costumava ter sentimentos fortes sobre isso, mas temperei minhas opiniões nos últimos meses. Acontece que a verdade está em algum lugar no meio - depende das equipes, requisitos, tempo, documentação e muitos outros fatores. Além disso, não creio que este texto represente a “forma final” dessa idéia. Deveríamos incentivar a experimentação nessa área para descobrir o que mais podemos fazer melhor e até incorporar algumas dessas coisas nos navegadores.
PS Tarde demais, percebi que esqueci de marcar a caixa "Tradução", então foi publicada assim. Link para o original .
Habr, conserte a interface, por que você não pode adicionar o sinalizador de tradução após a publicação?