[RFC] Rename of the `components` prop to `slots`

Problem

This is a continuation of #21453. With some hindsight, we have surfaced possible limitations:

1. In the documentation and comments we generally refer to sub-components of a component as “slots”. However, the props to control these slots are called components and componentsProps (as per #21453). We have used “components” so far with the objective to be as close as possible to the React implementation. But is it intuitive?
2. There is an inconsistency in the casing (members of components are Pascal-cased, while members of componentsProps are camel-cased) when comparing the props side-by-side.

<Slider components={{ Root }} componentsProps={{ root: {} }} />

The current casing aims to be consistent with the React conventions. In React components are Pascal-cased while elements props are camel-cased. But is it intuitive?

Solution

Therefore, I propose the following:

1. Rename the components prop to slots.
2. Rename the componentsProps prop to slotProps.
3. Rename the members of slots to use camel-case (e.g. root instead of Root).

Execution

This obviously would be a breaking change. For stable packages, we should introduce a transition period where both sets of props would be available. We will then deprecate the old ones, and finally, remove them in a future major version. We could provide a codemod to aid in the transition.

As MUI Base is not stable yet, we may introduce this change sooner, without a transition period. The library hasn’t been publicly announced yet, so there is an opportunity to introduce this change without impacting many developers.

Advantages

Rename of components and componentsProps

• Better alignment with the terms used throughout the documentation.
• Use of a less ambiguous and generic term (“component” has a much broader meaning than “slot”).
• Shorter words require less typing and take less horizontal space in components’ markup.

Camel-cased slots members

• It’ll be consistent with componentsProps.* . I often cringe when writing a component and having to override componentsProps.root and components.Root
• Pascal-cased props/fields look weird and are not common in JS/TS
• It would match the capitalization we use in for the theme component overrides https://mui.com/material-ui/customization/theme-components/#global-style-overrides.
• I understand the reasoning behind introducing Pascal-cased identifiers (components are written this way by convention). However, what goes into a components.* doesn’t have to be a React component (could be a div, for example). Besides, we don’t actually pass components.* to JSX directly, so we don’t have to rely on it being written in Pascal-case (we usually write const Root = components.Root ?? component ?? 'div')
• We’ve got the component prop, not Component
• It’s easier to type - developers won’t have to press Shift 🙂

Disadvantages

• Developers accustomed to the existing patterns will have to relearn them.
• Introducing breaking changes will require changes to downstream codebases.
• Some could argue that “components” is describing what the prop is doing more precisely. You might have to think twice about what’s the returned type of the “slot” prop, while it could be more intuitive when seeing “components”.

Benchmark

• https://github.com/straw-hat-team/adr/blob/master/adrs/1358452048/README.md

[alexfauquette]

Maybe a dumb proposal, but could we use “component slot” instead of “slot” in the doc and keep the prop naming as it is?

[michaldudak]

Agreed, both make perfect sense.

As for MUI X, @flaviendelangle also mentioned they’ll be affected by these changes. I’m eager to know if you guys consider these changes worth pursuing.