笔记----深刻浅出《React和Redux》第三章Flux框架

书中的此章节“思想”类成分较多，须要理解的内容也相对较多，若是一一列举，本文就写的相对繁琐了，推荐有兴趣的同窗能够去看一下书籍以及敲一下书中的代码，有助于理解做者大牛的思想，我就在此简略的记录一些相对重要的“点”了。

 

1、Flux框架的诞生以及解决了MVC框架哪些问题

  一、Flux出现背景

      Facebook的工程部门发如今前端使用MVC框架进行逻辑划分时，在业务量和代码量庞大的状况下，model层和view层之间依赖过于复杂，不利于后期对于代码的维护

      

   理想中，各个模块分工：

 　　Model：负责逻辑以及数据

       View：负责渲染界面

       Controller：负责接收用户的输入，根据用户的输入调用对应的Model部分逻辑，把产生的数据结果交给View部分，让View渲染出必要的输出

 

   MVC框架的请求流程：用户请求------>Controller------>Model------>View，View和Model不能直接进行互相通讯，都须要借助于Control

　　

 

　　

　　在实际工做中，对于浏览器端 MVC 框架，存在用户的交互处理，界面渲染出来以后，Model 和 View 依然存在于浏览器中，这时候就会诱惑开发者为了简便，让现存的 Model和 View直接对话，当代码量和逻辑复杂时，使程序“脆弱并且不可预测”

 

  二、Flux框架

　　 

 　　（1）特色：更严格的数据流控制

 

       （2）各个模块：

             Dispatcher(至关于“Controller”)：用来接收Actions、执行回调函数；

　　　　 Store(至关于“Model”)：用来存放应用的状态，一旦发生变更，就提醒Views要更新页面；

　　　　 Action(至关于“用户请求”)：视图层发出的消息；

             View：显示用户界面；

 

　　（3）与MVC框架的区别：

　　　　(i)当系统须要扩充应用所能处理的“请求”时，在MVC中，经过在Controller增长函数，来实现扩充；

               在Flux中，不须要Dispatcher增长新函数，而是经过增长新的Action类型，来实现扩充

 

　　（4）Flux实践 (直接上代码)

 

　　　　实现的效果：

　　　　　　 

　　　　　　　　

                   当点击“+”按钮或者“-”按钮，对应行的数字会时时进行改变，而且总数也会时时改变，下图：

　　　　　　

　　　　　　

 

 

              步骤一

　　　　　　  安装Flux：npm install --save flux             (若是感受慢，能够安装国内淘宝镜像)

 　　　　　　

（i）Dispatcher

                     

　　　　　　　做用：生成Dispatcher实例，用来以后将 Action 派发到 Store

　　　　　　　注意！注意！ 注意！Dispatcher实例在全局只有一个

 

（ii）Action（分2个文件，一个定义action类型，另外一个定义action构造函数）

　　　　　　　　ActionTypes.js

　　　　　　　　

　　　　　　　　说明：将常量放在单独一个文件方便管理

 

　　　　　　　　Actions.js 

　　　　　　　　

　　　　　　　　做用：根据类型，生成不一样的action对象，经过Dispatcher实例的dispatch函数派发出去

　　　　　　　　注意：出于业界习惯，这个文件被命名为Actions.js，可是要注意里面定义的并非action对象自己，而是可以产生并进行派发action对象的函数 

　　　　　　　　　　　　　　　　　　　　　　　　

（iii）Store（建立了两个store，CounterStore是为Counter组件服务，SummaryStore是为总数服务）

　　　　　　　　CounterStore.js

 　　　　　　　　

 　　　　　　　　

　　　　　　　　说明：在CounterStore中能够看出，首先定义了Counter组件初始化的值，而后使用Object.assgin()函数，对EventEmitter.prototype对象进行了浅拷贝，并在此浅拷贝对象的基础上扩充了getCounterValues、emitChange、addChangeListener、removeChangeListener方法。其中这四个方法的后三个方法，分别调用了EventEmitter.prototype的on()，emit()，removeListener()方法，做用以下：

　　　　　　　　 on(EVENT_TYPE，callback)：用来监听事件，第一个参数是字符串事件类型，第二个参数是事件处理函数；

　　　　　　　　 emit(EVENT_TYPE)：用来触发事件，第一个参数是字符串事件类型；

　　　　　　　　 removeListener(EVENT_TYPE，callback)：用来移除事件，若是要调用removeListener函数，就必定要保留对处理函数的引用，

                                                                                       第一个参数是字符串事件类型，第二个参数是事件处理函数。

最后，经过把AppDispatcher.register()中的回调函数注册到Dispatcher上，来接受以前经过AppDispatcher.dispatch()派发的action对象，经过switch或if-else来实现对应类型的动做实现对应类型的操做。

　　　　　　　　

　　　　　　　　

 

　　　　　　　　SummaryStore.js

　　　　　　　　 

　　　　 　　　　

　　　　　　　　说明：整体代码和以前CounterStore差很少。须要说明的是在这两个store中，AppDispatcher.register()会返回一个标记，保存在各自store的dispatchToken字段中，用来以后实现多个store之间行为的依赖顺序，借助waitFor()。在这个代码中，咱们但愿SummaryStore的逻辑在CounterStore以后进行

 

　　　　　　　　做用： Store是一个对象，既用于存储应用状态，也用来接受Dispatcher派发的动做，根据动做决定是否更新应用状态。

 

　　　　　　　　注意：store 在Flux中能够存在多个,每个 store 都会受到全部的 action 通知，而后自行以为是否对这个 action 作出响应，更新 state；

 　　　　　　　　　　  store对外只暴露了读取接口，若是想实现写入的功能，只能去实现对应action。

 

 　　　　

（iv）View（用React进行实现，3个视图组件，其中ControlPanel父组件包含Counter子组件，Summary子组件）

　　　　　　　　

　　　　　　　　 ControlPanel组件

　　　　　　　　

 

　　　　　　　　Counter

　　　　　　　　　　　　　　　　

 　　　　　　　  

 

 　　　　　　　　Summary

　　　　　　　　 

　　　　　　　　View 的代码就是常规React书写方式，就不一一叙述了

 

 　　　　　　　　注意：存在于Flux框架中的React组件须要实现如下几个功能

　　　　　　　　　　    1）建立时要读取Store上的状态来初始化组件内部状态；(而不像以前经过props传参，实现组件内部初始化)

　　　　　　　　　　　 2）当Store上状态发生变化时，组件要马上同步更新内部状态保持一致；(经过Store改变状态后调用emit()，以及View经过on()来监听Store中状态的变化)

　　　　　　　　　　　 3）View若是要改变Store状态，只能派发action。(Flux中，对Store进行修改，只能经过新建action)

 

 

（v）上述代码我的理解及总结：

过程一：按着组件的生命周期函数顺序，进行渲染。其中componentDidMount函数经过CounterStore.addChangeListen函数监听了CounterStore的变化以后，只要CounterStore发生变化，Counter组件的onChange函数就自动会被调用。不过首次挂载时，能够发现getCounterValue被重复调用了2次来读取相同值，分别是第一个是constructor中被调用，第二个是componentDidMount中的this.onChange中被调用

　　　　　　　　　　　　  

　　　　　　　　　　　　  

　　　　　　　　　　　　  　　　　

　　 

过程二：当进行点击“+”按钮时，this.props.caption当即读取了当前组件上的属性值First，以形参的形式传入increment()方法，并触发increment()；

　　　　　　　　　　　　  （以First为例子）　　　　　　　　　

 　　　　　　　　　　       

 

过程三：此时Dispatcher的实例（AppDispatcher）调用dispatch()方法，将刚产生的action对象派发出去，此时action对象上携带着动做类型，以及刚刚传入的First字符串标记

　　　　　　　　　　　  　 　　　　　　　　　　　　

 

过程四： 经过AppDispatche.register()来注册回调函数，以后这个回调函数就能够接受派发出来的action对象，并根据这个action对象的类型，执行对应的逻辑，即在这里的逻辑是根据action.counterCaption拿到First，而后经过counterValues[First]拿到当前保存在Store中的初始值，并进行加一操做，最后经过emit()，将事件触发

　　　　　　　　　　　　　　　　　　　　　　　　

 　　　　　　　　　　　　

 

过程五：在过程一首次挂载时，onChange函数做为形参数，最终传入on()中，监听事件的触发，也就是等待emit函数被调用，而后执行onChange函数内部操做，经过getCounterValues得到Store的新状态值，即First字段加一后的值，最后经过setState函数将这个值同步到组件内部状态count上，同时State的更新会触发生命周期的shouldComponentUpdate函数，判断这次渲染是否与上一次不一样，若是不一样则返回true，并将结果渲染到页面 

　　　　　　　　　　　　

 　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　

 

 　　　　　　　　　　　　其余的“-”按钮以及计算总和的步骤流程也差很少，我就不继续进行描述了，能够按照上面过程进行推演。 

 

　　　　　　　　　　　　结合本身理解，画了一个图，完毕。

　　　　　　　　　　　　

三、Flux框架的优势：

（1）对比纯粹使用React框架，当多个组件或者组件之间多层嵌套的状况下，对一个全局变量进行操做，只经过props进行操做显的特别的麻烦，

       在使用Flux框架状况下，React组件在其中只充当了View并对Store进行了时时的监听，全局变量由Store进行保存，组件能够经过action对Store进行操做，并反馈到View。

       避免的props带来的繁琐，不过程序若是不复杂，使用Flux也可能把“简单问题复杂化”，使用时视状况而定。

 

（2）对比前端MVC框架，他的“单向数据流”管理方式更加的严格。

 

 

四、Flux框架不足： 

(1) 多个Store之间的依赖

(2) Store混杂逻辑和状态

 

 

 

 

 

 

睡觉睡觉！！！！！！！未完待续~~~

 

 

其余参考：http://www.ruanyifeng.com/blog/2016/01/flux.html