Redux、Flux、Vuex

前言

這篇文章不會用具體的代碼去闡述redux、flux或者vuex，由於我以爲它們所帶來的更是一種編程思想。

前端進化和框架演變

在好久之前，前端沒有MVVM的概念，MVVM是對MVC細化的說法（我的以爲二者區別不大），MVC的模式一直在後臺使用，效果和優勢都很明顯。

後來前端工程師仿照MVC模式開發了不少框架出來：backbonejs、angularjs、emberjs、knockoutjs等等。

再後來nodejs的崛起，出現了reactjs、vuejs、avalonjs,都是主打組件化，讓數據來驅動視圖，再配合像grunt和webpack前端工具更是讓前端步入新的時代。

其實這裏我想吐槽一下，前端從之前把注意力集中在佈局和樣式，轉變成把精力投入到學習這些思想、工具、框架中，我作爲一個前端工程師在這種過渡中以爲是一種力不從心（可能年齡大了，es6普及後不知道還要了解多少新東西），雖然是一個把注意力從視圖轉到數據上的轉變，但這過程其實要付出的挺多。

好，廢話到此爲止。

Redux 思想

Redux讓你以一種新的方式思考開發應用個，這個方式是：狀態從一個初始狀態開始，被一系列動做序列改變，這種新方式是通往復雜Web應用的捷徑。

這麼一說，不少人一頭霧水，啥意思？下面來個簡單代碼

var store = {
  state: {
    message: 'Hello!'
  },
  actionA: function () {
    this.state.message = 'action A triggered'
  },
  actionB: function () {
    this.state.message = 'action B triggered'
  }
}
//若是你想改變message的值，你能夠調用actionA或者actionA去實現。

上面這段代碼能夠說就是Redux思想最簡單的體現。

Flux

Flux是Facebook用戶創建客戶端Web應用的前端架構， 它經過利用一個單向的數據流補充了React的組合視圖組件，這更是一種模式而非正式框架，你可以無需許多新代碼狀況下當即開始使用Flux

Flux應用有三個主要部分：Dispatcher調度 、存儲Store和視圖View(React 組件)，這些不該該和MVC:Model-View-Controll(模型-視圖-控制器)混淆，控制器在Flux應用中是存在的，可是他們是controller-view(控制器-視圖)，視圖一般在一個結構頂部，而這種結構是用來從存儲stroe得到數據，而後將數據傳遞到本身的子結構們，此外，Action建立者-Dispatcher的幫助類的方法 -用於支持一個語義API，這個API是描述應用程序中全部變化的可能，一般可將它們當作是Flux更新循環的第四部分。

Flux是以單向數據流方式支持MVC，當一個用戶和React視圖交互時，視圖會將這個動做傳播到一箇中央Dispatcher，一直到各類存儲，在那裏保存着應用的數據和業務邏輯，這個使用React的聲明式風格的過程是很是棒的，可以容許存儲發送更新信息，而無需指定在狀態之間如何切換視圖。(傳統方式更新狀態後，會推出一個新的視圖頁面。)

Flux最初是用於正確導出數據，好比若是咱們要顯示一系列消息的未讀數字，而另一個視圖顯示的是全部消息，其中未讀的消息會高亮顯示。這種狀況使用MVC很難處理，將一個消息變爲已讀狀態須要更新消息模型，而後再須要更新未讀的計數模型(將未讀模型數字減1，由於剛發生一個已讀改變)，這種依賴和級聯更新常常發生在大型MVC應用，致使一個混亂的數據流編織和不可預知的結果。

控制器被存儲反轉控制：存儲接受更新，適當地調節這些更新，而不是一致地依賴外部更新其數據，存儲以外根本不知道它是如何管理領域數據的，這有助於實現一種清晰的分離關注。存儲並無直接的相似setAsRead()之類的方法，而是隻有一個單一方式獲取數據到其自成一體的世界中，這個方式就是回調，註冊在dispatcher中的callback。

結構和數據流

一個單向數據流是Flux模式的核心，上面示圖應該是Flux程序員心中主要的模型圖。dispatcher 存儲和視圖是有着不一樣輸入輸出的獨立節點，Action動做是一個簡單對象，只是包含新的數據和一個標識符類型的屬性。

視圖也許引發新的動做Action，這個動做做爲用戶交互的響應將在整個系統傳播：

全部經過dispatcher的數據流將做爲一個集中式Hub，動做Action在一個action creator方法中被提供給dispatcher，這個動做一般來自於視圖中用戶的交互，dispatcher而後調用存儲已經註冊其中的回調函數，分發Action動做到全部的存儲，在它們註冊的回調函數中，存儲會響應每一個和它保存的狀態有關的每一個動做Action，存儲而後發射一個 change改變的事件去提醒controller-view（控制器-視圖），更新到剛剛改變的新數據。controller-view監聽這些事件，而後在一個事件處理器中從存儲中獲取數據，controller-view調用它們本身的"setState()"方法，這會觸發視圖的從新渲染，包括DOM組件樹中全部更新

經過應用的數據流是一個方向，沒有兩邊綁定(two-way bingding：Angular.js有此方式)，應用狀態在存儲中維護，容許應用不一樣部分保持解耦，在存儲之間發生依賴的地方，它們可以保持嚴格的層次關係（設計原則：儘可能鬆耦合，沒法迴避的就變成樹形層次結構），同步管理由dispatcher負責。

分享

說了那麼多，重點仍是上面兩張圖，知道了這個流程，就掌握了它的大概思想，若是你仍是不懂，這裏分享我的認爲比較好的文章：

• 怎樣理順react，flux，redux這些概念的關係，開發中有必要使用它們嗎?

• Redux 介紹

• 關於Vuex的幾個疑問

• vuex介紹

• [譯] Flux 入門