Problem with the latest MUIv5 and classes/withStyles overrides of nested elements

[garronej]

Problem with the latest MUIv5 and classes/withStyles overrides of nested elements

[garronej]

OK, thank you for the extra details.
I was making sure there wasn't anything I can do for you and I am afraid this is effectively the case.

In defense of the MUI team, if they are facing all theses specificity issues it is because they are allowing users to use styled-component instead of @emotion as underlying style engine. ref. It makes their job 10 times harder, I am not sure it's worth it.

[synaptiko]

Got it, I understand it's not an easy job to support customization, especially with more than one CSS engine. In any case, thanks for you help, feel free to close this issue and let's see if someone from MUI can help or if we just need to refactor the code to increase specificity.

[synaptiko]

I checked MUI's issues as well and the only partially related thing I found is mui/material-ui#30727

But it's about "state" rules, while in my case I'm overriding sub-component (slot).

I also took a look on the implementation of Chip to see how classes "resolution" is implemented but I got lost in it. But I can see now that they internally generate styles with specificity 2 for the sub-components: https://github.com/mui/material-ui/blob/master/packages/mui-material/src/Chip/Chip.js#L139

But then I'm not sure why classes is exposed at all, if it only can add new style props. Unless I'm missing something important here 🙂

[garronej]

Hi @synaptiko,

I might be able to do something about it but I am not sure.

Is the problem that the collor in the root take priority over the color in deleteIcon?

PS: Maybe related: #38

[synaptiko]

The issue is specifically about sub-component. Even if color from root is removed, the problem persist. And it's not only about Chip, I had similar issue with a few other components.

Thank you, I'll try to get help from MUI.

[garronej]

Is it that (1) doesn’t take precedence over (2) ?

  deleteIcon: {
    color: theme.palette.primary.contrastText, // (2)
    '&:hover': {
      color: `${theme.palette.primary.contrastText}6`, // (1)
    },
  },

Or is it that neither (1) nor (2) take precedence over an internal MUI style that defines color?

[synaptiko]

@garronej It's about specificity of what's generated by withStyles/makesStyles vs what's used by MUI internally for deleteIcon. I've added :hover only as an additional thing one could override but it's not specific to it. Even without :hover the color is not correct as it can be seen here: https://muiv5-problem-with-classes.vercel.app/

Here are the generated styles:

What's coming from MUI is .mui-hke119 .MuiChip-deleteIcon and what's coming from makeStyles is .tss-wtj64x-deleteIcon. But I would expect classes will merge both under .mui-hke119 .MuiChip-deleteIcon.

[garronej]

I'm interested to have the follow up on this.
And feel free to come back if you think there is something I can do from TSS-react.