Component Composition Over Configuration

We've all seen them: the "God Components." A single <Button /> or <Card /> with 20+ props, half of them optional, creating a configuration nightmare. You start with title, then add hasIcon, then iconPosition, then isLoading... before you know it, you’re debugging a labyrinth of if/else statements inside your JSX.

The "Prop Soup" Problem

Every new prop you add to a component increases its complexity exponentially:

• 🐜 Combinatorial Explosion: 10 boolean props mean 1,024 possible states to test.

• 🐜 Leaky Abstractions: Your component starts caring about things it shouldn't.

• 🐜 Rigidity: Want to add a sub-title? Now you need a subTitle prop and a subTitleStyle prop.

The Solution: Atomic Composition

Instead of trying to predict every future use case with props, give the power back to the developer using the component.

❌ The Configuration Nightmare (Rigid)

TypeScript

<Card 
  title="Project Alpha"
  showIcon={true}
  footerText="Active"
  variant="dark"
/>

✅ The Composition Dream (Flexible)

TypeScript

<Card variant="dark">
  <Card.Header>
    <Icon name="zap" />
    <h2>Project Alpha</h2>
  </Card.Header>
  <Card.Body>...</Card.Body>
  <Card.Footer>
    <Badge status="active" />
  </Card.Footer>
</Card>

Why Composition Wins

1. Inversion of Control: The consumer decides the structure, not the component author.

2. Reduced Surface Area: Your base component only manages state/logic; the layout is handled by the children.

3. No More "Prop Drilling": You don't need to pass a titleClassName through 3 layers just to change a font size.

When to Still Use Props

Props are for state and identity, not for structure.

• 🐜 Use Props for: size, color, isDisabled, onClick.

• 🐜 Use Composition for: Layout, nesting, and complex internal structures.

Conclusion

Think of your components as LEGO bricks, not as pre-built machines. A machine has limited settings; bricks can become anything. Build bricks.