redux深入高階

2021-09-19 11:06:51 字數 4641 閱讀 1701

閒話不多說,上**。

import thunk from 'redux-thunk';

import rootreducer from './reducers/index';

// create a store that has redux-thunk middleware enabled

thunk

)(createstore);

const store = createstorewithmiddleware(rootreducer);

這顯然是乙個裝飾器模式,通過不同的中介軟體對createstore方法進行修飾,最後形成新的createstore方法,那麼建立的store就具有這些中介軟體的特性,

非常出色的設計,驚喜不僅在這,看了之後的**你就更不得不佩服作者的**設計能力。

瞬間覺得別人都是碼神,而我就是碼農有木有/(ㄒoㄒ)/~~

import compose from './compose';

/** * of the redux store. this is handy for a variety of tasks, such as expressing

* asynchronous actions in a concise manner, or logging every action payload.

* * see `redux-thunk` package as an example of the redux middleware.

* * because middleware is potentially asynchronous, this should be the first

* store enhancer in the composition chain.

* * note that each middleware will be given the `dispatch` and `getstate` functions

* as named arguments.

* */

return (next) => (reducer, initialstate) => ;

chain = middlewares.map(middleware => middleware(middlewareapi));

dispatch = compose(...chain)(store.dispatch);

return ;

};}

這就是redux裡面這個方法的原始碼,其中還一半是注釋有木有。。。本來以為肯定有百來行**的

當然這裡不得不說es6的特性提供了非常多的幫助,所以為了省力吧es6玩透還是灰常有必要的(更別說為了裝x了(^__^) )

從這裡開始**就有點繞了,我們逐行分析

return (next) => (reducer, initialstate) =>
function (reducer, initialstate)
var store = next(reducer, initialstate);

var dispatch = store.dispatch;

var chain = ;

這裡沒什麼好講的,首先建立了乙個store,這個store就是最原始的通過createstore建立的store,後兩行只是變數賦值

var middlewareapi = ;

chain = middlewares.map(middleware => middleware(middlewareapi));

dispatch = compose(...chain)(store.dispatch);

這裡是關鍵,必須詳細進行講解。

首先,這邊宣告了乙個middlewareapi物件,這個物件包含兩個方法:

getstate:store中的getstate方法的引用

dispatch:對本身的dispatch方法進行一次封裝

然後

chain = middlewares.map(middleware => middleware(middlewareapi));
我們來仔細看看這行**,首先我們對所有的中介軟體進行乙個map,map結果就是呼叫中介軟體方法,將middlewareapi作為引數傳入,

這裡我們拿redux-thunk中介軟體舉例,來看看乙個中介軟體是長什麼樣子的,傳入的引數又是用來幹嘛的。

export default function thunkmiddleware()
redux-thunk的功能是讓action支援非同步,讓我們可以在action中跟伺服器進行互動等操作,而他的實現。。。(⊙﹏⊙)b是的,又是這麼幾行**。

我們回顧之前的**,在map所有中介軟體的時候我們呼叫了thunkmiddleware方法,傳入兩個方法dispatchgetstate,然後返回了乙個方法,

我們大致抽象一下,應該如下:

function (next) 

}

chain = middlewares.map(middleware => middleware(middlewareapi));
現在我們知道chain是乙個陣列,每一項是呼叫每個中介軟體之後的返回函式

dispatch = compose(...chain)(store.dispatch);
compose是redux裡面的乙個幫助函式,**如下:

export default function compose(...funcs)
~~(>_<)~~我已經不想再吐槽什麼了,

我們看到這邊先呼叫了compose函式,傳入了結構後的chain陣列,然後compose函式返回的也是乙個函式:

function (arg)
然後我們把store.dispatch函式作為arg傳入這個結果,這裡reduceright可以參考這裡

。那麼這邊得到的結果是什麼呢?

// 假設中介軟體陣列是[a, b, c]

// 那麼結果就是a(b(c(store.dispatch)))

再次結合redux-thunk來看,我們假設只有乙個中介軟體,那麼最終的dispatch方法就是

function (action) 

// 這裡的next方法,就是真正的store.dispatch方法

// 這裡的dispatch是(action) => store.dispatch(action)

我們再結合redux-thunk的使用方法來分析一下,

function incrementasync() , 1000);

};}

這是使用redux-thunk時可以定義的非同步action,我們觸發action的時候呼叫的是

dispatch(incrementasync())
incrementasync返回的是

function (dispatch) , 1000);

}

這個時候我們回想經過中介軟體加工的dispatch方法:

function (action) 

// 這裡的next方法,就是真正的store.dispatch方法

// 這裡的dispatch是(action) => store.dispatch(action)

action是乙個函式,所以action === 'function' ?成立,那麼就執行action, 並把中介軟體接收到的dispatch方法((action) => store.dispatch(action))方法作為引數傳入,在非同步方法執行完之後再次觸發真正的action。如果action不是非同步的,那麼久直接返回乙個物件,這個時候action === 'function' ?不成立,就直接呼叫next,也就是原始的store.dispatch方法。

我們再接著想,如果我們有許多個中介軟體,那麼沒乙個中介軟體的next就是下乙個中介軟體直到最後乙個中介軟體呼叫store.dispatch為止。

以上的**非常繞,建議去專研一下原始碼。這麼精簡的**包含了非常多的函式式程式設計的思想,也用到了裝飾器模式的原理,不得不說:

太燒腦啦/(ㄒoㄒ)/~~

redux深入高階

閒話不多說,上 import thunk from redux thunk import rootreducer from reducers index create a store that has redux thunk middleware enabled thunk createstore ...

redux筆記 高階

1 拆分ui元件和容器元件 return value onchange 提交 export 對應的聰明元件 render this state return inputvalue handleinputchange submitdata list deletelist 2 非同步請求可以放在元件中,...

深入理解redux中介軟體

摘自 please call me hr redux middleware 是 redux 的乙個 advanced feature.這個概念並不是很新奇,以為在 koa 裡面早已經實現過了.對比與原生的redux middleware koa 的 middleware 差不多相當於是爸爸級的 le...