Dependendo do tamanho do projeto em que você está trabalhando, você pode estruturar seu código Sass de duas maneiras: uma simples para projetos menores e outra mais complexa para projetos maiores. Leia mais para descobrir como.
Sass – o braço estendido do CSS; o fator de potência que traz elegância ao seu código.
Com Sass, é tudo sobre variáveis, aninhamento, mixins, funções, parciais, importações, herança e diretivas de controle. O Sass torna seu código mais sustentável e reutilizável.
E agora, vou mostrar como deixar seu código mais estruturado e organizado.
A organização de arquivos e pastas é crucial quando os projetos se expandem. A modularização do diretório é necessária, pois a estrutura do arquivo aumenta significativamente. Isso significa que a estruturação está em ordem. Aqui está uma maneira de fazer isso.
- Divida as folhas de estilo em arquivos separados usando parciais
- Importe os parciais para a folha de estilo mestre – que normalmente é o arquivo main.sass.
- Crie uma pasta de layout para os arquivos específicos de layout
Tipos de estruturas Sass
Existem algumas estruturas diferentes que você pode usar. Eu prefiro usar duas estruturas – uma simples e outra mais complexa. Vamos dar uma olhada.
ESTRUTURA SIMPLES
A estrutura simples é conveniente para um pequeno projeto, como uma única página da web. Para isso, você precisa criar uma estrutura mínima. Aqui está um exemplo:
- _base.sass – contém todas as redefinições, variáveis, mixins e classes de utilitários
- _layout.sass – todo o código Sass que trata do layout, que é o contêiner e os sistemas de grade
- _components.sass – tudo o que é reutilizável – botões, barras de navegação, cartões e assim por diante
- _main.sass – a parcial principal deve conter apenas as importações dos arquivos já mencionados
Outro exemplo da mesma estrutura simples é o seguinte:
- _core.sass – contém variáveis, redefinições, mixins e outros estilos semelhantes
- _layout.sass – existem os estilos para o cabeçalho, rodapé, sistema de grade, etc.
- _components.sass – estilos para cada componente necessário para aquele projeto, incluindo botões, modais, etc.
- _app.sass – importações
Este é o que eu geralmente uso para projetos menores. E quando se trata de tomar uma decisão sobre o tipo de estrutura a ser usada, o tamanho do projeto geralmente é o fator decisivo.
Por que usar essa estrutura?
Existem várias vantagens pelas quais você deve usar essa estrutura organizacional. Em primeiro lugar, o cache de arquivos CSS e, ao fazê-lo, diminui a necessidade de baixar um novo arquivo a cada nova visita à página. Dessa forma, as solicitações HTTP também diminuem.
Em segundo lugar, essa estrutura é muito mais fácil de manter, pois há apenas um arquivo.
Em terceiro lugar, os arquivos CSS podem ser compactados e, assim, diminuir seu tamanho. Para um melhor resultado, recomenda-se usar Sass / Less e depois fazer a concatenação e minificação dos arquivos.
Caso os arquivos fiquem desorganizados, será necessário expandir a estrutura. Nesse caso, você pode adicionar uma pasta para os componentes e dividi-la ainda mais em arquivos individuais. Se o projeto se ampliar e houver necessidade de reestruturar toda a estrutura do Sass, considere o próximo padrão mais complexo.
A ESTRUTURA PADRONIZADA 7-1
O nome desta estrutura vem de 7 pastas, 1 arquivo. Essa estrutura é utilizada por muitos, pois é considerada uma boa base para projetos de tamanhos maiores. Tudo o que você precisa fazer é organizar os parciais em 7 pastas diferentes, e um único arquivo (app.sass) deve ficar no nível raiz, tratando das importações. Aqui está um exemplo:
sass/
|
|- abstracts/
| |- _mixins // Sass Mixins Folder
| |- _variables.scss // Sass Variables
|
|- core/
| |- _reset.scss // Reset
| |- _typography.scss // Typography Rules
|
|- components/
| |- _buttons.scss // Buttons
| |- _carousel.scss // Carousel
| |- _slider.scss // Slider
|
|- layout/
| |- _navigation.scss // Navigation
| |- _header.scss // Header
| |- _footer.scss // Footer
| |- _sidebar.scss // Sidebar
| |- _grid.scss // Grid
|
|- pages/
| |- _home.scss // Home styles
| |- _about.scss // About styles
|
|- sections/ (or blocks/)
| |- _hero.scss // Hero section
| |- _cta.scss // CTA section
|
|- vendors/ (if needed)
| |- _bootstrap.scss // Bootstrap
|
- app.scss // Main Sass file
Na parcial abstrata , existe um arquivo com todas as variáveis, mixins e componentes semelhantes.
A parcial do Core contém arquivos como tipografia, redefinições e código clichê, usados em todo o site. Depois de escrever esse código, não há mais sobregravação.
A parcial de componentes contém estilos para todos os componentes que devem ser criados para um site, incluindo botões, carrosséis, guias, modais e outros semelhantes.
O Layout parcial possui todos os estilos necessários para o layout do site, ou seja, cabeçalho, rodapé.
A parcial de páginas contém os estilos de cada página individual. Quase todas as páginas precisam ter estilos específicos que devem ser usados apenas para aquela página em particular.
Para que cada seção seja reutilizável e o código sass seja facilmente acessível, existe a seção parcial / blocos . Além disso, é importante ter essa parcial para que você não precise pesquisar se um código específico está nos arquivos home.sass ou about.sass na parcial Pages.
É uma boa ideia colocar cada seção em um arquivo .sass separado. Portanto, se você tiver duas seções hero diferentes, coloque o código no mesmo arquivo para saber que lá você pode encontrar o código para as duas seções. E se você seguir esse padrão, terá a maioria dos arquivos nesta pasta.
A parcial de fornecedores é destinada a frameworks de bootstrap, portanto, se você usar uma em seu projeto, crie esta parcial.
Eu recomendo que você use app.sass como a pasta principal. Aqui está como deve ser:
// Abstract files
@import "abscracts/all";
// Vendor Files
@import "vendor/bootstrap.scss";
// Core files
@import "core/all";
// Components
@import "components/all";
// Layout
@import "layout/all";
// Sections
@import "sections/all";
// Pages
@import "pages/all";
Em vez de ter muitas importações no arquivo, crie um arquivo all.sass em cada pasta. Cada arquivo all.sass deve conter todas as importações para aquela pasta – e para torná-lo mais visível e compreensível, crie um arquivo principal.
Organização
O maior benefício dessa estrutura é a organização. Você sempre sabe onde verificar se precisa mudar algo específico. Por exemplo, se você deseja alterar o espaçamento em uma Seção / Bloco, vá diretamente para a pasta Seções / Blocos. Dessa forma, você não precisa pesquisar na pasta para encontrar a classe em um arquivo.
Facilitação
Quando o código é estruturado, os processos são rapidamente facilitados. Eles são simplificados e cada segmento do código tem seu próprio lugar.