DEV Community

loading...

Sometimes atomic, sometimes not. 7 lines of SCSS

Kevin Ard
I make things that do things.
・1 min read

I like atomic css for its balance of flexibility and consistency, but I don't necessarily love how verbose its front-end is.

Neither do the designers I co-op with.

For all that, the interweb at large doesn't love it either.


Seven lines of SCSS - not counting the config variable - to take the edge off:

// pre-compose config 
$composables: (
        'brand-button-orange': (
                '.btn', '.btn-brand-orange-300', '.font-weight-bold', '.text-white',
        ),
        'brand-header-base': (
                '.text-white', '.ml-md-r4',
        ),
        'brand-header-subline': (
                '.brand-header-base', '.font-size-xlg',
        ),
);


// pre-compose helper 
@each $class, $class_spec in $composables {
  .#{$class} {
    @each $extend in $class_spec {
      @extend #{$extend};
    }
  }
}

It's just a tiny bit of recursive string interpolation, but this has settled a ton of turbulence in my teams. If you don't already see what's going on there:

  1. The $composables config variable is a map that references a set of atomic rules under a named key.
  2. The helper creates a set of new classes by @extend each of the rules it maps to

Adding/Altering compositions is pretty simple. Design, in turn, can now use

<a href="#" class="brand-button-orange"></a>

instead of

<a href="#" class="btn btn-brand-orange-300 font-weight-bold text-white"></a>.

Of course, since we're just using @extend, this is really just shorthand/convenience wrapper, so:

  • our built sheet is pretty lean/efficient
  • we maintain consistency with the underlying atomics
  • we don't sacrifice front-end's ability to add more utils on top of the composed class.

Discussion (0)