Spiking out an idea to bring some clarity to our Sass files, specifically around the growing number of variables, functions, and settings. This is meant to invite further conversation, and shouldn't be reviewed yet.
Context
My idea here is that there can be greater clarity around the layers of Sass code. We have a few features to how we build this project, including:
- Several global settings (via
$enable-variables) - An entire color system (soon to be expanding with #)
- Layout and component settings (via our breakpoints, grid configuration, spacer ranges, etc)
- And lastly, more typical variables for nearly every
property: valuepairing we want to support customization for
Putting all that in _variables.scss makes for a conflated and potentially confusing file.
Changes
This PR stubs out at least two changes:
- Adds a new
_colors.scssfile for our growing list of color variables - Adds a new
_settings.scssfile for our$enable-variables for global configuration
I'm thinking our other configuration variables can go in _settings.scss) as well (e.g., breakpoints, grids, containers, spacers, escaped characters). The rest of our variables, including the additional Sass map here and there, can remain in the original file as they support our components.
Minimizing requirements for other builds
Our grid dist files currently bring in the entire Sass file, as mentioned in #29428 (closed). This fix would only require _settings.scss, _functions.scss, and _mixins.scss. This is a considerable reduction and more specific, while not overly complicated.
Split it all?
I've thought about this for a bit and believe we shouldn't split the variables files by every component. This makes our lives more difficult (looking across more files if variables are reusing other variables), and takes away the option of generating or reading from a single file (a la several customizers out there).
Thoughts? Alternate ideas? Additional concerns?
TODOs
-
Fix imports