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的比较学习
网友评论