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.
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:
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.
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.
At this point, and if you have read my other SASS articles, you know: