之前在复习Business Code 的时候，就想写一篇文章来谈谈我对Flux 的理解和看法，但是不知不觉时间已经过去了，所以这个周末我决定整理一下自己，写一篇这样的文章。
这篇文章讲述了我对Flux的理解和个人看法。如果您不熟悉Flux，请从这里开始。
另外，本文没有特别大的代码段，而是主要讨论架构设计及其背后的原理。可能看起来有点无聊，但是请选择一个不困的时间仔细阅读。 ）
Flux的一些基本概念
这是Flux 提供的插图。
图中有四个名词。
看法
店铺
行动
出发员
让我从我的角度解释每一个。
首先，视图是用户可以看到和触摸的东西，这个概念在MVC和MVVM架构中都存在。尽管它们的架构相同，但它们的定义不一致并且存在细微的差异。这种差异确实存在，但先了解一下视图这个术语也没什么坏处。
然后是商店。它对应于传统意义上的数据，与MVC、MVVM模型有一定的对应关系。之所以不直接称之为数据，是因为这就是知识分子和普通人表达方式的区别。当然，我只是想尽可能降低理解成本，用更笼统的方式把问题解释清楚。
接下来好像又出现了一个新的概念，叫做actions，但其实你还是可以找到一些有助于大家理解的术语，叫做events。它是从一个地方传递到另一个地方的结构化信息，整个过程是一个动作/事件。
最后，Dispatcher，我还想说一件事：我觉得前三个名词因为Dispatcher而让人耳目一新。这也是理解Flux的关键。更严格地说，调度程序是触发操作和导致存储发生变化之间的镇流器。这比典型架构设计中直接改变“事件”逻辑的“数据”更加“正式”。也就是说，无用的事件变成了动作，无用的数据变成了存储，无用的视图仍然变成了无用的视图。
为什么这些存储、视图和操作在添加Dispatcher 后变得神奇？
因为这很“正常”
传统的MVC 受到Flux 团队的批评最多，表面上是因为控制器集中化无助于扩展。在实践中，这是因为控制器需要处理大量复杂的事件。 Flux的第二个令人沮丧的点是事件可以来自不同的方向，因此不同的数据可以被来自不同方向的不同类型的事件修改，并且数据之间可以存在联系，这不可避免地导致混乱。
因此，与Dispatcher 一起使用的Store 将只有一个更改源，并且与Dispatcher 一起使用的Action 将仅具有有限数量的商定操作。最混乱的地方突然变得相当“正常”。架构复杂度自然而有效地得到控制。
另一个明显的点是，Actions 不仅限制了存储的修改方式，而且还增加了存储操作的粒度，使微小的数据更改变得清晰且有意义。
另外，在这两个位置被抽象之后，数据操作是“无状态的”，因此可以根据操作历史来确定存储的状态。这支持许多场景，例如撤消和管理恢复。
综上所述，在Flux架构中，数据变化的粒度更大、更语义化，上层数据操作的行为更加抽象，碎片化程度降低。
Flux架构是React技术栈独有的吗？
不，任何人只要专注于基于传统架构的数据操作和用户/客户端/服务器行为的抽象定义，就可以享受Flux架构中提到的各种好处。
让我们看一下Flux 被黑客攻击最多的例子：“许多V、许多M 和一个C”。如果您发现图像中的每个视图都在不同的模型上运行，请将这些操作抽象为操作。通过中心化逻辑找到对应的模型来完成实际上是Flux的改变。这里抽象的Action 必须与图的Controller 可以接收的Action 相同。这没什么特别的。
基于这种理解，Redux提出了对Flux架构的不同理解。
一、通过Creator创建商店
每个商店都有自己的状态来记录其当前状态。
当您创建存储时，您通过减速器建立状态-动作关系。
然后通过向Store 对象分派各种操作来修改状态。
本质上，它也是对数据操作和上层行为的抽象，从实现层面来说更加具有功能性。
Vuex 基于Vue.js 的架构设计。稍后我会更详细地解释我的观点。
Flux 架构有什么未知的陷阱吗？我们就像观看《Black Flux》的人一样！
（咳咳咳~~这个问题一定要认真回答）
Flux 架构并没有向所有人传达Flux 存储是中心化的事实，并且它使用中心化存储而不是人们所抱怨的中心化控制器。
我见过一些基于Flux/Redux/Vuex 架构的实现，但坦白说，这种程序不可能在不建立连接的情况下完全隔离。您使用什么架构并不重要。
为什么没有人抱怨中心化存储？因为中心化数据的复杂度明显低于中心化行为控制的复杂度。你甚至没有意识到它是中心化的，但这实际上从另一个方面证明了这一点。
因此，我想通过Flux来看看架构的本质。这不是一个陷阱或抱怨。我更想说的是，我们应该如何放下Flux这把锤子，去看世界。我们每天设计和构建的软件。
集中数据管理并避免数据隔离。一旦数据被分离，它就会变得更加复杂，因为它需要通过其他程序连接。这是一个潜在的条件或结论，以避免修改数据的不同操作引起的混乱。
它总结行为并提高抽象级别，无论它是由用户交互引起的、从服务器检索的还是由系统本身操纵的。
当您将修改数据的操作组合在一起时，粒度会变得更大，达到纯粹“无状态”的极限。
另一个不经常讨论的细节是从模型到视图的转换应该简单直接。这是不同架构之间达成的共识，因此我不再赘述。
在这些方面，只要建筑师实现了他的最终目标，无论使用什么建筑缩写都是一样的。
那么Vuex 呢？
首先，让我告诉你我对Vue.js 的看法。 Vue.js 本质上做了一些事情。
组件或组件化分解视图。
通过计算选项简化数据和模板之间的对应关系
通过方法选项明确每个行为的抽象
通过双向计算选项提高数据操作的粒度
一些方法选项也可以用来完成纯数据操作，增加数据操作的粒度。
所以Vue.js 本身已经提供了很多好的架构实践。不过，在Flux看来，这还不够纯粹。缺少两件事：
数据的组件之间具有树状关系，但变化是分散的。
相应的计算方法和方法不应该分散，必须进行改造。
所以Vuex需要做的事情很简单。
在集中式存储中，所有组件共享一份数据或一份状态。在更复杂的情况下，定义有限数量的getter 并将其与计算选项一起使用。
定义有限数量的突变（类似于Dispatcher to Store 约定）。这可以直接在方法选项中使用。对于更复杂的情况，定义有限数量的操作（类似于从各种行为到调度程序的规则）。可以在方法内使用。可选地，各种定义的突变在幕后调用。
这样，通过在Vue 上构建并与更强大的Vuex 相结合，开发人员可以享受类似Flux 的感觉。
谈话几乎就结束了，甚至没有提到“单向数据流”这个词。
是的，我认为这个词被过度使用了。当在求职面试中被问到Flux 时，很多人脱口而出“单向数据流”，并经常用Flux 这个词的中文翻译来回答。这就像谈论Scrum 时说“看板”一样.
我认为单向数据流过于肤浅，并不能正确反映Flux 的愿景和意图。当提到单向数据流时，您想到的第一个图像是这样的：
我差点就说完了，连“时间旅行”这个词都没有提。
这是数据操作变得更加精细之后使用的术语。我认为这只是一个名词，但为什么这么说呢？
“时间旅行”的本质是记录所有数据的变化。只要每次更改都是无状态的，理论上您可以随时通过更改记录来恢复您的数据。
事实上，每当你对数据进行最细粒度的、不可分解的、最直接的操作（例如分配、删除、添加或移除数据项）时，如果你编写简单的代码，他们本质上就想象成为无状态的。程序记录了所有直接修改数据的操作，还可以非常精确地进行“时空旅行”，尽管这个术语太细粒度并且没有语义，因此没有人愿意使用这样的术语。琐碎数据细化操作过程中的“时间和空间”。数据操作粒度的增加，使其更加直观、语义化和易于理解，实际上对于功能开发和调试很有用，从而产生了“穿越时空”的概念。
Weex 什么时候支持Flux/Vuex？
这是我想说的最后一件事。首先，接口、数据和行为并不是特别复杂，尤其是在手机上，无论你是否有Flux/Vuex。
其次，如果你基于Vue 2.0 开发Weex 页面或应用程序，Vuex 是原生支持的，你不需要任何额外的东西。如果您已经在浏览器中练习Vuex，无论是桌面还是手机，您都不会注意到任何差异。
最后，上周我克隆了Vuex 来与Weex 的JS 框架一起使用，但我不想在这里占用太多空间。坦白说，我希望大家更加注重理解Flux 和Vue。其他问题都是合乎逻辑的。
总结
这篇文章总结了我个人对Flux的理解和个人看法。我们首先解释Flux 的四个核心术语：View、Store、Action 和Dispatcher，提出Dispatcher 在Flux 架构中的重要地位，并解释为什么Dispatcher 可以使用其他功能。其中三个变得更好、更“正式”，并提炼了我在了解Flux 后在幕后认识到的一些架构设计最佳实践。
实在是没有代码啊.
.如果您需要查看代码，请参见此处。
https://github.com/reactjs/redux
https://github.com/vuejs/vuex
https://github.com/jin Jiang/weex-x
谢谢
更多详细技术内容请关注云栖社区微信公众号yunqiinsight。
版权声明：本文由今日头条转载，如有侵犯您的版权，请联系本站编辑删除。