component-organization

前端组件组织

这是一种参考模式。 借鉴这种方法，并根据你的情况进行调整——不要照搬。

问题：前端项目不断发展，目录也变得杂乱，相关文件难以查找，共享代码也没有明确的归属位置。

解决方案：按类型组织（组件、钩子、库、类型），并在各类型下创建子目录，以归类相关条目。

---

模式

frontend/
├── app/                 # Framework routing (Next.js app dir, Nuxt pages, etc.)
│   ├── layout.tsx
│   └── page.tsx
├── components/          # All components
│   ├── ui/              # Base primitives (Button, Input, Modal)
│   ├── UserProfile.tsx
│   ├── DashboardChart.tsx
│   └── PostCard.tsx
├── hooks/               # Custom hooks
│   ├── use-auth.ts
│   ├── use-dashboard.ts
│   └── use-debounce.ts
├── lib/                 # Utilities, services, business logic
│   ├── api/             # API client, fetch helpers
│   ├── auth/            # Auth context, cookie handling
│   └── utils/           # Pure helper functions
├── queries/             # Data fetching (GraphQL queries, API calls)
├── types/               # Shared type definitions
│   ├── user.ts
│   └── post.ts
└── public/              # Static assets

关键规则：

• 组件放在 components/ 中，相关组件按子目录分组（例如 ui/）
• 钩子放在 hooks/ 中，每个文件包含一个钩子
• 业务逻辑放在 lib/ 中，并按领域子目录组织
• 多个文件共享的类型放在 types/ 中
• 基础 UI 原语（按钮、输入框、模态框）放在 components/ui/ 中

---

为什么采用这种模式？

优点：

• 清晰可预测：明确知道去哪里查找——所有钩子都在 hooks/ 中，所有组件都在 components/ 中
• 可复用：易于查找并共享供多个功能使用的组件
• 可扩展：新增钩子或组件时，归属位置一目了然
• 适合组件库：符合共享 UI 套件的组织方式

何时在某种类型下使用子目录：

• components/ui/ — 在各处复用的基础原语
• lib/auth/ — 一个领域包含多个文件（上下文 + 工具函数 + 类型）
• lib/api/ — API 客户端、拦截器、辅助函数

---

何时拆分

• 在 components/ 中新建文件：当 UI 会被复用，或父组件超过约 200 行时
• 在 hooks/ 中新建文件：当有状态逻辑会被复用，或使组件变得臃肿时
• 在 lib/ 中新建子目录：当一个领域包含 2 个或更多相关文件时（服务 + 工具函数、上下文 + 辅助函数）
• 移至 components/ui/：当组件纯粹用于呈现，不包含业务逻辑时

---

渐进式改进

如果开发者纠正了本技能本应避免的行为，请提出对此技能的具体修订建议，以避免今后再次出现同样的问题。