深刻浅出React和Redux学习笔记（三）

从Flux到Redux

Redux管理应用状态的框架：

1. 单向数据流的始祖Flux;
2. Flux理念的一个更强实现Redux;
3. 结合React和Redux;

1.Flux

Redux是Flux思想的另外一种实现方式；

Flux(含Redux)贯彻的重要观点——单向数据流；

Flux推翻了MVC框架，用了新的思惟来管理数据流转；

1.1MVC框架的缺点

MVC框架把应用分为三部分：

1. Model(模型)：负责管理数据，大部分业务逻辑在Model之中；
2. View(视图)：负责渲染用户界面，应避免在View中涉及业务逻辑；
3. Controller(控制器)：负责接收用户的输入，根据用户输入的Model部分逻辑，把产生的数据交给View部分，让View渲染必要的输出；

MVC框架的缺点：

对于很是巨大的代码库和庞大的组织，MVC框架很快变得很复杂。每新增一个功能时，对代码的修改很容易引入新的Bug,不一样模块之间的依赖关系让系统变得“脆弱且不可预测”。

Flux的特色：

更严格的数据流控制；

Flux应用分为四个部分：

1. Dispatcher:处理动做分发，维持Store之间的依赖关系；
2. Store：负责存储数据和处理数据相关逻辑；
3. Action：负责驱动Dispatcher的JavaScrip对象；
4. View：视图部分，负责显示用户界面；

   

Flux和MVC结构上的区别：

1. Flux的Dispatcher至关于MVC的Controller；
2. Flux的Store至关于MVC的Model;
3. Flux的View至关于MVC的View;
4. Flux的Action能够理解为MVC框架的用户请求；

1.2Flux应用

一个EventEmitter实例对象支持的函数：

1. emit函数：能够广播一个特定事件，第一个参数是字符串类型的事件名称；
2. on函数:能够增长一个挂在此EventEmitter对象特定事件的处理函数，第一个参数是字符串类型的事件名称，第二个参数是处理函数；
3. removeListener函数：和on函数作的事情相反，删除一个挂在此EventEmitter对象特定事件的处理函数，和on函数同样的是，第一个参数是字符串类型的事件名称，第二个参数是处理函数。注意：若是要调用removeListener函数，就必定要保留对处理函数的引用；

如何使Dispatcher调用回调函数的顺序是咱们预期的呢？

Dispatcher的waitFor函数。

Dispatcher的waitFor函数能够接受一个数组做为参数，数组中的每个元素都是Dispatcherregister函数的返回结果，即dispatchToken。这个waitFor函数告诉Dispatcher，当前的处理必须暂停，直到dispatchToken表明的那些已注册回调函数执行结束才能继续。

存在于Flux框架中的React组件须要实现的功能：

1. 建立时读取Store的状态来初始化组件的状态；
2. 当Store上状态发生变化时，组件要马上更新内部状态保存一致；
3. View若是要改变Store状态，必须并且只能派发Action;

1.3Flux的优点

Flux的架构下，应用的状态被放在Store中，React组件只扮演View的做用，被动根据Store的状态来渲染。

Flux的优点主要表如今“单向数据流”的管理方式。

在Flux的理念中，改变界面就必须改变Store的状态，改变Store的状态就必须派发一个对象。

MVC最大的缺点就是没法禁绝View和Model之间的直接对话。

在Flux的体系下，驱动界面的改变始于一个动做的派发，别无他法。

1.4Flux的不足

1. Store之间的依赖关系；
2. 难以进行服务端渲染；
3. Store混杂了逻辑和状态；

2.Redux

若是把Flux看作一个框架理念的话，Redux就是Flux的一种实现，除Redux以外，实现Flux的框架有Reflux、Fluxible等。

2.1Redux的基本原则

Redux的三个基本原则：

1. 惟一数据源（Single Source of Truth):应用的状态只存储在惟一的一个Store上；
2. 保持状态只读(State is only-read):不能直接去修改状态，要修改Store的状态，必须派发一个Action对象完成。

   驱动用户界面渲染，就要改变应用的状态，但不是去修改状态的值，而是建立一个新的状态对象给Redux，由Redux完成新的状态的组装。

3. 数据改变只能经过纯函数改变(Changes are made with pure functions);

2.2Redux实例

无

2.3容器组件和傻瓜组件

在Redux的框架下，一个React组件基本要完成两个功能：

1. 和Redux Store打交道，读取Store的状态，用于初始化组件状态，同时还要监听Store的状态改变；当Store状态发生改变时，须要更新组件状态，从而驱动组件从新渲染；当须要更新Store状态时，就要派发Action对象；
2. 根据当前props和state,渲染出用户界面；

让一个组件专一一件事，若是发现一个组件作的事情太多，就能够把这个组件拆分红多个组件，让每一个组件依然只作一件事情。

容器组件(Container Component):承担第一个任务的组件，即负责和Redux Store打交道的组件，处于外层；另外一种说法叫作聪明组件(Smart Component)。容器组件作的事情涉及一些状态转换。

展现组件(Dumb Component):承担第二个任务的组件，即只专心负责渲染界面的组件，处于内层；另外一种说法叫作傻瓜组件(Dumb Component)。傻瓜组件其实就是一个纯函数，根据props产生结果。

2.4组件Context

组件Context:就是所谓的“上下文环境”，让一个树状组件上的全部组件都可以访问的对象，为了完成这个任务，须要上级组件和下级组件配合。

首先，上级组件要宣称本身支持Context，而且提供一个函数来返回表明Context的对象。

其次，此上级组件之下全部的子孙组件，只要宣称本身须要这个Context，就能够经过this.context访问到这个共同的环境对象。

1. 上级组件提供Context；
2. 下级组件使用Context;

Redux对Store的封装好,没有提供直接修改状态的功能。虽然组件可以访问全局惟一的Store，可是不能直接Store中的状态，克服Store做为全局对象的缺点。

2.5React-Redux

改进React应用的两个方法：

1. 组件拆分为容器组件和傻瓜组件；
2. 提供组件直接访问的Context；

Redux两个最主要的功能：

1. connect:链接容器组件和傻瓜组件；
2. Provider:提供包含Store的Context;

1.connect

容器组件的工做：

1. 把Store的状态转化为内层傻瓜组件的prop；
2. 把傻瓜组件的用户动做转化为派发给Store的动做；

简言之，一是对内层傻瓜组件的输入，二是内层傻瓜组件的输出。

2.Provider

React-Redux要求Store所包含的三个函数的Object:

1. subscribe
2. dispatch
3. getState

拥有以上三个函数的对象，才能称之为Redux的Store。

React-Redux定义了Provider的componentWillReceiveProps函数，在React的生命周期中，componentWillReceiveProps函数每次渲染时都会被调用。

每一个Redux应用只能有一个Redux Store ,在整个Redux的生命周期中都应该保持Store的惟一性。