CSS

16 set, 2015

Falando em organização… – Parte 01

Publicidade

Já escrevi alguns artigos que mostram um pouco de uma metodologia que eu estava utilizando. São eles:

O fluxo de trabalho atual funcionou muito bem nos últimos 3 semestres (1 ano e meio). Durante esse período, fiz diversas modificações pontuais. Mas através da experiência adquirida nesse tempoo, constatei possibilidade de melhorias profundas que poderiam trazer algumas vantagens no dia-a-dia:

  • Velocidade de desenvolvimento;
  • Qualidade do código;
  • Escalabilidade;
  • Componentização;
  • Performance.

Mas… calma!

É impressionante o número de ferramentas que surgem todo dia nesse louco mundo front-end. Portanto, precisamos ter cautela.

A palavra equilíbrio funciona muito bem aqui. Não saia rejeitando todas as novidades ou você vai ter dificuldades para acompanhar a evolução do mercado, mas também não mude seu fluxo de trabalho toda vez que surgir uma ferramenta que você achou interessante.

Teste e estude bem todas as ferramentas que você considera que podem agregar no seu dia-a-dia, mas seja cauteloso antes de aplicá-las em um projeto real.

Automatizador de Tarefas

Qual automatizador de tarefas utilizar? Grunt ou Gulp? Bom, o Gulp se saiu muito bem nos testes que realizei. A diferença de velocidade com relação ao Grunt é absurda. Mas ainda acho o Grunt mais adequado aos projetos que desenvolvo, portanto continuo usando o Grunt de forma “oficial”, o que não impede a utilização do Gulp em algum projeto específico.

Gerenciador de dependências

O uso de um gerenciador de dependências poderia facilitar a atualização e manutenção dos plugins? Após alguns testes, observei que o Bower se tornaria um importante aliado.

Todas as dependências externas utilizadas ficam registradas em um arquivo .json, dessa forma fica mais fácil ver quais estão sendo utilizadas no projeto. E facilita a atualização, exclusão e inclusão de novas dependências no seu projeto.

O Bower se mostrou uma importante ferramenta na busca de organização e escalabilidade.

Organização dos arquivos JavaScript

Ao usar o Bower, uma pasta chamada bower_dependencies é adicionada na raiz do projeto, e lá ficam todas as dependências externas.

Sobre as pastas

  • Os arquivos de dependências externas são chamados diretamente da pastabower_dependencies que está na raiz.
  • Scripts desenvolvidos para suprir as necessidades do projeto ficam dentro de uma pasta de desenvolvimento, por exemplo, assets/js

Sobre o ‘Gruntfile’

  • O plugin Concat é usado para concatenar os scripts de dependências externas, afinal, a ideia é que eles fiquem inalterados;
  • Esse arquivo concatenado é injetado dentro da pasta de desenvolvimento do JavaScript (ex,assets/js) e não deve ser alterado;
  • Os scripts de desenvolvimento que estão dentro desta pasta podem ser alterados a qualquer momento, portanto, observo através do Watch qualquer alteração feita neles;
  • E então todos os scripts serão minificados em tempo real pelo Uglify.

Integração com o Bower

Lembram das dependências externas que serão concatenadas? Também coloco o Watch para observar meu Gruntfile, portanto toda vez que adiciono ou removo alguma dependência no array do Concat e salvo o Gruntfile, é gerado um novo arquivo com as dependências atualizadas.

Esse é um ponto importante: o arquivo de ‘vendor’ com as dependências concatenadas não vai ser gerado o tempo todo, isso causaria sérios problemas de lentidão no Grunt. Ele só vai ser criado quando a gente adicionar (ou modificar/remover) um novo plugin no array do Concat, pois ao salvar o Gruntfile, tenho uma tarefa configurada no Watch para iniciar a tarefa de criação do ‘vendor.js’.

O scripts que modificamos o tempo todo vão ser concatenados com esse arquivo de ‘vendor.js’ e em seguida minificado através do Uglify. Isso aumenta consideravelmente o desempenho do Grunt no tempo para gerar o novo arquivo.

Exemplo de uso:

// Task: Concat
  // ---------------------------------
  concat: {
    vendor: {
      src: [
        // Vendor Plugins
        'bower_components/jquery/dist/jquery.min.js',    // jQuery
        'bower_components/bootstrap/js/transition.js',   // Bootstrap - Animation
        'bower_components/bootstrap/js/alert.js',        // Bootstrap - Alert
        'bower_components/bootstrap/js/carousel.js',     // Bootstrap - Carousel
        'bower_components/bootstrap/js/tab.js',          // Bootstrap - Tabs
        'bower_components/bootstrap/js/modal.js',        // Bootstrap - Modal
      ],
      dest: 'dev/assets/js/_vendor.js'
    }
  },

  // Task: Uglify
  // ---------------------------------
  uglify: {
    dev: {
      files : {
        'public/assets/js/scripts.min.js': [
        'dev/assets/js/_vendor.js',    // Vendor Scripts
        'dev/assets/js/functions.js',  // Functions
        'dev/assets/js/main.js'        // General
        ]
      }
    }
  },

  // Task: Watch
  // ---------------------------------
  watch: {
    build: {
      files: [
        'Gruntfile.js'
      ],
      tasks: ['concat', 'uglify']
    }
  }

Observem que gero um arquivo JavaScript chamado _vendor.js através do Concat, e nesse arquivo estão as dependências externas do bower. O _vendor.js só vai ser alterado caso seja necessário modificar essas dependências.

Os JavaScripts de chamadas e que são modificados frequentemente ficam dentro de uma pasta /js e são concatenados com o _vendor.js e minificados através do Uglify.

E o segredo para essa integração funcionar é colocar o Watch para rodar o Concat e o Uglify toda vez que fizer alguma alteração e salvar o Gruntfile.

O polêmico Boostrap

O Bootstrap está cada vez mais polêmico e no centro de discussões. Continuo achando que se utilizado de forma consciente, pode ajudar bastante – especialmente no início do desenvolvimento.

Passei a deixar nos projetos apenas o que utilizo de fato:

  • Os mixins;
  • Sistema de grid;
  • Componentes JavaScript (Carrossel, Collapse, Modal…) conforme necessário.

Sempre utilizo os mixins (com mais alguns que criei baseados nas necessidades dos projetos que desenvolvo).

O sistema de grid e os componentes JavaScript, eu posso optar por utilizar ou não. A ideia é que as dependências se adaptem à minha necessidade, e não ao contrário.

Lembrando que na versão 3+ do Boostrap ficou muito fácil de utilizar os grids de forma semântica e sem precisar colocar classes para sujar o HTML, tudo é feito diretamente no CSS.

Quanto aos componentes JavaScript, é muito fácil customizá-los e alterar seu comportamento padrão. Acho que trazem boa integração com outras bibliotecas e funcionam muito bem.

Atualmente essa é a participação do Boostrap nos meus projetos.

Organização do CSS

Me aproximei de vez do Atomic CSS. Não sei se estou usando a metodologia da forma que ela foi pensada, mas me senti muito confortável com a organização atual.

E é disso que vou falar na ‘Parte 02’ desse artigo. Vou desconstruir a organização e metodologia do CSS que estou utilizando.