Rethinking what a variable is in Bitters

[tysongach]

I’d like to investigate a refinement to how we set up Sass variables in Bitters.

Problem

Right now, we have one _variables.scss partial, and every Sass variable in Bitters is defined there. This is fine in the context of Bitters; the project itself. But when a project that uses Bitters grows and variables are added, I’ve found the _variables.scss partial often balloons to upwards of 100 lines (highest I’ve seen yet is 377!). It makes it very hard to parse and feels unorganized to me. You begin to see things like this:

// Core Bitters variables above

// Badges
$badge-size: 1em;

// Tooltips
$tooltip-background-color: $dark-gray;

// Component foo
$component-foo-variable: value;

// etc.

While technically these variables are global (because Sass), I’d bet each of them are only used in one place: components/_badges.scss and components/_tooltips.scss, respectively (or something similar).

I’ve been asking myself a lot lately: Why define these in a partial with global project variables and not alongside the component styles they are strictly used in?

Possible solution

Couple thoughts here…

Variables are a Sass feature. We’ve named this partial after the feature, and so I think people feel encouraged to put all variables here, when that might not best solve for the job-to-be-done.

We could rename _variables.scss to _global-tokens.scss. I’d be open to other names, but quite a few people have started using “token” as a term to describe global, project-specific decisions that establish a design system:

• https://www.lightningdesignsystem.com/design-tokens/
• https://medium.com/eightshapes-llc/tokens-in-design-systems-25dd82d58421#.nim8gy38q
• https://github.com/material-foundation/material-remixer (Google does use the term “ variable” here, but idea of them being extracted and separate from the component level is similar)

Encourage (unsure how Bitters could specifically help with this) component-level variables to be defined within the component’s partial. Here‘s an example showing this, and how it ties back to global tokens:

// _tokens.scss

// Colors
$medium-gray: #767676;
$yellow: #fff6bf;
$red: #fbe3e4;

// _button.scss

$_button-default-background-color: $medium-gray;

.c-button {
  background-color: $_button-default-background-color;
}

// _flashes.scss

$_flash-color-alert: #fff6bf;
$_flash-color-error: #fbe3e4;

.flash--alert {
  background-color: $_flash-color-alert;
}

.flash--error {
  background-color: $_flash-color-error;
}

Note: The underscore in $_button-default-background-color denotes it is a partial used only within the partial in which it is defined in.

The immediate change in Bitters with this idea would be to put the $form- variables inside the _forms partial.

Thoughts?

[whmii]

couple of notes here:

1. I am totally on board with encouraging component specific variables be placed within the components them selves. even so far as to say that the form variables be moved to within forms.scss. this will encourage a pattern of abstracting when appropriate and not just all abstraction all the time.
2. The change from "variables" to "tokens just reads as fashion to me. I think we should stick with the current nomenclature. if we want to change to 'global-variables' that would be fine, but changing the name entirely almost feels user hostile.
3. we should think about establishing a default for how we think of ordering 'object', 'state', and 'property'. I noticed you wrote $_button-default-background-color where I would have gone with $_button-background-color-default: $medium-gray;. obviously this is a huge issue that requires hours of discussion and deliberation.