| name | component-patterns |
| description | Modern UI component selection, composition, and theming patterns for web applications. Covers compound components, design tokens, variant systems, responsive patterns, and form architecture derived from 21st.dev SDK, Godly featured products, and current best practices. |
Component-Patterns
Modern UI component patterns for web applications. Component selection, composition, theming, and token systems following current standards (21st.dev SDK, Tailwind, Radix UI).
Scope
Use this skill when:
- You are designing or selecting UI components
- You are building a design token system
- You are implementing theming (dark/light/custom)
- You are planning compound components or variant systems
- You are designing form architectures
- You are defining responsive component strategies
Principles
1. Composition over Inheritance
Build components by assembling small, specialized parts. Props for configuration, children for content, slots for variation.
2. Server-First, Client Where Needed
Server Components as the default. Client Components only for interactivity (state, event handlers, browser APIs).
3. Token-Based Theming
Design tokens (CSS Custom Properties) control all visual aspects. No hardcoding of colors, spacing, or font sizes.
4. Accessibility as Architecture
ARIA roles, keyboard navigation, and focus management are part of the component definition, not an afterthought.
5. Composable Primitives
Base primitives (Button, Input, Text, Box) are unstyled and maximally flexible. Design system components build on top of them.
Rules
Component Structure
- DO: Each component as a single file with a clear export. One component = one responsibility.
- DO: Explicitly type the props interface (TypeScript). Zod schemas for validated inputs.
- DO: Compound components for complex UI elements:
<Card> <Card.Header /> <Card.Body /> <Card.Footer /> </Card> - DO: Variants with class-variance-authority (cva) instead of conditional classes.
- DON'T: Components with more than 10 props. Split when responsibilities grow too many.
- DON'T: Runtime CSS-in-JS. Tailwind CSS or CSS Modules for static styles.
- DON'T: Div soup. Use semantic HTML elements (section, article, nav, header, footer, main).
Theming and Design Tokens
- DO: Three-tier token system:
- Global Tokens: Raw values (
colors.blue.500,spacing.4,radius.md) - Semantic Tokens: Purpose-bound (
color.primary,color.surface,spacing.section) - Component Tokens: Specific (
button.bg,card.padding,input.border)
- Global Tokens: Raw values (
- DO: Theme switching via CSS Custom Properties with a
dataattribute or class onhtml/body. - DO: Dark/light as minimum. Optionally: high contrast, brand-specific themes.
- DON'T: Inline styles for themeable values. Always reference tokens.
- DON'T: Token names that describe colors (
--blue-500). Use semantic names (--color-primary).
Form Components
- DO: Schema-driven forms: Zod schemas define fields and validation.
- DO: React Hook Form or similar for performance (uncontrolled components).
- DO: Consistent field anatomy: Label > Input > Helper Text > Error Message.
- DON'T: Custom selects without keyboard support. Use native Select or Radix UI Select.
- DON'T: Forms without loading and success states after submit.
Responsive Components
- DO: Container queries for component-based responsiveness.
- DO: Mobile variants as dedicated states (chat panel becomes fullscreen, sidebar becomes drawer).
- DO: Touch targets at least 44x44px on mobile.
- DON'T: Hover-dependent interactions without a touch alternative.
- DON'T: Horizontal scrolling in components on mobile (exception: carousels).
Extended rules and code examples: see references/implementation.md
Patterns
| Pattern | Usage | Core Idea |
|---|---|---|
| Three-Panel Layout | Dashboards, chat apps | Navigation (240px) + Content (flex) + Context (320px) |
| Progressive Disclosure Card | Complex data, API responses | Summary > Details > Raw Data |
| Form-Agent Hybrid | Form assistants | Form left, chat right, agent populates fields |
| Real-Time Status Dashboard | Monitoring, DevOps | Live updates via WebSocket/SSE, color-coded tiles |
| Skill Configuration Panel | Agent setup | System prompt + skill library + deploy button |
Detailed pattern descriptions: see references/patterns.md
Anti-Patterns
- God Component -- One component for chat, tools, form, and navigation simultaneously. Split it up.
- Prop drilling for theme -- Theme values passed through 5+ levels. Use context or CSS Custom Properties.
- Client-side everything -- Everything as a Client Component. Use Server Components for static content.
- Inline styles for layout --
style={{ marginTop: 20 }}instead of token-based utilities. - Modal for everything -- Prefer inline expansion, drawers, or panels.
- Uncontrolled state explosion -- Use a central state store or server state (React Query/SWR).
- Hardcoded breakpoints -- Define breakpoint tokens in the theme configuration.
- Missing error boundaries -- Place React Error Boundaries around critical sections.
Checklist
- Every component has a typed props interface (TypeScript)
- Compound components for complex elements (Card, Dialog, Tabs)
- Variants with cva or similar system
- Design tokens in three tiers: global, semantic, component
- Theme switch via CSS Custom Properties, not JS runtime
- Forms use Zod schemas for validation
- Server Components as default, client only when needed
- Container queries for component-based responsiveness
- Error boundaries around critical UI sections
- Mobile touch targets at least 44x44px
- Keyboard navigation for all interactive elements
- ARIA roles and labels for screen readers
- Semantic HTML elements instead of div soup
Cross-References
design-trends-- Trends influencing component design (motion, dark mode)ui-patterns-- UI patterns implemented as componentsvisual-direction-- Visual tokens (colors, typography, spacing) for the token systemagent-ui-design-- Agent-specific components (chat, tools, streaming)accessibility-- Accessibility requirementsresponsive-design-- Breakpoint strategies and container queries