学习了架构思维之后，我们也必须要重视一个问题，那就是要做到合理的拆分组件。

合理拆分组件是我们能够正确践行架构思维的前提条件。很多同学往往没有理论依据，把场景变得更加复杂，从而脱离了架构思维的覆盖范围。自己的工作也变得更加困难。

因此，这篇文章，需要跟大家分享一下在异步请求逻辑中，合理拆分组件的一些重要标准。

一、总分总原则 我们在开发一个页面之前，首先会看到该页面的设计稿或者原型图。因此，这个页面要做成什么样子，是我们需要提前知道的。这里的完整的页面包括：布局、交互、数据逻辑。如果在开发之前，你仍然对这个页面的成品有疑问，那么就应该把这些疑问先搞清楚，而不是直接动手开发。

搞清楚了完整的页面应该长什么样子之后，我们再基于合理的开发的需求，去把这个页面拆分成为多个组件。

最后，这些组件会组合成为一个整体，形成最终的可运行的页面成品。

这就是我们在写页面的总分总原则。

总分总原则给我们的开发最直观的指导就是：先思考整体，再思考细节。许多同学喜欢一上来就开始写页面，凭感觉对页面进行拆分。写到一半发现写不下去了，又回过头来思考发现页面组件拆分不合理，于是就陷入了开发困境。先思考整体是非常容易被忽略的。

二、拆分目的：提高可读性和可维护性 许多人错误的把拆分与封装的目的理解为仅复用。因此，在组件拆分时，往往会存在许多不知道怎么办的情况。因为很多时候一个子组件拆分出来，也没别的地方会复用它。所以，这里我们，我们要正确的理解拆分的目的：是为了提高可读性和可维护性，而复用，是提高可维护性的一种情况。

在组件拆分的过程中，有许多组件单独拆分出来，单纯是因为代码太多、或者逻辑稍微复杂了一点。拆分的标准就是：这一段逻辑/代码在后期维护时，是可以不用过多关注从而简化重新阅读难度，从而快速定位问题。

例如，我们可以使用一个简单的逻辑表示一个列表的渲染

{list.map((item) => (
  <div key={item.id}>{item.name}</div>
))}

但是，很多时候，列表中的其中一项，涉及到的代码比较复杂，比较多，于是，我们就可以单独把每一项拆出来

<div>
  {list.map((item) => (
    <User key={item.id} data={item} />
  ))}
</div>

有的开发者有良好的封装思维。但是也存在过度封装的时候。因此，我们在封装的时候，需要注意一个标准：那就是如果你觉得足够复杂才需要考虑封装，如果复杂度不是很高，就不需要拆出来封装一个子组件。

INFO 刚开始，如果你还无法把控是否复杂的具体粒度，可以通过一个简单的规定来约束：一个文件的代码不能超过 200 行，如果超过了，就需要考虑拆分

三、拆分单位：需要能提炼出明确的语义 无论是封装函数，还是抽象一个架构层级，或者是拆分一个组件出来，我们都需要重视语义化。也就是说，你拆分出来的任何模块、函数，你都能够提炼出来明确的语义。用来表示他的职能。这跟设计模式中的单一原则有一点类似，但是更宽泛一点。

在组件拆分中，列举一个常见的语义：列表的子项、导航栏、新闻/xxxx模块、头图、推荐列表、评论列表...

如果你发现，你想要拆分出来的某一个逻辑，你无法提炼出明确的语义，那么就有可能存在拆分不合理的情况，以这个标准可以锻炼自己的封装能力。

四、异步组件基础标准：Loading 与 组件是一对一的关系 一个异步逻辑所对应的接口情况多种多样，比较复杂，但...

我们设计在页面上的每一个 Loading 组件，都代表了一个完整的异步逻辑：初始化中 loading -> 初始化完成 -> 更新中 loading -> 更新完成。因此，设计 Loading 时，往往不会考虑接口请求的具体情况。而是考虑将具有统一更新逻辑的区域设计为一个独立的组件。在实际情况中，初学者很难自己从一致的更新逻辑这个角度去思考自己的组件拆分，从而导致了某些情况下处理起来比较混乱。