[core] Using hardcoded pseudo classes versus values coming from classes object

Opening this issue so that we can align on the way we are writing the styles for the pseudo states.

Current Behavior 😯

We have inconsistencies with how we are defining the style for the pseudo states. On some places we use hardcoded classes:

    '&.Mui-disabled': {
      color: theme.palette.action.disabled,
      ...(styleProps.variant === 'outlined' && {
        border: `1px solid ${theme.palette.action.disabledBackground}`,
      }),
      ...(styleProps.variant === 'outlined' &&
        styleProps.color === 'secondary' && {
          border: `1px solid ${theme.palette.action.disabled}`,
        }),
      ...(styleProps.variant === 'contained' && {
        color: theme.palette.action.disabled,
        boxShadow: theme.shadows[0],
        backgroundColor: theme.palette.action.disabledBackground,
      }),
    },

and on other we are using the classes coming from componentClasses[pseudoState], for example:

    /* Styles applied to the root element if `disabled={true}`. */
    [`&.${iconButtonClasses.disabled}`]: {
      backgroundColor: 'transparent',
      color: theme.palette.action.disabled,
    },

Expected Behavior 🤔

We should use the same way for defining styles for the pseudo states, we just need to decide with which one to use. Here is comparison of both:

1. Using hardcoded classes +immediately obvious that it defined styles for pseudo state +easy to copy-paste when overriding -the prefix cannot be easily customized (not implemented currently as a functionality, but it could be 🤷)
2. Using componentClasses[pseudoState] +consistency with how all styles are defined +does not require knowledge of which classes are pseudo states and which are regular classes -~not easily noticeable which styles are for pseudo states, and which are styles for the slots~

I am leaning towards using option 2. everywhere, but I am open for other opinions. Anyway, we should be consistent and use the same everywhere.

[mnajdova]

I’ll create PR to normalize all styles to use 2. componentClasses[pseudoState], seems like it brings more benefits than 1. and we will at least have consistency.

[eps1lon]

Gotcha. Coming back to “-not easily noticeable which styles are for pseudo states, and which are styles for the slots”. This is irrelevant to this issue since the higher specificity is caused by the selector.