Lesson Weekend

Even though Sass allows us to DRY our styles in a big way, you may find stylesheets for larger projects still feeling clunky and disorganized; especially as we integrate mixins, operators, functions, and other new Sass functionality. How do we manage this?

This lesson will explore how we can organize and modularize our styles by creating multiple Sass files, and importing into one another as necessary. Modularity like this is also a hugely important part of the React library you'll study later. So it's important to begin thinking about this now!

Required Video: Importing Files by NetNinja

Begin by watching the following quick video for a general idea of how separating Sass into different files works:

(Don't worry about the compiler settings the narrator discusses at ~1:33. We're using terminal commands to compile, so these GUI settings do not apply.)

Partial Files

As you can see in the video above, the general process is pretty simple. We can break our Sass apart into multiple files for our own modular organization, then later 'assemble' them back together using @import.

There's only one thing we'd like to add to the discussion in the video. Instead of creating regular old .scss files when splitting our Sass, we should actually create partials. But don't worry, this isn't difficult! All we do is add an underscore to the beginning of the file name. That's it. As explained in the Import section of the Sass Basics Guide:

You can create partial Sass files that contain little snippets of CSS that you can include in other Sass files. This is a great way to modularize your CSS and help keep things easier to maintain. A partial is simply a Sass file named with a leading underscore. You might name it something like _partial.scss. The underscore lets Sass know that the file is only a partial file and that it should not be generated into a CSS file. Sass partials are used with the @import directive.

This is just extra assurance the Sass compiler won't compile each small Sass files into its own output file; but instead import them back together into one big output file for the browser.

But this underscore is not included in any @import statements. For instance, assume we have a basic Sass project like this:

example-sass-project/
├── css
│   └── output.css
├── index.html
└── scss
    ├── _mixins.scss
    ├── _variables.scss
    └── input.scss

Here we have two partial files preceded by an underscore, and our standard input.scss file. We can import these partials back into input.scss with the following code:

@import 'mixins';
@import 'variables';
...

Notice the import statements include neither the underscore preceding the filenames, or the file extension.

Then when we compile our Sass into CSS using the same standard command...

$ sass scss/input.scss css/output.css

...The Sass compiler will read our input.scss input file, the @import statements at the top of that file will invoke it to compile the partials, and our output.css output file will contain compiled CSS for both Sass code in input.scss and all imported partials.

This allows us to organize our Sass into smaller, modular blocks that are easier for us and other developers to manage and traverse, yet still compile it into a single CSS file for the browser. Best of both worlds!

Conclusion

Now that we understand how to break our Sass styles into multiple files, then compile them back together in our output file with @import, the next lesson will discuss best practices for organizing a Sass project with many modular files, just like we'll see in the field.

Lesson 24 of 36
Last updated more than 3 months ago.