Tuesday, June 2, 2020

challenges prioritizing specific classes using sass themes and css modules

At work we're proof-of-concepting using Sass and CSS modules, trying to find easy, flexible patterns to allow projects to have their own themes while still having shared components carry their own CSS.

Things built up pretty well: we had a project that had its own .scss file, and then a subproject with a .scss file that imported the base .scss.

I made it so our shared components could take in a className property, so that individual instances of a shared component can use a different class - or rather, can use that class as well. That worked ok for the main project, but the subproject's defaults were being applied after the individual override class.

I thought of insisting that override classes be "inside" of the class their overriding, like:
.btn {
   .specialcaseclassname {
  }
}

But that wouldn't work for the subproject including the base projects "btn" (but overriding it) - the name were munged

Three possible solutions:

  1. !important would work, but everyone would hate that. 
  2. We could set up a rule that every override class in .scss would have to use @extend against the base class, and then change our components so it would leave out the theme's class.
  3. We can declare that all override classes (at least those that are shred by multiple subprojects) must be in a separate file (and the override Sass files must be imported after the main theme Sass)
It's really a bummer that the order CSS classes are specified in for a DOM element don't matter,
<div class="mainthing specialcase">
is the same as 
<div class="specialcase mainthing">

Otherwise we might have another option. But I guess "3" it is.

No comments:

Post a Comment