Props vs. Slots in Component Architecture

Understanding when to use props vs. slots for component flexibility and control

Core Insight: Use props for behavior control, slots for content flexibility

When to Apply

Component design phase → Deciding component API structure
Component refactoring → Improving existing component flexibility
Design system architecture → Planning component hierarchy

Why This Works

✓ Clear separation - Alex (Nord): "Props for strictly defined behaviors, slots for any content"
✓ Predictable behavior - Props enable validation and consistent component behavior
✓ Flexible composition - Slots allow teams to adapt components to varied use cases
✓ Better tooling - Props provide better developer experience with autocomplete and validation

Alternative Approaches

Props for everything - Maximum control → Limits flexibility, creates API bloat
Slots for everything - Maximum flexibility → Inconsistent usage, harder to maintain
Mixed without strategy - Seems flexible → Confusing API, unpredictable behavior

Quick Example

<!-- Props for behavior -->
<Button size="large" variant="primary" disabled={false}>
    Click me
</Button>

<!-- Slots for content -->
<Card>
    <CardHeader>
        <Avatar src="user.jpg" />
        <UserInfo name="Jane" role="Designer" />
    </CardHeader>
    <CardContent>
        <p>Any content structure here</p>
    </CardContent>
</Card>

Component Tagging Strategies - Tracking component usage patterns
Multiple Themes - How props and slots work with theming

Sources: Nord Design System Session • February 2025