在學習了React以後, 緊跟着而來的就是Redux了~html
在系統性的學習一個東西的時候, 瞭解其背景、設計以及解決了什麼問題都是很是必要的。 接下來記錄的是, 我我的在學習Redux時的一些雜七雜八~vue
www.zhihu.com/question/41…react
先從官方的一句介紹看起:git
Redux is a predictable state container for JavaScript apps. (Redux是Javascript應用程序的可預測狀態容器。)github
固然,假如你在這以前並無接觸過相關的狀態管理庫或者框架, 看到這句話時是很是的懵逼的, 不過能夠帶着這句話來一步步探索~vuex
隨着Javascript單頁面應用開發日趨複雜,JavaScript 須要管理比任什麼時候候都要多的 state (狀態)。 這些 state 可能包括服務器響應、緩存數據、本地生成還沒有持久化到服務器的數據,也包括 UI 狀態,如激活的路由,被選中的標籤,是否顯示加載動效或者分頁器等等。管理不斷變化的 state 很是困難。若是一個 model 的變化會引發另外一個 model 變化,那麼當 view 變化時,就可能引發對應 model 以及另外一個 model 的變化,依次地,可能會引發另外一個 view 的變化。直至你搞不清楚到底發生了什麼。 -- Redux文檔編程
上面這一大段引用概況起來就是一句話, state(狀態)在何時什麼地方,由於什麼而變化成了一個不受控制的過程。(這不能忍,狀態若是沒法預測以及控制)redux
那麼Redux就是試圖讓state的變化變得可預測。這些限制條件反映在 Redux 的三大原則中。api
1.Redux使用普通的對象來描述state,這個對象就是Modal。
promise
2.要想更新 state 中的數據,你須要發起一個 action。Action 就是一個普通 JavaScript 對象用來描述發生了什麼。
3.爲了把 action 和 state 串起來,開發一些函數,這就是 reducer。reducer 只是一個接收 state 和 action,並返回新的 state 的函數。
瞭解到這些後,其實已經多少能明白Redux is a predictable state container for JavaScript apps. (Redux是Javascript應用程序的可預測狀態容器。)這句話,爲何是可預測的? 由於只有一個state樹,而且它是隻讀的,並且只能經過action來改變(改變的過程變得清晰可追蹤),而且獲取state(狀態)只能經過reducer,而reducer是一個純函數(此處瞭解state是重點),沒有反作用,也就意味着咱們能知道咱們最終獲得的state是什麼樣的。
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())))
Redux官方提供的 React 綁定庫。 具備高效且靈活的特性。
React是以組件化的形式開發。爲了組件的複用以及代碼的清晰,一般咱們將組件分爲容器組件以及UI組件。
關於容器組件和UI組件,推薦閱讀該文章,而引入了React-redux能夠很好的幫助咱們分離容器組件和UI組件。
使組件層級中的 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的優點而形成的不可避免的劣勢,問題應該辯證地看~
事實上,若是用過vuex或者dva的話, 我的以爲仍是會比較偏向於這種用法。比起Redux的囉嗦,dva幫忙簡化了不少步驟。具體的實現後續補充~
這裏先補充一點,vuex不是immutable,因此對於時間旅行這種業務不太友好。
Redux的代碼相對比較簡單,容易理解, 源碼的解讀推薦看這篇文章, 本段主要是對代碼裏一些我的以爲比較有意思的點進行分析~
在這裏看出,redux即便是在內部,也是函數式編程~
當咱們傳入了一個enhancer函數(即中間件),會把createStore自己當成參數傳給enhancer而後返回一個新的函數來調用 即 fn => fn
暴露出的subscribe函數也是挺有意思的, 首先是isSubscribed這個變量, 其實就是一種很是基礎的閉包使用,
而後是每次訂閱或者取消訂閱的時候,都會在dispatch以前保存一次快照, 而後當前的dispatch用的是上一份快照,而下一個dispatch則是使用當前這一份的快照
很是簡潔的寫出了函數式編程的一個經常使用函數(...args) => f(g(h(...args))).
能夠看出,每一次action都會從新計算全部的reducer~ 但若是不是很是巨大的state樹,而且拆分了不少模塊,我的認爲其實影響不大
bindActionCreator和applyMiddleware相對容易理解, 這裏就不贅述啦