Design reusable components and a frontend component library

Interview framing: A component library should make product teams faster while keeping UX consistent. The hard part is designing APIs that are flexible without becoming vague.

Design principles:

1. Start from real product use cases:

• Extract components after repeated patterns appear.
• Avoid abstracting one-off UI too early.

2. Separate primitives and product components:

• Primitives: Button, Input, Modal, Tooltip, Table.
• Product components: VulnerabilityCard, RiskBadge, AssetSelector.

3. Component APIs:

• Prefer composition for complex components.
• Keep props predictable and typed.
• Avoid boolean prop explosions like primary + danger + outlined + compact.

4. Accessibility:

• Keyboard behavior, focus management, ARIA, labels, and screen reader behavior are part of the component contract.

5. Theming:

• Use design tokens for color, spacing, typography, radius, shadows.
• Support dark mode/high contrast if required.

6. Testing and documentation:

• Unit/component tests for behavior.
• Visual regression for design-sensitive components.
• Storybook or equivalent docs with examples and edge cases.

7. Versioning:

• Communicate breaking changes.
• Provide migration notes or codemods for large changes.

Pitfalls:

• Too much configurability makes components hard to reason about.
• Too little flexibility causes teams to fork or bypass the library.
• Accessibility cannot be patched at the end.