[RFC] The way to override components and slots

What’s the problem? 🤔

Before reading this RFC, please go through #34333 first so that we are on the same page about the meaning of components and slots.

From #33416, and #21453 it seems like we are only talking about slot override (replacing the slot). However, for Material UI and Joy UI, we also need a component override (changing the HTML tag of the slot).

What are the requirements? ❓

• How to override the HTML tag on each slot
• How to replace the slot with a custom React component

Proposed solution 🟢

My proposed solution aims for the least breaking changes. All components (MUI Base, Material UI, and Joy UI) should follow this:

Components with a single slot (root)

• component (existing prop): for changing the root slot’s HTML tag. (I think we should not drop this prop because it will be a huge breaking change)

~For this kind of components, it does not make sense to replace the root slot so having just component prop is cleaner.~ This is not true for MUI Base 🤔.

Components with more than one slot

• component (existing prop): for changing the subcomponent of the root slot (could be an HTML tag or React element).
• slots and slotsProps same as https://github.com/mui/material-ui/issues/33416
• slots.{slot}.component: for changing the subcomponent of the target slot (could be an HTML tag or React element).

To replace the HTML of the slot, use slotsProps={{ listbox: { component: 'div' } }}.

Components that have nested components

See the problem and another example

Flatten the nested component slots with a new name. For example, TextField has Input as a nested component could look something like this:

<TextField
  slotsProps={{
    root: {...},
    inputRoot: { ... },
    inputInput: { ... },
    helperText: { ... }
  }}
/>

[siriwatknp]

Marked this as RFC for Material UI and Joy UI only.

[siriwatknp]

so we should need only one component prop per component.

Yes, the component prop can be considered as a shortcut for slotsProps.component. If both are provided, slotsProps.component should have higher priority. cc @michaldudak

Btw, this is how it already works in Material UI, so I don’t expect big change anyway, unless I am misunderstanding the proposal.

I’d say that I expect big change for Material UI because most components are using another pattern. e.g. Accordion has TransitionComponent and TransitionProps. This will be breaking changes:

// current
<Accordion TransitionComponent={Slide} TransitionProps={{ delay: 100 }} />

// new
<Accordion slots={{ transition: Slide }} slotsProps={{ transition: { delay: 100 } }} />