Flux：了解 React 的架构

joypaul00

什么是通量？ Flux是 Facebook 与React框架一起使用的架构。 但是，也许更容易首先说明 Flux 不是什么以及它不应该与什么进行比较，以便更容易理解！ Flux不是框架或库。 我们来和MVC架构对比一下。 使用 Flux，建议不要将应用程序划分为模型、视图和控制器，而是将其划分为Stores、Dispatcher、Views、ActionAction Creators。 构建此流程的简单视图如下所示： 通量状态 流动状态 当您尝试理解 MVC 时，您可能见过一些这样的图像。 他们通常会附带对每个项目的解释，就像我现在要做的那样： 视图– 用户界面，呈现并负责与用户的交互，回调将来自于此以创建操作。 操作– 将数据传递给调度程序的事件。 调度程序– 接收数据并将其发送到所有注册监听该操作的存储。 存储– 接收包含数据的操作并发出事件，这将更新状态数据，导致视图再次呈现。 揭开理论的面纱 流程步骤 Flux步骤的宏观规划 流动 当事件发生时，例如： 将新项目添加到列表中。 有一个回调函数，它将使用必要的数据创建一个操作并将其作为对象发送到调度程序。 调度程序已注册哪个商店将接收该操作，并将数据发送给它。 因此，由于商店是所有业务逻辑所在的位置，因此它将更新返回新值的视图。 非常适合React 编程风格。 由于商店发送更新时不需要详细说明状态和视图之间的转换是什么样的。

这证明了遵循单向数据流的Flux 模式。 操作、调度程序、存储和视图独立于特定的输入和输出。 数据通过调度程序，该调度程序管理并充当存储响应的所有回调的记录。 商店发出将由视图拾取的更改。 每个商店都会向调度程序注册一个回调。 每当有任 币安应用用户数据 何数据输入时，调度程序都负责查看已注册的操作并将其发送到进行注册的存储。 反过来，它返回结果，通过更新数据，导致与商店有连接的组件使用新信息再次呈现！ 与 MVC 和 Facebook 的比较 对于很多人来说，第一次接触极其知名且强大的架构就是MVC。 它基本上由模型组成，它将处理视图应用程序数据。 代表用户界面。 最后是控制器，它使用用户输入来操作模型并使用新内容更新视图。 就是一个简单的Flow，却让Facebook很头疼。 因为他们有一个巨大的数据库，每一个微小的变化都会导致一系列的功能。 问题被指出是双向 MVC 通信。 由于流程始终遵循同一条线，因此用户使用操纵模型的控制器，从而更新到达用户眼睛的视图。 在工作中，我们有多少次会遇到需要尽可能小心的屏幕？ 因为它是如此强大，以至于只要有最轻微的改变，它就会按顺序调用如此多的函数，以至于很难调试代码并真正理解正在做什么。 为了解决双向通信的问题，改为单向流。



其中，为了更直接的比较： 多维控制器    通量 双向数据流    单向数据流 数据连接是关键    事件和动作是主要部分 控制器负责业务逻辑    商店进行所有计算 同步    可以完全异步实现！ 被很多公司、很多项目使用的知名架构    帮助解决 MVC 无法轻松解决的复杂问题 代码示例 – TodoList 正确的！ 我们已经分解了很多理论，但如果没有实践，它就无法很好地发挥作用，所以让我们逐个部分地了解一下代码中的信息流。 我们将使用 Facebook 存储库中 TodoList（待办事项列表）中的部分代码！ 我们首先加载列表：Flux 比 MVC 更好吗？ 我不会说更好。 最大的区别在于选择的开发技术。 Flux与基于组件的 Web 开发（如React、Vuejs 和 Angular +）具有巨大的协同作用。 最终，最好的结果将反映在团队根据他们最熟悉的内容做出的决策中。 或者当他们想要给具有巨大潜力的技术一个机会时！ 考虑到 React 已经具备的规模，我想说它已经超越了技术水平。 今天，有合适规模的社区稳定供您投入时间学习，因为需求巨大！ 去完成 今天，我们试图尽可能地了解这个新标准的工作原理。 从理论开始，稍微看看它在代码中是如何工作的。 拥有一个改变我们开发方式的新标准是这个奇妙的开发领域的魔力之一。 我们在日常生活中总会有新的东西可以看到、研究、测试和应用！ 现在，当您查看开发人员职位空缺页面时（我相信您已经看到了一些，对吧？），React 职位空缺通常会附带“Redux”一词。