[React] React Repo 结构最佳实践

[PeterChen1997]

https://github.com/alan2207/bulletproof-react

一个简洁、强大、可扩展的前端项目架构是什么样的？ - 掘金

1. 当下 React Repo 结构问题

React 生态非常多样化，灵活有余但没有可以 遵循的、预定义的最佳实践（相对比来说，Angular 规范过于复杂但灵活性不足）

2. 搭建 repo 结构的目标

• 易维护
• 易扩展
• 简洁
• 强大

3. 最佳实践内容

• 文件目录组织
• 工程化配置推荐
• 业务组件规范
• 状态管理的设计与选择
• API 层如何设计

4. 文件目录组织

// repo 推荐
src
|
+-- assets            # 静态资源
|
+-- components        # 公共组件
|
+-- config            # 全局配置
|
+-- features          # 特性
|
+-- hooks             # 公用hooks
|
+-- lib               # 二次导出的第三方库
|
+-- providers         # 应用中所有providers
|
+-- routes            # 路由配置
|
+-- stores            # 全局状态stores
|
+-- test              # 测试工具、mock服务器
|
+-- types             # 全局类型文件
|
+-- utils             # 通用工具函数

// 个人建议
+-- ui                # UI 组件库

4.1 features 和 components 目录的区别

• components：公用组件
  • SearchInput
  • SelectInput
• features：业务组件
  • Comment
• ui：headless ui 组件
  • BaseInput

比如评论和富文本组件，都是特性，放在 features/comments 下，评论组件需要的 input 框组件就来自于 components 中

相比于现有项目结构的 /pages 来说，粒度更细一些

4.2 features 中的结构

src/features/xxx-feature
|
+-- api         # 与特性相关的请求
|
+-- assets      # 与特性相关的静态资源
|
+-- components  # 与特性相关的组件
|
+-- hooks       # 与特性相关的hooks
|
+-- routes      # 与特性相关的路由
|
+-- stores      # 与特性相关的状态stores
|
+-- types       # 与特性相关的类型申明
|
+-- utils       # 与特性相关的工具函数
|
+-- index.ts    # 入口

所有特性导出的内容都通过统一入口调用

// correct
import { CommentBar } from "@/features/comments"

// wrong
import { CommentBar } from "@/features/comments/components/CommentBar

可以通过配置 ESLint 实现

{
  rules: {
    'no-restricted-imports': [
      'error',
      {
        patterns: ['@/features/*/*'],
      },
    ],
    // ...其他配置
  }
}

5. 现有 repo 问题

• utils 目录过于冗余，糅合了部分 lib 、业务 utils
• 公用组件的目录包含了业务组件和基础的 UI 组件
• 现有功能按入口页面划分结构，而不是按特性划分，可能存在部分的冗余和重复代码
• 对于 hooks 的抽象较少
• routes…
• stores…