React Flux架构模式

前言：

    MVC是一种架构模式，它通过关注数据界面分离，来鼓励改进应用程序结构。MVC强制将业务数据（Modal）与用户界面（View）分离开，通过控制器（Controller）管理逻辑和用户输入。这种模式的缺点是：在你项目越来越大的时候，逻辑越来越复杂，数据流动的方式就很混乱。

   

在此基础上，又衍生出来了MVVM,由VM(ViewModal)q取代了C(Controller),关键的改进是数据绑定（DataBinding），也就是说，View的数据状态发生变化可以直接影响VM,反之亦然。

Flux架构模式

Flux的核心思想就是数据和逻辑永远单向流动。

众所周知，React提倡的是一种单向数据流，指的是父子组件之间的单向数据流。而Flux中的单向数据流则是在整体架构上的延伸。在Flux应用中，数据从action到dispatcher，再到store,最终到view的路线是单向不可逆的，各个角色之间不会像MVC模式中那样存在交错的连线

因为要实现单向数据流，所以在Flux模式中的dispatcher中定义了严格的规则来限定我们对数据的修改操作。只能通过dispatcher来修改store中的state，所以同时，store中不能不暴露setter，强化数据修改的纯洁性。

上面谈到的如果渲染函数只有一个后，即每次数据的更新都会调用重渲染，会十分的影响性能。在React中，通过Virtual DOM这个技术来进行优化性能，因为每次重渲染的是内存上的Virtual DOM，并由于PureRender保障从重渲染到局部渲染的转换。

一个Flux应用由三大部分组成dispatcher,store和view

• dispatcher负责分发事件
• store负责保存数据，同时响应事件并更新数据
• view负责订阅store中的数据，并使用这些数据渲染相应的页面

Flux的不足

虽然Flux的中心化控制十分优雅。但是它最大的问题就是Flux的冗余代码太多。虽然Flux源码中几乎只有dispatcher的实现，但是在每个应用中东需要手动创建一个dispatcher的实例，而且在一个应用中含有多个store。

基于Flux思想的Redux

Redux是基于Flux架构思想的一个库的实现，它主要的核心运作流程为：

Redux与Flux的区别

• Redux中只有一个store，而Flux中有多个store来存储应用数据，并在store里面执行更新逻辑，当store变化的时候再通知controller-view更新自己的数据，Redux是将各个store整合成一个完整的store,并且可以根据这个store来得到完整的state，而且更新的逻辑也不再store中，而是在reducer中。
• Redux没有Dispatcher这个概念。它使用的是reducer来进行事件的处理，reducer是一个纯函数(preState, action) => newState,在Redux应用中，可能有多个reducer，每一reducer来负责维护应用整体state树中某一部分，多个reducer通过combineReducers方法合成一个根reducer,来维护整个state

如图的比较
Flux：

Redux:

Redux设计和使用的三大原则

• 单一的数据源

  在Redux的思想里，一个应用永远只有唯一的数据源，使用单一数据源的好处在于整个应用状态都保存在一个对象中，我们随时可以提取出整个应用的状态进行持久化,这样的设计也为SSR提供了可能

• 状态是只读的

  状态是只读的这个和Flux的思想相同，但是Redux中还限制了store的setter从而限制修改应用状态的能力。在Redux中，我们不会用代码来定义一个store，而是通过reducer，通过当前触发的action来对当前应用的state进行迭代，这里没有直接改变应用的状态，而是返回了一个全新的状态。

• 状态修改均由纯函数完成

  在Flux中，是通过dispatcher的dispatch来触发action，不仅产生了冗余代码，而且直接修改了store中的数据，无法保存每次数据变化前后的状态，在Redux中，通过纯函数reducer来确定状态的改变，因为reducer是纯函数，所以形同的输入，一定会得到相同的输出，这样的话，返回的是一个全新的state，可以跟踪每一次触发action而改变状态的结果成为了可能，也就是可以达到炫酷的time travel 调试方法。