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

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

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

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

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

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

子到父。下面是一種方案：父給子傳遞一個函數(shù)，子在只要調(diào)用這個函數(shù)，父就能得到相關(guān)的數(shù)據(jù)。但是孫子到祖祖祖父呢。。

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

組件的一些關(guān)系和相應(yīng)的通信方式，官方有簡單的說明，見文檔

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

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

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.

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

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

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

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

事件發(fā)生，要分發(fā)出去，包括改變數(shù)據(jù)，然后通知給所有監(jiān)聽數(shù)據(jù)變化的Listeners

注冊監(jiān)聽者。

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

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

與上面四個組成部分項對應(yīng)。來個例子吧，以計數(shù)器為例吧。

class CountStore{
    static actionTypes:{
        UP:"UP", //你英語好，你用increase
        DOWN:"DOWN"
    }
    
    state:0 //數(shù)據(jù)，計數(shù)開始是零
    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)//對應(yīng)什么動作，誰發(fā)出的，額外信息。
        })
    }
    
    subscribe(ln){
        this.listeners.push(ln)
        //返回一個函數(shù)，調(diào)用，就取消注冊
        return ()=>{
            const index = this.listeners.indexOf(ln);
            if(index !== -1){
                this.listeners.splice(index,1)
            }
        }
    }
}

react的組件里，只要注冊成listener，然后state發(fā)生變化，被通知到，調(diào)用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里的數(shù)字就會加加減減。
可以想想一下，如果頁面有2，3個組件要根據(jù)計數(shù)器的數(shù)值，做界面的相應(yīng)變化，都是可以輕松滿足的。

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

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

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

    ListStore => ListState
    DetailStore => DetailState

全局就一個store，state是一個狀態(tài)樹，整個應(yīng)用需要的state，都在這個樹里。

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

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

這些分歧，加上函數(shù)式等，就導(dǎo)致了有flux,reflux,redux。。

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

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

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

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

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

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

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

多dispatch，多store多state。這個并沒實際用過，看文檔，應(yīng)該是這樣的。有問題，請?zhí)岢觥?/p> 后記

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

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

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

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