Repository: material-ui
Issue: [RFC] Rename of the `components` prop to `slots`
Labels: discussion,breaking change,package: material-ui,package: base-ui,package: joy-ui,RFC

## 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.

  ```jsx
  <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 :slightly_smiling_face:

## 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