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

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

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