Ícone do site Taller

Organizando CSS em Projetos Complexos #3 – Dicas Avançadas

Organizando CSS em projetos complexos 3

Dicas avançadas

O motivo da estrutura apresentada nas primeiras duas partes da série ser tão complexa é porque a mesma propõe boas práticas de desenvolvimento e manutenção de estilos, além de visar aproveitar da melhor forma possível os recursos disponíveis. Para otimizar os resultados e o uso dos recursos ao máximo, algumas dicas avançadas de SASS se fazem pertinentes para manter um bom workflow trabalhando com o SassySkeleton e bibliotecas externas.

A pasta library

Traduzindo a introdução do arquivo README da pasta assets/sass/library:

Este diretório deve ser composto de porções de código que não gerem CSS sozinhas. Isso deve permitir, entre outras coisas, que este diretório possa ser inteiramente reutilizado em outros projetos.

Dentro da estrutura desta pasta se utilizam recursos específicos de escrita de SASS, como variáveis, mixins, placeholders e funções, que não geram CSS quando o SASS é compilado, mas servem para serem aplicados em seletores que vão gerar. Ela é subdividida em quatro subpastas que ajudam a deixar a organização dos recursos mais modular. São elas:

Tá, e daí?

Tendo entendido melhor como funciona a estrutura de estilos aqui proposta, e também como usar bibliotecas externas de forma limpa e sem muitas complicações, é hora de avançar um pouco mais na organização do projeto. Para isso, é importante manter uma boa relação entre a arquitetura interna de estilos e o uso de estilos externos.

É altamente recomendado, sempre que possível, usar bibliotecas que forneçam seu código também em SASS, pois assim elas podem prover formas mais avançadas de seu uso dentro de uma arquitetura complexa. Algumas dessas formas serão detalhadas a seguir.

Para melhor exemplificar os recursos, será usada de exemplo uma biblioteca mais complexa, o Foundation (http://foundation.zurb.com/) que, por fornecer variados recursos, facilitará a amostragem de casos de uso. Basta rodar o comando bower install --save foundation na pasta /assets, adicionar o caminho ao arquivoassets/sass/config.rb e importar o arquivo base do Foundation no arquivo assets/sass/source/main.sass.

config.rb

# =================================
# Vendor Settings
# =================================

# Add importing paths to use vendor's partials that reside outside
# this directory.
# add_import_path '../../path/to/other/project'
add_import_path '../bower_components/unsemantic/assets/sass'  
add_import_path '../bower_components/foundation/scss'  

main.sass

// ------------------------------------
// Import outputing extensions.
// ------------------------------------

// @import normalize
@import unsemantic-grid-base
@import foundation

Existem formas mais avançadas de usar e importar o Foundation, vale a pena consultar sua documentação para SASS (http://foundation.zurb.com/docs/sass.html) para não importar o projeto inteiro.

Sobrescrevendo variáveis

Ao se usar uma biblioteca que traga várias coisas prontas, como faz o Foundation, é normal desejar usar ao máximo os padrões que são oferecidos. Alguns ajustes e customizações, entretanto, são comumente necessários. E há formas de fazer isso sem fugir da estrutura já oferecida, aproveitando definições já implementadas.

O caso das variáveis é um dos mais corriqueiros: pode ser necessário que a cor principal do site não seja a mesma do Foundation, mas para isso não é necessário criar uma nova variável. Sobrescrever a variável do Foundation já é o suficiente e também mais útil, porque mixins da biblioteca que usam essa variável já serão implementados com a cor nova, por exemplo.

A documentação recomenda que seja alterado o arquivo_settings.scss presente, neste caso, em assets/bower_components/foundation/scss/foundation, descomentando e alterando as variáveis para alterar o resultado final. Neste caso, porém, as variáveis serão sobrescritas dentro da arquitetura do SassySkeleton, para melhor centralizar as definições de estilos e poder usar a mesma abordagem para diferentes bibliotecas, caso necessário, e o arquivo _settings.scss será usado apenas como referência.

Neste arquivo, encontra-se a variável $primary-color: #008CBA;. Ela recebe um tom de azul padrão do Foundation. Caso o projeto em questão tenha como cor primária um tom de verde, por exemplo, basta sobrescrever a variável no arquivoassets/sass/library/settings/colors.sass com o valor desejado:

// Foundation overwritten color variables.
$primary-color: #00AA00

Vale ressaltar duas coisas: o novo valor da variável só será válido para estilos escritos depois de sobrescrevê-la e deve-se ter atenção à sintaxe, já que o exemplo está sendo escrito em SASS e a biblioteca em SCSS.

Agrupando extends e mixins

A partir do SASS, existem basicamente duas formas de usar os estilos dos componentes do Foundation: usar os estilos básicos, estendendo as classes com @extend .classe-foo, ou customizar os estilos, usando os mixins que ele provê na documentação.

É muito comum, no entanto, precisar estender duas ou mais classes no mesmo elemento mais de uma vez, ou algo semelhante envolvendo mixins. Para modularizar ainda mais a arquitetura, é possível criar novos mixins contemplando isso.

Exemplo: sempre que for usada a lógica de colunas do foundation, é necessário um container com os estilos da classe row. É necessário, também, que os itens dispostos em coluna sempre tenham a classecolumns. Pensando assim, a única coisa que realmente varia é o número de colunas. Um mixin poderia resolver isso, usando o número de colunas como argumento, escrito no arquivoassets/sass/library/components/columns.sass:

// General columns classes aplication.
=columns($large, $small)
  @extend .row
  > *
    @extend .column
    @extend .large-#{$large}
    @extend .small-#{$small}

Para melhor exemplificar, será criada uma lista no arquivoindex.html e nela será usado este mixin e a classe sobrescrita anteriormente no arquivo assets/sass/partials/base.sass:

index.html

<body>

  <header>
    <nav>
      <ul>
        <li>Your menu</li>
      </ul>
    </nav>
  </header>

  <h2>Foundation columns example. Resize the page to test.</h2>

  <ul class="foundation-example">
    <li>1</li>
    <li>2</li>
    <li>3</li>
    <li>4</li>
    <li>5</li>
    <li>6</li>
  </ul>
...

base.sass

.foundation-example
  +columns(4, 6)
  padding-bottom: 5rem
  list-style: none
  li
    background-color: $primary-color
    text-align: center
    line-height: 5em
    font-weight: bold
    color: white
    &:nth-child(odd)
      opacity: 0.8

Estilos condicionais

É possível aprofundar ainda mais: o mixin criado acima pode estar também sendo aplicado de forma repetitiva dentro do sistema, tendo sempre casos com 4 colunas para desktop e 3 para mobile ou 2 para desktop ou 1 para mobile. Conhecendo isso como um requisito dos sistema, é possível abstrair inclusive qual estilo da biblioteca será aplicado, tratando os componentes de forma semântica.

index.html

...
  <ul class="foundation-example">
    <li>1</li>
    <li>2</li>
    <li>3</li>
    <li>4</li>
    <li>5</li>
    <li>6</li>
  </ul>

  <ul class="foundation-example-2">
    <li>1</li>
    <li>2</li>
    <li>3</li>
    <li>4</li>
    <li>5</li>
    <li>6</li>
  </ul>
...

columns.sass

// General columns classes aplication.
=columns($large, $small)
  @extend .row
  > *
    @extend .column
    @extend .large-#{$large}
    @extend .small-#{$small}

=columns-translate($how-much)
  @if $how-much == many
    +columns(3, 4)
  @else if $how-much == few
    +columns(6, 12)

base.sass

%foundation-example
  padding-bottom: 5rem
  list-style: none
  li
    background-color: $primary-color
    text-align: center
    line-height: 5em
    font-weight: bold
    color: white
    &:nth-child(odd)
      opacity: 0.8

.foundation-example
  +columns(4, 6)
  @extend %foundation-example

.foundation-example-2
  +columns-translate(few)
  @extend %foundation-example

Já é uma base

Com essas dicas avançadas, já se pode ter um significativo avanço na modularidade dos estilos. Vale frisar que as ferramentas apresentadas possuem mais recursos e inclusive mais avançados do que os apresentados aqui, e que um estudo contínuo desses recursos sempre tem a melhorar a experiência do desenvolvedor e o código desenvolvido.

Sair da versão mobile