{"id":340343,"date":"2021-05-14T07:14:34","date_gmt":"2021-05-14T14:14:34","guid":{"rendered":"https:\/\/css-tricks.com\/?p=340343"},"modified":"2021-05-14T07:14:37","modified_gmt":"2021-05-14T14:14:37","slug":"creating-stylesheet-feature-flags-with-sass-default","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/creating-stylesheet-feature-flags-with-sass-default\/","title":{"rendered":"Creating Stylesheet Feature Flags With Sass !default"},"content":{"rendered":"\n

!default<\/code> is a Sass flag that indicates conditional assignment<\/em> to a variable\u2009\u2014\u2009it assigns a value only if the variable was previously undefined or null<\/code>. Consider this code snippet:<\/p>\n\n\n\n

$variable: 'test' !default;<\/code><\/pre>\n\n\n\n
To the Sass compiler, this line says:<\/p>\n\n\n\n
Assign $variable<\/code> to value 'test'<\/code>, but only if<\/strong> $variable<\/code> is not already assigned.<\/p><\/blockquote>\n\n\n\n
Here\u2019s the counter-example, illustrating the other side of the !default<\/code> flag\u2019s conditional behavior:<\/p>\n\n\n\n
$variable: 'hello world';\n$variable: 'test' !default;\n\/\/ $variable still contains `hello world`<\/code><\/pre>\n\n\n\n
After running these two lines, the value of $variable<\/code> is still 'hello world'<\/code> from the original assignment on line 1. In this case, the !default<\/code> assignment on line 2 is ignored since a value has already been provided, and no default value is needed.<\/p>\n\n\n\n\n\n\n
Style libraries and @use...with<\/code><\/h3>\n\n\n
The primary motivation behind !default<\/code> in Sass is to facilitate the usage of style libraries, and their convenient inclusion into downstream applications or projects. By specifying some of its variables as !default<\/code>, the library can allow the importing application to customize or adjust these values, without completely forking the style library. In other words, !default<\/code> variables essentially function as parameters<\/em> which modify the behavior of the library code.<\/p>\n\n\n\n
Sass has a special syntax just for this purpose, which combines a stylesheet import with its related variable overrides:<\/p>\n\n\n\n
\/\/ style.scss\n@use 'library' with (\n  $foo: 'hello',\n  $bar: 'world'\n);<\/code><\/pre>\n\n\n\n
This statement functions almost<\/em> the same as a variable assignment followed by an @import<\/code>, like so:<\/p>\n\n\n\n
\/\/ style.scss - a less idiomatic way of importing `library.scss` with configuration\n$foo: 'hello';\n$bar: 'world';\n@import 'library';<\/code><\/pre>\n\n\n\n
The important distinction here, and the reason @use...with<\/code> is preferable, is about the scope<\/em> of the overrides. The with<\/code> block makes it crystal clear\u2009\u2014\u2009to both the Sass compiler and anyone reading the source code\u2009\u2014\u2009that the overrides apply specifically to variables which are defined and used inside of library.scss<\/code>. Using this method keeps the global scope uncluttered and helps mitigate variable naming collisions between different libraries.<\/p>\n\n\n
Most common use case: Theme customization<\/h3>\n\n\n
\/\/ library.scss\n$color-primary: royalblue !default;\n$color-secondary: salmon !default: \n\n\n\/\/ style.scss\n@use 'library' with (\n  $color-primary: seagreen !default;\n  $color-secondary: lemonchiffon !default: \n);<\/code><\/pre>\n\n\n\n
One of the most ubiquitous examples of this feature in action is the implementation of theming<\/strong>. A color palette may be defined in terms of Sass variables, with !default<\/code> allowing customization of that color palette while all other styling remains the same (even including mixing or overlaying those colors).<\/p>\n\n\n\n
Bootstrap exports its entire Sass variable API<\/a> with the !default<\/code> flag set on every item, including the theme color palette, as well as other shared values such as spacing, borders, font settings, and even animation easing functions and timings. This is one of the best examples of the flexibility provided by !default<\/code>, even in an extremely comprehensive styling framework.<\/p>\n\n\n\n
In modern web apps, this behavior by itself could be replicated using CSS Custom Properties<\/a> with a fallback parameter<\/a>. If your toolchain doesn\u2019t already make use of Sass, modern CSS may be sufficient for the purposes of theming. However, we\u2019ll examine use cases that can only<\/em> be solved by use of the Sass !default<\/code> flag in the next two examples.<\/p>\n\n\n
Use case 2: Loading webfonts conditionally<\/h3>\n\n\n
\/\/ library.scss\n$disable-font-cdn: false !default;\n@if not $disable-font-cdn {\n  @import url(''https:\/\/fonts.googleapis.com\/css2?family=Public+Sans&display=swap'');\n}\n\n\n\/\/ style.scss\n@use 'library' with (\n  $disable-font-cdn: true\n);\n\/\/ no external HTTP request is made<\/code><\/pre>\n\n\n\n
Sass starts to show its strength when it leverages its preprocessor appearance in the CSS lifecycle. Suppose the style library for your company\u2019s design system makes use of a custom webfont. It\u2019s loaded from a Google\u2019s CDN\u2009\u2014\u2009ideally as quick as it gets\u2009\u2014\u2009but nevertheless a separate mobile experience team at your company has concerns about page load time; every millisecond matters for their app.<\/p>\n\n\n\n
To solve this, you can introduce an optional boolean<\/em> flag in your style library (slightly different from the CSS color values from the first example). With the default value set to false<\/code>, you can check this feature flag in a Sass @if<\/code> statement before running expensive operations such as external HTTP requests. Ordinary consumers of your library don\u2019t even need to know that the option exists\u2009\u2014\u2009the default behavior works for them and they automatically load the font from the CDN, while other teams have access to the toggle what they need in order to fine tune and optimize page loading.<\/p>\n\n\n\n
A CSS variable would not be sufficient to solve this problem\u2009\u2014\u2009although the font-family<\/code> could be overridden, the HTTP request would have already gone out to load the unused font.<\/p>\n\n\n
Use case 3: Visually debugging spacing tokens<\/h3>\n\n\n
\"\"
View live demo<\/a><\/figcaption><\/figure>\n\n\n\n
<\/p>\n\n\n\n
!default<\/code> feature flags can also be used to create debugging tools for use during development. In this example, a visual debugging tool creates color-coded overlays for spacing tokens. The foundation is a set of spacing tokens defined in terms of ascending \u201ct-shirt sizes\u201d (aka \u201cxs\u201d\/\u201dextra-small\u201d through \u201cxl\u201d\/\u201dextra-large\u201d). From this single token set, a Sass @each<\/code> loop generates every combination of utility classes applying that particular token to padding or margin, on every side (top, right, bottom, and left individually, or all four at once).<\/p>\n\n\n\n
Since these selectors are all constructed dynamically in a nested loop, and single !default<\/code> flag can switch the rendering behavior from standard (margin plus padding) to the colored debug view (using transparent borders with the same sizes). This color-coded view may look very similar to the deliverables and wireframes which a designer might hand off for development\u2009\u2014\u2009especially if you are already sharing the same spacing values between design and dev. Placing the visual debug view side-by-side with the mockup can help quickly and intuitively spot discrepancies, as well as debug more complex styling issues, such as margin collapse<\/a> behavior.<\/p>\n\n\n\n
Again\u2009\u2014\u2009by the time this code is compiled for production, none of the debugging visualization will be anywhere in the resulting CSS since it will be completely replaced by the corresponding margin or padding statement.<\/p>\n\n\n
Further reading<\/h3>\n\n\n
These are just a few examples of Sass !default<\/code> in the wild. Refer to these documentation resources and usage examples as you adapt the technique to your own variations.<\/p>\n\n\n\n