当你在构建 React 应用程序时，最基本的决策之一就是如何构造你的组件。你应该创建许多微小的、高度特定的组件吗？还是拥有更少的、处理更多功能的大型组件更好？这个问题困扰着各个层次的开发者，答案并不像你想象的那么直接。
1. 组件大小的重要性
把组件大小想象成存在于一个光谱上。从图片可以看到，一端是非常小的组件，另一端是巨大的组件。
“一个巨大组件”的问题
以这个 Airbnb 风格的房产卡片为例，如果我们将整个卡片构建为一个巨大的组件，会产生以下问题：
- 太多责任：组件承担了过多的职责
- 可能需要太多 props：需要大量属性才能正常工作
- 难以重用：由于复杂性而无法在其他地方使用
- 复杂代码，难以理解：代码变得复杂且难以维护
就像 JavaScript 函数一样，如果一个函数做太多不同的事情，我们应该把它分解成多个函数。同样的原则也适用于 React 组件。
2. 寻找正确的平衡
走向另一个极端同样有问题。如果我们创建许多微小组件，会导致：
- 数百个微型组件：最终得到数百甚至数千个微型组件
- 令人困惑的代码库：难以导航和理解
- 过度抽象：隐藏实现细节的抽象层过多
我们需要在过于具体和过于宽泛之间找到正确的平衡。
在编程中，抽象基本上意味着创建新的东西来隐藏该事物的实现细节。例如，当我们创建一个按钮组件时，该组件的用户可能不知道按钮实际上是如何工作的，因为实现细节隐藏在这个抽象后面。
3. 拆分UI的四个标准
1. 内容/布局的逻辑分离
组件应该创建内容的逻辑分离，甚至是页面布局的逻辑分离。
2. 可重用性
努力使其中一些组件可重用。
3. 责任/复杂性
确保每个组件都有单一的、明确定义的责任。
4. 个人编码风格
这是一个更主观的标准。有些人在使用较小的组件时工作得更好，有些人则更喜欢较大的组件。
理想的组件分解效果：
- ✅ 逻辑分离：每个部分都有清晰的分工
- ✅ 部分可重用：某些组件可以在其他地方使用
- ✅ 低复杂性：每个组件都相对简单
4. 创建新组件的框架
核心建议
💡 当有疑问时，从一个相对较大的组件开始，然后在必要时将其拆分为较小的组件
如果你确定需要重用某个组件，可以跳过这个过程直接创建。但除此之外，你不需要在早期就专注于可重用性和复杂性。
何时需要拆分？根据四个标准判断：
1. 逻辑分离 👉 组件是否包含不属于一起的内容或布局片段？
2. 可重用性 👉 是否可能重用组件的一部分？ 👉 你是否想要或需要重用它？
3. 责任/复杂性 👉 组件是否在做太多不同的事情？ 👉 组件是否依赖太多 props？ 👉 组件是否有太多状态片段和/或效果？ 👉 代码（包括 JSX）是否太复杂或令人困惑？
4. 个人编码风格 👉 你是否更喜欢较小的函数/组件？
如果这些问题的答案指向需要拆分，那么你可能需要一个新组件。
👋 这些都是指导原则…随着时间推移会变得直观！
5. 更多通用指导原则
💰 抽象的成本
要意识到创建新组件会创建新的抽象。抽象有成本，因为更多的抽象需要更多的心理能量来在组件之间切换。所以尽量不要过早创建新组件。
🏷️ 命名规范
根据组件的功能或显示内容来命名组件。不要害怕使用长组件名称。
🪆 重要禁忌
永远不要在另一个组件内部声明新组件！
📁 文件组织
将相关组件共同定位在同一个文件中。不要过早将组件分离到不同文件中。
↔️ 组件大小的现实
应用程序拥有许多不同大小的组件（包括非常小的和巨大的）是完全正常的。
6. 应用中组件大小和可重用性的分布
小型组件
- 某些非常小的组件是必需的！
- 高度可重用
- 非常低的复杂性
这些小组件虽然简单，但在应用中扮演重要角色，如按钮、图标等基础UI元素。
大型组件
- 大多数应用都会有一些巨大的组件
- 不打算重用（这不是问题！）
例如页面组件，它可能包含整个应用程序或页面的布局，可能是一个相当复杂的组件，但不打算重用。
总结
- 平衡是关键：避免极端的小组件和极端的大组件
- 使用四个标准：逻辑分离、可重用性、责任复杂性、个人风格
- 从大开始，必要时拆分：这是一个安全且实用的方法
- 抽象有成本：不要过早优化
- 多样性是正常的：应用中有各种大小的组件是自然的
记住，这些都只是指导原则和最佳实践。随着时间的推移，这些概念会变得直观，构建组件将成为你的第二天性。在你刚开始的时候，有这样的指导原则来帮助你做出明智的决策是非常宝贵的。
发表回复