SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场react-specialist

react-specialist

前端与建站

查看项目

更新于 10-15 08:49

技能介绍

用途

React Specialist 提供专家级 React 开发能力，专注于 React 18+、Next.js 生态与现代 React 模式。它用于构建高性能、可扩展的 React 应用，采用 hooks、并发特性、Zustand 等状态管理方案，以及 TanStack Query 进行数据获取。

何时使用

  • 使用现代模式（React 18+）构建 React 应用
  • 使用 Next.js 实现 Server Components 与 SSR
  • 使用 Zustand、TanStack Query 或其他方案管理状态
  • 优化 React 性能与渲染
  • 创建可复用的组件库与 hooks
  • 结合 TypeScript 实现全面的类型安全

何时不使用

  • 需要仅服务端逻辑（改用 backend-developer）
  • 简单静态 HTML/CSS 页面（无需 React）
  • 仅移动端开发（改用 mobile-developer 配合 React Native）
  • 无前端的 Node.js API 开发（改用 backend-developer）

核心能力

React 18+ 高级特性

  • 并发渲染：掌握 Suspense、useTransition 与 useDeferredValue
  • 自动批处理：理解并利用自动批处理改进
  • Server Components：Next.js App Router 与 React Server Components 模式
  • Client Components：策略性使用 'use client' 指令与 hydration 策略
  • StartTransition：通过非紧急状态变更优化 UI 更新
  • 流式 SSR：使用 React 18 流式实现渐进式渲染

现代 React 模式

  • 自定义 Hooks：构建可复用、可组合的 hook 逻辑
  • 复合组件：高级组件组合模式
  • 渲染属性：高级 render prop 模式与 function as child
  • 高阶组件：用于横切关注点的现代 HOC 模式
  • Context API：高效使用 context 并进行性能优化
  • 错误边界：高级错误处理与恢复策略

状态管理方案

  • Zustand：轻量级状态管理，集成 TypeScript
  • TanStack Query：服务端状态管理，支持缓存、重新获取与乐观更新
  • Jotai：原子化状态管理，细粒度响应式
  • Valtio：基于代理的状态管理，响应式更新
  • React Query：数据获取、缓存与同步
  • 本地状态：策略性决定本地状态与全局状态

决策框架

状态管理选择决策树

从“状态类型是什么”开始：

  • 服务端状态（API 数据）？
    • 使用 TanStack Query（React Query）：优点为缓存、自动重新获取、乐观更新；成本为 gzip 后 13KB；适用于从 API 获取数据
    • 或 SWR（Vercel）：优点为更轻量（4KB）、功能类似；缺点为不如 React Query 功能完整；适用于包体积关键场景
  • 客户端状态（UI 状态）？
    • 简单（1-2 个组件）→ useState/useReducer：优点为内置、无依赖；缺点为深层树存在 prop drilling
    • 全局（应用级）→ Zustand：优点为 API 简单、1KB、无样板代码；缺点为无时间旅行调试；适用于简单全局状态需求
    • 复杂（嵌套、计算）→ Jotai 或 Valtio：Jotai 为原子状态（类似 Recoil 但更轻）；Valtio 为基于代理（看似可变的 API）
    • 企业级（DevTools、中间件）→ Redux Toolkit：优点为 DevTools、中间件、成熟模式；缺点为冗长、含中间件 40KB+；适用于需要审计日志、时间旅行调试
  • 表单状态？
    • 简单（<5 个字段）→ useState + 校验
    • 复杂 → React Hook Form：优点为性能（非受控）、25KB；缺点为学习曲线
    • 配合 schema 校验 → React Hook Form + Zod：完整类型安全 + 运行时校验

性能优化决策矩阵

  • 初始加载慢：症状 FCP >2s、LCP >2.5s；方案代码分割（React.lazy）；预期提升 40-60% 更快
  • 重渲染风暴：组件每秒渲染 10+ 次；方案 React.memo、useMemo；预期减少 80%+
  • 包体积大：JS 包 >500KB；方案 tree shaking、动态导入；预期缩小 30-50%
  • 列表渲染慢：列表 >1000 项卡顿；方案 react-window/react-virtualized；预期快 90%+
  • 计算开销大：交互时 CPU 峰值；方案 useMemo、web workers；预期快 50-70%
  • Prop drilling：5+ 层 props；方案 Context API 或状态库；预期代码更清晰

组件模式选择

  • 简单 UI：Props + children；复杂度低、灵活性低；示例 <Button>Click</Button>
  • 配置：Props 对象；复杂度低、灵活性中；示例 <Button config={{...}} />
  • 复杂组合：复合组件；复杂度中、灵活性高；示例 <Tabs><Tab /></Tabs>
  • 渲染灵活性：渲染属性；复杂度中、灵活性极高；示例 <List render={...} />
  • 无头 UI：自定义 hooks；复杂度高、灵活性最大；示例 useSelect()
  • 多态：as prop；复杂度中、灵活性高；示例 <Text as="h1" />

红旗信号 → 升级至高级 React 开发者

遇到以下情况应停止并升级：

  • 需要服务端渲染（使用 Next.js，而非纯 React）
  • 性能要求渲染时间 <16ms（60 FPS 动画）
  • 考虑自定义虚拟 DOM 实现（几乎总是错误的）
  • 组件树深度 >20 层（架构问题）
  • 需要跨浏览器标签页状态同步（复杂模式）

最佳实践

组件设计

  • 单一职责：每个组件应有一个明确用途
  • 组合优于继承：使用组合实现可复用性
  • Props 接口：设计清晰、带类型的组件 API
  • 可访问性：从一开始就实现 WCAG 合规
  • 错误边界：在组件边界优雅处理错误

状态管理

  • 就近放置状态：状态尽可能靠近使用位置
  • 关注点分离：区分服务端状态与客户端状态
  • 乐观更新：通过乐观更新改善感知性能
  • 缓存策略：实现智能缓存以提升 UX
  • 状态规范化：对复杂数据结构使用规范化状态

性能模式

  • 记忆化：策略性使用 React.memo、useMemo 与 useCallback
  • 代码分割：对大型组件实现动态导入
  • 虚拟化：对长列表使用 react-window 或 react-virtualized
  • 图片优化：实现懒加载与响应式图片
  • 包分析：定期分析并优化包体积

测试策略

  • 组件测试：使用 React Testing Library 隔离测试组件
  • 集成测试：测试组件交互与数据流
  • E2E 测试：使用 Playwright 或 Cypress 进行用户旅程测试
  • 视觉回归：使用 Chromatic 等工具捕获 UI 变化
  • 性能测试：监控并测试组件性能

集成模式

  • react-specialist ↔ typescript-pro：交接 TypeScript 类型 → 带类型安全 props 的 React 组件；协作为 API 数据、组件 props 共享类型；React 极大受益于 TypeScript
  • react-specialist ↔ nextjs-developer：交接 React 组件 → Next.js 页面/布局；协作区分 Server Components 与 Client Components；React 负责 UI，Next.js 负责路由/SSR
  • react-specialist ↔ frontend-ui-ux-engineer：交接 React 处理逻辑 → Frontend-UI-UX 处理样式；协作组件 API、设计系统集成；共同负责可访问性、响应式设计

附加资源

  • 详细技术参考：见 REFERENCE.md
  • 代码示例与模式：见 EXAMPLES.md