說一說 Flux的小白知識

MV*

說Flux以前，先說說熟知的MV*模式。 MV*通常指MVC/MVVM.
MVC如咱們熟知：

• M = Model，負責數據的保存，檢驗，獲取等。
• V = View，數據的展現，DOM元素。
• C = Controller，與傳統的controller定義不一樣，前端中的controller的定義比較模糊。但通常做爲Model和View之間的協調。

而MVVM，就是在MVC的基礎上，用VM(ViewModel)替代Controller。
也就是數據綁定，界面與VM的數據狀態能夠相互影響。

說到這裏，其實不難想象，數據能夠多方影響，來源不明且多樣。混亂的數據流向致使項目後期，開發維護的難度加大。Model的構建數量過多，會影響View的構建結構與渲染優化。

Flux

Flux 的命名來自於拉丁語Flow。是一套基於dispatcher的前端應用架構模式。
\>核心思想是數據和邏輯永遠單向流動。
對比MV* 結構，Flux模式有着數據來源單一，數據變更可溯源的優勢。讓邏輯架構更加謹慎清晰。

這裏和React組件間的單向流動不一樣。React的單向數據流動是通常指基於Props的組件間通訊設計。而Flux的單向數據流，則是基於整個架構上的。

1. Dispatcher

一個全局惟一的數據流處理中心。有3個主要API：

• dispatch(object payload) : void

用於分發action。執行已註冊的監聽。

* **register(function callback) : string**
註冊監聽用於響應dispatch。 返回一個token可供waitFor()使用。
* **waitFor(array ids) : void**
當在回調中遇到waitFor()時，該回調暫停執行。在waitFor()完成執行並回調以後，再繼續執行原始回調。此方法能夠用於等待並執行其餘store操做。

*action是一個對象類型，在FSA規範中對其字段進行了列舉：type，error，payload，meta。其中type（或者name）爲必須，是store根據action修改數據的依據。
在Facebook的Flux實例源碼中，在Dispatcher類裏定義了一個\_callbacks數組，保存了在register方法中註冊的監聽器。並在dispatch方法中遍歷執行，且把action做爲參數傳入監聽函數。

2. Store

通常有如下幾個功能：

• 保存狀態數據(state)。
• 暴露一個Getter用於獲取狀態
• 定義修改數據的邏輯。
• 調用Dispatcher.register方法將本身註冊爲一個監聽器。
• 定義一個更新監聽方法

當調用dispatch分發action，store在register方法中註冊的監聽就會被調用，同時獲得傳入action。
store將根據action攜帶的type判斷是否響應操做。如響應，調用內部的數據修改邏輯。並在執行完畢後觸發更新事件。

3. Controller-View/View

Controller-View通常做爲最頂層的View，負責Store和View之間的數據傳遞。

• **進行store與View的綁定，定義數據更新及傳遞方式。**這裏說的View通常是React，固然也能夠是其餘框架。
• **監聽Store發出的更新事件。**當Store更新後，Controller-View會從新獲取store中的數據，並觸發界面重繪。

class CounterContainer extends Component {
static getStores() {
return [CounterStore];
}

static calculateState(prevState) {
return {
counter: CounterStore.getState(),
};
}

render() {
return ;

}
}

const container = Container.create(CounterContainer);
上面是Flux官方文檔中將一個React Class建立爲Controller-View的簡單調用實例。class向外暴露getStores、calculateState兩個方法：

• getStores用於綁定Class關聯的Store。
• calculateState用於獲取Store中的數據轉化爲自身的State，並做爲props傳給子組件。

Container.create方法中，會獲取綁定的Store中dispatchToken，而後根據dispatchToken利用waitFor方法等待Store完成數據更新邏輯，而後執行更新回調。
當Store觸發更新後，Container會調用setState方法更新State，同時觸發畫面渲染更新。
固然關聯store、更新回調等能夠有多種實現方法，以上只是其中一種思路。

View就是界面表現了，View能夠經過props得到Container傳入的數據。
若是View須要修改數據，必須使用dispatcher分發action的方式進行修改。
這也是單向數據流的重要特徵，view不能直接修改數據。

提及Flux，不少第一句就是單向數據流。但其實數據中心化控制，也是特色之一。全部的更改，必須經過action發出，dispatcher分配。store中心化控制了數據，令數據管理和問題追查變得清晰容易。action的管理，令架構不用關心辨別數據更新的觸發方式，全部觸發方式都抽象成了action。Flux架構並不是React獨有，也能做爲其餘組件框架的狀態管理方案。前面說到Flux對於MV*架構的優勢，固然Flux自己也有的坑。雖而後面提出的Redux，則對Flux中state與更新邏輯沒有分離抽象，沒有對URL路由進行管理等問題進行改進。但Flux只是一種設計約定，各人對其都有本身的觀點和想法。與其餘架構相比其實沒有絕對的優點劣勢，只是提供解決方案的一種。