Composition over configuration in component APIs

Every enterprise component eventually reaches a fork: add another boolean prop, or expose a slot and let the caller decide. The choice defines whether the component is a product or a prison.

The prop explosion

A Card with 32 props is not flexible, it's brittle. Every consumer's edge case becomes another prop, another test matrix cell, another line in the migration guide.

tsx// snippet
// configuration, the caller pleads with the component
<Card
  title="…" subtitle="…" icon={<X/>} iconPosition="start"
  actionLabel="…" actionVariant="outline" showDivider hasFooter
  footerAlign="end" densityCompact
/>

The shape that scales

tsx// snippet
// composition, the caller writes intent
<Card>
  <Card.Header>
    <Card.Title>…</Card.Title>
  </Card.Header>
  <Card.Body>…</Card.Body>
  <Card.Footer align="end">
    <Button variant="outline">…</Button>
  </Card.Footer>
</Card>

Fewer props. Sharper primitives. Let composition carry the weight.

When configuration wins

Small, opinionated components (Badge, Avatar) benefit from a tight prop surface. The rule of thumb: if the component contains more than one meaningful region, expose slots. If it's a single atom, ship props.