[zero] Add useThemeProps processor

[siriwatknp]

Motivation

Currently, all components are client components and will never be server components because they will always access to the theme context to look for default props (via system useThemeProps).

This PR aims to remove the usage of React context to make some components RSC compatible while having backward compatible with emotion.

How

1. Lift the current useThemeProps inside a component to the outer scope so that zero-runtime can transform the code by creating an adapter function called createUseThemeProps.

   // /mui-material/src/Badge/Badge.js
   - import useThemeProps from '../styles/useThemeProps';
   + import { createUseThemeProps } from '../zero-useThemeProps';
   + const useThemeProps = createUseThemeProps('MuiBadge');
   
      const Badge = React.forwardRef(function Badge(inProps, ref){
      …

2. At build-time, zero-runtime will replace the createUseThemProps argument with the defaultProps object defined in the theme config that passed to zero runtime.

   // e.g. next.config.js
   module.exports = withZeroPlugin(nextConfig, {
     theme: extendTheme({
       components: {
         MuiBadge: {
           defaultProps: {
             color: 'error',
           }
         }
       }
     })
   });

   After the transformation, the Badge will be:

   // /mui-material/src/Badge/Badge.js
   - const useThemeProps = createUseThemeProps('MuiBadge');
   + const useThemeProps = createUseThemeProps({ color: 'error' });

3. At runtime, the createUseThemeProps from zero runtime will merge props with the same logic as in system's useThemeProps.

Those components that haven't used createUseThemeProps, will continue to use React context as is.

In summary, we remove the React context usage by providing the defaultProps directly to components at build-time.

Trade-off

Some components, e.g. Select, allow developers to provide a React component for replacing icons. This is possible in React context approach but I won't work with zero-runtime because it is not serializable. cc @brijeshb42

---

• I have followed (at least) the PR section of the contributing guide.

[mui-bot]

Netlify deploy preview

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

Bundle size report

Details of bundle changes (Toolpad)
Details of bundle changes

Generated by 🚫 dangerJS against b9d0d9d

[oliviertassinari]

This PR aims to remove the usage of React context to make some components RSC compatible while having backward compatible with emotion.

What's the use case to have RSC compatible components? We use the Badge in the PR, but I guess it's not the objective (I don't see why a developer would want this with his component, there would be no state change animations, the onClick listener wouldn't works, etc.), but I guess the Badge is meant as a supplement for layout components. For instance, it makes a lot of sense to me with a <Container> with a different default layout mode propagated with the context or for a static content: mui/mui-x#12180).

Now, I don't think this change is needed, we can have context (maybe with nesting support but not sure) emotion-js/emotion#2978 (comment).

Trade-off

But them, how can we support theme nesting? I don't see this mentioned, but I think it matters. For example, how is the documentation of Material UI supposed to be able to show components in their default form while the docs has a MUI branded theme?

At first sight, I would recommend:

• We revert this PR.
• We introduce a server side theme, to live in the server bundle, alongside the a client bundle theme. We need this anyway to get RSC support with Emotion.
• We update the theme provider and theme customer to support both theme locations.

This way, we get:

• No theme propagation feature regression on the client bundle, theme nesting continues to work. On the server bundle, the theme nesting mighty not work, it depends on how React calls the cache API, but I wouldn't expect it to be achievable. Maybe one-day if React introduce a true context RSC API.
• The foundations for Emotion with RSC.

Opportunity moved to #43443