Redux，基礎

在學習了React以後， 緊跟着而來的就是Redux了~

 

在系統性的學習一個東西的時候， 瞭解其背景、設計以及解決了什麼問題都是很是必要的。

接下來記錄的是， 我我的在學習Redux時的一些雜七雜八~

 

Redux是什麼？

通俗理解

https://www.zhihu.com/question/41312576/answer/340471373

 

介紹

先從官方的一句介紹看起：

Redux is a predictable state container for JavaScript apps. （Redux是Javascript應用程序的可預測狀態容器。）

固然，假如你在這以前並無接觸過相關的狀態管理庫或者框架， 看到這句話時是很是的懵逼的， 不過能夠帶着這句話來一步步探索~

 

背景

隨着Javascript單頁面應用開發日趨複雜，JavaScript 須要管理比任什麼時候候都要多的 state （狀態）。 這些 state 可能包括服務器響應、緩存數據、本地生成還沒有持久化到服務器的數據，也包括 UI 狀態，如激活的路由，被選中的標籤，是否顯示加載動效或者分頁器等等。管理不斷變化的 state 很是困難。若是一個 model 的變化會引發另外一個 model 變化，那麼當 view 變化時，就可能引發對應 model 以及另外一個 model 的變化，依次地，可能會引發另外一個 view 的變化。直至你搞不清楚到底發生了什麼。 -- Redux文檔

上面這一大段引用概況起來就是一句話， state（狀態）在何時什麼地方，由於什麼而變化成了一個不受控制的過程。（這不能忍，狀態若是沒法預測以及控制）

那麼Redux就是試圖讓 state 的變化變得可預測。這些限制條件反映在 Redux 的三大原則中。

 

核心概念

　　1.Redux使用普通的對象來描述state，這個對象就是Modal。

　　

　　2.要想更新 state 中的數據，你須要發起一個 action。Action 就是一個普通 JavaScript 對象用來描述發生了什麼。

　　

　　3.爲了把 action 和 state 串起來，開發一些函數，這就是 reducer。reducer 只是一個接收 state 和 action，並返回新的 state 的函數。

　　

 

 

三大準則

• 只有一個state樹。

• state是隻讀的，只能經過action改變。

• reducer是純函數，沒有反作用。

   瞭解到這些後，其實已經多少能明白Redux is a predictable state container for JavaScript apps. （Redux是Javascript應用程序的可預測狀態容器。）這句話，爲何是可預測的？ 由於只有一個state樹，而且它是隻讀的，並且只能經過action來改變（改變的過程變得清晰可追蹤），而且獲取state（狀態）只能經過reducer，而reducer是一個純函數（此處瞭解state是重點），沒有反作用，也就意味着咱們能知道咱們最終獲得的state是什麼樣的。

 

api簡介

• createStore(reducer, [preloadedState], [enhancer]) 
  　　----建立store的函數，返回一個對象， 包含getState\dispatch\subscribe\getReducer\replaceReducer等方法
• combineReducers(reducers) 
  　　----合併多個reducer
• applyMiddleware(...middlewares) 
  　　----中間件處理，在 實際的dispatch前調用一系列中間件， 相似於koa
• bindActionCreators(actionCreators, dispatch) 
  　　----綁定action和dispatch
• compose(...functions) 
  　　----函數式編程中常見的方法， compose(funcA, funcB, funcC) => compose(funcA(funcB(funcC())))
  

 

React-redux

介紹

Redux官方提供的 React 綁定庫。 具備高效且靈活的特性。

 

動機

React是以組件化的形式開發。爲了組件的複用以及代碼的清晰，一般咱們將組件分爲容器組件以及UI組件。

關於容器組件和UI組件，推薦閱讀該文章 https://github.com/Hancoson/blog/issues/16，而引入了React-redux能夠很好的幫助咱們分離容器組件和UI組件。

 

爲何選擇react-redux

• react-redux是官方提供的綁定庫，由redux開發者維護，能夠很好的與redux保持同步。
• 它鼓勵組件分離。react-redux協助咱們分離容器組件和UI組件，經過提供API鏈接store（提供數據）和UI組件，而且使得UI組件不須要知道存在Redux（複用）。
• 性能優化。雖然React速度很快，可是re-redering是很是消耗性能的，而react-redux的內部作了許多性能優化。
• 社區支持，由於是官方指定的綁定庫，因此擁有大量的使用者，社區活躍度高，問題也容易解決。

 

api簡介

<Provider  store> 
　　----使組件層級中的 connect() 方法都可以得到 Redux store。
　　----store:  應用程序中惟一的 Redux store 對象

connect(mapStateToProps, mapDispatchToProps, mergeProps, options)

　　　 mapStateToProps(state, [ownProps]): stateProps: 

　　　　　　----映射state做爲UI組件的props

mapDispatchToProps(dispatch, [ownProps]): dispatchProps：

 　　----映射dispatch做爲UI組件的props

mergeProps(stateProps, dispatchProps, ownProps): props: 

 　　----若是指定這個函數， 即合併mapStateToProps\mapDIspatchToProps\oweProps做爲UI組件的props

options: 

　　　----定製 connector 的行爲

 

Redux存在的問題（解決的方案）？

與其說缺點，不如說是Redux的優點而形成的不可避免的劣勢，問題應該辯證地看~

• 純淨。Redux只支持同步，讓狀態可預測，方便測試。 但不處理異步、反作用的狀況，而把這個丟給了其餘中間件，諸如redux-thunk\redux-promise\redux-saga等等，選擇多也容易形成混亂~

• 囉嗦。那麼寫過Redux的人，都知道action\reducer\以及你的業務代碼很是囉嗦，模板代碼很是多。可是~，這也是爲了讓數據的流動清晰明瞭。

• 性能。粗暴地、級聯式刷新視圖（使用react-redux優化)。

• 分型。原生 Redux-react 沒有分形結構，中心化 store；

 

Redux的最佳實踐？

vuex（dva）

事實上，若是用過vuex或者dva的話， 我的以爲仍是會比較偏向於這種用法。比起Redux的囉嗦，dva幫忙簡化了不少步驟。具體的實現後續補充~

這裏先補充一點，vuex不是immutable，因此對於時間旅行這種業務不太友好。

 

Redux的實現淺析？

前言

Redux的代碼相對比較簡單，容易理解， 源碼的解讀推薦看這篇文章， 本段主要是對代碼裏一些我的以爲比較有意思的點進行分析~

 

createStore

在這裏看出，redux即便是在內部，也是函數式編程~

當咱們傳入了一個enhancer函數（即中間件），會把createStore自己當成參數傳給enhancer而後返回一個新的函數來調用 即 fn => fn

 

　　暴露出的subscribe函數也是挺有意思的， 首先是isSubscribed這個變量， 其實就是一種很是基礎的閉包使用，

　　而後是每次訂閱或者取消訂閱的時候，都會在dispatch以前保存一次快照， 而後當前的dispatch用的是上一份快照，而下一個dispatch則是使用當前這一份的快照

 

compose

很是簡潔的寫出了函數式編程的一個經常使用函數(...args) => f(g(h(...args))).

 

combineReducer

　　能夠看出，每一次action都會從新計算全部的reducer~ 但若是不是很是巨大的state樹，而且拆分了不少模塊，我的認爲其實影響不大

 

bindActionCreator和applyMiddleware相對容易理解， 這裏就不贅述啦

 

完......