Component Library Architecture
Date: May 5, 2025Version: 1.0.0
1. Architecture Overview
1.1 Core Architecture
The Component Library architecture combines visual and interactive components in a domain-driven organization structure, supporting the critical path implementation outlined in PRD 3.1.1.2 Architectural Principles
- Domain-Driven Organization: Components organized by business domain first
- Component Composition: Complex components built by composing simpler ones
- Separation of Concerns: Logic separated from presentation
- Accessibility: WCAG 2.1 AA standards throughout
- Performance: Server-first approach with selective client components
- Maintainability: Clear documentation and testing
- Reusability: Components designed for reuse across domains
1.3 Domain Organization
2. Component Categories
2.1 Visual Components
Visual components focus on presentation and styling, with limited interactivity:- Marketing Components: Landing page elements (header, hero, CTA)
- Marketplace Components: Builder cards, grids, and discovery interfaces
- Profile Components: Profile headers, cards, and information displays
- Trust Components: Validation badges, testimonials, and trust indicators
2.2 Interactive Components
Interactive components focus on user interactions and state management:- Form Components: Inputs, selects, checkboxes, validation
- Navigation Components: Tabs, accordions, dropdowns, menus
- Overlay Components: Modals, dialogs, popovers, tooltips
- Selection Components: Date pickers, time selectors, multi-select
2.3 Component Hierarchy
The architecture follows a layered approach:Components follow a strict dependency hierarchy to prevent circular dependencies. Domain components can depend on shared UI components, but shared UI components cannot depend on domain components.
3. Magic UI Pro Integration
3.1 Integration Approach
Magic UI Pro components will be installed directly using the shadcn-ui pattern:We will NOT migrate components from
/components/historic-magicui/. All components will be fresh installations.3.2 Component Customization
Magic UI Pro components can be customized through:- Tailwind Utilities: Apply Tailwind classes for styling
- Props Configuration: Modify behavior through component props
- Theme Configuration: Adjust theme variables in Tailwind config
- Component Extension: Create new components that extend Magic UI
3.3 Priority Magic UI Components
| Component | Variant | Primary Domain | Purpose |
|---|---|---|---|
| Header | 2 | Marketing | Main navigation |
| Hero | 1 | Marketing | Landing page banner |
| Social Proof | 1 | Trust | Display trusted partners |
| Feature Scroll | 1 | Marketing | Showcase features |
| Animated Card | 7, 9, 10 | Marketplace, Profile | Display builders/profiles |
| Call to Action | Multiple | Marketing | Drive conversions |
4. State Management
4.1 State Management Approach
The architecture uses React’s built-in state management:- Local Component State:
useStatefor component-specific state - React Context: For shared state across component trees
- Custom Hooks: For encapsulating reusable state logic
- Form Library:
react-hook-formwith Zod for validation
4.2 Key State Patterns
- Container/Presenter Pattern: Separate logic from presentation
- Lifting State Up: Parent components manage shared state
- Derived State: Calculate state from props/state with
useMemo - Context Providers: Domain-specific context providers
When implementing a component with state, first consider if the state could be managed by a parent component or a dedicated hook.
5. Component Implementation
5.1 Implementation Timeline
5.2 Component Implementation Priorities
Following PRD 3.1 critical path:- Landing Page: Marketing components - fastest path to value
- Marketplace: Builder discovery components - critical for revenue
- Liam’s Profile: Profile components - essential for booking
- Booking System: Calendar and form components - revenue generation
5.3 Testing Strategy
- Unit Testing: Component functionality and props
- Integration Testing: Component interactions
- Accessibility Testing: WCAG 2.1 AA compliance
- Visual Testing: Component appearance and responsiveness
6. Type System Integration
6.1 Standardized Component Props
All components follow standardized prop interfaces defined in/lib/types/component-types.ts:
6.2 Component Type Patterns
- UI Components: Extend base interfaces with variant support
- Domain Components: Include domain-specific data types
- Polymorphic Components: Support multiple element types
- Loading States: Consistent skeleton UI patterns
See the Type System Documentation for comprehensive guidelines on component prop standardization.
6.3 Variant System
Components use standardized variant and size systems:7. Code Quality and Standards
To ensure high-quality, maintainable component code:- TypeScript: Strict typing for all component props and state using standardized interfaces
- JSDoc: Documentation for all components and their props
- Storybook: Visual documentation and testing
- Automated Tests: Unit and integration tests with high coverage
- CI/CD: Automated testing and deployment workflows
- Type Safety: Zero TypeScript errors in component implementations
All components should have at least 90% test coverage, thorough documentation, and follow the standardized type system patterns.