⚛️ React 项目中的文件夹结构

在 React 项目中组织文件和目录对于可维护性、可扩展性和导航的便捷性至关重要。本文探讨了不同规模的 React 项目的通用架构和文件夹结构，并为每个级别提供了清晰的演示。

1️⃣ 第 1 级：按“文件类型”分组

这种结构的特点是简单——按文件类型分组：



└── src/
    ├── assets/
    ├── api/
    ├── configs/
    ├── components/
    │   ├── SignUpForm.tsx
    │   ├── Employees.tsx
    │   ├── PaymentForm.tsx
    │   └── Button.tsx
    ├── hooks/
    │   ├── usePayment.ts
    │   ├── useUpdateEmployee.ts
    │   ├── useEmployees.ts
    │   └── useAuth.tsx
    ├── lib/
    ├── services/
    ├── states/
    └── utils/

项目规模：小型到中型
优点：简单直接
缺点：
- 会迅速膨胀并变得难以维持
- 业务关注点未分离

假设你有很多与支付相关的代码。有一天，整个业务发生了变化或不再需要，替换或删除这些代码有多容易？使用这种文件夹结构，你必须仔细检查每个文件夹及其中的文件才能进行必要的更改。如果项目规模不断扩大，它很快就会变成一个维护地狱，而且随着时间的推移，情况只会越来越糟。

2️⃣ 第 2 级：按“文件类型”和功能分组

随着项目的发展，“2 级”结构引入了按每种类型中的功能进行分组：



└── src/
    ├── assets/
    ├── api/
    ├── configs/
    ├── components/
    │   ├── auth/
    │   │   └── SignUpForm.tsx
    │   ├── payment/
    │   │   └── PaymentForm.tsx
    │   ├── common/
    │   │   └── Button.tsx
    │   └── employees/
    │       ├── EmployeeList.tsx
    │       └── EmployeeSummary.tsx
    ├── hooks/
    │   ├── auth/
    │   │   └── useAuth.ts
    │   ├── payment/
    │   │   └── usePayment.ts
    │   └── employees/
    │       ├── useEmployees.ts
    │       └── useUpdateEmployee.ts
    ├── lib/
    ├── services/
    ├── states/
    └── utils/

项目规模：中型到大型
优点：
- 简单直接
- 物品按特征分组
缺点：
- 与功能相关的逻辑仍然分布在多个文件夹类型中

现在让我们回到需要修改或删除支付模块的问题描述。有了这个结构，现在修改或删除支付模块就容易多了。

如果您不知道选择什么，我推荐“2 级”文件夹结构。

3️⃣ 第 3 级：按功能 / 模块分组

对于较大的项目，“3 级”结构提供了高度模块化的方法，为每个模块内应用程序的不同方面定义了清晰的界限：



└── src/
    ├── assets/
    ├── modules/
    |   ├── core/
    │   │   ├── components/
    │   │   ├── design-system/
    │   │   │   └── Button.tsx
    │   │   ├── hooks/
    │   │   ├── lib/
    │   │   └── utils/
    │   ├── payment/
    │   │   ├── components/
    │   │   │   └── PaymentForm.tsx
    │   │   ├── hooks/
    │   │   │   └── usePayment.ts
    │   │   ├── lib/
    │   │   ├── services/
    │   │   ├── states/
    │   │   └── utils/
    │   ├── auth/
    │   │   ├── components/
    │   │   │   └── SignUpForm.tsx
    │   │   ├── hooks/
    │   │   │   └── useAuth.ts
    │   │   ├── lib/
    │   │   ├── services/
    │   │   ├── states/
    │   │   └── utils/
    │   └── employees/
    │       ├── components/
    │       │   ├── EmployeeList.tsx
    │       │   └── EmployeeSummary.tsx
    │       ├── hooks/
    │       │   ├── useEmployees.ts
    │       │   └── useUpdateEmployee.ts
    │       ├── services/
    │       ├── states/
    │       └── utils/
    └── ...

项目规模：大型且复杂
优点：
- 内容按功能/模块清晰分组
- 特征/模块是现实世界中对象的清晰表示
缺点：
- 您必须充分了解业务逻辑才能做出正确的分组决策

有了这个，如果您要删除或修改支付逻辑，您就会立即知道从哪里开始。

赋予文件夹名称一致的含义

无论结构层级如何，某些文件夹名称都应具有特定含义。文件夹名称的含义可能因您的偏好或项目惯例而异。

以下是我通常认为的文件夹名称：

UI 组件

组件：React 组件——主要的 UI 构建块。
设计系统：基于设计系统的基本 UI 元素和模式。
图标：用于内联使用的 SVG 图标。

React 具体

hooks：用于共享逻辑的自定义 React hooks。
hocs：React 高阶组件。
contexts / provider：包含 React Contexts 和 Providers。

实用程序和外部集成

utils：与业务逻辑或任何技术无关的通用逻辑实用程序，例如字符串操作、数学计算等。
lib：与某些技术相关的实用程序，例如 DOM 操作、HTML 相关逻辑、localStorage、IndexedDB 等。
plugins：第三方插件（例如 i18n、Sentry 等）

业务逻辑

服务：封装主要业务和应用逻辑。
helpers：提供特定于业务的实用程序。

样式

样式：包含（全局）CSS 或 CSS-in-JS 样式。

TypeScript 和配置

类型：用于通用 TypeScript 类型、枚举和接口。
configs：应用程序的配置（例如环境变量）
常量：常量，不变的值（例如export const MINUTES_PER_HOUR = 60）。

服务器通信

api：用于与服务器通信的逻辑。
graphql：GraphQL 特定的代码。

状态管理

states / store：全局状态管理逻辑（Zustand、Valtio、Jotai 等）
Reducers、Store、Actions、Selectors：Redux 特定的逻辑

路由

路由/路由器：定义路由（如果您使用 React Router 或类似的东西）。
页面：定义页面的入口点组件。

测试

测试：针对您的代码进行单元测试和其他类型的测试。

🏁 结论

在 React 项目中选择正确的文件夹结构至关重要，并且应根据项目的规模和复杂程度进行选择。“一级”文件夹结构可能适用于小型项目，而“二级”和“三级”文件夹结构则为中型和大型项目提供了更有条理、更模块化的结构。我个人通常推荐“二级”文件夹结构。此外，了解常用文件夹名称有助于在 React 应用程序中保持一致且直观的架构。

如果您认为这是一篇好文章，那么您可能也会发现这篇文章很有用：