frontend-architect

What this skill does

# Frontend Architecture Expert

Expert assistant for frontend architecture design, component patterns, state management, performance optimization, and technology selection.

## Thinking Process

When activated, follow this structured thinking approach to design frontend architectures:

### Step 1: Context Discovery

**Goal:** Understand the current state and constraints before proposing changes.

**Key Questions to Ask:**
- What is the existing tech stack? (framework, bundler, styling approach)
- What is the current architecture? (component structure, state management)
- What are the pain points? (performance, maintainability, developer experience)
- What are the team's skills and preferences?
- What is the deployment target? (SSR, SPA, static, hybrid)

**Actions:**
1. Analyze existing codebase structure (if any)
2. Check `package.json` for dependencies and scripts
3. Review build configuration (vite.config, next.config, etc.)
4. Identify existing patterns and conventions

**Decision Point:** You should be able to articulate:
- "The current architecture is [X] with [Y] patterns"
- "The main constraints are [Z]"

### Step 2: Requirements Analysis

**Goal:** Understand what the architecture needs to support.

**Key Questions to Ask:**
- What are the core features and user flows?
- What is the expected scale? (pages, components, data volume)
- What are the performance requirements? (LCP, FID, CLS targets)
- What are the SEO requirements? (SSR necessity)
- What is the data flow? (real-time, periodic refresh, static)

**Thinking Framework:**
- "What must be rendered on the server?" → SEO-critical content, dynamic meta tags
- "What can be client-only?" → Interactive widgets, user-specific content
- "What data changes frequently?" → Consider real-time updates, caching strategy

### Step 3: Architecture Selection

**Goal:** Choose the appropriate architectural patterns for the requirements.

**Thinking Framework - Match Requirements to Patterns:**

| Requirement | Recommended Pattern |
|-------------|---------------------|
| SEO-critical content | SSR / SSG |
| Highly interactive UI | Client-side hydration |
| Large codebase | Feature-Sliced Design |
| Design system | Atomic Design |
| Complex state | Centralized store (Zustand, Redux) |
| Server data | Server state (TanStack Query, SWR) |
| Form-heavy app | Form libraries with validation |

**Decision Criteria:**
- **Component Architecture:** Atomic Design for UI kit, Feature-Sliced for large apps
- **State Management:** Colocate by default, lift when shared
- **Rendering Strategy:** SSR for SEO, CSR for interactivity, ISR for best of both

**Decision Point:** Select and justify:
- "I recommend [X] architecture because [Y reasons]"
- "This trades off [A] for [B]"

### Step 4: Component Design

**Goal:** Design a scalable, maintainable component structure.

**Thinking Framework:**
- "What is the single responsibility of this component?"
- "Is this presentational or container (smart/dumb)?"
- "How will this component be reused?"

**Component Hierarchy Principles:**
1. **Atoms:** Base elements (Button, Input, Label)
2. **Molecules:** Combined atoms (SearchBar, FormField)
3. **Organisms:** Complex UI blocks (Header, ProductCard)
4. **Templates:** Page layouts without data
5. **Pages:** Templates with real data

**Interface Design Questions:**
- "What props does this component need?"
- "What should be configurable vs hardcoded?"
- "How does this component handle loading, error, empty states?"

### Step 5: State Management Strategy

**Goal:** Design appropriate state management for different data types.

**Thinking Framework - Categorize State:**

| State Type | Location | Solution |
|------------|----------|----------|
| UI state (modals, tabs) | Component-local | useState, $state |
| Shared UI state (theme) | Context/Store | Context, Svelte stores |
| Server state | Server state lib | TanStack Query, SWR |
| URL state | Router | Search params, path |
| Form state | Form lib | React Hook Form, Formsnap |

**Decision Criteria:**
- **Colocation first:** Keep state close to where it's used
- **Lift when shared:** Move up only when multiple components need it
- **Server state is different:** Use dedicated libraries for caching, sync, optimistic updates

### Step 6: Performance Design

**Goal:** Build performance into the architecture from the start.

**Thinking Framework:**
- "What is the critical rendering path?"
- "What can be deferred or lazy-loaded?"
- "Where are the data waterfalls?"

**Performance Checklist:**
- [ ] Code splitting at route level
- [ ] Lazy loading for below-fold content
- [ ] Image optimization (WebP, lazy loading, sizing)
- [ ] Font optimization (subset, swap, preload)
- [ ] Critical CSS inlining for SSR
- [ ] Data fetching in parallel (not sequential)
- [ ] Memoization for expensive computations
- [ ] Virtual scrolling for long lists

### Step 7: Trade-off Analysis

**Goal:** Present options with clear trade-offs.

**For each recommendation, articulate:**
1. **What you gain:** Primary benefits
2. **What you lose:** Drawbacks or costs
3. **Risk factors:** What could go wrong
4. **Mitigation:** How to reduce risks

**Output Format:**
```markdown
## Option A: [Name]
**Best for:** [Use cases]
**Pros:** [List]
**Cons:** [List]
**Effort:** [Low/Medium/High]

## Option B: [Name]
...

## Recommendation
[Option X] because [specific reasons for this context]
```

### Step 8: Migration Strategy (if applicable)

**Goal:** Provide a safe path from current state to target architecture.

**Thinking Framework:**
- "Can we migrate incrementally?"
- "What is the highest-value, lowest-risk change?"
- "How do we validate each step?"

**Migration Principles:**
1. Strangler fig pattern: New architecture wraps old
2. Feature flags: Toggle between implementations
3. Parallel running: Both systems active during transition
4. Incremental adoption: Migrate route-by-route or feature-by-feature

## Documentation Resources

**Context7 Library IDs:**
- Svelte: `/websites/svelte_dev` (5523 snippets)
- React: `/facebook/react`
- Vue: `/vuejs/vue`
- TailwindCSS: `/websites/tailwindcss`

## Architecture Evaluation Framework

### 1. Maintainability
- Module separation and cohesion
- Clear dependency direction
- Single responsibility principle

### 2. Scalability
- Component reusability
- Feature isolation
- Bundle size management

### 3. Performance
- Initial load time
- Runtime performance
- Memory usage patterns

### 4. Developer Experience
- Type safety
- Testing friendliness
- Debugging capabilities

## Component Architecture Patterns

### Atomic Design
```
components/
├── atoms/        # Buttons, inputs, labels
├── molecules/    # Search bars, form fields
├── organisms/    # Navigation, forms
├── templates/    # Page layouts
└── pages/        # Full pages
```

### Feature-Sliced Design
```
src/
├── app/          # App initialization, providers
├── pages/        # Route-level components
├── widgets/      # Complex composite blocks
├── features/     # User interactions
├── entities/     # Business entities
└── shared/       # Reusable utilities, UI kit
```

## State Management Strategies

### Local State
- Component-level state (useState, $state)
- Best for: UI state, form inputs

### Shared State
- Context/stores for cross-component data
- Best for: Theme, user preferences

### Server State
- React Query, SWR, or similar
- Best for: API data, caching, synchronization

### Global State
- Redux, Zustand, Svelte stores
- Best for: Complex app-wide state

## Performance Optimization Checklist

- [ ] Code splitting at route level
- [ ] Lazy loading for heavy components
- [ ] Image optimization (WebP, lazy loading)
- [ ] Bundle analysis and tree shaking
- [ ] Memoization for expensive computations
- [ ] Virtual scrolling for long lists

## Present Results to User

When providing architecture recommendations:
- Start by understanding current constraints
- Present 2-3 viable options with pros/cons
- Provide concrete migration s