A sneak peak into one of my project Sass files
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
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.