Reflux怎么玩？
Reflux的action应该全权负责async到服务器的数据处理，尤其是数据的卸载。
Reflux的store应该分为最少3种：
- 最基本的：数据型
- 少量：broadcast广播型
- 通道：tunnel型
一、数据型是基本数据的：
store用来存数据，这些数据在逻辑上与用户有关，比如用户的基本信息，存数据的store在以引用mixins的方式被引入react组件的时候需使用Reflux.connect方法，这样，react组件初始化时会调用store的getInitialState和react组件的getInitialState方法合并起来提供数据到react组件的state里。注意，这个地方组件调用store的getInitialState，但是store可能早已存在于内存里了，这个时候store里如果已有数据（比如用户信息已经从服务器获取到了），就应该把这些数据直接从store的getInitialState里返回回去，而不是再从服务器获取一次。所以，一个方便的react组件对接数据型store时的代码是这样的：
store：
/* 这样的store的基本行为模式是： */
/* 1. 初始化(init)里生成默认数据 */
/* 2. 某react的组件获取数据的时候走到getInitialState，去后台获取数据（仅一次） */
/* 3. 之后由于用this.data.pristine置位过，数据会直接从getInitialState流到react组件，而不会再去服务器获取 */
/* P.S. 谨慎使用或者干脆禁用开发者从component上自己调用服务器获取数据 */
const SomeDataStore = Reflux.createStore({
/* 这个只是给react组件用的，调一次执行一次，对store而言可不是一辈子就一次 */
getInitialState: function() {
if(this.pristine) { // 放这里调action，还用一个变量控制住，只发一次后台，而且是按需发后台
SomeDataAction.getSomeData() // 这里其实会有async的bug，少数情况下会有多个action发出，但业务逻辑明确组件结构明确的时候确实不会bug
}
// getInitialState是react组件初始化时必须调用的方法，这里给组件提供数据
// 但是这个方法并不是store初始化自己的方法（这个坑好痛）
return this.data
},
/* init才是store的生命周期好嘛 */
init: function() { // 这才是Store初始化的方法，这里一次性生成初始化数据
this.pristine = true // 增加这个字段来表达当前store的数据是否已从服务器获取过
this.data = {
userName: ‘unknown’,
userId: -1,
},
},
// 数据过来后，记得 this.pristine = false
})
react component:
/* 别忘了，挂载store的组件是smart component (container) */
const SomeComponent = React.reactClass({
mixins: [ Reflux.connect(SomeDataStore, ’someData') ], // 这个mixins会把SomeDataStore返回的数据挂到this.state.someData处
getInitialState: function() {
// 你还是可以用getInitialState来初始化一些界面内部的数据的，只是不要和store里的getInitialState冲突就好
return { uiData: ‘德玛西亚!' }
},
})
二、少量broadcast广播型store：
比如，好多http错误，很烦，真不想让他们跟数据混在一起，于是有这个想法：所有http错误让一个store去捕捉，捕捉后trigger出去的时候挂一个type字段，哪个组件想报错，就去监听（是的，这是async，发起的component要先Reflux.listenTo到）这个store的数据，用type过滤后报错给用户。（所以如果你明知道自己触发了http请求，但是并没打算报错到用户那里，完全可以不监听这个store）
const SOME_TYPE = 'some_type'
// maybe NotificationStore?
var NotifyStore = Reflux.createStore({
init: function() {
this.listenTo(Action.fetch.success, this.triggerWrapper(SOME_TYPE, true))
this.listenTo(Action.fetch.error, this.triggerWrapper(SOME_TYPE, false))
},
triggerWrapper: function(source, success) {
return function(resp) {
this.trigger({
source: source,
success: success && resp.Success,
code: resp.ErrorCode,
msg: resp.ErrorMsg, // TODO: 这里要“或”一个非200的http response
})
}
},
})
三、通道型的store：
这个store类型我其实还没有使用过，但是在看同事写某个翻页列表的时候看到的：有这么一些数据并不需要存放在数据型的store里，它们只对一个界面有意义，获取一次就抛弃了，没必要存着。怎么办呢？Reflux和Redux的最大区别也许也在这里：在Redux里，我们想把所有state存在store里，甚至组件只用一个render方法就写出来了，可是Reflux里基本只存了逻辑上的数据，组件的“小状态”基本都是封装在组件内部的，而这部分“只对一个界面有意义”的数据正是这种“小状态”。所以这个时候，毕竟所有http请求都习惯性封装进了action，所以做一下tunnel类的store，数据从action的async过来，经store转手交给react组件，不保存（没必要保存），所以称之为tunnel(隧道/通道).