[material-next][theme] Move ref palette out of color schemes

[DiegoAndai]

Move the ref.palette out of colorSchemes as it doesn't depend on the color mode (light | dark). Having it inside the colorSchemes.light might confuse users. The change in usage is the following:

 const customTheme = extendTheme({
-  colorSchemes: {
-   light: {
       ref: {
         palette: {
           // ...
         },
       },
-     },
-  },
 });

[mui-bot]

Netlify deploy preview

https://deploy-preview-40341--material-ui.netlify.app/

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against 626ff72

[mnajdova]

If I am not mistaken, this was initially defined like this, because people may want to define different palettes for light and dark mode, although the default Material You theme does not need it. How about we accept both and have a documentation about the different use-cases?

Edit: On the other hand, we can go initially with the minimal necessary API and see if it is needed based on the feedback.

[DiegoAndai]

@mnajdova I think that's a valid concern.

people may want to define different palettes for light and dark mode

Naming might be confusing here. In v5 we use different palettes for different color modes. In Material You, the tokens for this use case are the system tokens. These are even named similarly to v5's palette tokens: primary, secondary, error, etc. On the other hand, making the names confusing, Material You's reference palette is not supposed to change based on context, as they're reference tokens.

So, if people want to create tokens that change depending on the color mode, they should do it with system tokens, not reference tokens. This keeps the users in line with how the design system was designed. It will also mean our implementation is more in line with that, making it more predictable.

This is how material-web has it implemented as well: system tokens have different values for light and dark modes, but reference tokens do not.

How about we accept both and have a documentation about the different use-cases?

Edit: On the other hand, we can go initially with the minimal necessary API and see if it is needed based on the feedback.

I agree with the edited part; start with what the design system defined and don't go outside unless we have a good reason for it.

[mnajdova]

Agree! Likely it won't be needed, the palette itself should stay the same 👍