feat(mat.*-overrides): Improve the styles overrides functions to not generate so much duplicity selectors in the css.

[jorgedacal]

Feature Description

Explain the issue

Following your documentation, when we override the style we can do the next:

.SELECTOR {
  @include mat.*-overrides((
    TOKEN_1,
    TOKEN_2,
    TOKEN_3,
    ...
    TOKEN_n,
  ));
}

But this is translated into css in N duplicate definitios of SELECTOR:

.SELECTOR {
    TOKEN_1_RESULT;
}
.SELECTOR {
    TOKEN_2_RESULT;
}
.SELECTOR {
    TOKEN_3_RESULT;
}
...
.SELECTOR {
    TOKEN_n_RESULT;
}

And they should be filled togeteher in only one SELECTOR:

.SELECTOR {
    TOKEN_1_RESULT;
    TOKEN_2_RESULT;
    TOKEN_3_RESULT;
    TOKEN_n_RESULT;
}

Example with button

For example to override the button style we can do the next:

@use '@angular/material' as mat;

:root {
  @include mat.button-overrides((
    filled-container-color: orange,
    filled-label-text-color: red,
  ));
}

But this is translated into css in two duplicate definitios of :root

:root {
  --mdc-filled-button-container-color: orange;
}
:root {
  --mdc-filled-button-label-text-color: red;
}

And they should be filled togeteher:

:root {
  --mdc-filled-button-container-color: orange;
  --mdc-filled-button-label-text-color: red;
}

Explanation of why this should be improved

If we edit a lot of things it generate a lot of unnecessary verbiage that is unefficiency and cause greatly hinders debugging during develmpment.

For example, if we edit 100 Selectors and modify 20 tokens in each one, we have at the end 20 duplicate definitions per each selector that is a total of 2000 selector definitions with one line each instead of 100 selector definitions with 20 lines each.

Logically this makes the final css inefficient as it has many selectors to check, in this case 2000 instead of 100.

Thanks

Thank you very much for your great work. I hope you correct this, and if there is already a way to avoid these duplicities please let me know and you should add it to the official documentation.

Use Case

No response

[crisbeto]

The reason we generate the rules in such a way is to avoid deprecation warnings from https://sass-lang.com/documentation/breaking-changes/mixed-decls/

I tried to address it in #29982, but it ended up breaking some internal clients.