How to clean code with SASS
Firstly, let’s meet SASS
SASS, known as Syntactically Awesome Style Sheets, is a preprocessor scripting language that needs to be compiled into CSS, in order to be understood by browsers. It is defined by two syntaxes and they are:
- the original one — SASS — that uses indentation to define the code blocks;
- the newer one — SCSS (Sassy CSS) — and the one we are going to talk about in this article, that uses braces to define the structure of the code.
Secondly, let’s see how
Now, that we’ve introduced one another to the SASS language, let’s see how it works. As mentioned above, SASS needs to be compiled in order to be understood by the browser. This can be easily done by installing and running sass with your favourite package manager. After that, it will listen to your changes and convert your sass/scss file into a css file that can be linked to your HTML.
For more information regarding SCSS setup with node, you can check this article right here.
Then, let’s see why…
… would you want to add complexity to your project development?
Well, architecturing a project has always been a trade off between performance and abstraction or space and memory or many more others. So is the case with SASS. Yes, you add an extra step during your development, but you also win scalability and maintainability.
SASS is a wonderful way to write cleaner and scalable code and this comes along with the rules this language brings on top of already existing CSS rules.
With the possibility of having nesting, variables, functions, imports or even operators, SASS reveals a whole new chapter of frontend development that joyfully merges with clean code principles.
Alright, now! Enough with the talk, let’s see the code!
Even though one SASS feature is able to emphasize multiple clean code principles, let’s exemplify one feature for each principle.
- KISS — Keep It Simple Stupid
This principle stands for a codebase made of short, straightforward pieces of code, instead of having complex, hard to understand elements.
How can we assure this with SCSS? KISS can be applied using @mixin and @include. These two directives allow writing a piece of code once and using it anywhere inside the project, just like functions. Having short, intuitive mixins can improve project readability and understanding.
Think about justifying elements, using flexbox, inside different containers. You may apply flex rules on all containers and then customize each one with other styles, but wouldn’t it be even clearer to have a dedicated @mixin for justifying and use it everywhere you need?
Besides @mixins, you might have noticed @if @else directives. These are also SASS features that allow conditioning. In our example, they simplify the code by moving the style from the component into a @mixin, but without overloading it with a large number of parameters.
2. DRY — Don’t repeat yourself
As the name suggests, DRY stands for “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. Even though the above code is a great example for DRY principle as well, let’s see another SASS superpower for this one: nesting.
Since buttons have a lot of states and sometimes we need to apply style on the majority of them, automatically a lot of repetition will be involved. Nesting can reduce this kind of “dirty” code, by gathering everything together inside the same block.
Ampersand(&) is also a SASS feature that allows linking to the surrounding element — in our case, the button class.
3. One file, one purpose
A huge CSS file, containing multiple spaghetti rules, will always be hard to read and understand. Since we pursue having one-purpose classes, objects, functions and so on, why wouldn’t we want to have a single purpose SCSS file?
Let’s think about designing a form with complex rules applied and super specific inputs, buttons and title. Such a file can reach 150 lines of code or even more. SASS allows us to have a main form file, where we can import other individual files.
Also, SASS offers @use directive which is really helpful if you need to import only a specific rule from another scss file.
Having such a modularized component will keep the project maintainable, scalable and easier to fix, if it will be the case.
Bonus tip
We all want a clean code, but we also want a great performance, right? Since SASS is compiled into CSS afterall, always think about how the CSS file will look like after conversion.
A rule of thumb says that we should not use nested IDs or more than three-levels of nestings. This will lead to a substantial CSS file, that will slow down the load performance, which can be noticeable inside older browsers.
Since you’ve already invested a few minutes in your growth, what do you think about a small exercise that will make this time really count? I dare you to be creative, to open up jsfiddle and style a profile card using nestings, mixings, conditionals, variables and whatever you feel that will add value to your practice.
I hope this was helpful and made you better understand how much a preprocessor can influence the cleanliness of the project.
That was it for now! Stay curious!
Resources
https://sass-lang.com/documentation
https://medium.com/swlh/the-must-know-clean-code-principles-1371a14a2e75
