一直都說 redux 是 inspired by flux, 也就是說基本上這兩個是差不多的. redux 是遵循 flux 思想開發的一個
react 的狀態管理庫.

那麼我們或者說大家都還是有很多說這兩個地方到底有什麼不同的地方. 對此我也有自己的一個理解, 理解成了自己的東西才真正是自己的東西

1. flux 基本構成的幾大塊 store dispatch action vm(view)
   說 dispatch 是運轉的核心, 其實就是通過 dispatch 去驅動整個的資料流轉.
   說觸發關係之前, 有幾個監聽需要註明

   (1) 首先 store 註冊(其實就是監聽的意思) 了 dispatch 上的事件變化,
   view 中監聽了 store 的變化.
   (2) 然後 dispatch 變化後, store 進行相應, 然後 trigger(emit, 丟擲事件) 變化以供 view 變化
   view 中有監聽了 store 的變化, 然後 view 中觸發具體的 render 方法(react , vue 中等等 )

   核心思想:
   更改 store 中的資料一定是通過 dispatch 傳送一個 action 來進行實現, 複雜(或者說規則明確)了, 卻能帶來長久的規定與後續的清晰
   這樣也能說明是資料的單項流動.

   這其中並沒有規定只有一個 store, 這個 store 也只是 data, 並不是狀態, 具體的 state(狀態) 與 store 的繫結在 view 這一層.
   view 中有具體的響應, store 這裡只是把變更傳送了出去.
   action 在這裡可以理解為事件處理, 通過 action 提供介面供 view 層去呼叫, action 中呼叫 dispatch去觸發具體的事件
   或者把 action 整理理解為一個 事件的派發

   , 最終是要改變 store

   或者可以說 flux 只是一個指導思想. 規定資料的單項流動, 更改資料必須走統一的規則 (dispatch)

2. redux 基本構成 store dispatch reducer
   redux 在 flux 的思想上, 又進一步的約束.

   1. 只有一個 store
   2. 函數語言程式設計(reducer), 可以對結果進行預測, redux 的 r 就是 reducer
   3. 改變 store 方式唯一(即只有 store 中的 reducer 能夠進行更改)

   其實 redux 對 flux 的限制只是限制了 只有一個 store, 並且嚴格約束函數語言程式設計正規化.

   其中的 store 就是根據 reducer 進行生成的, 並且 dispatch 方法也是 從 store 中返回

   一切都圍繞著這一個 store.

   資料流程: store 中 dispatch action 後, 派發到對應的 reducer 處理, 然後返回對應的 新狀態.

擴充套件: 圍繞此基礎上又提供了一些功能加強
1. 比如 middware 加強了 dispatch 方法, 預設 dispatch 是隻能接受一個 action 物件
2. replaceReducer, combineReducer 可以認為是對 reducer 的加強
3. immutable 等不可變, 是提高效能, 也算是對 store 的資料加強

3. redux-react, 與 react 的結合屬於單獨的一部分, 只簡單說一下
   原理: 使用 connect 和 provider, 通過 react 中提供的 context 實現了 state 與 store 的連線.

總結:
目前專案中主要使用 mobx 在做狀態管理, 上邊只是按照自己的理解進行了梳理. redux 在大型專案中的確非常有用,
清晰的資料處理, 對於多人協作是非常有好處的. mobx 快速, 卻也讓我們 不明事理, 但是人家的初衷就是讓你 不用明事理...