A sneak peak into one of my project Sass files

I have talked about how I approach my projects from the 10k view. I have also talked about how I decide about how to break up components, what those file names look like, and why I use a git repo.

Today I want to take the look under the hood at my main scss file and show you how I am structuring things in a typical web project. This example is from Marcus’ new site, but the approaches I show here I use universally.

First lets take a look at the top of my ~/scss/app.scss file. This is the default name for a ZURB Foundation project, but it could literally have any name.

What is more important are the contents of this file.

You will notice the first thing I do is import a file called _brand-design-tokens.scss. I try to use names that are descriptive and literal. Here I place all of my tokens or variables for the project.

Below I have a small mixin called brand-shadow. You notice that it has a set of defaults that come from the brand-design-tokens file. If this was a much larger project, this mixin would have found itself into its own file as part of the build sequence.

Next up you will see the import of the _brand-setting.scss file. This is a copy of the built in ZURB Foundation _settings.scss file I change to take variables from my _brand-design-tokens file.

After this, if you are familiar with ZURB Foundation, you can see that I switch from the float based grid system to the new flexbox based one. Then I have a blanket import of the foundation components that I am using in the project.

Now I want to skip down the file to show you the project specific imports.

Here I am using line spaces to create logical groups. Foundation Overrides and Helpers are exactly what they sound like. Places I override the base framework with additional CSS and also small classes that don’t fit elsewhere.

Next up I have my page specific imports. These are pages that have specific components or spacing patterns that are not shared.

Below I have my general components. These could be used anywhere in the project but they are named in such a way to correspond with the CSS class names and the documentation in the living / coded styleguide.

Another way to look at this information is by taking a look at the actual file structure that also matches the imports above.

Now lets take a deeper look at my _brand-design-tokens.scss file. These are not formally design tokens, but have been arranged so they could be integrated with a 3rd party design token system such as Brand.ai or Salesforce Theo. The name indicates that future role.

Here you see that I use comments and white space to break this file up into logical sections.

  • Colors: Brand, Text, and UI
  • Shadow Settings
  • Fonts
  • Spacing

You can see I put a lot of thought into how to organize this project. I also spent time to make sure I stayed consistent throughout.

Tomorrow I will talk about the coded styleguide. I will show you how a styleguide paired with an organized Sass build system gives developers a fantastic set of documentation and tools. This allows them to focus on implementation and business logic, rather than fussing around with bits of CSS.


Originally published at James Stone.

Show your support

Clapping shows how much you appreciated James Stone’s story.