MUI v5 does not work with Theme-UI

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

Dear MUI dev team and community,

My team maintains a frontend which utilizes MUI v4 and Theme UI. We are trying to upgrade to MUI v5 but are not able to because of a bug which occurs when using Theme UI and MUI v5 together. Using both libraries ThemeProviders, MUI will crash our app under specific circumstances.

I could create a codesandbox example reproducing the error: https://codesandbox.io/s/github/seisenreich/theme-ui-vs-mui-v5/tree/main/?file=/src/App.tsx

The crash seems to occur everytime you try to use a component which has access to any property of MUI’s theme. This is an assumption - I have no proof for this statement, because I didn’t find and read the code which could be responsible for this. Fact is: some MUI components will cause a crash and others don’t. But the MUI components which crash the application will always trigger different error messages. And these messages content seems to correlate to the theme props accessible by the error throwing components. E.g. <Grid /> will fire this one: Uncaught TypeError: theme.breakpoints is undefined

A simple example: You can use MUI’s <Box /> component without crashing the app as it’s props do not seem to have access to any MUI theme property. When using MUI’s <Grid /> component the app will crash with the message Uncaught TypeError: theme.breakpoints is undefined because <Grid />'s sx, sm, md, ld and xl props have access to theme.breakpoints.

I don’t get why this happens. Can you help me?

Also the full error message output with callstack for you:

TypeError
theme.breakpoints is undefined
generateDirection@https://wpfvdf.csb.app/node_modules/
[mui/material/Grid/Grid.js:101:5]()
muiStyledResolver/expressionsWithDefaultTheme</<@https://wpfvdf.csb.app/node_modules/
[mui/system/esm/createStyled.js:96:18]()
handleInterpolation@https://wpfvdf.csb.app/node_modules/
[emotion/serialize/dist/emotion-serialize.browser.esm.js:126:37]()
serializeStyles@https://wpfvdf.csb.app/node_modules/
[emotion/serialize/dist/emotion-serialize.browser.esm.js:226:15]()
createStyled/</Styled<@https://wpfvdf.csb.app/node_modules/
[emotion/styled/base/dist/emotion-styled-base.browser.esm.js:106:69]()
withEmotionCache/<@https://wpfvdf.csb.app/node_modules/
[emotion/react/dist/emotion-element-cbed451f.browser.esm.js:110:12]()
renderWithHooks
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:14985:27]()
updateForwardRef
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:17044:20]()
beginWork
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:19098:16]()
callCallback
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:3945:14]()
invokeGuardedCallbackDev
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:3994:16]()
invokeGuardedCallback
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:4056:31]()
beginWork$1
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:23964:28]()
performUnitOfWork
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:22776:12]()
workLoopSync
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:22707:22]()
renderRootSync
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:22670:7]()
performSyncWorkOnRoot
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:22293:18]()
scheduleUpdateOnFiber
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:21881:28]()
updateContainer
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:25482:24]()
legacyRenderSubtreeIntoContainer/<
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:26021:22]()
unbatchedUpdates
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:22431:12]()
legacyRenderSubtreeIntoContainer
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:26020:21]()
render
[https://wpfvdf.csb.app/node_modules/react-dom/cjs/react-dom.development.js:26103:10]()
$csb$eval
[/src/index.tsx:6]()

  3 | import App from "./App";
  4 | 
  5 | const rootElement = document.getElementById("root");
> 6 | render(<App />, rootElement);
  7 | 

View compiled
▶ 10 stack frames were collapsed.

Expected behavior 🤔

Theme UI and MUI v5 work together flawlessly.

Steps to reproduce 🕹

Look at this codesandbox: https://codesandbox.io/s/github/seisenreich/theme-ui-vs-mui-v5/tree/main/?file=/src/App.tsx

Or follow these Steps:

1. Install clean react project with CRA or any other setup tool you like - TypeScript usage is optional
2. Install MUI v5 dependencies: npm install @mui/material @emotion/react @emotion/styled
3. Follow MUI v5’s installation instructions https://mui.com/getting-started/installation/
4. Install Theme UI dependencies: npm install theme-ui @emotion/react @emotion/styled @mdx-js/react
5. Follow Theme UI’s Getting Started guide to set it up https://theme-ui.com/getting-started/
6. Follow the automatic Theme UI jsx pragma setup guide https://theme-ui.com/guides/jsx-pragma/#using-babelpreset-react
7. Wrap your app into both libraries’ <ThemeProvider /> components using aliases for each for better readability
8. Use a MUI v5 component in between the wrapping providers which uses any theme prop of MUI’s theme. E.g. the Grid component, which has access to theme.breakpoints
9. Load your app
10. Boom.

Context 🔦

My team maintains a frontend which utilizes MUI v4 and Theme UI. We are trying to upgrade to MUI v5 but are not able to because of a bug which occurs when using Theme UI and MUI v5 together.

Your environment 🌎

`npx @mui/envinfo` The error occurs in any browser.

```

❯ npx @mui/envinfo npx: Installierte 2 in 4.934s

System: OS: Linux 5.15 Manjaro Linux Binaries: Node: 14.18.3 - ~/.nvm/versions/node/v14.18.3/bin/node Yarn: 1.22.17 - ~/Code/WAF/frontend/node_modules/.bin/yarn npm: 6.14.15 - ~/.nvm/versions/node/v14.18.3/bin/npm Browsers: Chrome: Not Found Firefox: 97.0.1 npmPackages: @emotion/react: 11.8.1 => 11.8.1 @emotion/styled: 11.8.1 => 11.8.1 @mui/base: 5.0.0-alpha.70 @mui/icons-material: 5.4.4 => 5.4.4 @mui/lab: 5.0.0-alpha.71 => 5.0.0-alpha.71 @mui/material: 5.4.4 => 5.4.4 @mui/private-theming: 5.4.4 @mui/styled-engine: 5.4.4 @mui/styles: 5.4.4 => 5.4.4 @mui/system: 5.4.4 @mui/types: 7.1.2 @mui/utils: 5.4.4 @types/react: 17.0.39 => 17.0.39 react: ^17.0.2 => 17.0.2 react-dom: 17.0.2 => 17.0.2 typescript: 4.6.2 => 4.6.2

</details>

[siriwatknp]

It’s not about emotion as a dependency is about depending on the theme having specific structure. Thinking about this now, maybe we should allow some experimental prop on the ThemeProvider where developers can specify if the MUI theme is a subpart of the theme, so that it can be defined nested in the original theme. Maybe something like:

const muiTheme = createTheme();
const theme = { ...themeUITheme, _muiTheme: muiTheme };

return (
  <ThemeProvider
    theme={theme} 
    themeKey="_muiTheme"
  >
    // Your app
  </ThemeProvider>
)

I believe this should be possible, not sure how much amount of work it will require, but we can test it.

Ideally, emotion should provide us with a way to use our own React context (that would solve a lot of existing issues). I propose that we open a feature request to emotion/styled-components and do the POC on what’s @mnajdova proposed to see how much impact we have.

I see some possible ways:

1. The feature request is not considered. We continue making POC as an experimental workaround.
2. The feature request is considered but takes time to be done. We continue making POC as an experimental workaround and drop it once the feature request is done.
3. The feature request is implemented very soon. We drop the POC.

[seisenreich]

@mnajdova You are absolutely right, it looks pretty similar to #25852 . I wonder if it’s possible to have decoupled instances when using “styled” syntax for both: self written components utilizing Theme UI and MUI 5 components utilizing the MUI 5 theme?

Yes, there definitely are some things I can’t do with @mui/material but can do with Theme UI. Me and my team are writing simple components - or very specific components not already included in MUI - in plain JSX, styling them with emotion and using Theme UI’s sx prop and media query shortcut syntax in it on them. With Theme UI I can use the sx prop on any JSX element I want. May this be a div, a span or a third party component like FontAwesome’s React icon components. As far as I understood MUI only supports the sx prop for the components included in MUI’s component library, and I haven’t seen documentation on media query shortcut syntax yet (is this a thing in MUI 5?).

Also often times MUI’s components include way more logic than I need for a specific use case, impacting performance whenever I face performance heavy tasks like having to render a list of many complex components. This has been the case e.g. in a list with up to ~1000 components having nested components each: While using MUI’s Grid component rendering the list took about 10 seconds. Excluding the Grid, only using plain divs and building a simple flexbox grid system for the mentioned list -> less then a second to render the full list.

We use MUI components for things like forms, date pickers, accordions - basically everything that’s a somewhat standard ux element you already styled by Material’s UI/UX guidelines for us. We also utilize the grid system where performance doesn’t matter. But there will always be components in our project we build without MUI.

At the moment we’re planning to remove Theme UI from our code, which is a huge amount of work to be done, and this will take away the possibility for us to use the sx prop on any JSX element we like and using Theme UI’s smart media query shortcut syntax, which is a huge bummer. But excluding MUI from our project would take even longer, because we would have to build input fields, accordions, date pickers and many other standard components by ourselfs, which we really don’t want to do, because we haven’t got time and money for that. This is why we chose MUI 4 in the first place: Being able to use material style ux elements which simply do the job and work well, without having to write them by ourselfs.

I don’t get why emotion as a sub dependency of to different libraries can’t be used isolated in both libraries. I guess I simply don’t know well enough about how exactly peer dependencies work in bigger JS projects to get why this is such a big deal.