Sass Melhores Práticas Dicas E Ferramentas Para Desenvolvedores

Muito parecido como jQuery revolucionou o JavaScript vanilla, Sass revolucionou o CSS vanilla. A maioria dos desenvolvedores que aprendem o Sass concordam que nunca mais gostariam de voltar. Muitos também concordam que o maior problema com os novos desenvolvedores é o caminho eles usam Sass, não o próprio Sass.

Eu vasculhei a web e compilei este artigo de melhores práticas para escrever código Sass expansível e reutilizável. Sugestões são de minhas próprias opiniões e de sites confiáveis ​​como o Sass Guidelines.

Você certamente não precisa implementar todos esses recursos em seu fluxo de trabalho. Mas vale a pena pelo menos entreter essas idéias e contemplar os benefícios potenciais.

Organização de arquivos

O melhor lugar para começar com o desenvolvimento do Sass é a organização de arquivos. Se você já está no código modular, então você deve entender o valor das importações e parciais (mais sobre isso mais tarde).

Mas por enquanto, basta dar uma olhada neste exemplo de estrutura de arquivos do DoCSSa. Eu recriou esta estrutura de arquivos que você pode ver abaixo:

Esta é apenas uma sugestão e é uma das muitas maneiras de organizar seus arquivos. Você pode encontrar outros métodos que usam diferentes estruturas de pastas como “globals” para SCSS em todo o site e “Páginas” para SCSS específico da página.

Vamos percorrer este estilo de organização sugerido para examinar o objetivo de cada pasta:

• / globals - contém arquivos Sass que são aplicados em todo o site, como tipografia, cores e grades
• / componentes - contém arquivos Sass com estilos de componentes como botões, tabelas ou campos de entrada
• /Seções - contém arquivos Sass dedicados a páginas ou áreas específicas em uma página (pode funcionar melhor combinada na pasta / components /)
• /útil - contém utilitários de terceiros, como o Normalize, que podem ser atualizados dinamicamente com ferramentas como o Bower.
• main.scss - o arquivo principal do Sass na pasta raiz que importa todos os outros.

Este é apenas um ponto de partida básico e há muito espaço para expandir com suas próprias ideias.

Mas não importa como você escolha organizar seu SCSS, é crucial que você tem alguma organização com um arquivo (ou pasta) separado para bibliotecas como Normalize que precisam ser atualizadas, além de componentes em parciais Sass para seu projeto.

As parciais do Sass são vitais para as melhores práticas modernas. Estes são altamente recomendados pela equipe de design da Zurb e por muitos outros desenvolvedores frontend profissionais.

Aqui está uma citação do site Sass explicando parciais:

“Você pode criar arquivos Sass parciais que contêm pequenos trechos de CSS que você pode incluir em outros arquivos Sass. Esta é uma ótima maneira de modularize seu CSS e ajude a manter as coisas mais fáceis de manter. Um parcial é simplesmente um arquivo Sass chamado com um sublinhado principal. Você pode nomear algo como _partial.scss. O sublinhado permite que o Sass saiba que o arquivo é apenas um arquivo parcial e que ele não deve ser gerado em um arquivo CSS. Sass parciais são usados ​​com o @importar diretiva.”

Também dê uma olhada nessas outras mensagens relacionadas à estrutura de arquivos do Sass:

• Como eu estruturo meus projetos Sass
• Sass estética: Arquitetura e estilo de organização
• Estruturas de diretório que ajudam você a manter seu código

Estratégias de Importação

Não se pode dizer o suficiente sobre o valor da importação e dos parciais do Sass. A organização do código é fundamental para obter uma estrutura de importação e um fluxo de trabalho que funcione.

O melhor lugar para começar é com uma planilha global contendo importações, variáveis ​​e mixins juntos. Muitos desenvolvedores preferem separar variáveis ​​e mixins, mas isso se resume a semântica.

Tenha em mente que mixins são uma maneira de importar, ou melhor, duplicar o código Sass. Eles são incrivelmente poderosos, mas não devem ser usados ​​com “estático” código. Tenha em mente que há uma diferença entre mixins, extends e placeholders, todos os quais têm seu uso no desenvolvimento do Sass.

Mixins são melhor usados ​​com valores dinâmicos passados ​​no mixin para alterações de código. Por exemplo, confira este Sass mixin que cria um gradiente de fundo entre duas cores.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Navegadores antigos * / background: -moz-linear-gradiente (top, $ top 0%, $ bottom 100%); / * FF3.6 + * / background: -webkit-gradient (linear, superior esquerdo, inferior esquerdo, cor-stop (0%, $ superior), cor-stop (100%, $ inferior)); / * Chrome, Safari4 + * / background: -webkit-linear-gradiente (top, $ top 0%, $ bottom 100%); / * Chrome10 +, Safari5.1 + * / plano de fundo: -o-linear-gradiente (superior, $ superior 0%, $ inferior 100%); / * Opera 11.10+ * / background: -ms-linear-gradiente (top, $ top 0%, $ bottom 100%); / * IE10 + * / background: gradiente linear (para baixo, $ top 0%, $ bottom 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

O mixin leva dois valores: uma cor superior e uma cor inferior. Você pode escrever mixins diferentes para diferentes tipos de gradientes que incluem 3 ou 4 cores diferentes. Isso permite importar e clonar o código mixin ao alterar os parâmetros para opções personalizadas.

O exemplo do Code Responsible se parece com isto:

.botão @include linearGradient (#cccccc, # 666666); 

Relacionado ao mixin está o placeholder da Sass, que é principalmente útil com a diretiva extend. É reconhecidamente mais complexo do que mixins, mas isso pode ser uma maneira de combinar seletores juntos sem reescrever o excesso de código.

Embora o Sass tenha apenas um método @import, incluímos mixins e espaços reservados para demonstrar a flexibilidade do código que pode ser gravado em um arquivo, mas incluído em qualquer lugar.

Ao construir uma estrutura de importação, lembre-se de seguir os conceitos de codificação DRY (Don't Repeat Yourself).

Convenções de Nomenclatura

Regras gerais para convenções de nomenclatura se aplicam a variáveis, funções e mixins. Ao nomear qualquer coisa no Sass, recomenda-se use todas as letras minúsculas com traços para separação.

A sintaxe do código Sass é, na verdade, baseada no conjunto de regras de diretrizes do CSS. Veja algumas práticas recomendadas recomendadas:

• dois (2) espaços recuos, sem guias
• idealmente, linhas com 80 caracteres ou mais
• uso significativo de espaço em branco
• usar comentários para explicar as operações de CSS

Estes não são itens obrigatórios para o código Sass válido. Mas essas sugestões vêm de desenvolvedores profissionais que Descobrimos que esses conjuntos de regras fornecem a experiência de codificação mais uniforme.

Mas no que diz respeito às convenções de nomenclatura, você pode acabar com duas estruturas diferentes: uma para nomes Sass e outra para nomes de classes CSS. Alguns desenvolvedores preferem sugestões BEM over Sass. Nenhum deles é mais ou menos correto; apenas diferente com diferentes procedimentos operacionais.

O problema é que o BEM não se aplica bem a variáveis ​​ou mixins do Sass porque eles não têm a estrutura de modificador de bloco / elemento / modificador (BEM). Eu pessoalmente prefiro usar as convenções de nomenclatura Sass, mas você pode tentar qualquer coisa, desde o camelCase até sua própria sintaxe interna..

Ao organizar suas variáveis ​​e mixins, recomenda-se divida-os por categoria e, em seguida, liste-os em ordem alfabética. Isso torna a edição muito mais fácil porque você sabe exatamente onde encontrar algo.

Por exemplo, para alterar a cor de um link você abriria seu arquivo de variáveis ​​(talvez _variables.scss) e localize a seção para variáveis ​​de cor. Em seguida, encontre o link por nome (link de cabeçalho, link de texto, etc) e atualize a cor. Simples!

Para ter uma idéia de como você pode estruturar um índice para seus arquivos Sass, confira o arquivo de configurações do Foundation.

 // Foundation for Sites Settings // ----------------------------- // // Tabela de Conteúdos: // // 1 Global // 2. Pontos de Interrupção // 3. A Grade // 4. Tipografia Base // 5. Auxiliares de Tipografia… // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // etc

Outra prática de nomeação diz respeito a pontos de interrupção responsivos. Ao nomear pontos de interrupção Sass, tente evitar nomes específicos de dispositivos. É melhor escrever nomes como small, med, lg e xlg, porque eles são em relação um ao outro.

Isso é melhor para relacionamentos internos entre pontos de interrupção, mas também ótimo para equipes em que os desenvolvedores podem não saber quais dispositivos se relacionam entre si..

Quanto a realmente colocar nomes, é recomendável que você seja o mais específico possível sem variáveis ​​extra longas. Você deve adotar convenções de nomenclatura em todo o site que sejam fáceis de lembrar enquanto codifica.

Dê convenções de nomenclatura específicas para tudo, como cores, margens, pilhas de fontes e alturas de linha. Não só os nomes podem ser rapidamente lembrados, mas torna seu trabalho mais fácil ao escrever novos nomes de variáveis ​​que precisam corresponder a uma sintaxe existente.

Mas há um linha tênue entre especificidade e convolução. A prática irá ajudá-lo a encontrar essa linha, e escrever nomes mais memoráveis ​​facilita a cópia do código em outros projetos..

Aninhamento e Looping

Estas duas técnicas Sass são muito diferentes em ação, mas ambas têm capacidade de ser abusado se não for usado.

Aninhamento é o processo de adicionando seletores aninhados através de recuo para criar mais especificidade com menos código. O Sass possui um guia de aninhamento que ilustra exemplos de aninhamento de código em ação. Mas é fácil se deixar levar pelo aninhamento. Se você está com excesso de zelo, você pode acabar com um código como este:

corpo div.content div.container … corpo div.content div.container div.articles … corpo div.content div.container div.articles> div.post … 

Muito específico e quase impossível de sobrescrever, esse tipo de código anula a finalidade das folhas de estilo em cascata.

Percorrendo este guia do SitePoint, você encontrará três regras de ouro para aninhamento:

• Nunca vá mais de 3 níveis de profundidade.
• Certifique-se de que a saída CSS esteja limpa e reutilizável.
• Use o aninhamento quando fizer sentido, não como uma opção padrão.

O desenvolvedor Josh Broton sugere aninhamento quando necessário, recuar o resto como regra geral de sintaxe.

Recuar seus seletores não causará efeitos CSS em cascata. Mas você vai ter um tempo mais fácil skimming seu arquivo Sass apontando quais classes se relacionam entre si.

Loops também podem ser usado em demasia se não for aplicado corretamente. Os três loops Sass são @para, @enquanto, e @cada. Eu não vou entrar em detalhes sobre como todos eles funcionam, mas se você estiver interessado confira este post.

Em vez disso eu gostaria de cobrir o propósito de usar loops e como eles funcionam no Sass. Estes devem ser usados ​​para economizar tempo escrevendo código que pode ser automatizado. Por exemplo, aqui está um trecho de código da postagem do Clubmate mostrando algum código do Sass seguido da saída:

/ * Código Sass * / @for $ i de 1 a 8 $ width: porcentagem (1 / $ i) .col - # $ i largura: $ largura;  / * output * / .col-1 largura: 100%; .col-2 largura: 50%; .col-3 largura: 33,333%; .col-4 largura: 25%;  .col-5 largura: 20%; .col-6 largura: 16.666%; .col-7 largura: 14.285%; .col-8 largura: 12.5%;

Essas classes de coluna podem ser usadas em conjunto com um sistema de grade. Você pode até adicionar mais colunas ou remover algumas apenas editando o código de loop.

rotações devemos não ser usado para duplicar seletores ou propriedades para um seletor; é para isso que os mixins são.

Além disso, quando há um loop, há algo chamado mapas Sass que armazenam pares de dados key: value. Usuários avançados devem tirar proveito disso sempre que possível.

Mas os loops regulares do Sass são simples e eficazes em fornecer saída de código sem repetição. A melhor razão para usar loops é com Propriedades CSS que variam de saída de dados.

Aqui está uma boa maneira de verificar se o seu loop é útil: pergunte a si mesmo se houver alguma outra maneira de produzir o CSS que você precisa com menos linhas de código. Se não, então a sintaxe do loop é provavelmente uma ótima idéia.

Se você está confuso ou quer feedback sobre aninhamento ou loops Sass você deve postar uma pergunta em / r / sass / ou / r / css /, comunidades Reddit ativas com desenvolvedores Sass muito bem informados.

Modularização

A prática de escrever Sass modular é uma necessidade absoluta para a maioria dos projetos (eu diria, cada projeto). Modularização é o processo de dividindo um projeto em módulos menores. Isso pode ser feito em Sass usando parciais.

A idéia por trás do Sass modular é escrever arquivos SCSS individuais com um propósito específico de segmentação de conteúdo global (tipografia, grades) ou elementos de página (guias, formulários).

A definição do módulo Sass é bastante clara e faz uma sugestão muito específica: importar um módulo nunca deve produzir código.

A ideia de saída obrigatória para todos os módulos seria um pesadelo para a otimização. Em vez disso, você deve criar módulos individualmente e apenas ligue para aqueles que você precisa. Módulos podem ser definidos por mixins ou funções, mas também é possível criar módulos que contenham seletores.

No entanto, um artigo da Sass Way sugere escrever todos os seletores como mixins e apenas chamá-los conforme necessário. Se você adotar isso ou não, é a sua escolha. Eu acho que depende do tamanho do projeto e do seu conforto em lidar com mixins.

Citando John Long de seu post no The Sass Way:

“Para mim, os módulos se tornaram as unidades básicas ou blocos de construção dos meus projetos Sass.”

Se você está realmente procurando uma rotina Sass, recomendo ir totalmente modular. Tente criar quase tudo como uma parte modular que seja incluída em um arquivo CSS principal. No começo, esse fluxo de trabalho pode parecer assustador, mas faz sentido em uma escala maior - especialmente com grandes projetos.

Além disso, é muito mais fácil copiar módulos de um projeto para outro quando eles estão localizados em arquivos separados. Flexibilidade e código reutilizável são os pilares do desenvolvimento modular.

Para aprender mais sobre os módulos Sass e as técnicas de modularização, confira estes posts:

• Módulos CSS: Bem-vindo ao Futuro
• Os prós e contras do Sass Modular
• Organização modular de CSS com SMACSS e SASS

Encontre o seu fluxo de trabalho perfeito

Cada equipe e desenvolvedor individual tem suas próprias práticas que funcionam melhor. Você deve adotar práticas que funcionem melhor para você pessoalmente ou opte por adotar as que melhor funcionam para sua equipe profissionalmente.

Considere também o uso de Gulp ou Grunt para automação de projetos e redução de seu código. Isso economizará muito trabalho manual e ferramentas de automação agora são, sem dúvida, parte das melhores práticas para desenvolvimento de frontend moderno.

Percorra as bibliotecas de código aberto, como o SCSS da Foundation no GitHub, para saber mais sobre as práticas recomendadas utilizadas por outras bibliotecas.

A coisa sobre as melhores práticas é que elas realmente melhoram seu trabalho a maior parte do tempo, mas existem muitas alternativas. Apenas tente as coisas e veja como elas se sentem. Você estará sempre aprendendo para que suas melhores práticas possam mudar rapidamente ao longo de 5 anos.

Uma sugestão final que tenho para todo o processo Sass é tomar decisões com clareza em mente. Escreva um código que facilite seu trabalho. Não complique demais um projeto se houver uma maneira mais simples de fazer isso.

Sass destina-se a melhorar a experiência de desenvolvimento CSS, por isso trabalhar com clareza e melhores práticas para obter a melhor experiência possível.

Embrulhar

O congestionamento em um fluxo de trabalho Sass pode ser corrigido ajustando estilos de código e seguindo as práticas recomendadas. Eu descrevi um punhado de sugestões nesta postagem, fornecidas por blogs e desenvolvedores profissionais da Sass..

A melhor maneira de aprender mais é aplicar essas práticas em seu fluxo de trabalho e veja o que funciona. Com o tempo, você descobrirá que algumas atividades são mais benéficas que outras, e nesse caso você deve manter o que funciona e soltar o que não funciona.

Confira esses links para encontrar mais dicas e práticas recomendadas para o desenvolvimento do Sass:

• Diretrizes Sass
• Uma visão para nosso sass
• 8 dicas para ajudar você a obter o melhor do Sass
• Estendendo-se no Sass sem criar uma bagunça
• Sass Best Practices - Aninhando mais de 3 níveis de profundidade