[poll] Rename of the components prop to slots

[michaldudak]

We've discussed the advantages and disadvantages of renaming the components/componentsProps props in #33416. It's time to make a decision if we want to proceed with this further.

[samuelsycamore]

I voted to rename components to slots and use camelCase in fields because I think it's a great opportunity to improve the learning curve for new users and make the DX more intuitive for everybody.

• Though it deviates from terminology that already exists in the React ecosystem, I think that the concept of slots within components makes a lot more sense than how we currently describe it: components within components that we usually refer to as slots but also sometimes subcomponents, interior components, or just components—and also they can be HTML elements so not technically always components in the sense that we mean it elsewhere. 😅
  • It's much easier (for me) to conceptualize it like this: a component (Slider) contains slots (root, thumb, track etc.) that you can customize with the slots prop.
• This change would also help reinforce (as I understand it) the difference between the component prop and what we're currently calling components—if you only need to customize the root (and it has no interior slots), then you're essentially overriding the component as a whole, so use component; but when you're working with a more complex component and you need to dig deeper into the interior structure, then you can customize the slots.
• I prefer camelCase for the consistency. It's unintuitive to use root in some places and Root in others.

Curveball: whether slots or components, I think that the corresponding *Props prop should be slotProps or componentProps rather than slotsProps and componentsProps. This would be the grammatically correct way to describe it in English: slot props / component props. (e.g. "Slot props are the props for the slots." You would never say "Slots props are the props for the slots.")

[michaldudak]

I think that the corresponding *Props prop should be slotProps or componentProps rather than slotsProps and componentsProps. This would be the grammatically correct way to describe it in English: slot props / component props. (e.g. "Slot props are the props for the slots." You would never say "Slots props are the props for the slots.")

Good point! I won't change the poll, but if we decide to rename, I'll use slotComponents.

[mbrookes]

Would it make sense for the fields be made case insensitive for backward compatibility if we decide to change the casing?

[oliviertassinari]

Agree, anything that helps us to slowly make these changes would be a win. We are out of breaking change credits since the v4 -> v5 release. For example, taking two years to entirely phase the old name out doesn't sound bad. For examples, class components are still working with React.

[michaldudak]

Yes, whatever we decide to do, we're going to continue supporting the current API (see #33416 (comment))

[mnajdova]

I feel like there are two different polls happening. Renaming component -> slot and using camel case vs pascal case. I am mentioning this because the final results may be misleading. For example people not being in agreement on the casing, but in favor of slots or vice versa :)

[LukasTy]

Just chiming in. I've voted for option 2 because we get all the benefits with a bit less breaking changes in sensitive case - casing.
Going with option 2 we still leave users the option to define their components with the same name as the slot and "stay sane". 😃

const Root = () => <div className="root">root</div>;
...
<Input
  slots={{ Root }}
/>

And regarding the slots vs components debate, I might be biased, but other big industry players have successfully went with slots and IMHO are reaping benefits of clear naming.

• Vue (named) slots
• Svelte named slots

[yishay-at-bay]

Hi
I wanted to ask something regarding this discussion
MUI is using slots for overriding some parts of a given component. Is there any advantage of using slots approach over something like render prop approach to make parts of the component override-able?
For example, is this

interface CardProps {
  cardContentComponent: React.FC<unknown>;
  cardContentComponentProps: Record<string, unknown>;
}

const Card: React.FC<CardProps> = ({
  cardContentComponent: CardContentComponent,
  cardContentComponentProps,
}) => {
  return (
    <div>
      <h3>Card Title</h3>
      <CardContentComponent {...cardContentComponentProps} />
    </div>
  );
};

const p = { text: "hi there" };

const App: React.FC = () => {
  return (
    <div>
      <Card cardContentComponent={CardContent} cardContentComponentProps={p} />
    </div>
  );
};

better than this?

interface CardProps {
  cardContentComponent: React.ReactElement;
  // or
  cardContentComponent: () => React.ReactElement;
}

const Card: React.FC<CardProps> = ({ cardContentComponent }) => {
  return (
    <div>
      <h3>Card Title</h3>
      {cardContentComponent}
      // or
      {cardContentComponent()}
    </div>
  );
};

const App: React.FC = () => {
  return (
    <div>
      <Card cardContentComponent={<CardContent text={"hi there"} />} />
      // or
      <Card cardContentComponent={() => <CardContent text={"hi there"} />} />
    </div>
  );
};

If it is, then can you give an example that shows why?

Thanks !!

[michaldudak]

There's a discussion about the shape of this API in #21453

[yishay-at-bay]

@michaldudak thanks for your response
I went over 21453 and read the interesting discussion.
I saw that here it says that the render prop proposal was declined due to readability issues. But here I see that it says that with render props

React loses the ability to figure out if the component needs to be re-rendered since it is no longer a component but a function call

Do you know if using something like
props.renderLabel({ className: 'label' })
over something like
<Label className="label" />
is a performance downgrade?

And in general, the discussion doesn't mention much performance/rendering differences between the different approaches (like the examples I used here). Do you know if there are some?

[michaldudak]

I don't know it yet, but we are revisiting this topic, and I'm going to measure the differences.