React Flux架构简介
个人现阶段对Flux架构的明白，求拍砖求star!
原文链接：https://github.com/kuitos/kuitos.github.io/issues/27
React 简介请戳 这里
Flux是什么
Flux是Facebook用来构建客户端web运用的运用架构。它应用单向数据流的体式格局来组合react中的视图组件。它更像一个情势而不是一个正式的框架，开发者不须要太多的新代码就能够疾速的上手Flux。
Flux的中间部份
1. dispatcher
事宜调理中间，flux模子的中间关键，治理着Flux运用中的一切数据流。它本质上是Store的回调注册。每一个Store注册它本身并供应一个回调函数。当Dispatcher相应Action时，经由过程已注册的回调函数，将Action供应的数据负载发送给运用中的一切Store。运用层级单例！！
2. store
担任封装运用的营业逻辑跟数据的交互。
Store中包括运用一切的数据
Store是运用中唯一的数据发作变动的处所
Store中没有赋值接口—一切数据变动都是由dispatcher发送到store，新的数据跟着Store触发的change事宜传回view。Store对外只暴露getter，不允许供应setter！！制止在任何处所直接操纵Store。
3. view
controller-view 能够明白成MVC模子中的controller，它平常由运用的顶层容器充任，担任从store中猎取数据并将数据通报到子组件中。简朴的运用平常只要一个controller-view，庞杂运用中也能够有多个。controller-view是运用中唯一能够操纵state的处所(setState())
view(UI组件) ui-component 职责单一只允许挪用action触发事宜，数据从由上层容器经由过程属性通报过来。
4. 其他
action creators 作为dispatcher的辅佐函数，一般能够认为是Flux中的第四部份。ActionCreators是相对自力的，它作为语法上的辅佐函数以action的情势使得dispatcher通报数据更加方便。
How Flux(Unidirectional Data Flow) Works
view –> actionCreators
// Nav.jsx export default class Nav extends React.Component { _handleClick(nav) { NavActionCreators.clickNav(nav); } render() { let itemList = this.props.list.map((nav, index) => { return ( <li className="index-menu-item" onClick={this._handleClick.bind(this, nav)} key={index}> <span>{nav.text}</span> </li> ); }); return ( <nav className="index-menu"> <ul className="index-menu-list"> {itemList} </ul> </nav> ); } }action dispatch
// NavActionCreators.js export default { clickNav(nav){ AppDispatcher.dispatch( { type: ActionTypes.CLICK_NAV, nav } ); } };dispatcher –> store callback
AppDispatcher.register(action => { switch (action.type) { // nav点击 case ActionTypes.CLICK_NAV: IndexWebAPIUtils.getGiftList(_currentUserInfo.userId, action.nav.id) .then(function (giftList) { _currentGiftList = giftList; IndexStore.emitChange(); }); break; // no default } });store emitChange –> controller view –> setState
export default class Index extends React.Component { constructor(props) { super(props); let currentUser = UserStore.getCurrentUser(); this.state = IndexStore.getAll(); } componentDidMount() { IndexStore.addChangeListener(this._onChange.bind(this)); } componentWillUnmount() { IndexStore.removeChangeListener(this._onChange.bind(this)) } _onChange() { this.setState(IndexStore.getAll()); } render() { let state = this.state; return ( <div className="page active"> ... <Nav list={state.navList}/> ... </div> ); } }
Flux vs MVVM
MVVM
1. 简朴的MVVM
2. 庞杂的MVC
Flux
1. 庞杂的Flux
Flux的上风
1. 数据状况变得稳固同时行动可展望
因为angular双向绑定的缘由，我们永久没法晓得数据在哪一刻处于稳固状况，所以我们常常会在angular中看到经由过程setTimeout的体式格局处置惩罚一些题目(其实有更文雅的解决方案，不在本次议论以内)。同时因为双向绑定的缘由，行动的流向我们也很难展望，当视图的model变多的时刻，假如再加上一堆子视图依靠这些model，题目发作时定位简直是恶梦啊(这也是angular的错误信息那末不友好的缘由，因为框架开发者也没法肯定当前行动是谁触发的啊，绑定的人太多了…)。然则这里照样要强调一点就是，并非说双向绑定就一定会致使不稳固的数据状况，在angular中我们经由过程一些手腕依旧能够使得数据变得稳固，只是双向绑定(mvvm)相对于flux更轻易激发数据不稳固的题目。
2. 一切的数据变动都发作在store里
flux里view是不允许直接修正store的，view能做的只是触发action，然后action经由过程dispatcher调理末了才会流到store。一切数据的变动都发作在store组件内部，store对外只供应get接口，set行动都发作在内部。store里包括一切相干的数据及营业逻辑。一切store相干数据处置惩罚逻辑都集合在一起，防止营业逻辑疏散下降保护本钱。
3. 数据的衬着是自上而下的
view一切的数据泉源只应该是从属性中通报过来的，view的一切表现由上层掌握视图(controller-view)的状况决议。我们能够把controller-view明白为容器组件，这个容器组件中包括多少微小的子组件，容器组件差别的状况对应差别的数据，子组件不能有本身的状况。也就是，数据由store通报到controller-view中以后，controller-view经由过程setState将数据经由过程属性的体式格局自上而下通报给各个子view。
4. view层变得很薄，真正的组件化
因为2、3两条缘由，view本身须要做的事变就变得很少了。营业逻辑被store做了，状况变动被controller-view做了，view本身须要做的只是依据交互触发差别的action，仅此而已。如许带来的优点就是，全部view层变得很薄很地道，完整的只关注ui层的交互，各个view组件之前完整是松耦合的，大大提高了view组件的复用性。
5. dispatcher是单例的
对单个运用而言dispatcher是单例的，最主要的是dispatcher是数据的分发中间，一切的数据都须要流经dispatcher，dispatcher治理差别action于store之间的关联。因为一切数据都必须在dispatcher这里留下一笔，基于此我们能够做许多风趣的事变，种种debug东西、行动回滚、日记纪录以至权限阻拦之类的都是能够的。
Flux的逆境
1. 过量的榜样代码
flux只是一个架构情势，并非一个已完成好的框架，所以基于这个情势我们须要写许多榜样代码，代码量duang的一会儿上来了。。不过幸亏现在已经有许多好用的基于flux的第三方完成，现在最火的属redux。
2. dispatcher是单例
dispatcher作为flux中的事宜分发中间，同时还要治理一切store中的事宜。当运用中事宜一多起来事宜时序的治理变得庞杂难以保护，没有一个一致的处所能清楚的表达出dispatcher治理了哪些store。
3. 异步处置惩罚究竟写在那里
按flux流程，action中处置惩罚：依靠该action的组件被迫耦合进营业逻辑
按store职责在store中处置惩罚：store状况变得不稳固，dispatcher的waitFor失效
4. 至今还没有官方完成
写在末了
前端摩尔定律：前端每18个月难度增加一倍
没有银弹
