[system] Remove createUseThemeProps API about material-ui

[brijeshb42]

I can share a working POC later (I have a minimal demo working). But nested themes will work like this -

1. You provide a single theme object through the bundler config. This is used as a reference to generate and inject css variables.
2. If you want to override parts of the app, you can use a custom ThemeProvider (which is not based on context

Suppose you have this as the main theme -

{
  palette: {
    background: "0 0% 100%",
    foreground: "240 10% 3.9%",
    primary: "240 5.9% 10%",
    border: "240 5.9% 90%",
  },
}

And this is how you'll override the global values to scoped areas on the page

<ThemeProvider theme={{
  palette: {
    border: "240 59.7% 56.9%",
  },
}}>
  <div>Your demo</div>
</ThemeProvider>

It'll generate inline styles of css variables that have overriden values that are provided, like this -

Any component inside this ThemeProvider will use css variables with local values for styling.
So ThemeProvider is not actually a context in this case, it's just a div that does not have it's own layout.
Note that this only handles theme token but not other overrides, like component defaultProps. For those, we can still have ThemeProvider with context similar to what we have right now.

[oliviertassinari]

Off-topic (style theme nesting isn't something I was thinking of covering in this issue)

As far as I understand, nested theming for styles should be supported by using CSS variables. It's the <CssVarProvider> component's responsibility to get this to work (which IMHO would be better called ThemeProvider). The zero-runtime should only hard code theme values that aren't CSS variables, or use CSS variables when they are.

It'll generate inline styles of css variables that have overriden values that are provided, like this

We should try to have no inline style in the framework for strict CSP policies. If we can have this in a class name, this would be better.

[siriwatknp]

We introduce a server side theme, to live in the server bundle, alongside the a client bundle theme

I don't see a picture of it. Is server-side theme is the one you define in the config (e.g. next.config.js)?

We should try to have no inline style in the framework for strict CSP policies. If we can have this in a class name, this would be better.

Then, how do you support dynamic runtime styles? Inline style seems to be the only way to connect JS with CSS statically.

// css
.hash {
  opacity: var(--hashed-var);
}

// js
<div style={{ '--hashed-var': opacity }}>

[oliviertassinari]

how do you support dynamic runtime styles?

@siriwatknp Property assignment: #19938

Is server-side theme is the one you define in the config

For Emotion RSC and runtime theme dependencies, you define it once in a RSC and once in a React Client Component. Actually because of this: https://nextjs.org/docs/app/building-your-application/rendering/composition-patterns#supported-pattern-passing-server-components-to-client-components-as-props we can likely have a single component that does both client and server context assignment under the hood.

For zero-runtime RSC, yeah, you also need to define it in the plugin that does the transpilation.

[oliviertassinari]

They use the React.cache for the server context: https://yak.js.org/how-does-it-work