Flux |概念与应用
笔记，参考程墨老师的《深入浅出React和Redux》
Flux概念
- Dispatcher，处理动作分发，维持Store之间的依赖关系
- Store，负责存储数据和处理数据相关逻辑
- Action，提供给Dispatcher，传递数据给Store
- View，视图部分，负责显示用户界面
首先会产生一个事件，一般是由用户对界面执行的一个操作，Action得到这个操作后，将其交给Dispatcher，再由Dispatcher来进行分发给Store, Store收到通知后对相关数据进行维护，再发出一个更改通知，告诉视图层需要更新View了，然后重新从Store中检索数据，调用setState方法对View进行更新。
Flux应用
示例
安装
npm install --save flux
Dispatcher
src/AppDispatcher.js
//1.从flux库导入Dispatcher
//Dispatcher用来派发action
import {Dispatcher} from 'flux'
export default new Dispatcher();
Action
src/AcitonTypes.js
//1.定义actions类型
export const INCREMENT='increment'
export const DECREMENT='decrement'
src/Actions.js
//2.定义action构造函数
// 这是能够产生并派发action对象的函数（increment和decrement）
// 只要这两个函数被调用，就会创造对应的action对象 并通过AppDispatcher.dispatch派发出去
import * as AcitonTypes from './ActionTypes';
import AppDispatcher from './AppDispatcher'
export const increment = (counterCaption)=>{
AppDispatcher.dispatch({
type:AcitonTypes.INCREMENT,
counterCaption:counterCaption
})
}
export const decrement = (counterCaption)=>{
AppDispatcher.dispatch({
type:AcitonTypes.DECREMENT,
counterCaption:counterCaption
})
}
Store
store对象
- 存储应用状态
- 接受Dispatcher派发的动作
- 根据动作来决定是否要更新应用状态
[例子]有3个Counter组件，1个统计3个Counter计数值之和的组件
- 为Counter组件服务的CounterStore
- 为总数服务的SummaryStore
src/stores/CounterStore.js
import AppDispatcher from '../AppDispatcher'
import * as AcitonTypes from '../ActionTypes';
import {EventEmitter} from 'events';
const CHANGE_EVENT='changed'
const counterValues = {
'First': 0,
'Second': 10,
'Third': 30
};
const CounterStore=Object.assign({},EventEmitter.prototype,{
//1.用于让应用中其他模块读取当前的计数值
getCounterVlues:function(){
return conterValues
},
//2.定义监听
emitChange:function(){
this.emit(CHANGE_EVENT)
},
addChangeListener:function(callback){
this.on(CHANGE_EVENT,callback)
},
removeChangeListener:function(callback){
this.removeListener(CHANGE_EVENT,callback)
}
})
EventEmitter.prototype可以让对象变成EventEmitter对象。EventEmitter的实例对象支持下列相关函数：
- emit函数，广播特定事件，第一个参数是字符串类型的事件名称；
- on函数，增加一个挂在这个EventEmitter对象特定事件上的处理函数，第一个参数是字符串类型的事件名称，第二个参数是处理函数；
- removeListener函数，和on函数做的事情相反，删除挂在这个EventEmitter对象特定事件上的处理函数。
三者完成：更新的广播、添加监听函数和删除监听函数
//3. 把CounterStore注册到全局唯一的Dispatcher上去
//4. Dispatcher有一个register函数，接受回调函数作为参数
//5. 返回值是一个token，这个token可以用于Store之间的同步
// 返回值token在稍后的SummaryStore中会用到，现在保存在CounterStore.dispatchToken中
CounterStore.dispatchToken=AppDispatcher.register((action)=>{
if(action.type===AcitonTypes.INCREMENT){
counterValues[action.counterCaption]++
//6.更新监听
CounterStore.emitChange()
}else if(action.type===AcitonTypes.DECREMENT){
counterValues[action.counterCaption]--
CounterStore.emitChange()
}
})
export default CounterStore
当通过register函数把一个回调函数注册到Dispatcher之后，所有派发给Dispatcher的action对象，都会传递到这个回调函数中来。比如通过Dispatcher派发一个动作：
AppDispatcher.dispatch({ type:AcitonTypes.INCREMENT, counterCaption:'First' }) //1. 现在，当在CounterStore注册（register）的回调函数就会被调用 // register的参数就是这个派发的action对象 //2. 回调函数会根据action对象来决定改如何更新自己的状态 // 比如该动作含义：名为First的计数器要做加一动作。根据不同的type，会有不同的操作 //3. 所以注册的回调函数很自然有一个模式，就是函数体是if-else条件语句或者switch条件语句 // 条件语句的跳转条件，都是针对参数action对象的type字段 //4. 无论是加一或者减一，最后都要调用CounterStore.emitChange函数。 // 此时，如果有调用者通过CounterStore.addChangeListner关注了CounterStore的状态变化 // 这个emitChange函数调用就会引发监听函数的执行
src/stores/SummaryStore.js
import CounterStore from './CounterStore'
import AppDispatcher from '../AppDispatcher'
import * as AcitonTypes from '../ActionTypes';
import {EventEmitter} from 'events';
const CHANGE_EVENT='changed'
function computeSummary(counterValues){
let summary=0
for(const key in counterValues){
if(counterValues.hasOwnProperty(key)){
summary+=counterValues[key]
}
}
return summary
}
const SummaryStore=Object.assign({},EventEmitter.prototype,{
getSummary:function(){
return computeSummary(CounterStore.getCounterValues())
},
emitChange: function() {
this.emit(CHANGE_EVENT);
},
addChangeListener: function(callback) {
this.on(CHANGE_EVENT, callback);
},
removeChangeListener: function(callback) {
this.removeListener(CHANGE_EVENT, callback);
}
})
SummaryStore并没有存储自己的状态。当getSummary被调用时，它是直接从CounterStore里获取状态计算。SummaryStore提供了getSummary让其他模块可以获得所有计数器当前值的总和。
SummaryStore.dispatchToken=AppDispatcher.register((action)=>{
if((action.type===AcitonTypes.INCREMENT)||(action.type===AcitonTypes.DECREMENT)){
AppDispatcher.waitFor([CounterStore.dispatchToken]);
SummaryStore.emitChange()
}
})
export default SummaryStore
//1. SummaryStore同样通过AppDispatcher.register函数注册回调函数，用于接受派发的action对象
// 在回调函数中，只关注INCREMENT和DECREMENT类型的action对象。并通过emitChange通知监听者
//2. waitFor函数解决了调用顺序问题
// 这时，在CounterStore中注册回调函数时保存下来的dispatchToken终于派上了用场。
// 调用waitFor的时候，把控制权交给Dispatcher
// 让Dispatcher检查dispatchToken代表的回调函数有没有被执行，如果已经执行，那就直接接续;
// 如果还没有执行，那就调用dispatchToken代表的回调函数之后waitFor才返回
Dispatcher的register函数，只提供了注册一个回调函数的功能，但不能让调用者在register时选择只监听某些action。即当一个动作被派发的时候，Dispatcher就是简单地把所有注册的回调函数全都调用一遍
View
Flux框架下，View并不是说必须要使用React, View本身是一个独立的部分，可以用任何一种UI库来实现。
存在于Flux框架中的React组件需要实现以下几个功能:
1. 创建时要读取Store上状态来初始化组件内部状态；
2. 当Store上状态发生变化时，组件要立刻同步更新内部状态保持一致；
3. View如果要改变Store状态，必须而且只能派发action。
src/views/ControlPanel.js
class ControlPanel extends React.Component{
render(){
return(
<div>
<Counter caption="First" />
<Counter caption="Second" />
<Counter caption="Third" />
<hr/>
<Summary/>
</div>
)
}
}
src/views/Counter.js
import * as Actions from '../Actions'
import CounterStore from '../stores/CounterStore'
class Counter extends React.Component{
constructor(props) {
super(props);
this.onChange = this.onChange.bind(this);
this.onClickIncrementButton = this.onClickIncrementButton.bind(this);
this.onClickDecrementButton = this.onClickDecrementButton.bind(this);
//1.CounterStore.getCounterValues函数获得了所有计数器的当前值
//然后把this.state初始化为对应caption字段的值
this.state = {
count: CounterStore.getCounterValues()[props.caption]
}
}
//2.现在，Counter组件中的state是Flux Store上状态的一个同步镜像
//为了保持两者一致，当CounterStore上状态变化时，Counter组件也要对应变化
componentDidMount(){
CounterStore.addChangeListener(this.onChange)
}
componentWillUnmount(){
CounterStore.removeChangeListener(this.onChange)
}
onChange(){
const newCount =CounterStore.getCounterValues()[this.props.caption]
this.setState({count: newCount});
}
//3.只有当状态不一致时才更新状态
shouldComponentUpdate(nextProps, nextState) {
return (nextProps.caption !== this.props.caption) ||
(nextState.count !== this.state.count);
}
//4.让React组件触发事件时派发action,只需把action对象
onClickIncrementButton(){
Actions.increment(this.props.caption)
}
onClickDecrementButton(){
Actions.decrement(this.props.caption)
}
render(){
const {caption} =this.props
return(
<div>
<input type="button" onClick={this.onClickIncrementButton} value="+"/>
<input type="button" onClick={this.onClickDecrementButton} value="-"/>
<span>{caption} count:{this.state.count}</span>
</div>
)
}
}
可见，在Counter组件中有两处用到CounterStore的getCounterValues函数，
第一处是在构造函数中初始化this.state的时候
第二处是在响应CounterStore状态变化的onChange函数中
同样一个Store的状态，为了转换为React组件的状态，有两次重复的调用
src/views/Summary.js
import SummaryStore from '../stores/SummaryStore'
class Counter extends React.Component{
constructor(props){
super(props)
this.onUpdate = this.onUpdate.bind(this);
this.state={
sum:SummaryStore.getSummary()
}
}
componentDidMount(){
SummaryStore.addChangeListener(this.onUpdate)
}
componentWillUnmount(){
SummaryStore.removeChangeListener(this.onUpdate)
}
onUpdate() {
this.setState({
sum: SummaryStore.getSummary()
})
}
render(){
return(
<div>
total:{this.state.sum}
</div>
)
}
}
总结
- 引入Dispatcher对象
- 定义action类型
- 定义action构造函数
- view中触发事件以派发action
- 编写store状态
- 定义默认状态值
- 定义变量以让其它地方获取当前状态
- 定义监听
- 注册一个回调，接受派发过来的action对象为参数。接着通过传过来的对象更新store状态；再更新监听（示例中是emitChange），然后调用者通过addChangeListner监听某store的变化，如果有变化，就调用传进来的回调（示例中是onChange），将store中新的状态渲染到视图中
Flux的架构下，应用的状态被放在了Store中，React组件只是扮演View的作用，被动根据Store的状态来渲染。在上面的例子中，React组件依然有自己的状态，但是已经完全沦为Store组件的一个映射，而不是主动变化的数据。
用户的操作引发的是一个“动作”的派发，这个派发的动作会发送给所有的Store对象，引起Store对象的状态改变，而不是直接引发组件的状态改变。
Flux带来了哪些好处呢？最重要的就是“单向数据流”的管理方式。
在Flux中，如果要改变界面，必须改变Store中的状态，如果要改变Store中的状态，必须派发一个action对象
Flux的不足
Store之间依赖关系
如果两个Store之间有逻辑依赖关系，就必须用上Dispatcher的waitFor函数。SummaryStore对action类型的处理，依赖于CounterStore已经处理过了。
SummaryStore靠register函数的返回值dispatchToken标识CounterStore，而dispatchToken的产生，当然是CounterStore控制的，即：
- CounterStore必须要把注册回调函数时产生的dispatchToken公之于众
- SummaryStore必须要在代码里建立对CounterStore的dispatchToken的依赖
难以进行服务器端渲染
在Flux的体系中，有一个全局的Dispatcher，然后每一个Store都是一个全局唯一的对象，这对于浏览器端应用完全没有问题，但是如果放在服务器端，就会有大问题。
和一个浏览器网页只服务于一个用户不同，在服务器端要同时接受很多用户的请求，如果每个Store都是全局唯一的对象，那不同请求的状态肯定就乱套了。
Store混杂了逻辑和状态
Store封装了数据和处理数据的逻辑。但是，当我们需要动态替换一个Store的逻辑时，只能把这个Store整体替换掉，那也就无法保持Store中存储的状态。
还有一些应用，在生产环境下就要根据用户属性来动态加载不同的模块，而且动态加载模块还希望不要网页重新加载，这时候也希望能够在不修改应用状态的前提下重新加载应用逻辑，这就是热加载(Hot Load)
