Back to Details

frontend-architect

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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

步骤1：背景信息挖掘

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]"
目标： 在提出变更前，先了解当前状态与约束条件。
核心问题：
  • 现有技术栈是什么？（框架、打包工具、样式方案）
  • 当前架构是怎样的？（组件结构、状态管理方式）
  • 存在哪些痛点？（性能、可维护性、开发者体验）
  • 团队的技能与偏好是什么？
  • 部署目标是什么？（SSR、SPA、静态站点、混合模式）
行动：
  1. 分析现有代码库结构（如有）
  2. 查看
    package.json
    中的依赖与脚本
  3. 审核构建配置（vite.config、next.config等）
  4. 识别现有模式与约定
决策节点： 你需要能够清晰说明：
  • "当前架构为[X]，采用[Y]模式"
  • "主要约束条件为[Z]"

Step 2: Requirements Analysis

步骤2：需求分析

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
目标： 明确架构需要支持的内容。
核心问题：
  • 核心功能与用户流程是什么？
  • 预期规模如何？（页面数量、组件数量、数据量）
  • 性能要求是什么？（LCP、FID、CLS指标目标）
  • SEO要求是什么？（是否需要SSR）
  • 数据流是怎样的？（实时更新、定期刷新、静态数据）
思考框架：
  • "哪些内容必须在服务器端渲染？" → SEO关键内容、动态元标签
  • "哪些内容可以仅在客户端渲染？" → 交互式组件、用户专属内容
  • "哪些数据更新频繁？" → 考虑实时更新、缓存策略

Step 3: Architecture Selection

步骤3：架构选型

Goal: Choose the appropriate architectural patterns for the requirements.
Thinking Framework - Match Requirements to Patterns:
RequirementRecommended Pattern
SEO-critical contentSSR / SSG
Highly interactive UIClient-side hydration
Large codebaseFeature-Sliced Design
Design systemAtomic Design
Complex stateCentralized store (Zustand, Redux)
Server dataServer state (TanStack Query, SWR)
Form-heavy appForm 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]"
目标： 为需求选择合适的架构模式。
思考框架 - 需求与模式匹配：
需求推荐模式
SEO关键内容SSR / SSG
高交互性UI客户端水化（Client-side hydration）
大型代码库Feature-Sliced Design
设计系统Atomic Design
复杂状态集中式状态管理库（Zustand、Redux）
服务器数据服务器状态管理库（TanStack Query、SWR）
表单密集型应用带验证功能的表单库
决策标准：
  • 组件架构： UI套件采用Atomic Design，大型应用采用Feature-Sliced Design
  • 状态管理： 默认就近托管状态，仅在需要共享时提升层级
  • 渲染策略： SEO场景用SSR，交互场景用CSR，兼顾两者用ISR
决策节点： 选择并说明理由：
  • "我推荐[X]架构，因为[Y理由]"
  • "该方案以[A]为代价换取[B]"

Step 4: Component Design

步骤4：组件设计

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?"
目标： 设计可扩展、可维护的组件结构。
思考框架：
  • "该组件的单一职责是什么？"
  • "它是展示型组件还是容器型组件（智能/纯展示）？"
  • "该组件将如何被复用？"
组件层级原则：
  1. Atoms（原子）： 基础元素（Button、Input、Label）
  2. Molecules（分子）： 原子组合（SearchBar、FormField）
  3. Organisms（有机体）： 复杂UI块（Header、ProductCard）
  4. Templates（模板）： 不含数据的页面布局
  5. Pages（页面）： 填充真实数据的模板
接口设计问题：
  • "该组件需要哪些props？"
  • "哪些内容应该可配置，哪些应该硬编码？"
  • "该组件如何处理加载、错误、空状态？"

Step 5: State Management Strategy

步骤5：状态管理策略

Goal: Design appropriate state management for different data types.
Thinking Framework - Categorize State:
State TypeLocationSolution
UI state (modals, tabs)Component-localuseState, $state
Shared UI state (theme)Context/StoreContext, Svelte stores
Server stateServer state libTanStack Query, SWR
URL stateRouterSearch params, path
Form stateForm libReact 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
目标： 为不同类型的数据设计合适的状态管理方案。
思考框架 - 状态分类：
状态类型存储位置解决方案
UI状态（模态框、标签页）组件本地useState、$state
共享UI状态（主题）Context/状态库Context、Svelte stores
服务器状态服务器状态管理库TanStack Query、SWR
URL状态路由查询参数、路径
表单状态表单库React Hook Form、Formsnap
决策标准：
  • 优先就近托管： 将状态保留在使用它的组件附近
  • 仅在共享时提升： 仅当多个组件需要访问时才提升状态层级
  • 服务器状态特殊处理： 使用专用库处理缓存、同步、乐观更新

Step 6: Performance Design

步骤6：性能设计

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
目标： 从架构层面原生保障性能。
思考框架：
  • "关键渲染路径是什么？"
  • "哪些内容可以延迟加载或懒加载？"
  • "数据瀑布流问题出现在哪里？"
性能检查清单：
  • 路由级别代码分割
  • 可视区域以下内容懒加载
  • 图片优化（WebP、懒加载、尺寸适配）
  • 字体优化（子集化、字体交换、预加载）
  • SSR场景下内联关键CSS
  • 并行数据获取（而非串行）
  • 昂贵计算的记忆化处理
  • 长列表虚拟滚动

Step 7: Trade-off Analysis

步骤7：权衡分析

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
undefined
目标： 展示包含清晰权衡的方案选项。
针对每个推荐方案，需说明：
  1. 收益： 主要优势
  2. 代价： 劣势或成本
  3. 风险因素： 可能出现的问题
  4. 缓解措施： 降低风险的方法
输出格式：
markdown
undefined

Option A: [Name]

选项A：[名称]

Best for: [Use cases] Pros: [List] Cons: [List] Effort: [Low/Medium/High]
最佳适用场景： [适用案例] 优势： [列表] 劣势： [列表] 实施成本： [低/中/高]

Option B: [Name]

选项B：[名称]

...
...

Recommendation

推荐方案

[Option X] because [specific reasons for this context]
undefined
[选项X]，因为[针对当前场景的具体理由]
undefined

Step 8: Migration Strategy (if applicable)

步骤8：迁移策略（如适用）

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
目标： 提供从当前状态到目标架构的安全过渡路径。
思考框架：
  • "我们能否增量迁移？"
  • "价值最高、风险最低的变更是什么？"
  • "如何验证每一步的正确性？"
迁移原则：
  1. Strangler fig模式：新架构逐步包裹旧架构
  2. 功能开关：在不同实现间切换
  3. 并行运行：过渡期间同时运行新旧系统
  4. 增量采用：按路由或功能逐步迁移

Documentation Resources

文档资源

Context7 Library IDs:
  • Svelte: 
    /websites/svelte_dev
    (5523 snippets)
  • React: 
    /facebook/react
  • Vue: 
    /vuejs/vue
  • TailwindCSS: 
    /websites/tailwindcss
Context7库ID：
  • Svelte: 
    /websites/svelte_dev
    （5523个代码片段）
  • React: 
    /facebook/react
  • Vue: 
    /vuejs/vue
  • TailwindCSS: 
    /websites/tailwindcss

Architecture Evaluation Framework

架构评估框架

1. Maintainability

1. 可维护性

  • Module separation and cohesion
  • Clear dependency direction
  • Single responsibility principle
  • 模块分离与内聚性
  • 清晰的依赖方向
  • 单一职责原则

2. Scalability

2. 可扩展性

  • Component reusability
  • Feature isolation
  • Bundle size management
  • 组件复用性
  • 功能隔离
  • 包体积管理

3. Performance

3. 性能

  • Initial load time
  • Runtime performance
  • Memory usage patterns
  • 初始加载时间
  • 运行时性能
  • 内存使用模式

4. Developer Experience

4. 开发者体验

  • Type safety
  • Testing friendliness
  • Debugging capabilities
  • 类型安全性
  • 测试友好性
  • 调试能力

Component Architecture Patterns

组件架构模式

Atomic Design

Atomic Design

components/
├── atoms/        # Buttons, inputs, labels
├── molecules/    # Search bars, form fields
├── organisms/    # Navigation, forms
├── templates/    # Page layouts
└── pages/        # Full pages
components/
├── atoms/        # 按钮、输入框、标签
├── molecules/    # 搜索栏、表单字段
├── organisms/    # 导航栏、表单
├── templates/    # 页面布局
└── pages/        # 完整页面

Feature-Sliced Design

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
src/
├── app/          # 应用初始化、提供者
├── pages/        # 路由级别组件
├── widgets/      # 复杂复合块
├── features/     # 用户交互功能
├── entities/     # 业务实体
└── shared/       # 可复用工具、UI套件

State Management Strategies

状态管理策略

Local State

本地状态

  • Component-level state (useState, $state)
  • Best for: UI state, form inputs
  • 组件级状态（useState、$state）
  • 最佳适用：UI状态、表单输入

Shared State

共享状态

  • Context/stores for cross-component data
  • Best for: Theme, user preferences
  • 跨组件数据的Context/状态库
  • 最佳适用：主题、用户偏好

Server State

服务器状态

  • React Query, SWR, or similar
  • Best for: API data, caching, synchronization
  • React Query、SWR或同类库
  • 最佳适用：API数据、缓存、同步

Global State

全局状态

  • Redux, Zustand, Svelte stores
  • Best for: Complex app-wide state
  • Redux、Zustand、Svelte stores
  • 最佳适用：复杂的应用级状态

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
  • 路由级别代码分割
  • 重型组件懒加载
  • 图片优化（WebP、懒加载）
  • 包体积分析与摇树优化
  • 昂贵计算的记忆化处理
  • 长列表虚拟滚动

Present Results to User

向用户展示结果

When providing architecture recommendations:
  • Start by understanding current constraints
  • Present 2-3 viable options with pros/cons
  • Provide concrete migration steps
  • Consider team size and skill level
  • Include diagrams for complex architectures
提供架构推荐时：
  • 先了解当前约束条件
  • 展示2-3个可行选项及优缺点
  • 提供具体的迁移步骤
  • 考虑团队规模与技能水平
  • 复杂架构需包含示意图

Troubleshooting

故障排查

"Bundle too large"
  • Analyze with webpack-bundle-analyzer or vite-plugin-visualizer
  • Implement code splitting and lazy loading
  • Check for duplicate dependencies
"State management complexity"
  • Consider colocation (keep state close to usage)
  • Evaluate if global state is truly needed
  • Look into server state solutions for API data
"Component coupling issues"
  • Apply dependency inversion principle
  • Use composition over inheritance
  • Define clear component interfaces
"包体积过大"
  • 使用webpack-bundle-analyzer或vite-plugin-visualizer分析
  • 实施代码分割与懒加载
  • 检查重复依赖
"状态管理复杂度高"
  • 考虑就近托管状态（将状态保留在使用位置附近）
  • 评估是否真的需要全局状态
  • 针对API数据使用服务器状态管理方案
"组件耦合问题"
  • 应用依赖倒置原则
  • 优先组合而非继承
  • 定义清晰的组件接口