bqxhxg
Last Updated: February 25, 2016
·
6.371K
· taybenlor
B4f834aadebcb9f7e351312cc14680b7

Organising SASS Assets in Rails

It's not always obvious how you should be organising your code. Rails with its defaults suggests a good place to start for your app. But once you dive into your assets/stylesheets folder theres so much freedom that you may not even think about organisation.

In the past I've worked on big projects with 10K+ LOC in a single CSS file. This is ridiculous, and it's this sort of practice that the asset pipeline was created to defend against.

My basic starter setup normally looks something like this:

app/assets/stylesheets/
  application.css
  style.css.scss

lib/assets/stylesheets/
  normalize.css

With this setup I'm showing a distinction between our library code (the normalize css) and our application code.

I'm a big believer of not doing too much organisation early on. If we start organising this stuff prematurely we'll create a ridiculous scheme, one that's harder to maintain than a single file.

First off I'll normally do some global layout styles like html, body, header, footer. I also make sure I store standard colours and measurements up the top of the style file as variables. I use measurements to make sure I keep everything aligned to a vertical and horizontal grid at all times. I won't start ranting about grids here, but look into it. At this point I only have one file.

When I start getting into styling the application I like to break down my CSS based on what sort of UI element it is. I've seen people break it down by controller, or section of the app, but this is folly. If you need special cases for a single section of the app that's fine. But you're aiming for a global style sheet, not a series of special cases.

So now I might have something like:

app/assets/stylesheets/
  application.css
  style.css.scss
  layout.css.scss
  buttons.css.scss
  forms.css.scss
  media.css.scss
  comments.css.scss

lib/assets/stylesheets/
  normalize.css
  player.css
  editor.css

You'll notice I needed other library CSS. Often things like a text editor, video player, or any other packaged set of functionality are required for your app.

You shouldn't use the asset pipeline to include all your sass files. Instead you should be using SASS itself to do that, the asset pipeline is simply concatenating everything post compilation, whereas SASS will resolve dependencies during compilation. So my application.css would have:

/* 
 *= require_self
 *= require reset
 *= require player
 *= require editor
 *= require style
 */

Then within style.css.scss I would use @import "layout" etc. to import all my UI styling.

This isn't a complete list of everything I do, but it's a general guideline to my thought process. I think it's most important to divide things functionally within the context of the CSS - don't get tricked into structuring it the same as your views. Also, you don't necessarily need one global CSS file to rule them all. It's appropriate to split up your landing page and marketing from your application styling. This goes again for your admin interface.

The most important thing is to always be organising. As your project grows you'll need to add more organisation. Don't try to nip this in the bud by doing it all early, and similarly, don't leave it once it's mature and patch around it.

Tell me about your organisation style in the comments.

Say Thanks
Respond

6 Responses
Add your response

385
A0cc4d1c55ee3ae48437c4e7774355b7

This is much like the setup I use usually with the small difference that I use vendor/assets for external assets.

over 1 year ago ·
386
B4f834aadebcb9f7e351312cc14680b7

@koraktor Good idea. Makes a bit more sense.

over 1 year ago ·
711
2e3325fbe0f268a5ac99e0163066bf9c

I tend to avoid the .css extension on anything other than the main application stylesheet. Also I prefer to use Sass's include syntax to build my final stylesheet since that way I can easily share variables and mixins across all my different files.

over 1 year ago ·
712
2e3325fbe0f268a5ac99e0163066bf9c

@koraktor Yeah /vendor is definitely the right place to put those, lib is more for code you've written yourself. Basically any regular Ruby code that doesn't fit into Rails' organisation structure like custom subclasses of markdown parsers.

over 1 year ago ·
713
B4f834aadebcb9f7e351312cc14680b7

@rhys Oh yeah, definitely use sass for almost everything. I even mentioned that "You shouldn't use the asset pipeline to include all your sass files.". But when you're working with stuff like a reset/normalize stylesheet or packaged styles I feel it's better to use the pipeline.

over 1 year ago ·
714
2e3325fbe0f268a5ac99e0163066bf9c

Yep, that's a totally sensible approach, I have a whole bunch of complaints I could level at the asset pipeline but it's not too much of an inconvenience.

over 1 year ago ·