How to organize your SASS code

Alexandre SimõesSoftware Architect
CERTIFIED EXPERT
Published:
SASS allows you to treat your CSS code in a more OOP way. Let's have a look on how you can structure your code in order for it to be easily maintained and reused.
SASS is an awesome way to treat your CSS as if it was an OOP language. Among many other features, SASS allows you to approach CSS in a modular way, enabling reusability and maintainability features that are not that evident in CSS.

Here I'll show you how I manage my SASS files and hopefully convince you to engage in a similar practice.
 

Before you start

If you know nothing about SASS, I recommend you read these first:
The Power os SASS
From SASS to CSS
 

The art of isolation

If you start writing your CSS with SASS, you'll end up with a fairly good amount of potentially reusable code. These these will mainly be Mixins that address general of particular situations. Let's take, for instance, the example of a Mixin that applies rounded corners to an element given radius value:


@mixin border-radius($radius) {
                        -webkit-border-radius: $radius;
                        -moz-border-radius: $radius;
                        -ms-border-radius: $radius;
                        border-radius: $radius;
                      }
                      

Open in new window

Once you have this, probably you want to be able to reuse it, instead of copy/paste it around each time you need it.

Another good example is the color palette of your company's branding that can be represented by a set of variables:

$font-family: Verdana;
                      $font-size: 10px;
                      
                      $color-text: #555;
                      $color-text-active: #000;
                      $color-background: #fff;
                      $color-background-active: #dcdcdc;
                      
                      $rounded-corner-radius: 5px;
                      

Open in new window

These are independent pieces of code that will be certainly used together or not, depending on the application.

So the main idea is to split them in groups and, per application, pick the ones you want to use.


Why not using the native CSS @import?

I want to take this out of the way because is the obvious question:


If CSS already supports @import, why do I need SASS for this?
Well, it's true that the standard CSS support the @import out of the box but it comes with some caveats. One evident problem is that each @import is handled by loading the correspondent CSS file, and this process behaves differently depending on the browser. I don't want to go too much in detail here, but the way the browser loads the @import files can be different if you have only imports in your style block or if you have other styles of links before.

More importantly, with the default CSS @import instruction, you're not generating one single CSS file, you're simply avoiding multiple links in the head of your page.


The Power of @import in SASS

The great advantage of combining your CSS with SASS is that, at the end, you'll have one single CSS file; which means, one single HTTP request. This is one of the main things to do when you want to optimise the way you load your static resources.


Group your Mixins

The obvious first  ones to be reorganized are the Mixins. Create a mixins folder with multiple SASS files, grouping your Mixins in a logical way. For instance, group your mixins by generic and application specific. By generic I mean, for instance, the above  border-radius mixin, and others like gradients, rotations, etc.


Split your files by View and/or Component

Create another folder for application specific SASS files; feel free to split the files as much as possible. Personally, I like to split them by view and by component; it makes it easier to know where to go if we need to change them.

Do you have a toolbar, header, footer, or menu? Create a separate SASS file for each one.


Put them all back together with @import

So now that have a bunch of SASS files, it's time to put them all together and build your application's CSS file. The main idea is to have one file that only has @import instructions inside and imports all the "components" you need.

Here's an example for a myapplication . scss file:


@import 'mixins/_generic.scss';
                      
                      @import 'app/_variables.scss';
                      @import 'app/_fonts.scss';
                      
                      // views
                      @import 'app/views/_view1.scss';
                      @import 'app/views/_view2.scss';
                      @import 'app/views/_view3.scss';
                      

Open in new window

Notice that all the file names I'm referencing here are prefixed with an _ (underscore). The reason for this is because SASS specification says that if a filename is prefixed with _ (underscore) then the compiler must not compile that file. This makes complete sense because we will never use, for instance, the variables.css file so, we don't need to compile it.


Final thoughts

At this point, and if you have read my other SASS articles, you know:

Please post your questions below; they will certainly help me improve this SASS series.
4
2,195 Views
Alexandre SimõesSoftware Architect
CERTIFIED EXPERT

Comments (0)

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.