摘要：當(dāng)響應(yīng)時(shí)，通過(guò)已注冊(cè)的回調(diào)函數(shù)，將提供的數(shù)據(jù)負(fù)載發(fā)送給應(yīng)用中的所有。對(duì)外只暴露，不允許提供禁止在任何地方直接操作。是單例作為中的事件分發(fā)中心，同時(shí)還要管理所有中的事件。

個(gè)人現(xiàn)階段對(duì)Flux架構(gòu)的理解，求拍磚求star!
原文鏈接：https://github.com/kuitos/kuitos.github.io/issues/27

React 簡(jiǎn)介請(qǐng)戳 這里

Flux是Facebook用來(lái)構(gòu)建客戶端web應(yīng)用的應(yīng)用架構(gòu)。它利用單向數(shù)據(jù)流的方式來(lái)組合react中的視圖組件。它更像一個(gè)模式而不是一個(gè)正式的框架，開(kāi)發(fā)者不需要太多的新代碼就可以快速的上手Flux。

事件調(diào)度中心，flux模型的中心樞紐，管理著Flux應(yīng)用中的所有數(shù)據(jù)流。它本質(zhì)上是Store的回調(diào)注冊(cè)。每個(gè)Store注冊(cè)它自己并提供一個(gè)回調(diào)函數(shù)。當(dāng)Dispatcher響應(yīng)Action時(shí)，通過(guò)已注冊(cè)的回調(diào)函數(shù)，將Action提供的數(shù)據(jù)負(fù)載發(fā)送給應(yīng)用中的所有Store。應(yīng)用層級(jí)單例?。?/p> 2. store

負(fù)責(zé)封裝應(yīng)用的業(yè)務(wù)邏輯跟數(shù)據(jù)的交互。

Store中包含應(yīng)用所有的數(shù)據(jù)

Store是應(yīng)用中唯一的數(shù)據(jù)發(fā)生變更的地方

Store中沒(méi)有賦值接口---所有數(shù)據(jù)變更都是由dispatcher發(fā)送到store，新的數(shù)據(jù)隨著Store觸發(fā)的change事件傳回view。Store對(duì)外只暴露getter，不允許提供setter?。〗乖谌魏蔚胤街苯硬僮鱏tore。

controller-view 可以理解成MVC模型中的controller，它一般由應(yīng)用的頂層容器充當(dāng)，負(fù)責(zé)從store中獲取數(shù)據(jù)并將數(shù)據(jù)傳遞到子組件中。簡(jiǎn)單的應(yīng)用一般只有一個(gè)controller-view，復(fù)雜應(yīng)用中也可以有多個(gè)。controller-view是應(yīng)用中唯一可以操作state的地方(setState())

view(UI組件) ui-component 職責(zé)單一只允許調(diào)用action觸發(fā)事件，數(shù)據(jù)從由上層容器通過(guò)屬性傳遞過(guò)來(lái)。

action creators 作為dispatcher的輔助函數(shù)，通常可以認(rèn)為是Flux中的第四部分。ActionCreators是相對(duì)獨(dú)立的，它作為語(yǔ)法上的輔助函數(shù)以action的形式使得dispatcher傳遞數(shù)據(jù)更為便利。

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 (
        

          {nav.text}
        
      );
    });

    return (
      
    );
  }
}

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點(diǎn)擊
    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 (
      

        ...
        
    );
  }

}

MVVM

因?yàn)閍ngular雙向綁定的原因，我們永遠(yuǎn)無(wú)法知道數(shù)據(jù)在哪一刻處于穩(wěn)定狀態(tài)，所以我們經(jīng)常會(huì)在angular中看到通過(guò)setTimeout的方式處理一些問(wèn)題(其實(shí)有更優(yōu)雅的解決方案，不在本次討論之內(nèi))。同時(shí)由于雙向綁定的原因，行為的流向我們也很難預(yù)測(cè)，當(dāng)視圖的model變多的時(shí)候，如果再加上一堆子視圖依賴這些model，問(wèn)題發(fā)生時(shí)定位簡(jiǎn)直是噩夢(mèng)啊(這也是angular的錯(cuò)誤信息那么不友好的原因，因?yàn)榭蚣荛_(kāi)發(fā)者也無(wú)法確定當(dāng)前行為是誰(shuí)觸發(fā)的啊，綁定的人太多了...)。但是這里還是要強(qiáng)調(diào)一點(diǎn)就是，并不是說(shuō)雙向綁定就一定會(huì)導(dǎo)致不穩(wěn)定的數(shù)據(jù)狀態(tài)，在angular中我們通過(guò)一些手段依然可以使得數(shù)據(jù)變得穩(wěn)定，只是雙向綁定(mvvm)相對(duì)于flux更容易引發(fā)數(shù)據(jù)不穩(wěn)定的問(wèn)題。

flux里view是不允許直接修改store的，view能做的只是觸發(fā)action，然后action通過(guò)dispatcher調(diào)度最后才會(huì)流到store。所有數(shù)據(jù)的更改都發(fā)生在store組件內(nèi)部，store對(duì)外只提供get接口，set行為都發(fā)生在內(nèi)部。store里包含所有相關(guān)的數(shù)據(jù)及業(yè)務(wù)邏輯。所有store相關(guān)數(shù)據(jù)處理邏輯都集中在一起，避免業(yè)務(wù)邏輯分散降低維護(hù)成本。

view所有的數(shù)據(jù)來(lái)源只應(yīng)該是從屬性中傳遞過(guò)來(lái)的，view的所有表現(xiàn)由上層控制視圖(controller-view)的狀態(tài)決定。我們可以把controller-view理解為容器組件，這個(gè)容器組件中包含若干細(xì)小的子組件，容器組件不同的狀態(tài)對(duì)應(yīng)不同的數(shù)據(jù)，子組件不能有自己的狀態(tài)。也就是，數(shù)據(jù)由store傳遞到controller-view中之后，controller-view通過(guò)setState將數(shù)據(jù)通過(guò)屬性的方式自上而下傳遞給各個(gè)子view。

由于2、3兩條原因，view自身需要做的事情就變得很少了。業(yè)務(wù)邏輯被store做了，狀態(tài)變更被controller-view做了，view自己需要做的只是根據(jù)交互觸發(fā)不同的action，僅此而已。這樣帶來(lái)的好處就是，整個(gè)view層變得很薄很純粹，完全的只關(guān)注ui層的交互，各個(gè)view組件之前完全是松耦合的，大大提高了view組件的復(fù)用性。

對(duì)單個(gè)應(yīng)用而言dispatcher是單例的，最主要的是dispatcher是數(shù)據(jù)的分發(fā)中心，所有的數(shù)據(jù)都需要流經(jīng)dispatcher，dispatcher管理不同action于store之間的關(guān)系。因?yàn)樗袛?shù)據(jù)都必須在dispatcher這里留下一筆，基于此我們可以做很多有趣的事情，各種debug工具、動(dòng)作回滾、日志記錄甚至權(quán)限攔截之類(lèi)的都是可以的。

flux只是一個(gè)架構(gòu)模式，并不是一個(gè)已實(shí)現(xiàn)好的框架，所以基于這個(gè)模式我們需要寫(xiě)很多樣板代碼，代碼量duang的一下子上來(lái)了。。不過(guò)好在目前已經(jīng)有很多好用的基于flux的第三方實(shí)現(xiàn)，目前最火的屬redux。

dispatcher作為flux中的事件分發(fā)中心，同時(shí)還要管理所有store中的事件。當(dāng)應(yīng)用中事件一多起來(lái)事件時(shí)序的管理變得復(fù)雜難以維護(hù)，沒(méi)有一個(gè)統(tǒng)一的地方能清晰的表達(dá)出dispatcher管理了哪些store。

按flux流程，action中處理：依賴該action的組件被迫耦合進(jìn)業(yè)務(wù)邏輯

按store職責(zé)在store中處理：store狀態(tài)變得不穩(wěn)定，dispatcher的waitFor失效

前端摩爾定律：前端每18個(gè)月難度增加一倍

沒(méi)有銀彈