[system][material-ui] Stabilize CssVarsProvider about material-ui

[DiegoAndai]

@mnajdova @siriwatknp @brijeshb42 what do you think about this one?

We could also plan to make the CssVarsProvider the only provider in v7. If we wish to do that, we would have to stabilize it in v6 as well as deprecate the ThemeProvider, marking it for removal in v7.

[DiegoAndai]

@siriwatknp, May I assign this one to you? You seem to have better context for it right now, having worked on the CssVarsProvider and the zero-runtime side.

[oliviertassinari]

Involved discussion: #41068

[siriwatknp]

I agree to stabilize the API. The big task left is to handle the performance. createTheme takes ~0.x ms but extendTheme takes ~2-5ms.

The best way I found to optimize this (for MUI system) is that the extendTheme should be called at build-time via a CLI.

[brijeshb42]

In that case, a user friendly way to do this would be to have a bundler plugin to inject the themes. It would be similar to a subset of what the zero runtime plugin does.

[DiegoAndai]

I added an overview of the steps to the description. I also added it to the v6 milestone. It doesn't require breaking changes, but we have to deprecate ThemeProvider as soon as possible to give users time to adjust. Because of this, we'll schedule this work alongside the v6 work.

[siriwatknp]

@siriwatknp, May I assign this one to you? You seem to have better context for it right now, having worked on the CssVarsProvider and the zero-runtime side.

Yes, please assign it to me.

[oliviertassinari]

I dove into the logic in: #41223.

1. The behavior of the returned value by:

const { mode, systemMode } = useColorScheme();

is probably not right. I would expect these two should be undefined/null on the first render, unless { noSsr: true } is provided as an option. Otherwise, how are you supposed to handle hydration? The main downside is that it mean that the component renders twice, but this is more sound. And developers could still use { noSsr: true } like useMediaQuery provides.

2. Also, I noticed that we don't memo the theme when we update the mode-related value. This means that we render all the descendants of that rely on the theme twice, this is horrible for performance. A reproduction: https://codesandbox.io/p/sandbox/gracious-currying-nxfvjd?file=%2Fsrc%2FDemo.tsx. Can someone create a dedicated GitHub issue for this? Thanks

Deprecate ThemeProvider in favor of CssVarsProvider

Are we sure about this? It doesn't sound compatible with keeping emotion running on the side.

[siriwatknp]

Deprecate ThemeProvider in favor of CssVarsProvider

I don't think we need to deprecate ThemeProvider, it's still useful for testing purpose.

[DiegoAndai]

It doesn't sound compatible with keeping emotion running on the side.

Why? The current CssVarsProvider works with Emotion.

I don't think we need to deprecate ThemeProvider, it's still useful for testing purpose.

The purpose of deprecating it would be to be able to eventually remove it, to avoid confusing users about which one they should use, and to avoid duplicating work on maintaining and supporting two different theme providers.