Por que razão deve utilizar SCSS em vez de componentes estilizados?

Depois de comparar soluções populares, como CSS simples, Emotion, SCSS e Componentes com estiloPor fim, selecionei a última. Tudo parecia estar bem. Atualmente, tem uma biblioteca muito popular, o que significa
já existe uma grande comunidade, pelo que, se me deparar com algum problema, provavelmente encontrarei uma solução algures no Stack Overflow ou no GitHub. Para além disso, Componentes com estilo têm algumas caraterísticas de otimização, o que significa que só são apresentados quando são necessários. O projeto era esperado para ser construído utilizando React e Tipografia. Esta biblioteca tem um ótimo suporte para ambas as tecnologias. Parece fantástico, certo?

Nessa altura, comecei a programar. Passado um mês, quando a aplicação cresceu, o frontend equipa e eu concentrado em fornecer funcionalidades, descobrimos que o fantástico Componentes com estilo A biblioteca tinha o seu próprio objetivo e eu digo-vos porquê.

Em primeiro lugar, a convenção de nomes. Para diferenciar Componentes com estilo de componentes React, tive de utilizar o Com estilo prefixo que diminuiu código legibilidade. Depois (o que pode ser estranho), suporte Typescript. Componentes com estilocomo deves saber, são baseados na abordagem CSS-in-JS. Isto significa que se pode passar qualquer prop para eles e alterar o estilo, ou seja, o input com base nessa prop e, pessoalmente, acho que esta funcionalidade é espetacular. No Typescript, você também deve implementar o tipo dessa prop, o que torna o código mais longo que qualquer Componente estilizado. "Mas isso demoraria mais 5 segundos, então qual é o problema?" - pode dizer-se. Tem razão, embora quando a aplicação se expande rapidamente e o número de componentes é
aumentando, estes 5 segundos podem ser facilmente multiplicados por centenas de vezes. Outro problema é a colocação do Componentes com estilo.

Alguns Programadores JS colocam-nos no mesmo ficheiro com o componente a que pertencem, e outros criam ficheiros separados para eles. Ambas as abordagens são boas por muitas razões. Depende sobretudo da complexidade do componente. Seguir uma destas técnicas pode manter a coesão, mas fundi-las dá exatamente o contrário. Abandonámos a abordagem CSS-in-JS e migrámos para SCSS. Não foi fácil nem rápido, mas com uma pequena ajuda conseguimos. Começámos a estilizar as etiquetas html segundo a metodologia BEM e, claro, colocámos os estilos em ficheiros separados, um por componente. Eu disse que passar props JS para Componentes com estilo é uma funcionalidade fantástica, mas em SCSS é impossível. Penso que todos concordamos também que a sintaxe que o React pretende para codificar classes condicionais é horrível.

Bem, há uma solução bastante interessante. Se ligar a metodologia BEM com o clsx obterá algo como isto (um grande agradecimento ao meu amigo Przemek Adamczyk por me ter mostrado esta biblioteca)

Parece muito mais limpo, não acha?

O melhor é que só tem de escrever a variável de condição ao nível do componente e
não ao nível do estilo. Poupa realmente tempo. Infelizmente, esta solução tem os seus contras.
SCSS é fácil e amigável, mas tenha cuidado ao usá-lo com Next.js. Esta estrutura não
permitem importar ficheiros de estilo diretamente para o ficheiro do componente (apenas módulos CSS).

Se preferir um ficheiro por componente, tem de criar index.scss contendo todos os seus SCSS ficheiros e
importá-lo para o _app.tsx ficheiro. O único problema é que tem de importar manualmente cada ficheiro SCSS ficheiro que criou. No entanto, no React, este problema não existe e é possível importar SCSS ficheiros onde quiser. Não me interpretem mal. Componentes com estilo são muito bons. Como já referi, a passagem de variáveis JS, bem como o tema global, são funcionalidades fantásticas. Quando se constrói uma grande aplicação onde a otimização é crucial, esta biblioteca irá provavelmente satisfazer as suas necessidades. No nosso caso, porém, a migração para SCSS acertar no jackpot.

Resumo

Em conclusão, embora existam argumentos válidos para ambos SCSS e componentes estilizados em desenvolvimento web A decisão final depende de vários factores. SCSS oferece uma sintaxe mais familiar para programadores com experiência no CSS tradicional e proporciona uma integração perfeita com as bases de código e bibliotecas de componentes .

Por outro lado, Componentes com estilo oferecer uma melhor experiência de programador com a sua capacidade de encapsular estilos em componentes e simplificar o processo de criação de estilos. Também promove a modularidade e a reutilização do código, permitindo que o front-end engenheiros para gerir eficazmente o diretório de componentes e criar uma IU em todo o aplicação web . Considerando a importância da dados do utilizador segurança e desempenho, é crucial avaliar o impacto de ambas as abordagens no tamanho final do pacote e nos tempos de carregamento. Em última análise, a escolha entre SCSS e componentes estilizados deve basear-se nas necessidades específicas do projeto, no conjunto de competências do equipa de desenvolvimento e os objectivos globais do aplicação web . É aconselhável que os programadores avaliem todos os factores, se mantenham actualizados através de publicações no blogue e os debates no sector, e tomar uma decisão informada que se alinhe com os requisitos do seu projeto e melhore a front-end processo de desenvolvimento .