Material-components-web: Add !default property for all variables in SASS

[xSirrioNx]

Is it a good idea to add !default property for all variables in _variables.scss files for all components?
It allow to write your own scss file, redefine variables in it and include it before including all other components.
Example:

• custom_variables.scss
  $mdc-toolbar-row-height: 40px;
• material/toolbar/_variables.scss
  $mdc-toolbar-row-height: 64px !default;
• material-components-web.scss
  @include "custom_variables"
  @include "material/toolbar/variables"

So after compiling material-components-web.scss your toolbar height will be 40px.

[Garbee]

When we initially wrote the baseline we didn't default everything since the goal is to adhere to the MD spec. And you shouldn't go changing those values without understanding the ramifications that exist. We only defaulted things that made sense for developers to have some control over without compromising MD alignment.

Want to change the toolbar height? Write your own class to modify that for the element in question. That lets developers have full control without compromising what we offered internally. It also allowed us to refactor the internals as-needed without worrying about any conflicts with external developers modifications in the Sass layer as much.

The idea is, keep things as private as possible and only open them up publicly once a compelling use-case has been provided where a given variable should be open. Instead of defaulting to public everything and regretting it when refactoring something heavily is going to ruin a handful of developers' days.

[bonniezhou]

We are also working on creating public mixins for easier customization of components.

[WillsB3]

Surely things like error colour should be customizable, for instance $mdc-text-field-error-on-light in @material/textfield/_variables.scss.

The way it is right now makes it more difficult to tweak these colours without writing extra classes, and going the custom classes route makes it more likely that we as consumers of the library won't have considered all the possible states for the component.

Surely Material Design doesn't force you to use an exact shade of Red for errors?

[Garbee]

It does specify the exact color for errors. Hence, why it isn't defaulted.

[kfranqueiro]

Also bear in mind that as Bonnie said above, we're working on creating public mixins to allow better customization. While we have accomplished this for several components so far, we haven't gotten to it for Text Fields yet.

1526 should be relevant to this in particular.

[WillsB3]

Great, thanks for the info everyone 👍