@(Redux)[|用法|源碼]
Redux 由Dan Abramov在2015年建立的科技術語。是受2014年Facebook的Flux架構以及函數式編程言語Elm啟示。很快，Redux因其簡樸易學體積小短時間內成為最熱點的前端架構。
@[三大準繩]
- 單一數據源 – 全部運用的
state被儲存在一棵object tree中，而且這個object tree只存在於唯一一個store中。統統數據會經由過程store.getState()要領挪用獵取. - State‘只讀’ – 依據
State只讀準繩，數據變動會經由過程store,dispatch(action)要領. - 運用純函數修正 –
Reducer只是一些純函數1，它吸收先前的state和action，並返回新的state.
[TOC]
預備階段
柯里化函數（curry）
//curry example
const A = (a) => {
return (b) => {
return a + b
}
}淺顯的來說，能夠用一句話歸納綜合柯里化函數：返回函數的函數.
長處: 避免了給一個函數傳入大批的參數，將參數的代入分脫離，更有利於調試。下降耦合度和代碼冗餘，便於復用.
代碼組合（compose）
舉個例子
let init = (...args) => args.reduce((ele1, ele2) => ele1 + ele2, 0)
let step2 = (val) => val + 2
let step3 = (val) => val + 3
let step4 = (val) => val + 4
let steps = [step4, step3, step2, init]
let composeFunc = compose(...steps)
console.log(composeFunc(1, 2, 3))
// 1+2+3+2+3+4 = 15接下來看下FP頭腦的compose的源碼
const compose = function (...args) {
let length = args.length
let count = length - 1
let result
let this_ = this
// 遞歸
return function f1(...arg1) {
result = args[count].apply(this, arg1)
if (count <= 0) {
count = length - 1
return result
}
count--
return f1.call(null, result)
}
}淺顯的講: 從右到左實行函數，最右函數以arguments為參數，其他函數以上個函數結果為入參數實行。
長處: 經由過程如許函數之間的組合，能夠大大增添可讀性，結果遠大於嵌套一大堆的函數挪用，而且我們能夠隨便變動函數的挪用遞次
CombineReducers
作用
跟着全部項目愈來愈大，state狀況樹也會愈來愈巨大，state的層級也會愈來愈深，因為redux只保護唯一的state，當某個action.type所對應的須要修正state.a.b.c.d.e.f時，我的函數寫起來就異常複雜，我必需在這個函數的頭部考證state 對象有無誰人屬性。這是讓開發者異常頭疼的一件事。因而有了CombineReducers。我們撤除源碼校驗函數部份，從終究返回的大的Reducers來看。
Note:
- FinalReducers : 經由過程
=== 'function'校驗后的Reducers.- FinalReducerKeys :
FinalReducers的統統key（與入參
Object的key區分:過濾了value不為function的值）
源碼
// 返回一個function。該要領吸收state和action作為參數
return function combination(state = {}, action) {
var hasChanged = false
var nextState = {}
// 遍歷統統的key和reducer，離別將reducer對應的key所代表的state，代入到reducer中舉行函數挪用
for (var i = 0; i < finalReducerKeys.length; i++) {
var key = finalReducerKeys[i]
var reducer = finalReducers[key]
// CombineReducers入參Object中的Value為reducer function，從這能夠看出reducer function的name就是返回給store中的state的key。
var previousStateForKey = state[key]
// debugger
var nextStateForKey = reducer(previousStateForKey, action)
// 假如reducer返回undefined則拋出毛病
if (typeof nextStateForKey === 'undefined') {
var errorMessage = getUndefinedStateErrorMessage(key, action)
throw new Error(errorMessage)
}
// 將reducer返回的值填入nextState
nextState[key] = nextStateForKey
// 假如任一state有更新則hasChanged為true
hasChanged = hasChanged || nextStateForKey !== previousStateForKey
}
return hasChanged ? nextState : state
}小結
combineReducers完成要領很簡樸，它遍歷傳入的reducers，返回一個新的reducer.該函數依據State 的key 去實行響應的子Reducer，並將返回結果合併成一個大的State 對象。
CreateStore
作用
createStore重要用於Store的天生，我們先整頓看下createStore詳細做了哪些事兒。(這裏我們看簡化版代碼)
源碼（簡化版）
const createStore = (reducer, initialState) => {
// initialState平常設置為null，或許由效勞端給默認值。
// internal variables
const store = {};
store.state = initialState;
store.listeners = [];
// api-subscribe
store.subscribe = (listener) => {
store.listeners.push(listener);
};
// api-dispatch
store.dispatch = (action) => {
store.state = reducer(store.state, action);
store.listeners.forEach(listener => listener());
};
// api-getState
store.getState = () => store.state;
return store;
}小結
源碼角度，一大堆範例推斷先疏忽，能夠看到聲清楚明了一系列函數，然後實行了dispatch要領，末了暴露了dispatch、subscribe……幾個要領。這裏dispatch了一個init Action是為了天生初始的State樹。
ThunkMiddleware
作用
起首，說ThunkMiddleware之前,或許有人會問，究竟middleware有什麼用？
這就要從action提及。在redux里，action僅僅是攜帶了數據的一般js對象。action creator返回的值是這個action範例的對象。然後經由過程store.dispatch()舉行分發……
action ---> dispatcher ---> reducers
同步的狀況下統統都很圓滿……
假如碰到異步狀況，比方點擊一個按鈕，願望1秒以後顯現。我們能夠這麼寫:
function (dispatch) {
setTimeout(function () {
dispatch({
type: 'show'
})
}, 1000)
}這會報錯，返回的不是一個action，而是一個function。這個返回值沒法被reducer辨認。
人人能夠會想到，這時刻須要在action和reducer之間架起一座橋樑……
固然這座橋樑就是middleware。接下來我們先看看最簡樸，最精華的ThunkMiddleware的源碼
源碼
const thunkMiddleware = ({ dispatch, getState }) => {
return next => action => {
typeof action === 'function' ?
action(dispatch, getState) :
next(action)
}
}異常之精華。。。我們先記住上述代碼，引出下面的ApplyMiddleware
ApplyMiddleware
作用
引見applyMiddleware之前我們先看下項目中store的運用要領以下:
let step = [ReduxThunk, middleware, ReduxLogger]
let store = applyMiddleware(...step)(createStore)(reducer)
return store經由過程運用要領能夠看到有3處柯里化函數的挪用，applyMiddleware 函數Redux 最精華的處所，勝利的讓Redux 有了極大的可拓展空間，在action 通報的過程當中帶來無數的“副作用”，雖然這每每也是貧苦地點。 這個middleware的洋蔥模子頭腦是從koa的中間件拿過來的，用圖來示意最直觀。
洋蔥模子
我們來看源碼:
源碼
const applyMiddleware = (...middlewares) => {
return (createStore) => (reducer, initialState, enhancer) => {
var store = createStore(reducer, initialState, enhancer)
var dispatch
var chain = []
var middlewareAPI = {
getState: store.getState,
dispatch: (action) => dispatch(action)
}
// 每一個 middleware 都以 middlewareAPI 作為參數舉行注入，返回一個新的鏈。
// 此時的返回值相當於挪用 thunkMiddleware 返回的函數： (next) => (action) => {} ，吸收一個next作為其參數
chain = middlewares.map(middleware => middleware(middlewareAPI))
// 並將鏈代入進 compose 構成一個函數的挪用鏈
dispatch = compose(...chain)(store.dispatch)
return {
...store,
dispatch
}
}
}applyMiddleware函數第一次挪用的時刻，返回一個以createStore為參數的匿名函數,這個函數返回另一個以reducer,initialState,enhancer為參數的匿名函數.我們在運用要領中，離別能夠看到傳入的值。
連繫一個簡樸的實例來明白中間件以及洋蔥模子
// 傳入middlewareA
const middlewareA = ({ dispatch, getState }) => {
return next => action => {
console.warn('A middleware start')
next(action)
console.warn('A middleware end')
}
}
// 傳入多個middlewareB
const middlewareB = ({ dispatch, getState }) => {
return next => action => {
console.warn('B middleware start')
next(action)
console.warn('B middleware end')
}
}
// 傳入多個middlewareC
const middlewareC = ({ dispatch, getState }) => {
return next => action => {
console.warn('C middleware start')
next(action)
console.warn('C middleware end')
}
}當我們傳入多個相似A，B，C的middleware到applyMiddleware后，挪用
dispatch = compose(...chain)(store.dispatch)連繫場景而且實行compose結果為：
dispatch = middlewareA(middlewareB(middlewareC(store.dispatch)))從中我們能夠清楚的看到middleware函數中的next函數相互連接，這裏表現了compose FP編程頭腦中代碼組合的壯大作用。再連繫洋蔥模子的圖片，不難明白是怎樣的一個事情流程。
末了我們看結果，當我們觸發一個store.dispath的時刻舉行分發。則會先進入middlewareA而且打印A start 然後進入next函數，也就是middlewareB同時打印B start，然後觸發next函數，這裏的next函數就是middlewareC，然後打印C start,以後才處置懲罰dispath，處置懲罰完成后先打印C end,然後B end,末了A end。完成團體流程。
小結
-
Redux applyMiddleware機制的中心在於，函數式編程（FP）的compose組合函數，需將統統的中間件串連起來。 - 為了合營
compose對單參函數的運用，對每一个中間件採納currying的設想。同時，應用閉包道理做到每一个中間件同享Store。(middlewareAPI的注入)
Feedback & Bug Report
- github: @同性結交網站
Thank you for reading this record.
- 純函數，它不依賴於外部環境（比方：全局變量、環境變量）、不轉變外部環境（比方：發送要求、轉變DOM構造），函數的輸出完全由函數的輸入決議。比方 slice 和 splice，這兩個函數的作用並沒有二致——然則注重，它們各自的體式格局卻大不同，但不管怎麼說作用照樣一樣的。我們說 slice 相符純函數的定義是因為對雷同的輸入它保證能返回雷同的輸出。而 splice 卻會嚼爛挪用它的誰人數組，然後再吐出來；這就會發生可觀察到的副作用，即這個數組永遠地轉變了。能夠看到，splice轉變了原始數組，而slice沒有。我們以為，slice不轉變本來數組的體式格局越發“平安”。轉變原始組數，是一種“副作用”。 ↩
