Open csvan opened 3 months ago
The DefaultPropsProvider
in @mui/material
is a reexport of @mui/system
so the context is already created from a shareable package: https://github.com/mui/material-ui/blob/next/packages/mui-system/src/DefaultPropsProvider/DefaultPropsProvider.tsx#L6.
Can you provide a reproducible sandbox that replicate the issue you are facing? I can take a look.
@siriwatknp thanks for the reply! We already share @mui/system
, and unfortunately the problem is still happening.
I will look into a reproducible example, but unfortunately our setup is proprietary and quite complex.
We already share @mui/system, and unfortunately the problem is still happening.
The behavior should already be the same for the ThemeProvider
and the DefaultPropsProvider
from @mui/system. You mentioned @mui/styles - this package is related to the v4 styling (makeStyles, etc).
One thing to make sure is to check that you have the same versions everywhere - this is most often the issue for ending up with different contexts.
Summary
The newly introduced
DefaultPropsProvider
(https://github.com/mui/material-ui/pull/42820) causes problems in micro-frontend setups, since it is located in the main@mui/material
package which is usually too big to be shared between modules in a micro-frontend environment.The root of the problem is that each module in the environment will get its own instance of
DefaultPropsProvider
, meaning that custom properties injected in an orchestrator (e.g. an App Shell) are erased on the module-level.The common way to solve this issue would be to instead move this provider to a smaller, shareable package which can be shared. The best place is probably
@mui/styles
, which also houses theThemeProvider
(which also needs to be shared across modules).Examples
No response
Motivation
Better support for micro-frontends.
Search keywords: DefaultPropsProvider