DEV Community 👩‍💻👨‍💻

Kevin Ard
Kevin Ard

Posted on

Sometimes atomic, sometimes not. 7 lines of SCSS

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};
Enter fullscreen mode Exit fullscreen mode

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.

Top comments (0)

Head to your account's Settings to...

🌚 Enable dark mode
🔠 Change your default font
📚 Adjust your experience level to see more relevant content