[theme] Custom "Built-in/Default" Theme

[kealjones-wk]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Summary 💡

When developing a design system/component library on top of MUI components, there should be an easy path to "build in" the Theme that goes with these components and use that theme as the "default theme" for all MUI components as well, or at least pass that theme to the MUI components being wrapped rather than relying on the presence of a wrapping ThemeProvider.

Examples 🌈

We found a way that seems to work but doesn't seem to be documented as a supported method anywhere. We spiked this out and found that using @mui/system's useThemeWithoutDefault and passing in our custom theme as the default and then passing that return value to the theme prop of the MUI component (no official MUI support for this prop, i think this is part of emotion's styled api). This covers a lot of the cases except for nested components within that Root Component.

For example, https://github.com/mui-org/material-ui/blob/master/packages/mui-material/src/LinearProgress/LinearProgress.js#L193 LinearProgressBar1 uses the call theme.palette[ownerState.color].main in its styled implementation, and ownerState in this case is correct but the theme is just the default MUI theme because the ownerState.theme (our theme) is not passed as the theme prop to the inner slot components. This means that the theme will apply to LinearProgress then be completely ignored on the inner slot components. We are able to work around these inconsistencies by writing styles in our wrapper that fix them but that seems a little gross for this particular case.

I took some time and made a simple example codesandbox that demonstrates the above: https://codesandbox.io/s/built-in-default-theme-for-mui-components-sksmu?file=/wrapped-mui/linearprogress.tsx

I am not saying that the above approach is the best for this, maybe there's something that MUI could do to build in support for this so we don't have to do all this finagling, this was just an approach that we discovered could work.

Motivation 🔦

We create a Button component that wraps MUI's Button using the styled API. We build it expecting our custom augmented theme, but when used without a ThemeProvider, it ends up throwing errors, we can code more defensively to prevent the errors, but even then our components end up looking nothing like the design system we are implementing as the expected "out of the box" for this component library.

We could just use a ThemeProvider but some additional reasons this is difficult are:

• All unit tests that implement our components now require a ThemeProvider with our theme.
• Our app is very large and contributed to by many different teams, meaning we have many render roots in our app, and it's possible for some places to accidentally not use a ThemeProvider, especially if the root isn't rendering MUI components at the time it's migrated company wide.

[danielvianna]

I would suggest a total different approach based on design tokens, and possibly using amazon style dictionary
Google Material 3 is just implemented: https://m3.material.io/foundations/design-tokens/overview

I've seen 3 projects that getting messed up because the lack of people start doing "quick fixes" based on inline styles, it quickly becomes a snowball. Trying to align with other products in mobile is impossible

Design tokens are timeless and tech agnostic and there is a working group in w3c standardizing this:
https://www.w3.org/community/design-tokens/