Theme overrides do not work for classes defined for custom component in withStyles

[oakhtar147]

I have a use case where I have defined classes for a custom component and inject those using the withStyles HOC. My classes depend heavily on the props passed to the component. However, I would also like to be able to override these classes using the global theme's overrides object.

• The issue is present in the latest release.
• I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

Let me explain by showing the code:

const styles = (theme: Theme) =>
  createStyles({
    Appbar: ({ backgroundColor }: ComponentProps) => ({
        backgroundColor,
        // other styles
    }),
    // other classes...
});

This Appbar class is depending on the backgroundColor prop. That is why the class is a callback that returns the style object. Makes sense. I inject the classes like this:

export default withStyles(styles, {
  name: 'Component',
})(Component);

Now in global theme's overrides, I would like to be able to override this class. I will do it something like this:

const theme = createTheme({
    overrides: {
         Component: {
             Appbar: {
                 backgroundColor: 'black',
             },
         } ,
      },
     // my large theme...
});

Unfortunately, this override will not work, and I will lose the styles that were defined in the component itself as well. If I remove the prop from the component class itself (making it independent of props) and a simple style object, the theme override works.

The strange thing is that the callback function that returns the style object is never called if I have overrides defined for that class. That is why I would also lose the class defined within the component itself.

Expected Behavior 🤔

The overrides classes should override the component level class, regardless if the component level class is a props dependent callback that returns the style object, or the style object itself.

Using material-ui: ^4.12.3

[azz0r]

Theming is flat out broken right now

[oakhtar147]

The workaround is to make the individual CSS properties dependent on the props, instead of the whole class object.

const styles = (theme: Theme) =>
  createStyles({
    Appbar: {
        backgroundColor: (props: ComponentProps) => props.backgroundColor,
        // other styles
    },
    // other similar classes...
});

You only have to type the props once, in the rest of the classes it is automatically inferred then.

[PabloLION]

Hi, @oakhtar147,

• When checking a checkbox - [ ], its better not to leave a space before the x, like this - [x].
• You checked The issue is present in the latest release and you have material-ui: ^4.12.3 , AFAIK, the latest version is 5.0.3
• I'm having the same problem that my TSlint is giving this error:

  (alias) withStyles(stylesCreator: any, options?: object | undefined): never
  ---
  This expression is not callable.
    Type 'never' has no call signatures.ts(2349)
  

  I guess we are facing different bugs?

[oakhtar147]

Hi @Pablion,

• I have fixed the checkboxes, thank you for pointing it out.
• The latest stable version of @material-ui/core is 4.12.3. You can confirm this by either looking into their NPM page or run npm info @material-ui/core | grep latest in your project's root dir.
• No, we do not have the same bugs; however, I might be able to help if you could elaborate more, perhaps show the styles you have created.

Thanks.

[PabloLION]

Thank you for the reply @oakhtar147,

• Nice to see you fix the problems.
• Truely, the @material-ui is still with version 4.x.x but I think they are moving on @mui with version 5.x.x.
• Thanks for offering the help. I already resolved it: I imported in MUIv5 both withTheme() and withStyle() from @mui/material, but they are moved to @mui/styles.
  By the way, I like your personal website a lot!

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

Note

@oakhtar147 How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.