Table of Contents
Although the asset pipeline in Ruby on Rails is a powerful feature, it can be pretty perplexing. Rails’ scaffold automatically generates a style sheet for each controller. As a result, your styles are organized according to the domain model of your application. You will not find it very convenient if you create a modular codebase and reusable components. In this case, a standard CSS architecture will be the most appropriate option since you’ll be able to create, change, and reuse the elements.
Before placing the assets in the public/assets folder, the asset pipeline pre-compiles, concatenates and minifies them. Sprockets and Tilt are two technologies that power the asset pipeline.
Tilt is a template engine used by Sprockets. It supports the file types such as saas, erb,
coffee, etc. which can be used in the Asset Pipeline.
The main function of Sprockets is to package the assets, that is, to gather the assets from all the specified paths, compile them, and place them in the public/assets folder.
Here emerges the question as to the principle and algorithm of files concatenation. The answer lies in a manifest file – the core of the asset pipeline. Based on the received directives, it marks the files to be included and defines the order in which they will be organized. The number of manifest files can be different and depends on your own needs and preferences. It’s up to you to choose one per layout or one per page.
CSS Preprocessing
Any CSS preprocessor (LESS, SASS or Sylus) can be easily used with the asset pipeline. As to us, we prefer SASS for two reasons: it comes with a Rails app by default and it’s simply great.
All CSS preprocessors allow you to use features, variables, mixins, and other useful stuff shared through all modules and files. However, before you can use them, SASS source code should be combined and then compiled to CSS.
The main challenge here is connected with Sprockets //=require syntax used to identify the files that should be combined. Firstly, Sprockets compiles your SASS source code as separate style sheets. After that, it combines the resulting CSS into a single file. There will be an exception if you try to use any mixin unless you have imported your mixins.sass at the top of each file. Using the @import syntax, you instruct the SASS compiler to combine the SASS source code first, and only then perform the compilation.
File organization
Although the majority of Rails projects feature several layouts with different styles, yet they share a common codebase. Here are some tips on how to organize your asset files and directories to make them easily extendable, flexible, and well-structured.
Base styles. All fixed base styles (reset, grids, spaces, and helpers) are placed in the base folder. They can be added to any manifest.
Manifest files per layout. If the layouts have different styles, you should create one manifest file for each layout. “Manifest” means not Sprockets manifest, but .sass file with all @imports of necessary files (variables, mixins, objects and modules).
Folder for each manifest file. One folder should be allotted for each manifest file. It should have the same name: application folder for application.sass file as a default layout. The folder will contain layout styles, typography, all objects and modules used in this layout.
Every manifest folder can contain responsive styles in a responsive folder. You can also divide your interface into objects and modules and put them inside the appropriate folder. This will keep your styles independent and modular. If you need to reuse some styles from a different manifest folder, move them to a shared folder that is located on the same level as manifest itself.
It is highly important to organize the assets properly from the start; otherwise, you take the risk of getting lost in your style sheets after the first month of development. Following the conventions, you’ll prevent mixing styles of different layouts and divide your styles into smaller reusable parts. Ultimately, everything will be located in the right place.
