em #Front-End
Organizando CSS em Projetos Complexos #2
Gerenciando dependências
Projetos de alta complexidade frequentemente requerem o uso de uma série de dependências. Não é difícil usar pacotes de CSS desenvolvidos por terceiros, mas simplesmente aproveitar os estilos não é uma boa prática. É preciso ter dinamicidade para atualizá-los e se preocupar com performance ao carregá-los.
Uma boa ferramenta para gerenciamento de dependências é o Bower. Ele será usado aqui para demonstrar sua facilidade trabalhando juntamente com SASS e Compass e sua importância para gerenciamento de bibliotecas front-end, inclusive de Javascript (JS não será abordado agora, mas é bom saber). No primeiro artigo da série, foi implementada uma estrutura para trabalhar com SASS e Compass, e agora o Bower será usado em conjunto com ela.
Usando o Bower
Para usá-lo com eficiência, primeiro deve ser rodado o comandobower init na pasta assets (não dentro da estrutura de SASS, pois isso conflitaria com a importação dos arquivos, já que pacotes de Bower possuem, normalmente, mais de uma opção de arquivos para serem carregados). Basta inserir o nome do projeto e confirmar todas as outras opções (por hora não é necessário se preocupar com elas).
Agora é nessária uma dependência para ser usada como exemplo. Como a série de artigos é sobre CSS em projetos complexos, nada melhor que um framework de CSS, sempre indispensável nesse tipo de projeto. Uma boa escolha é o Unsemantic, que também é desenvolvido usando SASS e Compass e oferece uma abordagem bastante amigável aos desenvolvedores, principalmente se tratando de performance. Para instalar Unsemantic (ou qualquer outro pacote) usando Bower pela primeira vez, basta rodar o comand obower install --save unsemantic na mesma pasta em que foi rodado o comando bower init. A opção --save serve para salvar a dependência no arquivo bower.json. Sendo assim, quando o projeto for versionado, apenas este arquivo é versionado junto, ignorando as dependências em si. Isso quer dizer que, nos outros ambientes, basta pegar a versão mais recente do código e rodar o comandobower install, que vai instalar todas as dependências declaradas no arquivo bower.json.
Como é possível perceber, as dependências são baixadas para dentro da pasta assets/bower_components. Essa pasta, assim como a pasta assets/css, não deve ser versionada. A estrutura atual de pastas deve ficar assim:
- complex-css-projects
- assets
- bower_components
- unsemantic
- css
- sass
- source
- main.sass
- library
- library.sass
- components
- extensions
- settings
- sprites
- partials
- shame.sass
- config.rb
- Gemfile
- source
- bower.json
- index.html
- bower_components
- assets
Usando o Unsemantic
Agora é hora de usar a dependência de estilos dentro da arquitetura de SASS já implementada. Como já foi dito no artigo anterior, o arquivoassets/sass/source/main.sass é o responsável por importar os arquivos que serão usados para gerar estilos. Para facilitar a importação das bibliotecas gerenciadas com Bower, é interessante adicionar a pasta do arquivo que será importado como import_pathno arquivo assets/sass/config.rb. Desta forma, se o caminho da pasta assets/bower_components for alterado, basta arrumar a declaração no arquivo de configuração, sem se preocupar com as importações dentro da arquitetura, além de poder importar vários arquivos da mesma biblioteca com mais facilidade. As configurações prévias do SassySkeleton já prevêem onde declarar pastas de dependências externas como import_path, logo após declarar as pastas da própria arquitetura, e é ali que será declarada a pastaassets/bower_components/unsemantic/assets/sass com caminho relativo ao arquivo:
# Add the partials path to the possible import origins.
add_import_path "library"
add_import_path "partials"
# =================================
# 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'
Analisando a estrutura de pastas do Unsemantic, percebe-se que ele traz uma quantidade enorme de recursos, inclusive de Javascript. Por hora, o que interessa são os estilos do gridsystem gerados em SCSS. Esses estilos estão na pasta assets/bower_components/unsemantic/assets/sass, na qual o arquivo unsemantic-grid-base.scss já carrega recursos suficientes para começar um projeto com Unsemantic e usar no exemplo desenvolvido durante este artigo. O seu funcionamento e recursos não serão aprofundados aqui, afinal o objetivo é que qualquer outra biblioteca de CSS possa ser tratada da mesma forma, com as particularidades de cada uma. Para usar os estilos do Unsemantic, o arquivo antes mencionado deve ser importado no arquivo assets/sass/source/main.sass. Graças à configuração recém adicionada no arquivo assets/sass/config.rb, basta declarar seu nome para que a importação suceda:
// ------------------------------------
// Import outputing extensions.
// ------------------------------------
// @import normalize
@import unsemantic-grid-base
Para garantir que o arquivo está sendo importado corretamente, basta compilar o SASS, se não ocorrer erro é porque já é possível estilar o site com as propriedades do Unsemantic. Para isso, alguns estilos serão modificados no arquivo assets/sass/partials/base.sass. Vale notar que todos os estilos do Unsemantic que estão sendo usados são placeholders de SASS, mas não é a única forma de usá-lo, este é apenas um exemplo.
/**
* Basic theme styles.
*/
*
box-sizing: border-box
body
@extend %grid-container
> header
@extend %grid-100
padding: 20px
background-color: gray
section
@extend %grid-60
padding: 20px
background-color: yellow
aside
@extend %grid-40
padding: 20px
footer
@extend %grid-100
padding: 20px
background-color: green
Com os passos acima já é possível gerenciar e usar dependências de estilos de forma eficiente e modular. O básico sobre organização de estilos já passou, na sequência serão dadas algumas dicas mais avançadas CSS em projetos complexos e as ferramentas envolvidas no processo.
