How to use Sass !default values
Tags: sass, css, styling
Published: 2019-05-16 19:42:07

---
title: How to use Sass !default values
published: true
description: One of the core selling points of writing styles using Sass (or SCSS) is being able to use variables. This isn’t as novel a concept now that we have CSS variables native to CSS, but it’s still a big part of Sass. They work as you’d expect for the most part with one exception, the !default keyword. It’s not a feature most people take advantage of that often or maybe even know about, but let’s take a look at how this works so you can leverage it should the need arise.
tags: sass, css, styling
---

One of the core selling points of writing styles using Sass (or SCSS) is being able to use variables. This isn’t as novel a concept now that we have CSS variables native to CSS, but it’s still a big part of Sass. They work as you’d expect for the most part with one exception, the `!default` keyword. It’s not a feature most people take advantage of that often or maybe even know about, but let’s take a look at how this works so you can leverage it should the need arise.

As the keyword suggests this allows us to create a _default_ value for a variable. Ok, so what does that mean exactly in Sass-land? In plain English this means that we are allowing the value to be set anywhere higher up the load order and if it doesn’t get set then we apply the default value. Pretty straightforward really. Let’s look at an example of when you may use this feature.

Ok, let’s set the stage. Importing our SCSS files into one file is a very common pattern when working with Sass (SCSS). Here we load a variables file so they’re available in the rest of our SCSS and then import our `example.scss` (and lots of other SCSS files if this was a real application).

```scss
// main.scss

@import "variables.scss";
@import "example.scss";
```

Let’s take a look at that `example.scss` file. We’re just creating a class and using a `$primary-color` variable we’ve defined above the class.

```scss
// example.scss

$primary-color: blue !default;

.example {
  color: $primary-color;
  border: 1px solid $primary-color;
}
```

Here we’ve defined `$primary-color` with a _default_ value of `blue`. Right now everything works great and we’d end up with the following CSS.

```css
.example {
  color: blue;
  border: 1px solid blue;
}
```

Ok, that’s what we’d expect. Let’s see just how this `!default` thing works. So let’s now set our `$primary-color` variable inside of our `variables.scss` file (we’ll leave the definition in our `example.scss` file as well).

```scss
// variables.scss

$primary-color: red;
```

Our generated CSS now looks like the following.

```css
.example {
  color: red;
  border: 1px solid red;
}
```

Because we defined the `$primary-color` value higher up in the load order, our default value that we defined inside of our `example.scss` file wasn’t used. Here we're saying we don't want to use the default, we want to set this ourselves.

This feature can help us out a lot with modularity and sharing code between projects. You’ll see nearly all frameworks that use Sass leverage this feature. It's incredibly powerful from a framework perspective. They’ll typically provide you with a variables file with all the variables that you can set if you’d like (but you don't have to because they all have values). These are all `!default` marked variables defined somewhere in their code. You define what you’d like for those values and you’ve customized the framework. Pretty slick, huh?

I think the pattern (as contrived as it was in this case) I used to illustrate how this works is another great use case. By leveraging variables at a file (or component) level and marking those we want to make available for customization with the `!default` flag we’ve exposed a customization interface for this file. It’s doesn’t need to be dependent on any other files (so long as you’re not using variables defined elsewhere and not marking them with `!default`) and you can make your components as customizable as you’d like. We end up with customizable, portable component files.

Maybe you don’t want to re-write your button component for the 75th time so you pull in a button file from another of your projects. You can then set the exposed variables in the `variables.scss` file for the project you’re working on and you’ve got a customized button and all you did was copy in a file and set a few variables. Pretty cool.

I bet you can see how handy this could be. You can leverage a feature of Sass used by frameworks, but use it at a much smaller level. And at a level that you can control. You end up with your own framework of sorts that you have 100% control of. Your styles become much easier to share between projects and between your team members. Both huge wins.