At first glance it looks similar to BEM: great for setting up reusable components. My problem is I tend to run into cases where components need a little tweaking on a page.
Let's dig into this a little more! There are two main approaches to organizing CSS: component-oriented approaches like BEM, and inline-oriented approaches like Tachyons. Component-oriented approaches like BEM tend to work well if you're building a design system. But design systems are hard to build! They're hard to build because we can't anticipate all of the use cases that we'll need at the beginning of a project. Folks often struggle when they hit a use case their design system didn't anticipate.
To me, this sounds like exactly the problem you're experiencing. IME, when we butt up against the limits of a design system, we have three options:
Decide we value having a consistent design, and figure out how to use the component WITHOUT those "few little tweaks."
Decide that we value having a consistent design, but realize the component isn't usable without tweaking. So, we then redesign the component for ALL of its use cases. That way, we can make it more adaptable for the needs that we've discovered we actually have. This can be a chain-reaction kind of thing, but it's a GOOD chain reaction! We're refactoring the design because we know more.
Decide that, even though there's value in a consistent design, right now there's more value in just getting the thing done. Here, what I'd actually recommend is NOT trying to fit the variations into any organizational scheme! Create lots of BEM --variants, add some Tachyons classes, or (GASP) just inline the tweak CSS. I think there's a lot of value in just letting things that are iffy stay iffy.
This does two things. First off, code is read more often than it's written. When your teammate comes to it in two weeks (or you come to it in two months), code that looks intentional is going to be imitated and code that looks like hacky bullshit is going to be treated like hacky bullshit. If something isn't ready to be imitated, don't invite folks to imitate it!
Second, and more importantly: if fitting something into a consistent design/organization scheme feels awkward, that means that the scheme is broken. If reworking the scheme to fit the new thing feels difficult, that means we don't know enough to fix that scheme yet. All of the mess? That's INFORMATION. When we try to prematurely organize it because we're embarrassed, we hide all of that information! (We're also likely to build on that shaky foundation; see above.) When the iffy tweak bits wind up being problematic later, we need to UNDO all of the premature organizational work before we can get started organizing things properly. So you're adding work now, and you're adding work later... better just to leave a mess, even if it feels super awkward!
(It can be helpful to have a junk_drawer.scss file next to your shame.scss file.)
Or there are unique pages/sections that only appear once so creating a component for them feels overkill.
The approach I'd recommend here depends A LOT on what's unique about them! Could you elaborate?
That said, you saying that PLUS you mentioning really bad chain reactions has me wondering.... how are you handling layout and positioning? If you're experiencing a lot of chain reactions, to me that implies that your components are tightly coupled to each other. Layout and positioning issues are often WHY un- or semi-related components wind up coupled. If you're not using it yet, you might want to look into switching your layouts to CSS Grid. I've found that the way it simplifies layout logic can really help chain-reaction issues.
Let's dig into this a little more! There are two main approaches to organizing CSS: component-oriented approaches like BEM, and inline-oriented approaches like Tachyons. Component-oriented approaches like BEM tend to work well if you're building a design system. But design systems are hard to build! They're hard to build because we can't anticipate all of the use cases that we'll need at the beginning of a project. Folks often struggle when they hit a use case their design system didn't anticipate.
To me, this sounds like exactly the problem you're experiencing. IME, when we butt up against the limits of a design system, we have three options:
Decide we value having a consistent design, and figure out how to use the component WITHOUT those "few little tweaks."
Decide that we value having a consistent design, but realize the component isn't usable without tweaking. So, we then redesign the component for ALL of its use cases. That way, we can make it more adaptable for the needs that we've discovered we actually have. This can be a chain-reaction kind of thing, but it's a GOOD chain reaction! We're refactoring the design because we know more.
Decide that, even though there's value in a consistent design, right now there's more value in just getting the thing done. Here, what I'd actually recommend is NOT trying to fit the variations into any organizational scheme! Create lots of BEM
--variants, add some Tachyons classes, or (GASP) just inline the tweak CSS. I think there's a lot of value in just letting things that are iffy stay iffy.This does two things. First off, code is read more often than it's written. When your teammate comes to it in two weeks (or you come to it in two months), code that looks intentional is going to be imitated and code that looks like hacky bullshit is going to be treated like hacky bullshit. If something isn't ready to be imitated, don't invite folks to imitate it!
Second, and more importantly: if fitting something into a consistent design/organization scheme feels awkward, that means that the scheme is broken. If reworking the scheme to fit the new thing feels difficult, that means we don't know enough to fix that scheme yet. All of the mess? That's INFORMATION. When we try to prematurely organize it because we're embarrassed, we hide all of that information! (We're also likely to build on that shaky foundation; see above.) When the iffy tweak bits wind up being problematic later, we need to UNDO all of the premature organizational work before we can get started organizing things properly. So you're adding work now, and you're adding work later... better just to leave a mess, even if it feels super awkward!
(It can be helpful to have a junk_drawer.scss file next to your shame.scss file.)
The approach I'd recommend here depends A LOT on what's unique about them! Could you elaborate?
That said, you saying that PLUS you mentioning really bad chain reactions has me wondering.... how are you handling layout and positioning? If you're experiencing a lot of chain reactions, to me that implies that your components are tightly coupled to each other. Layout and positioning issues are often WHY un- or semi-related components wind up coupled. If you're not using it yet, you might want to look into switching your layouts to CSS Grid. I've found that the way it simplifies layout logic can really help chain-reaction issues.
I loled at "junk_drawer.scss" and "shame.scss". Lots of good stuff to think about. Thanks!