The 7–1 SCSS Architecture
As you advance in your programming knowledge and start working on development teams either for an internship or as a part of a full-time development team, you are bound to use Sass in your coding career. With today’s modern web applications, CSS files are getting larger, more complex, and harder to maintain. One website or application can have several different styles and themes, which can lead to a lot of CSS rules that need to be defined. The advent of CSS preprocessors in recent years makes managing and organizing stylesheets much, much easier.
What are CSS Preprocessors?
A CSS preprocessor is a scripting language that allows you to compile CSS code from the preprocessor’s unique syntax. Preprocessors add features to styling websites and applications that do not exist in pure CSS. These unique added features include nested styles, mix-ins, and inheritance selectors, as well as more advanced custom variables.
There are several CSS preprocessor programs to choose from, but by far the most popular is Sass. Sass is an acronym that stands for Semantically Awesome Style Sheets, and was first designed and developed back in 2006 by Hampton Catlin and Natalie Weizenbaum. Sass is a free CSS preprocessor that can be downloaded and used by anyone, and it is compatible with all versions of CSS.
How Does Sass Work?
Browsers cannot directly interpret Sass code, so in order to turn Sass into browser-friendly CSS code, a transpiler is needed to convert the Sass into CSS. Luckily, a lot of IDE text editors that are developed for programmers offer plug-ins or extensions that can be installed that automatically convert Sass to CSS. Visual Studio Code (which is my preferred IDE editor) has an extension called “Watch Sass” that takes Sass files and automatically generates a CSS file, as well as a map file. In addition to automatically and instantly compiling Sass, it also adds in the appropriate browser prefixes needed for compatibility across multiple browsers and versions — making Sass that much more powerful when building applications.
What is the 7–1 Sass Architecture?
So now we know what Sass is and how it works, as well as some of its benefits. But even using Sass, how can we keep our style files organized and avoid having large, unmanageable, and difficult to navigate Sass files? The best way to accomplish this is to break our Sass files up into individual files (or modules) that each handle specific parts of the application or project (again: another example of the Separation of Concerns concept).
Even breaking files into more manageable modules can be a difficult task, as there is no universally accepted, standard, or endorsed “best practices” for doing so, and this will often vary across different companies, development teams, and even projects. As Hugo Giraudel states, architecting a CSS project is probably one of the most difficult things you will have to do in a project’s life. Keeping the architecture consistent and meaningful is even harder.
As with a lot of development principles and tools, the benefits of Sass might not seem too obvious or helpful on smaller-scale websites and applications where minimal styles are necessary, but as websites and web applications scale in size and become larger and larger, a tool such as Sass and a good organizational structure for Sass files will prove to be helpful and meaningful — if done properly.
One popular and effective modular way of structuring Sass projects is the 7–1 pattern. The 7–1 Sass Architecture pattern essentially breaks style files into 7 different subdirectories (the 7 part), which are all imported through one main sheet in the Sass root folder (the 1 part). The main sheet is called the input file and contains no actual style rules. It simply imports all of the other styles from the seven other directories in a specific order. Here is an example of a Sass directory tree:
The file structure is as follows:
1. Abstracts — this subdirectory contains no actual styles, but rather just functions and mechanisms that help to define other styles (essentially your “helpers” directory).
2. Vendors — these are third-party stylesheets used by a project. For instance, if we used Bootstrap in a project, the Bootstrap CSS file would be downloaded and added to this directory.
3. Base — This is the boilerplate styles used globally across the application. In this directory we would include our default CSS resets and typography styles.
4. Layout — contains the styles for parts of the site’s structural layout (such as headers, footers, navbars, etc).
5. Components — these are styles for “mini” layouts, such as buttons, form styles, profile pictures, cards, etc. that can be used across the site.
6. Pages — This directory contains page-specific styles — for instance, if we used certain styles on our homepage, we would have a _homepage.scss file that declares these page-specific elements.
7. Themes — If a site has multiple themes (for instance a “Day” and “Night” theme, or an “Admin” and “Default” theme, where the site looks different for logged-in admins versus regular visitors) the different styles needed for each theme will be in this directory.
Then, inside of the root sass directory is a main.scss file that imports all of the styles from these sub-directories.
The 7–1 Sass Architecture helps to organize stylesheets in a concise and easy-to-follow manner. Not all sites or applications will need every single directory, though. For instance, if an application or website does not use third-party styles (such as bootstrap), or there is only one theme across the site, a “themes” directory and a “vendors” directory may not be needed, and therefore will be excluded from the file structure — leaving only five sub-directories.
Personally, I am relatively new to using Sass in my projects. With the advent of custom CSS variables, I had not found the need for such complex structures for my CSS — until recently. Once I started using Sass and realized all of the awesome features and tools (such as nesting my CSS properties to write DRYer CSS and the automatic addition of browser prefixes), I was sold! I came across the 7–1 Sass Architecture recently too, as I was trying to find a way to better organize my stylesheets for an application that had a front-facing site (for visitors to learn about the company), a users’ area (where customers could book spaces, pay monthly invoices online, and manage their accounts), and an admin area (where the business owner could manage available spaces, customers, and keep track of billing).
Scss is powerful and awesome to use in your projects. However, keeping everything organized is the key to success. By following the 7–1 SCSS Architecture, you should have no problem organizing and maintaining you CSS files!
