Structuring Sass Files

Posted on August 11, 2016 by Addie Padula

Sass is a CSS preprocessor that offers developers features like mixins, nesting, and variables to help keep their CSS DRY (Do Not Repeat Yourself).

The Sass feature I find most useful is the @import feature. @import makes your code easier to maintain because it allows you to break up your code into multiple files or “partials”, and import them into a single file that you link to in your HTML document. This is extremely helpful because CSS files can grow to thousands of lines of code, which is difficult to sort through just to change the font-size on that one element. When your CSS files grow to be that large, comments just aren’t enough. 

This, however, sometimes leads to another problem. What do you do with so many files? That is where file structuring comes in. There are many articles on different ways to structure your project when it comes to having multiple Sass files, but one basic rule to go by is this: do what makes sense. The purpose of file structuring is to make it easier for YOU to find exactly what you need with as little hassle as possible. Or if you’re working on a team, it keeps everyone on that project more organized and less confused.

For example, you might have a main.scss file to import all of your partials, and to set some base styles on the body and/or container element. Then you would create separate files for your header, footer, main content, features, etc. 

first-structure.png

This is definitely a good start. And in small projects, it may be all you need! But we can take this even further. 

 It’s a good idea to develop an organization plan for small projects in case they need to scale up to much larger projects. So that individual component files don’t grow to large, we can break down our components even further by separating them into more than one file, and giving them their own folder. Some components may not need more than one file, and it may feel a bit ridiculous at first to have a folder that contains only one file. But once you start working with larger projects, you’ll definitely see the benefits. You can also have files for your mixins and variables. These are commonly kept either in the root styles folder, or in their own separate folder called “utilities” or “helpers”. 

Now let’s say we’re working on a multipage website. You may want to organize your folders by content unique to the webpage they appear on. This is so that our ‘_main-content’ file doesn’t get out of control. So what do we do? We make more folders! You can never be too organized. The smaller your components are, the better. So don’t be afraid!

We’re going to keep these pages in a ‘pages’ folder. Makes sense right? There we will have a folder for every page that has unique content. Our utilities and features components can stay in the root since they are most likely used throughout our website. Also if you have a consistent header and footer on every page of your site, those components can stay in the root as well. If a component has varying styles on pages on your site, you can create an alternate file for that component and store it in its respective page folder.

And there you have it! While you want to be organized, you also want to keep your file structure as simple as possible for easy navigation. Like I said, there are many ways to organize your Sass files and a lot of times it’s unique to the project you are working on. More than anything it is important to structure your project in a way that makes sense for you and your team.