Skip to main content

Component Library Architecture

Date: May 5, 2025
Version: 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

  1. Domain-Driven Organization: Components organized by business domain first
  2. Component Composition: Complex components built by composing simpler ones
  3. Separation of Concerns: Logic separated from presentation
  4. Accessibility: WCAG 2.1 AA standards throughout
  5. Performance: Server-first approach with selective client components
  6. Maintainability: Clear documentation and testing
  7. Reusability: Components designed for reuse across domains

1.3 Domain Organization

/components
├── marketing/       # Landing page components
├── marketplace/     # Builder discovery components
├── profile/         # User profile components
├── trust/           # Trust indicators
├── booking/         # Scheduling components
├── payment/         # Payment processing
├── learning/        # Learning experience
├── community/       # Community features
├── ui/              # Shared UI components
└── providers/       # Context providers

2. Component Categories

2.1 Visual Components

Visual components focus on presentation and styling, with limited interactivity:
  1. Marketing Components: Landing page elements (header, hero, CTA)
  2. Marketplace Components: Builder cards, grids, and discovery interfaces
  3. Profile Components: Profile headers, cards, and information displays
  4. Trust Components: Validation badges, testimonials, and trust indicators

2.2 Interactive Components

Interactive components focus on user interactions and state management:
  1. Form Components: Inputs, selects, checkboxes, validation
  2. Navigation Components: Tabs, accordions, dropdowns, menus
  3. Overlay Components: Modals, dialogs, popovers, tooltips
  4. Selection Components: Date pickers, time selectors, multi-select

2.3 Component Hierarchy

The architecture follows a layered approach:
Page Components


Domain Components


Shared UI Components


Base Components (Magic UI Pro)
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:
pnpm dlx shadcn@latest add "https://magicui.design/r/[component].json"
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:
  1. Tailwind Utilities: Apply Tailwind classes for styling
  2. Props Configuration: Modify behavior through component props
  3. Theme Configuration: Adjust theme variables in Tailwind config
  4. Component Extension: Create new components that extend Magic UI

3.3 Priority Magic UI Components

ComponentVariantPrimary DomainPurpose
Header2MarketingMain navigation
Hero1MarketingLanding page banner
Social Proof1TrustDisplay trusted partners
Feature Scroll1MarketingShowcase features
Animated Card7, 9, 10Marketplace, ProfileDisplay builders/profiles
Call to ActionMultipleMarketingDrive conversions

4. State Management

4.1 State Management Approach

The architecture uses React’s built-in state management:
  1. Local Component State: useState for component-specific state
  2. React Context: For shared state across component trees
  3. Custom Hooks: For encapsulating reusable state logic
  4. Form Library: react-hook-form with Zod for validation

4.2 Key State Patterns

  1. Container/Presenter Pattern: Separate logic from presentation
  2. Lifting State Up: Parent components manage shared state
  3. Derived State: Calculate state from props/state with useMemo
  4. 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:
  1. Landing Page: Marketing components - fastest path to value
  2. Marketplace: Builder discovery components - critical for revenue
  3. Liam’s Profile: Profile components - essential for booking
  4. Booking System: Calendar and form components - revenue generation

5.3 Testing Strategy

  1. Unit Testing: Component functionality and props
  2. Integration Testing: Component interactions
  3. Accessibility Testing: WCAG 2.1 AA compliance
  4. 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:
// All components extend base interfaces
export interface ComponentProps extends 
  BaseComponentProps,
  WithChildrenProps,
  DisableableProps {
  // Component-specific props
}

6.2 Component Type Patterns

  1. UI Components: Extend base interfaces with variant support
  2. Domain Components: Include domain-specific data types
  3. Polymorphic Components: Support multiple element types
  4. 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:
export type StandardSize = 'xs' | 'sm' | 'md' | 'lg' | 'xl';
export type ButtonVariant = 'default' | 'primary' | 'secondary' | 'destructive';

7. Code Quality and Standards

To ensure high-quality, maintainable component code:
  1. TypeScript: Strict typing for all component props and state using standardized interfaces
  2. JSDoc: Documentation for all components and their props
  3. Storybook: Visual documentation and testing
  4. Automated Tests: Unit and integration tests with high coverage
  5. CI/CD: Automated testing and deployment workflows
  6. 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.

See Also