[theme] Rename theme keys to defaultProps and styleOverrides

[mnajdova]

This PR continues the work from #22293 by applying the following renaming:

• props => defaultProps
• overrides => styleOverrides
• variant's styles => style

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against eeb65be

[mnajdova]

The changes to the variants are not part of v4 theme, so that logic was removed

[eps1lon]

Since it isn't restricted to CSS I'd prefer a more generic name such as stylesOverrides

[oliviertassinari]

Since it isn't restricted to CSS I'd prefer a more generic name such as stylesOverrides

This would match the vision in https://react-select.com/styles. Maybe?

• props => defaultProps
• overrides => styleOverrides
• variants.styles => variants.style

[mnajdova]

Regarding style vs css wording, there was a #21923 (comment) for it that I think made sense, as with html style you cannot use any sub-selector, or pseudo elements, so it may sound confusing, but css gives this association by default.

This was the only reason why I went for css, but I would be fine with also using styleOverrides and styles, as long we don't mix up both of them (style for one and css for the other)

[oliviertassinari]

Right, the above proposal is in opposition with #21923 (comment). It's motivated by:

• we don't write CSS, but an object with multiple values that are converted into CSS, later on.
• defaultProps because if we allow the same object configuration to be used in the theme or at the component level, it would be confusing.

[mnajdova]

I would say then let's go with the ones proposed from @oliviertassinari

props => defaultProps
overrides => styleOverrides
variants.styles => variants.style

Will update the PR later. @eps1lon do you agree with these names?

[mnajdova]

I did the renaming

[mbrookes]

variants.styles => variants.style

A bit late to the party (sorry) considering that @mnajdova has already made the change, but I'm not sure about that one. variants.styles feels more natural (to me at least), especially alongside variants.props. Isn't it a list of styles (plural)?

[mnajdova]

variants.styles => variants.style

A bit late to the party (sorry) considering that @mnajdova has already made the change, but I'm not sure about that one. variants.styles feels more natural (to me at least), especially alongside variants.props. Isn't it a list of styles (plural)?

@mbrookes not really, we support here only styles for the root, which are applied based on the given props.

[mnajdova]

That makes sense @oliviertassinari let me revert my reverted changes :D

[mnajdova]

I've updated the PR description to reflect current state of things, I think we are all on the same page now 👍

[mbrookes]

It's not the case of variant.styles, it takes a single value

That isn't true:

https://github.com/mui-org/material-ui/pull/22347/files#diff-7df98e40ad908a04619a4dbfbabab223L25-L29

const theme = createMuiTheme({
  components: {
    MuiButton: {
      variants: [
        {
          props: { variant: 'dashed' },
          styles: {
            textTransform: 'none',
            border: `2px dashed ${defaultTheme.palette.primary.main}`,
            color: defaultTheme.palette.primary.main,
          },
        },
        [...]
      ],
    },
  },
});

[mnajdova]

Those are different variants, we are still always specifying style only for the root, not the slots for for example

[mbrookes]

I highlighted a single variant with multiple styles, but GitHub screws up the page scroll. While you were replying, I was editing the comment to include the same example, in which styles contains multiple... styles.

[eps1lon]

We use the plural in all other places

In all these cases, we accept an object with multiple keys (root, label, etc), it's not the case of variant.styles, it takes a single value. Also, consider the singular or StyleSheet.

I was not arguing about variant.styles but styleOverrides. I agree with variant.style which mirrors the style attribute on HTML elements.

[mbrookes]

variant.style [...] mirrors the style attribute on HTML elements.

Fair point.

[mnajdova]

After some thoughts, it look strange that on one place we have style and in the other stylesOverrides. As a developer I would not like to think when I type whether I should use style or styles. styleOverrides as a term already has the plurality in itself, so I am leaning forward towards using styleOverrides instead, so that at least we are consistent with the style wording...

[mbrookes]

I'm inclined to agree. stylesOverrides may be technically more correct, but it's unlikely to be the first thing a developer tries.

I think we should go with the simplest most consistent alternative, in the spirit of: "Don't make me think" (design affordance), "principal of least surprise" (UI/UX design), "programmer happiness" (Ruby programming language)...

[jimmyandrade]

LGTM