Product Design Lessons

Intro to Foundation  |   Lesson #89

Avoid a Cluttered Mess - Sensible Sass file Structure

Setting up a sane file structure to organize your projects.

Setting up a sane file structure will really help you organize your projects. You’ll be better able to manage your Sass and so will the rest of your team. Normally, a single CSS or Sass file will typically look like this:

Before too long, the file can get really huge and difficult to manage. In this Lesson, we’re going to cover best practices around organizing Sass code. It may not be the flashiest topic, but it’s an essential one. You’ll thank yourself later for the time you spend organizing well!

Use Sass partials to create quickly identifiable stylesheets

Use descriptive names for your files because it helps you and others find them quickly. The browser never sees these names so make them as descriptive as needed.

Depending on the complexity of your site, you can break out sets of partials into smaller categories. You would do this by creating sub folders in the components directory. For example, if you had a main navigation, side navigation, and a say a breadcrumb, these could be in a components -> naviagation sub folder. This works well because in the end, the partials will all be imported into a single CSS file.

For example, let’s say we’re working on our Interstellar project. We have an index.html file, default JS , SCSS and CSS folders. We'll also create an assets folder for our images, fonts and icons.

In the open Sass folder, you’ll see the _settings.scss and app.scss files. You’ll be importing all your Sass partials into the app.scss file.

We’re going to create 2 new folders, components and mixins. The components folder is going to contain our component specific Sass partials. We’re not going to write any actual CSS in our app.scss file, instead we’ll use it as the file that imports all our new partials into it.

Tip: Creating Sass partials for components, layout and global styles is recommended. Try to avoid creating page specific styling as much as possible to make your code more reusable.

In the components folder, we’ll create partials for things like footer, hero, main navigation, side navigation, and thumbnails.

A couple of things to note about these files: They have an underscore in front of the name. This is a Sass feature that tells the pre-processor not to compile this file into its own CSS file. So unless this is imported into an app.scss file, it won’t be compiled anywhere.

The advantage here is that it keeps our file structure and the files that we eventually deploy organized.

Another thing to note about how the files are named, you’ll notice how we name the 2 nav partials. The type comes first, then get more specific. This makes it easier to find groupings of like partials in your finder and text editor file browser.

Let’s take a look at one of these components.

The Sass can be as simple as this example, or much more complex. If this was in a single Sass file that was a 1000+ lines long, it would be hard to find the component's code. In that case, you might break a component up into smaller partials if there are logical separate pieces. Especially if these smaller partials can be re-used in other projects.

Import your Sass partials into your app.scss file

The app.scss file acts as your index for all your components in your site. We want to make sure we start off by importing mixins. They go after both the _setting.scss and foundation imports. Earlier, we created 2 folders, one for mixins and one for components. You should separate these because it helps with both readability and find-ability.

Now, the components are imported below. We did this in alphabetical order because we wanted to make it’s easier to find. Imagine if you had 30+ partials, sites like Vans, Toms, JCPenny usually do!

The reason the mixins come first, is that we’ll be using the mixins in our components styles. Like @include panel();. Check out our lesson on mixins here ->

Sass is a declarative language that goes through your files line by line so we’ll make sure we import them first avoiding any Sass errors in the console.

Starting your project off on the right foot with sensible organization will definitely save you time and energy, not to mention anyone else who has to work on the project will find it easier to jump in. Just like Foundation, consistent file structure is a language that allows your team to quickly contribute to the work.

Next Steps

Next step? Styling with the _settings.scss file. Luckily, we already wrote about this. Enjoy!

About the instructor


Rafi Benkual oversees the Foundation Forum. Rafi managed people, stores and small organizations before joining ZURB as our Foundation Advocate.