O CSS-in-JS , por não ser uma tecnologia completamente nova e implementada em muitas bibliotecas , ainda levanta dúvidas e debates sobre a adequação de seu uso. Gajus Kuizinas , autor de react -css-modules e babel-plugin , destacou o “i” em disputas sobre CSS-in-JS em geral, e sobre componentes de estilo em particular, há um ano (27 abr 2017) -react-css-modules , na publicação atual ainda na minha opinião "Pare de usar CSS-in-JavaScript no desenvolvimento da web" .
A seguir, uma tradução ligeiramente abreviada com algumas adições e conclusões:
CSS não vai a lugar algum . Em muitos projetos, a escolha do estilo no JavaScript está errada. Listaremos equívocos comuns (mitos) e suas decisões correspondentes por meio do CSS.
Histórico de Css e JavaScript
CSS foi criado para descrever a apresentação de um documento escrito em uma linguagem de marcação. O JavaScript foi criado como uma "cola de linguagem" para montar componentes como imagens e plugins. Ao longo dos anos, a JS cresceu e mudou, adaptando-se a novas áreas de aplicação. E, como resultado, hoje vivemos na era dos aplicativos de página única (SPA), aplicativos montados a partir de componentes.
E o CSS?
Aqui está uma citação da documentação dos componentes denominados :
O problema do CSS comum é que ele foi criado em uma época em que a web era composta de documentos. A Web foi criada para trocar documentos predominantemente científicos em 1993 e o CSS foi introduzido como uma solução para estilizar esses documentos. No entanto, hoje estamos desenvolvendo aplicativos desenvolvidos, interativos e orientados ao usuário, e o CSS simplesmente não foi projetado para isso.
Isto não é verdade.
O CSS já leva em consideração todos os requisitos das interfaces de usuário modernas. O número de novas funções implementadas na última década é tal que é impossível listá-las todas (pseudo-classes, pseudo-elementos, variáveis CSS, consultas de mídia, quadros-chave, combinadores, colunas, flex, grid, valores computados, ...).
Do ponto de vista da interface do usuário, "componente" é um fragmento isolado do documento (<botão /> é "componente"). O CSS foi projetado para estilizar documentos, e o documento cobre todos os componentes. Qual é o problema?
Como diz o ditado: "Use a ferramenta certa para o trabalho".
Componentes estilizados
componentes estilizados torna possível escrever CSS em JavaScript usando o chamado cadeias de modelo com tags . A biblioteca remove o mapeamento entre componentes e estilos - o componente se transforma em uma construção de estilo de baixo nível, por exemplo:
// Create a <Title> react component that renders an <h1> which is // centered, palevioletred and sized at 1.5em const Title = styled.h1` font-size: 1.5em; text-align: center; color: palevioletred; `;
O styled-components é popular hoje em dia e é conhecido como uma nova maneira de estilizar componentes no React, embora às vezes seja apresentado como o "pináculo do desenvolvimento de CSS":
Evolução do CSS: dos módulos CSS, SASS, BEM, CSS aos componentes com estilo .
Mas vamos esclarecer o seguinte: componentes com estilo é apenas um complemento de CSS. Esta biblioteca analisa os estilos CSS definidos em JavaScript e cria os elementos JSX apropriados.
A popularidade dos componentes estilizados é repleta de muitos conceitos errados. Uma revisão das respostas dos programadores (encontradas no IRC, Reddit e Discord) a uma pergunta sobre os motivos que os levaram a usar essa biblioteca tornou possível fazer uma lista dos mais mencionados. Vamos chamá-los de mitos.
Mito 1: componentes estilizados resolvem problemas globais de namespace e conflitos de estilo
Isso é um mito, porque parece que o problema supostamente mencionado ainda não foi resolvido. No entanto, Módulos CSS , Shadow DOM e inúmeras convenções de nomenclatura (como o BEM ) ofereceram soluções para o problema há muito tempo.
styled-components (assim como os módulos CSS) remove a questão da responsabilidade de nomear uma pessoa. É da natureza humana cometer erros; os computadores cometem erros não com tanta frequência.
Por si só, esse não é um motivo suficientemente bom para usar componentes estilizados.
Mito 2: O uso de componentes com estilo torna possível obter um código mais compacto.
Em apoio a isso, muitas vezes dê um exemplo:
<TicketName></TicketName> <div className={styles.ticketName}></div>
Primeiro de tudo, isso não importa. A diferença é insignificante.
Em segundo lugar, isso não é verdade. O número total de caracteres depende do nome do estilo.
<TinyBitLongerStyleName></TinyBitLongerStyleName> <div className={styles.longerStyleName}></div>
O mesmo se aplica à criação de estilos, que veremos mais adiante neste artigo.
(Mito 5: componentes estilizados facilita o estilo condicional dos componentes). os componentes denominados vencem em concisão apenas nos casos dos componentes mais básicos.
Mito 3. O uso de componentes estilizados faz você pensar mais em semântica.
A mensagem original em si está incorreta. Estilização e semântica são problemas diferentes e requerem soluções diferentes. Leia, por exemplo, este é Adam Morse (mrmrs) .
No entanto, considere:
<PersonList> <PersonListItem> <PersonFirstName>Foo</PersonFirstName> <PersonLastName>Bar</PersonLastName> </PersonListItem> </PersonList>
A Semântica lida com o uso das tags corretas para marcação. Você sabe quais tags HTML serão usadas para renderizar esse componente? Não, você não sabe.
Compare:
<ol> <li> <span className={styles.firstName}>Foo</span> <span className={styles.lastName}>Bar</span> </li> </ol>
Mito 4: É mais fácil expandir estilos.
Compare:
const Button = styled.button` padding: 10px; `; const TomatoButton = Button.extend` color: #f00; `;
Ótimo! Mas você pode fazer o mesmo em CSS (ou usar a composição do módulo CSS, bem como a herança SASS mixin @extend).
button { padding: 10px; } button.tomato-button { color: #f00; }
E quanto mais simples a primeira opção?
Mito 5: Estilo condicional facilitado de componentes
A ideia é que você possa estilizar elementos usando adereços, por exemplo:
<Button primary /> <Button secondary /> <Button primary active={true} />
Isso faz sentido no React. No final, o comportamento do componente é controlado por meio de adereços. Faz sentido vincular diretamente valores de prop a estilos? Talvez. Mas vamos dar uma olhada na implementação de tal componente:
styled.Button` background: ${props => props.primary ? '#f00' : props.secondary ? '#0f0' : '#00f'}; color: ${props => props.primary ? '#fff' : props.secondary ? '#fff' : '#000'}; opacity: ${props => props.active ? 1 : 0}; `;
Criar estilos condicionais usando JavaScript oferece inúmeras possibilidades. No entanto, isso também significa que os estilos serão muito mais difíceis de interpretar. Compare com CSS:
button { background: #00f; opacity: 0; color: #000; } button.primary, button.seconary { color: #fff; } button.primary { background: #f00; } button.secondary { background: #0f0; } button.active { opacity: 1; }
Nesse caso, o CSS é mais curto (229 caracteres versus 222) e mais fácil de entender (subjetivamente). Além disso, em CSS, você pode usar um pré-processador para obter um resultado ainda mais curto e agrupado:
button { background: #00f; opacity: 0; color: #000; &.primary, &.seconary { color: #fff; } &.primary { background: #f00; } &.secondary { background: #0f0; } &.active { opacity: 1; } }
Mito 6: Organização do código melhora
Alguns dizem que gostam de componentes estilizados, porque é possível colocar estilos e scripts em um arquivo. Você pode entender que ter vários arquivos para um componente pode parecer entediante, mas colocar estilos e layout em um único arquivo é terrível. Este sistema de controle de versão não apenas complicará as alterações de rastreamento, mas também levará a uma "rolagem" infinita em qualquer elemento mais complicado do que um simples botão.
Se você certamente precisa colocar CSS e JavaScript no mesmo arquivo, tente css-literal-loader . O último permite que você crie estilos durante a compilação usando o extract-text-webpack-plugin e use a configuração padrão do carregador para lidar com CSS.
Mito 7: "Developer Experience (DX)" está ficando ótimo. A ferramenta é incrível!
Obviamente você não usou componentes estilizados.
- Se algo desse errado com os estilos, o aplicativo inteiro trava com um longo rastreamento da pilha do erro. O oposto disso é CSS, onde um erro nos estilos simplesmente levará a uma exibição incorreta do elemento.
- Os elementos não possuem className distinguível; portanto, durante a depuração, você terá que alternar infinitamente entre a árvore de elementos React e a árvore DOM do DevTools.
- Embora já existam plug-ins para linting, destaque de código, conclusão de código e outros "encantos" semelhantes para componentes estilizados, eles ainda podem não estar disponíveis para o seu IDE. Se você trabalha com finanças em uma agência governamental, há uma chance de o IDE Atom não estar disponível.
Mito 8: Tudo se torna "mais rápido", tudo se torna "mais fácil"
- Como se viu, os estilos de componentes com estilo não podem ser extraídos em estática
Arquivo CSS (por exemplo, usando extract-text-webpack-plugin ). Isso significa que o navegador não poderá começar a interpretar estilos até que os componentes denominados os analisem e os adicionem ao DOM. - Combinar estilos e scripts em um arquivo significa que o cache separado não é possível.
- A natureza dos componentes estilizados é tal que todos eles são envolvidos em HOC adicional. E isso é uma diminuição desnecessária no desempenho. A mesma falha levou à descontinuação de react-css-modules e ao aparecimento de babel-plugin-react-css-modules .
- Devido ao mesmo HOC , a renderização no servidor resulta em tamanhos de marcação de documento significativamente maiores.
- Nem tente animar componentes usando estilos dinâmicos em vez de quadros-chave.
Mito 9: Existe a possibilidade de desenvolver componentes "responsivos"
Estamos falando da capacidade de estilizar um componente com base no ambiente, por exemplo, o tamanho do contêiner pai, o número de herdeiros etc.
Antes de tudo, os componentes estilizados não têm nada a ver com isso.
Isso está além do escopo do projeto. Nesse caso, é melhor definir diretamente os valores do estilo do componente para evitar cargas adicionais do processador.
Espere um minuto, no entanto!
Muitos desses problemas, se não todos, podem ser resolvidos a longo prazo pela comunidade, por alterações no React ou nos próprios componentes estilizados. Mas porque? O CSS já é amplamente suportado, existe uma comunidade sólida e ... simplesmente funciona.
Mas você não deve sempre evitar o uso de CSS-in-JavaScript ou componentes estilizados.
Há algo que faz dos componentes estilizados uma boa biblioteca - este é o melhor suporte para várias plataformas.
Apenas não use componentes estilizados com base em representações errôneas.
Um par de opiniões das partes interessadas.
Usando componentes estilizados em nosso projeto, descobrimos que existem algumas regras de estilo difíceis de implementar em componentes estilizados; por exemplo, regras que controlam o posicionamento de elementos em uma página (margens ou propriedade de exibição). Como era difícil padronizar, ainda tínhamos que confiar muito em CSS simples para colocar componentes no fluxo de elementos.
... embora houvesse dificuldades no uso de componentes com estilo, a biblioteca nos ajudou a reduzir a base de código.
(comentário sobre “Evolução do CSS: de CSS, SASS, BEM e CSS - módulos a componentes estilizados” )
... Nenhuma evolução do CSS aqui significa que as ferramentas evoluem.
Na minha opinião, não há problema quando a composição está envolvida no layout e o programador está envolvido na programação.
Mas quando os programadores estão envolvidos na digitação, todo esse zoológico começa, o que, em vez de SIMPLICITY com mais suporte, causa uma dor de cabeça extra.
...
Escreva em CSS puro e dê às ferramentas o papel de um espaço para nome e de um coletor - então tudo ficará feliz ...
E, finalmente, uma palavra ao autor:
Gajus Kuizinas: - Então, o que, afinal, usar?