一块儿学react | 漫谈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的理解，若有不正确的地方欢迎你们指正，但愿今天的分享对你们有所帮助，谢谢你们。