tgoop.com/cosine_front_end/2960
Create:
Last Update:
Last Update:
#优质博文 #React #前端 #工程化
React Folder Structure in 5 Steps (2025)
AI 摘要：本文详解了作者多年实践总结出的 React 项目结构化思路，以「逐层演进」为主线，从单文件组件到分页驱动(Page-driven)架构，展示了如何通过结构分层与命名规范，实现 React 应用在复杂度与团队协作下的平衡。文章强调不存在唯一正确方案，读者应根据项目规模与团队习惯灵活调整。
[以下是方便搜索索引的大纲(AI 生成)，请读原文]
1. 单文件阶段（Single React File）
• 初始项目通常包含一个 src/App.js 文件。
• 所有组件起初可写在单文件中，便于快速原型开发。
• 随项目增长，应将可复用组件拆分，以减少冗余和嵌套复杂度。
2. 多文件阶段（Multiple React Files）
• 抽离可重复使用的组件为独立文件，如 List 和 ListItem。
• 通过文件导出（export）定义组件的“公共接口”(API)。
• 使用文件扩展名策略（.js/.jsx/.ts/.tsx）统一文件规范。
• 建议仅对可复用组件拆分，不要过早抽象。
3. 文件夹化阶段（From Files to Folders）
• 随组件复杂度增加，将相关技术关注点（测试 test、样式 style、类型 type、工具 utils）集中在组件文件夹。
• 采用“一个组件一个文件夹”的结构，如 src/list/ 或 src/app/。
• 使用 index.js 作为模块对外出口（即“barrel 文件”），控制组件的公共 API。
• 讨论命名规范（如 .spec.js、.module.css）与层级深度（避免超过两级嵌套）。
• 建议尽量避免过深目录，用功能聚合代替结构嵌套。
4. 技术型文件夹（Technical Folders in React）
• 当项目达到中等规模，应区分“组件类”与“技术类”逻辑。
• 在 src/ 中增设按技术职能划分的文件夹：
• components/：组件逻辑
• hooks/：自定义 React Hooks
• context/：应用全局状态
• services/：通用服务（格式化、错误追踪、请求封装等）
• 服务示例通过 Intl API 实现日期格式化并由模块封装暴露。
• 推荐使用路径别名（alias，如 @/services/...）避免相对路径混乱。
• 指出 barrel 文件的利弊——简化导入但可能削弱 tree-shaking。
5. 功能型文件夹（Feature Folders in React）
• 大型项目中，按“业务领域（Feature）”划分文件夹，以聚合其内所有组件与逻辑。
• 结构区分：
• feature/：业务特定代码（如 user、post、payment）
• components/：跨 feature 可复用的 UI 组件
• services/hooks/context：依旧保留为全局可重用逻辑
• 每个 feature 内可包含对应 components/、services/ 等子文件夹以划分技术关注点。
• 帮助团队并行开发、限域依赖，提高可维护性与灵活性。
6. 页面驱动结构（Page Driven Structure）
• 当应用存在多页面（特别是 Next.js 或 Vite + React），建议围绕 pages/ 或 app/ 文件夹组织。
• 每个页面对应入口点 (page.tsx)，并链接相关 feature。
• 在同页面内是否嵌套 feature/取决于其复用度与作用域；鼓励保持一致的目录结构。
• 比较 Next.js 的文件路由与客户端路由在结构设计上的差异。
• 最终形成具有多层抽象但一致规则的工程化结构，支持扩展与团队协作。
7. 总结与启发
• 无绝对正确的文件结构，应随项目自然演化。
• 遵循“按复用程度而分层”，“按技术职能而归类”，“按业务边界而划分”的原则。
• 五步推进法可帮助开发者在项目复杂化时保持组织清晰。
author Robin Wieruch
BY cosine - 前端人の日常频道
Share with your friend now:
tgoop.com/cosine_front_end/2960