Organize Stylesheets in Rails

Design Front End Development
1

As a Rails developer I generally write both front and back-end code. However, I often find my stylesheets quickly become unorganised and are a pain to go back to and update without duplicating code somewhere.

The Rails convention creates stylesheet files for each generated resource and I understand there is some benefit there if you can configure it to only request stylesheets based on that resource (rather than the entire compiled application.css file)?

My question is for the front-end guys at Thoughtbot (and any other awesome front-end devs) and it’s related to how you organize your stylesheets?

Recently I read this great post by @CarolannBonner - which appears to take a modular approach of creating lots of partials in your views and then mirroring those partials as stylesheets in a /partials directory.

I also just discovered Github’s styleguide (which is awesome) - Primer Design System | styleguide and they’re ‘file organization’ looks nice. I was thinking of applying something similar except changing the /components directory to a /partials directory since if I’m using Bourbon + Refills, most of the ‘components’ will already be defined so it’s more likely I’ll be tweaking partials instead.

Would love to hear some opinionated solutions for this topic which I don’t think gets that much attention! (I see there is a front-end development workshop - would love to see that online!)

Thanks,

Ralph

2

One way I have seen it is to use the application.css for housing shared styles, and then scoping the styles for each resource’s css file. So you put a class on the body that gets swapped out per resource. Then use that dynamic class as a layer of specificity in the selectors for each stylesheet.

No clue if that is the best way or not, but it seems sound in theory.

3

I tend to organise my CSS files/file contents in a few ways:

  • Files are by ‘logical area’, which could be resource/model or for a smaller app it might just be ‘admin’ and ‘shop’ or ‘pages’.
  • Selectors are organised by:
    • Elements (body, html, a, label etc)
    • Classes (.hero, .table, .intro)
    • IDs (#header, #fallback, #logo)
    • Alphabetically within these sections
  • Styles are organised alphabetically so when you have a 30 line style block, you know roughly where ‘text-transform’ or ‘height’ will be down the list.

I don’t like having too many CSS files, since I tend to end up getting lost, however the ones I do have need to make it easy to find both the selector and style within, searching is fine but grouped styles should be grouped by css class, and therefore appear together in the stylesheet as well. I also use the vertical approach so

.class {
  font-weight: bold;
}

rather than: .class { font-weight: bold; } though I have a bad habit of varying that by project…

4

Here’s my personal approach:

|-- app
|   |-- assets
|       |-- images
|       |-- javascripts
|       |-- stylesheets
|           |-- controllers
|           |   |-- products
|           |   |   |-- index.css.less
|           |   |   |-- show.css.less  
|           |-- lib
|           |-- application.css

Since I don’t use require_tree in my manifest file, using a structure like this allows me to programatically load stylesheets based on the current controller and action where applicable. Is it the most optimal approach? Perhaps not, but it keeps me sane, and I don’t have to worry about style conflicts if I scope it to the view. I use this same directory structure for JavaScript as well, however, with JavaScript I load thrid party assets using Bower as opposed to tossing it inside of a lib folder.

I was reading a long debate on loading JavaScript on a per view basis versus using require_tree loading all JavaScript at once on stackoverflow. Both sides offered good arguments, but ultimately I was sold on the former - I’ll see if I can find that discussion again.

5

@ralphwintle - glad you found the blog post helpful!

Personally, a modular structure helps me organize workflow and stay on task.

I’ve experienced an unexpected benefit when jumping on to an existing project that is new to me: When the main stylesheet acts as a sort of manifest, I can get a good idea of what components or styles I’m dealing with before I even see the app running.

I have an easier time targeting styles I need to edit and assessing if I need to add a new class.