摘要：的關鍵構成梳理了一下，需要配合的庫去使用，是因為要解決通信問題。還有各個事件之間，有可能存在依賴關系，事件后，也觸發。相比于傳統的事件系統，融入了不少的思想。中，將會是最大的門檻之一。

我覺得應該有不少同學和我一樣，上來學React,覺得甚是驚艷，看著看著，發現facebook 安利了一個flux，圖畫的巨復雜,然后各種例子都有用這個東西，沒辦法，硬著頭皮看。看得似懂非懂，然后突然大家又都推薦Redux,號稱最簡單的flux-like的實現，結果實現的源碼是很簡單，但是文檔是源碼的幾十倍，概念甩一臉，寫個簡單東西，要建十幾個文件，寫得云里霧里。

有沒有想到，為什么要用Flux這類東西？本篇的定位是讓大家知道有個脈絡,所以不會太注意措辭的準確性.

React只是一個view層的解決方案，光有界面沒用，還得加上數據才行。React通過props和state去渲染界面，所以有個很形象的描述UI = f(props,state).

有數據，就有數據通信的問題。react是單向數據流，父組件通過props把數據傳遞給子組件。但是數據的流向不可能只有這一種。

祖父組件到孫子組件。
這個看上去只是父到子的衍生,但是祖祖祖父到孫子組件呢。這個react在（好像是）0.13時通過context基本解決了，關于context，之前沒接觸的同學，可以看文檔

子到父。下面是一種方案：父給子傳遞一個函數，子在只要調用這個函數，父就能得到相關的數據。但是孫子到祖祖祖父呢。。

非父子關系：基本可以叫做是兄弟關系，以網頁為例，總歸有一個共同的祖先，但是有可能是非常非常遠的兄弟。這個怎么處理。

組件的一些關系和相應的通信方式，官方有簡單的說明，見文檔

對于上面的2，3兩點,用react本事的機制，寫出來都很別扭，特別是第3點。兩個不相關的地方，要數據通信，最簡單就是一個全局變量嗎。當然光有全局變量還不行，你改了全局變量，其他所有對這個變量感興趣React組件的都要被通知到,這樣才能相應改變界面。你如果接觸到設計模式，應該能想到觀察者模式(中介者模式也可以,實際上flux更像中介者中,不過觀察者應該接受度更高點,而且這里不影響理解)。

其實官方文檔中，也有些小線索。

For communication between two components that don"t have a parent-child relationship, you can set up your own global event system. Subscribe to events in componentDidMount(), unsubscribe in componentWillUnmount(), and call setState() when you receive an event. Flux pattern is one of the possible ways to arrange this.

這段的關鍵是you can set up your own global event system。所以你只要去研究以前各種事件系統是怎么設計，就可以自己擼一套 **ux了。

梳理了一下，React需要配合Flux-Like的庫去使用，是因為要解決通信問題。通信的關鍵有一下幾點：

數據，這個不用說的吧。因為react中，通過setState去觸發改變界面，命名成state

各種事件，叫event可能更直觀，但是大家都叫它action,一個意思，發生了一個動作。這個動作有一下幾個關鍵屬性：什么動作，誰發出的（這個我看各個類flux庫中，好像都沒處理），有沒有額外信息嗎。

事件發生，要分發出去，包括改變數據，然后通知給所有監聽數據變化的Listeners

注冊監聽者。

這些都是大家能想象到。好了，根據這幾點，一個簡單的Myux就可以寫了

class Myux{
    state:{},
    actionTypes:{},
    dispatch(){},
    subscribe(){}
    listeners:[]
}

與上面四個組成部分項對應。來個例子吧，以計數器為例吧。

class CountStore{
    static actionTypes:{
        UP:"UP", //你英語好，你用increase
        DOWN:"DOWN"
    }
    
    state:0 //數據，計數開始是零
    listeners:[]
    
    dispatch(actionType){
        if(actionType === CountStore.actionTypes.UP){
            this.state++;
        }
        if(actionType === CountStore.actionTypes.DOWN){
            this.state--;
        }
        this.listeners.forEach((ln)=>{
            ln(actionType,this,undefined)//對應什么動作，誰發出的，額外信息。
        })
    }
    
    subscribe(ln){
        this.listeners.push(ln)
        //返回一個函數，調用，就取消注冊
        return ()=>{
            const index = this.listeners.indexOf(ln);
            if(index !== -1){
                this.listeners.splice(index,1)
            }
        }
    }
}

react的組件里，只要注冊成listener，然后state發生變化，被通知到，調用setState進行視圖更新就好。

class CountComponent extends React.Component{
    constructor(props,context){
        super(props,context)
        const store = this.props.store;
        this.state = store.getState();
        
    }
    
    componentDidMount(){
        this.unsubscribe = store.subscribe((actionType,store)=>{
            if(this.state !== store.getState()){
                this.setState(store.getState());
            }
        })
    }
    
    componentWillUnmount(){
        if(typeof this.unsubscribe === "function"){
            this.unsubscribe();
        }
    }
    
    
    render(){
        const state = this.state
        return 
{state}
    }
}

使用嗎，直接mount到body上，會報warning，忽略...

const countStore = new CountStore()
ReactDOM.render(
    ,
    document.body
)

這樣，只要在任何地方，countStore.dispatch(upOrDown),CountComponent里的數字就會加加減減。
可以想想一下，如果頁面有2，3個組件要根據計數器的數值，做界面的相應變化，都是可以輕松滿足的。

當然，如果只有一個組件用需要這個store，那么單純代碼上，這樣寫，要多寫很多東西。但是誰知道以后頁面不會加一個要共用這個store的組件,這時候這個store就是組件間通信的法寶了。

上面只有一個store，這是store還只有一個state,這個太簡單了。實際，你的應用可能要維護多個狀態。怎么辦

一個store里一個state，然后多個store

    ListStore => ListState
    DetailStore => DetailState

全局就一個store，state是一個狀態樹，整個應用需要的state，都在這個樹里。

    GlobalStore => state:{list:[],detail:{}} //...
    

還有一個問題dispatch,是全局一個dispatch,還是每個store一個dispatch。

這些分歧，加上函數式等，就導致了有flux,reflux,redux。。

還有各個事件之間，有可能存在依賴關系，A事件后，B也觸發。又要加waitFor和中間件等概念。不過整體來說，就這些東西。

redux的文檔里，有三大原則，有了上面的概念，我們來對照看一下

Single source of truth：就是更改應用一個state tree，儲存在一個store里，這種情況，也只能有一個dispatch

State is read-only：state是全局的，如果不是只讀的，很難維護。這個上面沒有體現，但是也是很自然的想法。

Mutations are written as pure functions：這個算redux最大的特點，引入了reducers的概念，和第二點有相輔相成的感覺。

另外還有中間件系統。2、3兩點，其實是函數式編程的基本概念，不變量和pure function。相比于傳統的事件系統，Redux融入了不少functional reactive programming（FRP)的思想。

單dispatch，多store多state，用waitFor處理store的依賴。

多dispatch，多store多state。這個并沒實際用過，看文檔，應該是這樣的。有問題，請提出。

現在有種趨勢，傳統的事件系統逐漸讓大家覺得low b，functional reactive programming（FRP）高大上。
Redux有一些FRP的思想，被大家覺得比Flux高大上，但是不是很復雜的項目，應該會有：臥槽，那么簡單的東西，為毛有那么多文件，寫得那么繞的感覺。

angular2中，RxJS將會是最大的門檻之一。

我覺得把，從能解決問題的復雜度上，FRP的確比傳統的事件系統高級，但是概念也更多，不是特復雜的程序，這些概念只會增加你的開發難度，并且對后面維護的人要求更高。

Java那么多年，沒RxJava，服務器端，android端，那么多年也挺過來了，雖然先進，不一定合適。我們現在自己的項目，使用的就是自己擼的一個小東西。對我們現在的規模，開發和維護都挺好的。