Flux-Redux先驱

Flux的诞生是为了解决MVC模式 在不断开发中难以维护和扩展的问题 他的解决方案就是 单向数据流

由于MVC最大的问题 Model和View之前可以相互通信,在项目后期尤其是大项目中,会越来越混乱

MVC的缺点
Flux模式:中央集权,专管专治
Flux单向数据流模式

1 结构

一个Flux应用包括四个部分

• Dispatcher 处理时间分发, 维护store之间的依赖关系
• Store 扶着存储数据和处理数据相关逻辑
• Action 驱动Dispatcher和JavaScript对象
• View 视图部分,负责显示用户界面

Dispathcer

dispatcher 存在的作用就是用来派发action

import { Dispatcher } from 'flux'

Action

action 就是一个"动作", 是一个Js对象,其中一个必须有一个名为type的字段,用于记录日志或者debug方便

Store

一个Store也是一个对象,这个对象存储应用状态,同事还要接受Dispatcher派发的动作,根据动作来决定是否要更新应用状态.
注册(register)：把当前store注册到Dispatcher下，加入dispatcher关系网
通过emit广播、on挂载事件
store需要注册到全局唯一的Dispatcher上才有效

View

View并不是必须要使用React,View本身也是一个独立的部分,可以使用任何一种UI库来实现.使用的时候必须实现以下功能

• 创建时要读取Store上状态来初始化组件内部状态
• 当Store上状态发生变化是,组件要立刻同步更新内部状态保持一致
• View如果要改变Store状态,必须而且只能派发action

2 理念

如果要改变界面,必须改变Store中的状态,如果要改变Store中的状态.必须派发一个action对象,这就是规矩和必须.在这个规矩下,想要追溯一个应用的逻辑就变得非常容易.

3 不足

Store之间依赖关系

若果两个Store之间有逻辑依赖关系,就必须用上Dsipatcher的waitFor函数,先处理依赖关系

难以进行服务器端渲染

如果要做服务器端渲染,输出的应该是全部都是HTML的字符串.在Flux中有一个全局的Dispathcer,然后每一个Store都是一个全局的唯一对象.这样在客户端还好,但是在服务器端就很困难实现.

Store混杂了逻辑和状态

推荐图书：程墨《深入浅出React和Redux》 推荐阅读react入门之 Redux与flux的比较学习