Qual é a pergunta?
Olá pessoal, hoje quero compartilhar com vocês minha experiência pessoal em escrever estilos, ou mais, simplesmente colocar minha visão sobre o problema de escrever css para sites.
Parece que na era do desenvolvimento tecnológico, quando todos os dias nos deparamos com novas e novas estruturas, pré-processadores, mecanismos de modelo e outras coisas, os problemas não devem surgir. Desenvolvedores inteligentes criaram um monte de "recursos" interessantes para a conveniência de criar sites poderosos e expansíveis. Mas como usar essas ferramentas corretamente em CSS? E quais são as dificuldades?
Tentarei responder a essas e outras perguntas sugerindo meus métodos e abordagens para resolver alguns problemas.
Realidade dura
Não será segredo para ninguém que os desenvolvedores iniciantes e experientes de front-end geralmente recebem projetos prontos nos quais você precisa fazer alterações, refazer o design e assim por diante. Na minha prática, havia muitas dessas tarefas quando você trabalha com o código de outra pessoa, das quais precisa se aprofundar e entender. E se um site pronto cair em suas mãos, abra uma folha de estilo e esteja preparado para ver
milhares de linhas de código .
É claro que você, como desenvolvedor experiente, irá abri-lo em algum tipo de IDE, como o Visual Studio Code e, com um leve aceno de sua mão através da função de pesquisa e substituição, poderá encontrar e reescrever facilmente qualquer classe.
Mas se você precisar fazer uma quantidade decente de edições integrando parte do novo design em algumas seções, quanto tempo você
gastará nisso ?
Eu penso
muito E tudo o que você fizer será levemente "inútil". Imagine uma situação em que o site que você remodelou é transferido para outro desenvolvedor ou depois de algum tempo, é solicitado que você faça
novas alterações lá .
SASS resolverá nossos problemas
Depois de digerir todas essas informações, um desenvolvedor web típico diz que está fora da situação: use pré-processadores CSS. Lá e modularidade e conforto e tudo.
Claro! Mas qualquer ferramenta nas mãos de um programador inexperiente perde todo o significado. Às vezes, você abre os estilos do site e vê a pasta estimada com o nome "sass". Esperar um milagre na maioria das vezes você só fica decepcionado.
Divisão de estilos em arquivos separados: header.sass, main.sass, animation.sass, etc. Quão "brilhante" é. E não é eficaz. Ao abrir o próximo arquivo, você encontra o mesmo monte de linhas de estilo.
Quais são as alternativas?
É melhor ficar calado sobre como os desenvolvedores chamam suas classes às vezes, bem como sobre cadeias de aninhamento de estilos. Acho que todo mundo que se virou nessa área ouviu algo sobre o BEM e entende a importância de nomear corretamente as classes. Com isso, vale a pena começar
a resolver todos os problemas.Ofereço a você uma abordagem especial, uma metodologia especial para desenvolver seus estilos, mas não sem a ajuda de pré-processadores. Existem várias etapas para implementar essa metodologia:
- A primeira , como você já entendeu, é a nomeação adequada de suas classes.
- O segundo é se livrar dos estilos de aninhamento. Aqui a metodologia BEM nos ajudará. Depois de se familiarizar com o básico desta documentação maravilhosa, você pode prosseguir para a próxima.
- SASS - sem esta ferramenta de forma alguma. É ele quem garante a modularidade e o poder do seu projeto.
- Montagem do projeto. Eu acho que você já ouviu muito sobre montadores modernos (há muita informação sobre a criação de um projeto na Internet). Gulp nos ajudará aqui .
Agora você está pronto.
Agora essencialmente
Na interpretação moderna do frontend, você pode encontrar algumas estruturas javascript. A maioria deles divide o site em partes menores, componentes. Sugiro que você faça o mesmo ao pensar em como escrever estilos. Cada botão, item de menu, link bonito, figura e até texto sem formatação podem ser um componente.
Por exemplo, nesta forma de entrar no site, podemos distinguir vários componentes:
- Formulário de login em si
- Campos de entrada
- Botão Enviar
- Caixa de seleção
E, como mostra a prática, além do botão de envio no site, haverá muitos outros botões e seria lógico manter todos os estilos para eles em um só lugar. O mesmo pode ser dito sobre os campos de entrada, eles podem estar em diferentes locais do site, repetindo sua aparência.
Com base nisso, será lógico criar uma pasta separada para cada componente e manter os estilos somente nele, o que permitirá implementar uma abordagem modular. Mas isso não é tudo.
Componentes internos
Como eu disse, pode haver muitos botões em um site, com cores diferentes, recuos diferentes, tudo isso são dados e é muito inteligente separar esses dados dos estilos. O que eu proponho fazer.
Proponho apresentar cada componente na forma de três entidades: vars, maker e creater. Em termos simples, são dados, um criador de ações (métodos para gerenciar esses dados) e um criador de estilos. Agora, as primeiras coisas primeiro.
- Dados ou vars. Eles incluem: cor do texto do botão, cor do fundo do botão, preenchimento, raio da borda, tamanho da fonte etc. Todos esses dados são gravados na forma de variáveis ou uma matriz associativa em um arquivo separado.
- Criador ou criador de ações. Ele contém várias funções ou mixins que receberão os dados como argumentos e gerarão estilos a partir deles.
- Criador ou criador de estilos. Na verdade, aqui importamos dados e métodos para nós mesmos e os vinculamos conforme necessário.
O diagrama a seguir mostra a interação das três entidades.
É difícil colocar tudo isso na sua cabeça? Considere o exemplo da criação do componente básico de um botão - "botão". Usaremos o SCSS como pré-processador.
Como você já entendeu, na nova pasta de botões, criamos três arquivos: _vars.scss, _cength.scss, _maker.scss.
_vars.scss$button_size:( sm:5px 20px, md:15px 20px ); $button_color:( white:#ffffff ); $button_back:( blue: #00e5e5 ); $button_config:( padding:$button_size, color:$button_color, background:$button_back );
Como vemos, os dados são apresentados na forma de uma matriz associativa. Todos os estilos individuais estão incluídos no conjunto principal button_config. Para criar novos estilos, o desenvolvedor precisa apenas criar uma nova matriz, preenchê-la com os valores necessários e conectá-la ao button_config.
_cength.scss: @import "vars"; @import "maker"; .button{ @include InitialComponent($button_config); }
Aqui importamos dados e criador de ações. Então, através do mixin InitialComponent registrado no maker, inicializamos todos os estilos passando a variável button_config. E aqui está a mágica. Todas as classes necessárias são criadas de acordo com a nomeação BM.
O resultado da execução serão os estilos:
.button_padding_sm { padding: 5px 20px; } .button_padding_md { padding: 15px 20px; } .button_color_white { color: #ffffff; } .button_background_blue { background: #00e5e5; }
E qual é o sucesso aqui?
A vantagem dessa abordagem não é sentida imediatamente. Mas à medida que o projeto cresce, você entende a conveniência de tal metodologia. Se você precisar alterar a cor de vários botões em páginas diferentes, não precisará procurar classes em vários estilos. Tudo o que é necessário é abrir a pasta de botões e, consequentemente, o arquivo de dados e substituir o estilo desejado.
E se você precisar criar um novo botão?
E fica ainda mais fácil: escrevemos os estilos necessários em uma matriz já preparada ou criamos uma nova e a conectamos lá na configuração e as classes são criadas.
Tudo isso é muito conveniente, especialmente quando você transfere seus componentes de projeto para projeto e a velocidade dos estilos de escrita aumenta várias vezes, deixando apenas uma sensação de conforto e satisfação de que o projeto esteja em ordem total.
Essa abordagem foi testada com sucesso em muitos projetos e a implementação dessa metodologia em breve estará disponível gratuitamente com documentação em russo e inglês.