一起学react | 漫谈Flux

小编最近一直想写一篇关于Flux的文章分享给大家，为了让大家更容易理解，小编也是刻苦学习了许久，终于有所领悟，今天小编将用漫画的形式给大家介绍下什么是Flux，有什么不正确的欢迎大家多多指正。

要解决什么问题

首先小编先给大家介绍下Flux为什么存在，是解决什么问题的。Flux是一种开发模式，而不是具体的一个框架，关键是它内在的思想。它核心的概念就是单向数据流。

React出现的时候，就已存在了Flux,它们是一起成长和发展的，他们刚开始是为了解决Facebook网站开发中遇到的一系列的开发问题，比如消息通知场景：

开发过消息通知场景同学们，估计会遇到类似的BUG，明明接收到新消息提醒了，点进去没有任何消息。没过多久，又收到新消息了，点击进去，又没看到任何消息。就这样周而复始，这种感觉确实糟透了。

FaceBook的工程师看到这个问题后，这怎么能行，赶紧修复后就发布了。没过多久，Bug又出现了。

因此FaceBook的工程师不希望这样的问题周而复始的出现，他们希望系统是可以预测的，只改一次，直接定位到问题的原因。

潜在的问题

潜在的问题是应用程序的数据流，下面的图是我们常见的应用设计模式:

可以看出，如果MODEL变化了，会影响好几个相关VIEW的变化，同时一个VIEW也会对应多个MODEL,就好比我们打乒乓球，遇到高手时，不知道他打过来的球在什么位置，我们如何去接。如果我们的业务越来越复杂，就可能如下图：

这些改变更多是异步发生的，一个发生改变，会引起多个改变。就好比多个乒乓球向你飞来，你很难确认这些球在什么位置落下。

因此你要调试BUG，很难定位到问题的根源。

解决方案：单向数据流

为了解决上述问题，FaceBook大胆尝试一种不同类型的架构，比如插入一条数据需求，数据插入的触发，只能有一种方式，数据流的方向只能是单向的，如果再次插入，还需要从头开始，具体示意如下图（来自官网）：

这张图看起来十分简单清晰明了，你真的能很清楚这个图的原理？尤其对于新手，越是简单的图不一定是越容易理解的，为了让大家更好的理解这张图，小编还是用卡通人物的场景给大家介绍下。

人物介绍

小编一一介绍完这些人物后，再给大家讲解下他们是如何一起工作的：

The action creator

第一个介绍的人物是The action creator，每当你需要改变the state或者让页面有所变化，你必须创建action。

The action creator 就相当一个发电报的打字员，你只需要告诉他要发什么内容，他们就会把你的内容处理成系统认识的格式，把它发送出去。

The action creator 会创建一个你定义的类型和传入的参数。例如MESSAGE_CREATE 和 MESSAGE_READ 的 action。

这样的好处就是，对于一个新加入你们团队新人来说，打开项目是清晰明了的，对应的state是有哪个Action触发的一一对应，明明白白。

一旦Action创建，the action creator 会把Action传递给the dispatcher。

The dispatcher

The dispatcher 翻译过来就是调度员的意思，所有的Action传递到这里后，统一由它进行调度。The dispatcher  注册了对应的回调函数，就像一个管理电话交换机的管理员，它会把Action传递给对应store。store只会接受处理自己关心的Action，不符合的Action将会被无视。

The store

接下来要介绍的是The store，The store更像一个独裁者，他控制着 the state 改变的业务逻辑。

所有的store必须在dispatcher 进行注册，所有的Action发送dispatcher 后，在dispatcher 里通过switch语句来决定请求哪个store，store接收请求后就会做出state的改变。

一旦state改变后，将会触发一个改变事件，the controller view 将会监听到这个事件，从而在view 显示 state的改变。

The controller view and the view

The views 负责获取 state 状态呈现给用户并且接收用户输入的请求。

The view 就相当一个会议发言人，他只需将结果结论的东西告诉大家，他并不需要知道这些结果是如何出来的。在系统里，它并不关心系统中数据是如何处理的，它只负责将数据在用户面前呈现出来。

The controller 就相当 store 和 view 之间的中间人，view 的管理者，如果store 告诉他state改变了，他负责收集和整理。然后让The view 进行把新的state呈现给用户。

他们是如何一起工作的？

介绍完这些人物后，小编给大家介绍下他们是如何配合和工作的。

系统初始化

1. 应用加载初始化时，Stores 命令 dispatcher 让他时刻注意任何action的创建。

2.然后the controller views 告诉 the stores 如果state有变化，请告诉他。

3.如果 the stores 把 the state 改变的信息通知了the controller views,  controller views 就会命令相关的 views 做出响应。

4. The controller views 告诉 the stores 时刻保持联系，以便他们能做及时的反馈与响应呈现给用户。

The data flow

一旦应用程序初始化完毕，就等待着用户发号施令，下面小编给大家演示这这个流程是如何完成的。

首先用户在界面中输入了一个指令要求

1. The view 告诉 the action creator 去创建一个action。

2. The action creator 将格式化后的 the action 传递给 the dispatcher。

3. The dispatcher 将 the action 发送给对应的store 。每个 store 处理他们关心的 actions。然后 the store 决定是否改变 the state。

4.一旦 state 改变, the store就去通知view controllers。

5. view controllers 就会要求 the store 告诉他们更新后的state。

6.  the store 告知更新后的state, the view controller 告诉 views 在页面中显示新的state。

这就是我对于Flux的理解，如有不正确的地方欢迎大家指正，希望今天的分享对大家有所帮助，谢谢大家。

更多精彩内容，请微信关注”前端达人”公众号！

新年大礼包

关注“前端达人”公众号，回复“新年大礼包”获取英文电子书：

更多精彩内容，请微信关注”前端达人”公众号！