现代前端架构介绍（第二部分）：如何将功能架构分为三层

远离JavaScript疲劳和框架大战，了解真正重要的东西

在这个系列的前一部分《App是如何由不同的构建块构成的》中，我们揭示了现代Web应用是由不同的构建块组成的，每个构建块都承担着特定的角色，如核心、功能等。在这篇文章中，我们将深入探讨功能模块，了解其面临的挑战。废话不多说，下面是第二部分的内容。

特性是一组在树的同一分支上排列的组件的集合。

这些组件需要相互通信以实现预期的业务价值。例如，当用户从列表中选择一项时，其详细信息应被检索并显示在另一个组件上。

因为分支的形状不可预测，所以通信流可以向任何方向流动，可以遵循非传统的模式。这很危险，因为它会混淆应该将数据获取代码、用户交互逻辑等放在何处的判断。这甚至可能导致具有混合关注点的组件。

将功能混杂在一起不仅违反了软件工艺的许多原则，还会使理解功能变得繁琐。代码调试变得必要，从而导致沮丧和低效。

特征内部组件之间的通信

所以，第一个挑战是：

通过将组件划分为两类来明确它们的职责：

呈现组件（也称为“哑组件”）：正如其名称所述，它的唯一作用是显示UI并与用户交互。它不知道自己被用于哪个领域，也不包含任何业务逻辑，因此具有很高的可重用性。列表组件就是一个很好的例子。它知道如何显示其项以及如何与用户交互，但不知道这些项是如何获取的，也不知道谁对用户事件感兴趣。
容器组件（也称为智能组件）：由于呈现组件缺乏上下文，容器组件充当其上下文提供者。它知道如何获取要传递给呈现组件的数据，以及如何处理用户事件。这使其了解其功能领域，因此是理想的业务逻辑宿主，但也使其更难重用。

容器组件与表现层组件之间的通信

PS：一些框架，比如 React，通过将回调函数与数据一起传递来促进单向通信。这并不与容器将数据传递并处理用户事件的事实相矛盾。

虽然容器与呈现组件之间的通信遵循一种标准模式，但不同容器或甚至功能之间的数据流仍然不清晰。它们需要共享、读取和更新应用程序中的数据。这被称为状态管理。

所以，第二个挑战是：🔥

确定谁负责管理应用程序状态并保护其免受不一致性的影响。

虽然解决这个问题的技术方案各不相同，但它们都基于一个简单的基本概念。

因为状态可以被应用程序的任何部分更新和读取，因此其管理不应由任何一方负责。

相反，将由一个全局实体负责管理App的状态。由于它是全局的，因此它是唯一的“真实”来源，从而保护状态免受不一致的影响，并使App更容易理解。

通过全局实体进行状态管理

它将状态管理的责任从容器组件中移除，并将它们转换为一个业务逻辑层，连接状态组件和表现组件。

特征层之间的通信流

这有助于实现职责分离，使每个层级只承担单一职责：

状态：管理应用程序的状态并确保其一致性。
业务逻辑：包含业务逻辑并为表现层组件提供上下文。
UI：显示用户界面并与用户交互。

如果我们希望开发人员能够快速在应用程序代码中找到所需内容，这也会对代码结构产生影响。

<span style="color:rgba(0, 0, 0, 0.8)"><span style="background-color:#ffffff"><span style="background-color:#f2f2f2"><span style="color:#242424">AppRepo│  ├──/Overview                           <strong>|</strong>   ├──/Components                     <strong>|</strong>      ├──/ListComponent               │      └──/ChartComponent              <strong>|</strong>   ├──/State                          </span></span></span></span>

状态文件夹将包含与该功能状态相关的所有内容。它与其他功能状态一起构成了整个应用程序的状态。