您好,登錄后才能下訂單哦!
小編給大家分享一下實現redux, koa, express中間件的示例分析,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
如果你有 express ,koa, redux 的使用經驗,就會發現他們都有 中間件(middlewares)的概念,中間件 是一種攔截器的思想,用于在某個特定的輸入輸出之間添加一些額外處理,同時不影響原有操作。
最開始接觸 中間件是在服務端使用 express 和 koa 的時候,后來從服務端延伸到前端,看到其在redux的設計中也得到的極大的發揮。中間件的設計思想也為許多框架帶來了靈活而強大的擴展性。
本文主要對比redux, koa, express 的中間件實現,為了更直觀,我會抽取出三者中間件相關的核心代碼,精簡化,寫出模擬示例。示例會保持 express, koa,redux 的整體結構,盡量保持和源碼一致,所以本文也會稍帶講解下express, koa, redux 的整體結構和關鍵實現:
示例源碼地址, 可以一邊看源碼,一邊讀文章,歡迎star!
本文適合對express ,koa ,redux 都有一定了解和使用經驗的開發者閱讀
服務端的中間件
express 和 koa 的中間件是用于處理 http 請求和響應的,但是二者的設計思路確不盡相同。大部分人了解的express和koa的中間件差異在于:
express采用“尾遞歸”方式,中間件一個接一個的順序執行, 習慣于將response響應寫在最后一個中間件中;
而koa的中間件支持 generator, 執行順序是“洋蔥圈”模型。
所謂的“洋蔥圈”模型:
不過實際上,express 的中間件也可以形成“洋蔥圈”模型,在 next 調用后寫的代碼同樣會執行到,不過express中一般不會這么做,因為 express的response一般在最后一個中間件,那么其它中間件 next() 后的代碼已經影響不到最終響應結果了;
express
首先看一下 express 的實現:
入口
// express.js var proto = require('./application'); var mixin = require('merge-descriptors'); exports = module.exports = createApplication; function createApplication() { // app 同時是一個方法,作為http.createServer的處理函數 var app = function(req, res, next) { app.handle(req, res, next) } mixin(app, proto, false); return app }
這里其實很簡單,就是一個 createApplication 方法用于創建 express 實例,要注意返回值 app 既是實例對象,上面掛載了很多方法,同時它本身也是一個方法,作為 http.createServer的處理函數, 具體代碼在 application.js 中:
// application.js var http = require('http'); var flatten = require('array-flatten'); var app = exports = module.exports = {} app.listen = function listen() { var server = http.createServer(this) return server.listen.apply(server, arguments) }
這里 app.listen 調用 nodejs 的http.createServer 創建web服務,可以看到這里 var server = http.createServer(this) 其中 this 即 app 本身, 然后真正的處理程序即 app.handle;
中間件處理
express 本質上就是一個中間件管理器,當進入到 app.handle 的時候就是對中間件進行執行的時候,所以,最關鍵的兩個函數就是:
app.handle 尾遞歸調用中間件處理 req 和 res
app.use 添加中間件
全局維護一個stack數組用來存儲所有中間件,app.use 的實現就很簡單了,可以就是一行代碼 ``
// app.use app.use = function(fn) { this.stack.push(fn) }
express 的真正實現當然不會這么簡單,它內置實現了路由功能,其中有 router, route, layer 三個關鍵的類,有了 router 就要對 path 進行分流,stack 中保存的是 layer實例,app.use 方法實際調用的是 router 實例的 use 方法, 有興趣的可以自行去閱讀。
app.handle 即對 stack 數組進行處理
app.handle = function(req, res, callback) { var stack = this.stack; var idx = 0; function next(err) { if (idx >= stack.length) { callback('err') return; } var mid; while(idx < stack.length) { mid = stack[idx++]; mid(req, res, next); } } next() }
這里就是所謂的"尾遞歸調用",next 方法不斷的取出stack中的“中間件”函數進行調用,同時把next 本身傳遞給“中間件”作為第三個參數,每個中間件約定的固定形式為 (req, res, next) => {}, 這樣每個“中間件“函數中只要調用 next 方法即可傳遞調用下一個中間件。
之所以說是”尾遞歸“是因為遞歸函數的最后一條語句是調用函數本身,所以每一個中間件的最后一條語句需要是next()才能形成”尾遞歸“,否則就是普通遞歸,”尾遞歸“相對于普通”遞歸“的好處在于節省內存空間,不會形成深度嵌套的函數調用棧。有興趣的可以閱讀下阮老師的尾調用優化
至此,express 的中間件實現就完成了。
koa
不得不說,相比較 express 而言,koa 的整體設計和代碼實現顯得更高級,更精煉;代碼基于ES6 實現,支持generator(async await), 沒有內置的路由實現和任何內置中間件,context 的設計也很是巧妙。
整體
一共只有4個文件:
application.js 入口文件,koa應用實例的類
context.js ctx 實例,代理了很多request和response的屬性和方法,作為全局對象傳遞
request.js koa 對原生 req 對象的封裝
response.js koa 對原生 res 對象的封裝
request.js 和 response.js 沒什么可說的,任何 web 框架都會提供req和res 的封裝來簡化處理。所以主要看一下 context.js 和 application.js的實現
// context.js /** * Response delegation. */ delegate(proto, 'res') .method('setHeader') /** * Request delegation. */ delegate(proto, 'req') .access('url') .setter('href') .getter('ip');
context 就是這類代碼,主要功能就是在做代理,使用了 delegate 庫。
簡單說一下這里代理的含義,比如delegate(proto, 'res').method('setHeader') 這條語句的作用就是:當調用proto.setHeader時,會調用proto.res.setHeader 即,將proto的 setHeader方法代理到proto的res屬性上,其它類似。
// application.js 中部分代碼 constructor() { super() this.middleware = [] this.context = Object.create(context) } use(fn) { this.middleware.push(fn) } listen(...args) { debug('listen') const server = http.createServer(this.callback()); return server.listen(...args); } callback() { // 這里即中間件處理代碼 const fn = compose(this.middleware); const handleRequest = (req, res) => { // ctx 是koa的精髓之一, req, res上的很多方法代理到了ctx上, 基于 ctx 很多問題處理更加方便 const ctx = this.createContext(req, res); return this.handleRequest(ctx, fn); }; return handleRequest; } handleRequest(ctx, fnMiddleware) { ctx.statusCode = 404; const onerror = err => ctx.onerror(err); const handleResponse = () => respond(ctx); return fnMiddleware(ctx).then(handleResponse).catch(onerror); }
同樣的在listen方法中創建 web 服務, 沒有使用 express 那么繞的方式,const server = http.createServer(this.callback()); 用this.callback()生成 web 服務的處理程序
callback 函數返回handleRequest, 所以真正的處理程序是this.handleRequest(ctx, fn)
中間件處理
構造函數 constructor 中維護全局中間件數組 this.middleware和全局的this.context 實例(源碼中還有request,response對象和一些其他輔助屬性)。和 express 不同,因為沒有router的實現,所有this.middleware 中就是普通的”中間件“函數而非復雜的 layer 實例,
this.handleRequest(ctx, fn); 中 ctx 為第一個參數,fn = compose(this.middleware) 作為第二個參數, handleRequest 會調用 fnMiddleware(ctx).then(handleResponse).catch(onerror); 所以中間處理的關鍵在compose方法, 它是一個獨立的包koa-compose, 把它拿了出來看一下里面的內容:
// compose.js 'use strict' module.exports = compose function compose (middleware) { return function (context, next) { let index = -1 return dispatch(0) function dispatch (i) { index = i let fn = middleware[i] if (i === middleware.length) fn = next if (!fn) return Promise.resolve() try { return Promise.resolve(fn(context, dispatch.bind(null, i + 1))); } catch (err) { return Promise.reject(err) } } } }
和express中的next 是不是很像,只不過他是promise形式的,因為要支持異步,所以理解起來就稍微麻煩點:每個中間件是一個async (ctx, next) => {}, 執行后返回的是一個promise, 第二個參數 next的值為 dispatch.bind(null, i + 1) , 用于傳遞”中間件“的執行,一個個中間件向里執行,直到最后一個中間件執行完,resolve 掉,它前一個”中間件“接著執行 await next() 后的代碼,然后 resolve 掉,在不斷向前直到第一個”中間件“ resolve掉,最終使得最外層的promise resolve掉。
這里和express很不同的一點就是koa的響應的處理并不在"中間件"中,而是在中間件執行完返回的promise resolve后:
return fnMiddleware(ctx).then(handleResponse).catch(onerror);
通過 handleResponse 最后對響應做處理,”中間件“會設置ctx.body, handleResponse也會主要處理 ctx.body ,所以 koa 的”洋蔥圈“模型才會成立,await next()后的代碼也會影響到最后的響應。
至此,koa的中間件實現就完成了。
redux
不得不說,redux 的設計思想和源碼實現真的是漂亮,整體代碼量不多,網上已經隨處可見redux的源碼解析,我就不細說了。不過還是要推薦一波官網對中間件部分的敘述 : redux-middleware
這是我讀過的最好的說明文檔,沒有之一,它清晰的說明了 redux middleware 的演化過程,漂亮地演繹了一場從分析問題到解決問題,并不斷優化的思維過程。
總體
本文還是主要看一下它的中間件實現, 先簡單說一下 redux 的核心處理邏輯, createStore 是其入口程序,工廠方法,返回一個 store 實例,store實例的最關鍵的方法就是 dispatch , 而 dispatch 要做的就是一件事:
currentState = currentReducer(currentState, action)
即調用reducer, 傳入當前state和action返回新的state。
所以要模擬基本的 redux 執行只要實現 createStore , dispatch 方法即可。其它的內容如 bindActionCreators, combineReducers 以及 subscribe 監聽都是輔助使用的功能,可以暫時不關注。
中間件處理
然后就到了核心的”中間件" 實現部分即applyMiddleware.js:
// applyMiddleware.js import compose from './compose' export default function applyMiddleware(...middlewares) { return createStore => (...args) => { const store = createStore(...args) let dispatch = () => { throw new Error( `Dispatching while constructing your middleware is not allowed. ` + `Other middleware would not be applied to this dispatch.` ) } const middlewareAPI = { getState: store.getState, dispatch: (...args) => dispatch(...args) } const chain = middlewares.map(middleware => middleware(middlewareAPI)) dispatch = compose(...chain)(store.dispatch) return { ...store, dispatch } } }
redux 中間件提供的擴展是在 action 發起之后,到達 reducer 之前,它的實現思路就和express 、 koa 有些不同了,它沒有通過封裝 store.dispatch, 在它前面添加 中間件處理程序,而是通過遞歸覆寫 dispatch ,不斷的傳遞上一個覆寫的 dispatch 來實現。
每一個 redux 中間件的形式為 store => next => action => { xxx }
這里主要有兩層函數嵌套:
最外層函數接收參數store, 對應于 applyMiddleware.js 中的處理代碼是 const chain = middlewares.map(middleware => middleware(middlewareAPI)), middlewareAPI 即為傳入的store 。這一層是為了把 store 的 api 傳遞給中間件使用,主要就是兩個api:
getState, 直接傳遞store.getState.
dispatch: (...args) => dispatch(...args),這里的實現就很巧妙了,并不是store.dispatch, 而是一個外部的變量dispatch, 這個變量最終指向的是覆寫后的dispatch, 這樣做的原因在于,對于 redux-thunk 這樣的異步中間件,內部調用store.dispatch 的時候仍然后走一遍所有“中間件”。
返回的chain就是第二層的數組,數組的每個元素都是這樣一個函數next => action => { xxx }, 這個函數可以理解為 接受一個dispatch返回一個dispatch, 接受的dispatch 是后一個中間件返回的dispatch.
還有一個關鍵函數即 compose, 主要作用是 compose(f, g, h) 返回 () => f(g(h(..args)))
現在在來理解 dispatch = compose(...chain)(store.dispatch) 就相對容易了,原生的 store.dispatch 傳入最后一個“中間件”,返回一個新的 dispatch , 再向外傳遞到前一個中間件,直至返回最終的 dispatch, 當覆寫后的dispatch 調用時,每個“中間件“的執行又是從外向內的”洋蔥圈“模型。
至此,redux中間件就完成了。
其它關鍵點
redux 中間件的實現中還有一點實現也值得學習,為了讓”中間件“只能應用一次,applyMiddleware 并不是作用在 store 實例上,而是作用在 createStore 工廠方法上。怎么理解呢?如果applyMiddleware 是這樣的
(store, middlewares) => {}
那么當多次調用 applyMiddleware(store, middlewares) 的時候會給同一個實例重復添加同樣的中間件。所以 applyMiddleware 的形式是
(...middlewares) => (createStore) => createStore,
這樣,每一次應用中間件時都是創建一個新的實例,避免了中間件重復應用問題。
這種形式會接收 middlewares 返回一個 createStore 的高階方法,這個方法一般被稱為 createStore的 enhance 方法,內部即增加了對中間件的應用,你會發現這個方法和中間件第二層 (dispatch) => dispatch 的形式一致,所以它也可以用于compose 進行多次增強。同時createStore 也有第三個參數enhance 用于內部判斷,自增強。所以 redux 的中間件使用可以有兩種寫法:
第一種:用 applyMiddleware 返回 enhance 增強 createStore
store = applyMiddleware(middleware1, middleware2)(createStore)(reducer, initState)
第二種: createStore 接收一個 enhancer 參數用于自增強
store = createStore(reducer, initState, applyMiddleware(middleware1, middleware2))
第二種使用會顯得直觀點,可讀性更好。
縱觀 redux 的實現,函數式編程體現的淋漓盡致,中間件形式 store => next => action => { xx } 是函數柯里化作用的靈活體現,將多參數化為單參數,可以用于提前固定 store 參數,得到形式更加明確的 dispatch => dispatch,使得 compose得以發揮作用。
總結
總體而言,express 和 koa 的實現很類似,都是next 方法傳遞進行遞歸調用,只不過 koa 是promise 形式。redux 相較前兩者有些許不同,先通過遞歸向外覆寫,形成執行時遞歸向里調用。
總結一下三者關鍵異同點(不僅限于中間件):
實例創建: express 使用工廠方法, koa是類
koa 實現的語法更高級,使用ES6,支持generator(async await)
koa 沒有內置router, 增加了 ctx 全局對象,整體代碼更簡潔,使用更方便。
koa 中間件的遞歸為 promise形式,express 使用while 循環加 next 尾遞歸
我更喜歡 redux 的實現,柯里化中間件形式,更簡潔靈活,函數式編程體現的更明顯
redux 以 dispatch 覆寫的方式進行中間件增強
最后再次附上 模擬示例源碼 以供學習參考,喜歡的歡迎star, fork!
回答一個問題
有人說,express 中也可以用 async function 作為中間件用于異步處理? 其實是不可以的,因為 express 的中間件執行是同步的 while 循環,當中間件中同時包含 普通函數 和 async 函數 時,執行順序會打亂,先看這樣一個例子:
function a() { console.log('a') } async function b() { console.log('b') await 1 console.log('c') await 2 console.log('d') } function f() { a() b() console.log('f') }
這里的輸出是 'a' > 'b' > 'f' > 'c'
在普通函數中直接調用async函數, async 函數會同步執行到第一個 await 后的代碼,然后就立即返回一個promise, 等到內部所有 await 的異步完成,整個async函數執行完,promise 才會resolve掉.
所以,通過上述分析 express中間件實現, 如果用async函數做中間件,內部用await做異步處理,那么后面的中間件會先執行,等到 await 后再次調用 next 索引就會超出!,大家可以自己在這里 express async 打開注釋,自己嘗試一下。
以上是“實現redux, koa, express中間件的示例分析”這篇文章的所有內容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內容對大家有所幫助,如果還想學習更多知識,歡迎關注億速云行業資訊頻道!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。