React项目为何按类型而非功能组织文件?
Great question! This is such a common point of confusion, especially since React's whole component model is built around colocating JS, HTML, and CSS instead of separating them by technology. Let's break this down:
1. Historical & Tooling Habits
Early React projects drew heavily from Node.js/JavaScript ecosystem conventions, where organizing files by type (e.g., components/, utils/, styles/) was standard. Tools like Create React App (CRA) also shipped with this structure by default, which meant most new developers learned this pattern first. Even linters, formatters, and build tools were optimized for this setup, making it a low-friction choice for small to medium projects.
2. Convenience for Smaller Projects
For tiny apps or prototypes, a type-based structure works really well. If you only have a handful of components, utility functions, and styles, it's easy to scan all your components in one folder, all your helpers in another, without having to navigate nested feature directories. For example, tweaking a reusable Button component only requires checking one components/Button/ folder, not hunting through every feature that uses it.
3. But Wait—Feature-Based Structure Aligns Better With React's Core Idea!
Here's the key point you're getting at: React's emphasis on coupling related concerns absolutely supports feature-based organization, and this pattern is becoming the standard for larger projects.
When your app grows beyond a handful of features, a type-based structure starts to break down. Imagine you need to modify the authentication flow: you'd have to jump between components/LoginForm.js, utils/authHelpers.js, styles/login.css, and maybe hooks/useAuth.js—all scattered across different folders. That's the opposite of the "colocation" React promotes!
A feature-based structure fixes this by grouping everything related to a feature in one place. For example:
src/ Auth/ LoginForm.jsx LoginForm.module.css useAuth.js authHelpers.js index.js Dashboard/ DashboardLayout.jsx DashboardStats.jsx DashboardStyles.module.css useDashboardData.js
This way, every file tied to the Auth feature lives together, just like how a single React component couples its JS, HTML, and CSS. It makes debugging, refactoring, and onboarding new developers way easier.
The Bottom Line
There's no "one size fits all" answer:
- Type-based: Great for small projects, prototypes, or teams just getting started with React. It's simple and familiar.
- Feature-based: Better for medium-to-large apps, as it aligns perfectly with React's colocation principle and keeps related code together.
In fact, modern React tooling (like Next.js App Router) now defaults to feature/route-based organization, which is a clear sign that the community is moving toward this more aligned approach.
内容的提问来源于stack exchange,提问作者Johnstedt

