Introdução

Neste post estudaremos Asset Pipeline, um recurso disponível a partir do Rails 3 para facilitar a manipulação de JavaScripts, CSS e imagens utilizadas em uma aplicação.

Vantagens

Este recurso é habilitado por padrão e garante alguns benefícios:

• Concatenar arquivos CSS e JavaScript, diminuindo o número de requisições necessárias para se carregar uma página e permitindo o cache desses arquivos.
• Comprime e minifica os arquivos CSS e JavaScript, ou seja, elimina espaços em branco, comentários e otimiza seu código além de já disponibilizar uma versão comprimida em GZIP para o caso de seu uso ser possível em sua aplicação.
• Pré-compila os códigos CSS e JavaScript, fazendo todo esse trabalho apenas uma vez, e não a cada requisição.
• Permite a escrita de assets em outras linguagens, uma vez que o código será pré-compilado (Exemplos de outras linguagens: CoffeeScript e SASS).
• Adiciona assinatura aos assets, permitindo que os caches existentes sejam mantidos atualizados. É criado um hash MD5 a partir do conteúdo do asset. Dessa forma, cada vez que o conteúdo de um asset mudar, o hash MD5 acompanhará a mudança e o nome do arquivo final será diferente, forçando o browser a baixar o novo ao invés de continuar utilizando o antigo.

Em versões anteriores do Rails, os assets eram mantidos nas pastas:

• public/images
• public/javascripts
• public/stylesheets

Mas atualmente o local preferido para se manter os assets é em:

• app/assets/images
• app/assets/javascripts
• app/assets/stylesheets

Os assets ainda podem ficar na pasta ‘public’, mas os arquivos nela contidos serão servidos como arquivos estáticos, ou seja, não haverá nenhuma concatenação, compressão ou minificação, não será possível utilizar outras linguagens como CoffeeScript e SASS e não haverá a assinatura mencionada anteriormente. Resumindo, manter os assets na pasta ‘public’ invalidam os maiores benefícios do asset pipeline.

Manifest

Asset pipeline sabe quais arquivos processar e em que ordem através de arquivos Manifest. Estes arquivos têm o nome ‘application’ e estão localizados nas pastas de seus respectivos assets com suas devidas extensões(app/assets/javascripts/application.js e app/assets/stylesheets/application.css).

Em uma aplicação recém criada, o arquivo application.css se parece com o seguinte:

[code language=”css” collapse=”false”]
/*
* This is a manifest file that’ll be compiled into application.css, which will include all the files
* listed below.
*
* Any CSS and SCSS file within this directory, lib/assets/stylesheets, vendor/assets/stylesheets,
* or vendor/assets/stylesheets of plugins, if any, can be referenced here using a relative path.
*
* You’re free to add application-wide styles to this file and they’ll appear at the bottom of the
* compiled file so the styles you add here take precedence over styles defined in any styles
* defined in the other CSS/SCSS files in this directory. It is generally better to create a new
* file per style scope.
*
*= require_tree .
*= require_self
*/
[/code]

Note que é um arquivo CSS comum com comentários. A parte importante do arquivo são as linhas que possuem um ‘=’ na frente do ‘*’:

[code language=”css” collapse=”false”]
*= require_tree .
[/code]

[code language=”css” collapse=”false”]
*= require_self
[/code]

Essas linhas são diretivas que indicam ao asset pipeline o que fazer, que itens incluir e em que ordem.
A diretiva

[code language=”css” collapse=”false”]
*= require_tree .
[/code]

Indica que deve-se incluir todos os arquivos que estiverem dentro do diretório atual e todos os que estiverem dentro dele (representado pelo ‘.’), enquanto

[code language=”css” collapse=”false”]
*= require_self
[/code]

Indica que deve-se incluir todo o código CSS presente no próprio arquivo do Manifest.

Graças ao Manifest, pode-se carregar, processar, concatenar e comprimir os arquivos na ordem correta, já que esse processo ocorre de cima para baixo nas diretivas, e gerar apenas um arquivo para toda a aplicação, uma vez que servir apenas um arquivo é mais eficiente.

A diretiva ‘require_tree’ não possui uma ordem específica, então, se uma determinada ordem deve ser garantida, deve-se requisitar os arquivos prioritários antes de usar o ‘require_tree’.

Observação: O mesmo explicado para CSS vale para JavaScript.

Depois de escrito o Manifest, Rails irá pré-compilar os assets e colocar os arquivos finais (o arquivo resultante e sua versão compimida em GZIP) no diretório ‘public/assets’. Assim os arquivos serão servidos estaticamente ao browser do usuário. Dessa forma, os arquivos em ‘app/assets’ nunca são servidos diretamente em produção.

O Resultado

Em ambiente de desenvolvimento, o Rails pula as etapas de concatenação, compressão e assinatura, para evitar muito processamento durante as fases de desenvolvimento da aplicação, mantendo apenas o processamentos do arquivos para continuar a permitir o uso de outras linguagens.

Já em ambiente de produção, o Rails também pula todo o processamento dos arquivos, pois ele assume que todos os assets já foram pré-compilados.

Dessa forma, devemos pré-compilar os assets anteriormente, pois esse é um processo muito lento que pode facilmente demorar de 1 a 5 minutos. O comando para pré-compilar os assets é:

[code collapse=”false”]
rake assets:precompile
[/code]

Devido a essa diferença entre os ambientes de desenvolvimento e produção, um dos problemas do asset pipeline é que o código que funciona em ambiente de desenvolvimento não necessariamente funciona em ambiente de produção. Pode haver problemas em seu Manifest ou como seu código referencia as localizações de seus assets. Então, antes de fazer o deploy de sua aplicação para produção, é uma boa ideia testar sua aplicação em modo de produção, localmente ou em um servidor de testes.