[docs] : Reintroduce aliasing in MUI v5

[VargaElod23]

Duplicates

• [X] I have searched the existing issues

Related page

https://mui.com/material-ui/guides/interoperability/

Kind of issue

Missing information

Issue description

We had a very simple approach to development:

• We have a component library built with MUI v5
• We are implementing an app using MUI and the component library from above.
• Both expose their themes.

Conflict

In the scenario above, with the information available, there is no solution about tackling the jss generation and miss-insertion as in production code the generated jss classes are misimported and the styles are broken.

Solution

After days of research and multiple tens of tries, we found the aliasing part of the legacy documentation.

const generateClassName = createGenerateClassName({
  productionPrefix: 'yourPrefix',

...

<StylesProvider generateClassName={generateClassName}>
      <ThemeProvider theme={theme}>{children}</ThemeProvider>
    </StylesProvider>
});

As it seems, that's the only thing that solved our styling conflict. Please reintroduce it in the MUI v5 docs.

Context 🔦

No response

[siriwatknp]

Thanks for the feedback but I believe that the page is still there (in v5) > https://mui.com/system/styles/api/#creategenerateclassname-options-class-name-generator.

Note that @mui/styles v5 is considered a legacy package.

[siriwatknp]

Feel free to close the issue if that link helps or any suggestion is very welcome.

[VargaElod23]

Is there a way to actually mention a solution to this problem inside the non-legacy documentation? It could spare hours if not days of research for the next interested peer.

[siriwatknp]

Is there a way to actually mention a solution to this problem inside the non-legacy documentation? It could spare ours if not days of research for the next interested peer.

Definitely yes, which page do you think it is the best place to mention it?

[VargaElod23]

Is there a way to actually mention a solution to this problem inside the non-legacy documentation? It could spare ours if not days of research for the next interested peer.

Definitely yes, which page do you think it is the best place to mention it?

In my opinion, defo the interoperability page I added on the issue, but it feels like a new page called "Solving style generation ordering" or "Working with multiple MUI packages", or something like that would be even better because then Google searches would directly pick that up and return it on hits.

[oliviertassinari]

In my opinion, defo the interoperability page I added on the issue

@VargaElod23 This page is for using Material UI with other styling libraries. This seems unrelated to the problem that you faced. To me, it makes more sense to have this covered in the legacy style documentation as the problem is coming from using it. I wonder if the problem is not about #15914.

[VargaElod23]

It might be related, honestly, however, I think that there should be a place for this to be specified either on the migration part of the docs or in the new one too. 👍🏼

In my opinion, defo the interoperability page I added on the issue

@VargaElod23 This page is for using Material UI with other styling libraries. This seems unrelated to the problem that you faced. To me, it makes more sense to have this covered in the legacy style documentation as the problem is coming from using it. I wonder if the problem is not about #15914.

[mapache-salvaje]

I'm going to close this issue as not planned, because the solution is documented in the correct place. If it's difficult to find, it's because it concerns a very outdated legacy solution that we don't recommend using. The doc itself could be improved, but it's a very low priority, and it doesn't belong in the Material UI docs because it's not a part of Material UI.