Unit
- Definition: A component is a self-contained, reusable piece of a design system that encapsulates a specific function or visual element. Examples include buttons, cards, modals, and navigation bars. Components have clear inputs (props or parameters) and outputs (events or rendered output).
- Characteristics: Components are independent, reusable, composable, and maintainable. Independence means a component does not rely on external styles or scripts beyond its own scope. Reusability implies the component can be used in multiple contexts with different configurations.
- Component vs. Element: An element is a basic HTML tag (e.g.,
<div>), while a component is a higher-level abstraction that may combine multiple elements with behavior. A button component may include an icon, label, and hover state. - Benefits: Components improve development speed, consistency, and scalability. Teams can build pages by assembling pre-tested components rather than writing custom code each time. This reduces bugs and accelerates design handoffs.
- Design System Role: Components form the atomic units of a design system. They are governed by design tokens (colors, typography, spacing) and follow predefined interaction patterns. A well-structured component library serves as the single source of truth.
- Real-World Analogy: Think of components as Lego bricks. Each brick has a standard connection interface, can be used in many models, and can be combined with others to create complex structures. The design system provides the brick catalog.
- Common Pitfalls: Over-engineering a component to handle every possible edge case makes it complex and hard to maintain. Start with the 80% use case and extend later. Also, avoid making components too large or too small.
- Component Lifecycle: Components are created, used, and potentially deprecated. They evolve through versioning. A component library requires governance to track changes, deprecate old versions, and communicate updates to teams.
- Testing Strategies: Unit tests verify a component's isolated behavior, integration tests confirm it works with other components, and visual regression tests catch unintended style changes. Aim for high coverage on critical paths, but prioritize user-facing interactions and edge cases to ensure reliability.
- Accessibility Considerations: Components must support keyboard navigation, screen reader announcements, and sufficient color contrast. Use semantic HTML roles like button or listbox, and provide ARIA attributes when needed. Test with real assistive technology to validate that all users can interact equally.
- Documentation Best Practices: Maintain a living style guide that shows each component's props, examples, and usage guidelines. Include code snippets, live previews, and a changelog. Good documentation reduces onboarding time and helps teams adopt components correctly without repeated questions.
Design Principle
Principle: Single Responsibility Principle (SRP)
Definition: A component should have one primary responsibility. It should do one thing and do it well. For example, a dropdown component handles selection, not search or filtering; those belong in separate components.
Application: When designing a card component, separate the image, title, and action button into distinct sub-components if they can be reused independently. The card component composes them, but each sub-component has its own responsibility.
Quick Revision
- A component is a self-contained, reusable UI unit with defined inputs and outputs.
- Key characteristics: independent, reusable, composable, maintainable.
- Components differ from basic elements by encapsulating behavior and styles.
- Benefits include consistency, speed, and scalability.
- The Single Responsibility Principle guides component scope to avoid over-engineering.