Details of bundle changes

Generated by 🚫 dangerJS against eeb65be

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

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)

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.

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?

I did the renaming

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)?

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.

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

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

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,
          },
        },
        [...]
      ],
    },
  },
});

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

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.

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.

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

Fair point.

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...

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)...