Pitfalls and anti-patterns

This section is a warning to not use certain features of Sass that you have at your disposal. Sass is only a tool to generate CSS, nothing more. However, when working in a component-based setup, there are a few things that won’t work that well anymore.

Extends #

Extends only work well when you compile all your CSS in to one big file. However, in a component-setup, extends don’t make much sense anymore.

In short: use mixins and define them inside _sass-essentials folder.

An example

components
bar
sass Created with Sketch.
bar.scss

.bar {
  color: red;
}

foo
sass Created with Sketch.
foo.scss

.foo {
  @extend .bar;
}

The example above won't compile, because the 2 Sass files have nothing to do with each other, and are separately generated. This means that the Sass compiler won't find the "bar" class to extend internally, as we have a component-based Sass compilation.

If we wanted to make this example work, we would need to change foo.scss as follows:
 

foo
dist
css3-full Created with Sketch.
foo.css

.foo, 
.bar {
 color: red;
}

sass Created with Sketch.
foo.scss

@import "../bar/bar.scss";

.foo {
  @extend .bar;
}

This approach causes a few problems: to start, you have to create a fragile cross-component relation by defining the path from the location from one component to the location of another component: ../bar/bar.scss

On top of that, you also have to ignore that the resulting CSS files are quite awkward, as there will be no reference inside bar.css to the "foo" component:

css3-full Created with Sketch.
bar.css
.bar {
  color: red;
}

Putting the contents of bar.scss inside the _sass-essentials folder would generate CSS in each component of your theme. So trying to find a way to use Sass extends turns out to be more pain than gain.