小編給大家分享一下實現(xiàn)redux, koa, express中間件的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
我們提供的服務(wù)有：成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、高淳ssl等。為1000+企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的高淳網(wǎng)站制作公司
如果你有 express ,koa, redux 的使用經(jīng)驗，就會發(fā)現(xiàn)他們都有 中間件（middlewares）的概念，中間件 是一種攔截器的思想，用于在某個特定的輸入輸出之間添加一些額外處理，同時不影響原有操作。
最開始接觸 中間件是在服務(wù)端使用 express 和 koa 的時候，后來從服務(wù)端延伸到前端，看到其在redux的設(shè)計中也得到的極大的發(fā)揮。中間件的設(shè)計思想也為許多框架帶來了靈活而強大的擴展性。
本文主要對比redux, koa, express 的中間件實現(xiàn)，為了更直觀，我會抽取出三者中間件相關(guān)的核心代碼，精簡化，寫出模擬示例。示例會保持 express, koa，redux 的整體結(jié)構(gòu)，盡量保持和源碼一致，所以本文也會稍帶講解下express, koa, redux 的整體結(jié)構(gòu)和關(guān)鍵實現(xiàn)：
示例源碼地址, 可以一邊看源碼，一邊讀文章，歡迎star!
本文適合對express ,koa ,redux 都有一定了解和使用經(jīng)驗的開發(fā)者閱讀
服務(wù)端的中間件
express 和 koa 的中間件是用于處理 http 請求和響應(yīng)的，但是二者的設(shè)計思路確不盡相同。大部分人了解的express和koa的中間件差異在于：
express采用“尾遞歸”方式，中間件一個接一個的順序執(zhí)行, 習(xí)慣于將response響應(yīng)寫在最后一個中間件中；
而koa的中間件支持 generator, 執(zhí)行順序是“洋蔥圈”模型。
所謂的“洋蔥圈”模型:
不過實際上，express 的中間件也可以形成“洋蔥圈”模型，在 next 調(diào)用后寫的代碼同樣會執(zhí)行到，不過express中一般不會這么做，因為 express的response一般在最后一個中間件，那么其它中間件 next() 后的代碼已經(jīng)影響不到最終響應(yīng)結(jié)果了;
express
首先看一下 express 的實現(xiàn)：
入口
重慶分公司
重慶分公司
// express.js
var proto = require('./application');
var mixin = require('merge-descriptors');
exports = module.exports = createApplication;
function createApplication() {
// app 同時是一個方法，作為http.createServer的處理函數(shù)
var app = function(req, res, next) {
app.handle(req, res, next)
}
mixin(app, proto, false);
return app
}這里其實很簡單，就是一個 createApplication 方法用于創(chuàng)建 express 實例，要注意返回值 app 既是實例對象，上面掛載了很多方法，同時它本身也是一個方法，作為 http.createServer的處理函數(shù), 具體代碼在 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 調(diào)用 nodejs 的http.createServer 創(chuàng)建web服務(wù)，可以看到這里 var server = http.createServer(this) 其中 this 即 app 本身, 然后真正的處理程序即 app.handle;
中間件處理
express 本質(zhì)上就是一個中間件管理器，當(dāng)進入到 app.handle 的時候就是對中間件進行執(zhí)行的時候，所以，最關(guān)鍵的兩個函數(shù)就是：
app.handle 尾遞歸調(diào)用中間件處理 req 和 res
app.use 添加中間件
全局維護一個stack數(shù)組用來存儲所有中間件，app.use 的實現(xiàn)就很簡單了，可以就是一行代碼 ``
// app.use
app.use = function(fn) {
this.stack.push(fn)
}express 的真正實現(xiàn)當(dāng)然不會這么簡單，它內(nèi)置實現(xiàn)了路由功能，其中有 router, route, layer 三個關(guān)鍵的類，有了 router 就要對 path 進行分流，stack 中保存的是 layer實例，app.use 方法實際調(diào)用的是 router 實例的 use 方法, 有興趣的可以自行去閱讀。
app.handle 即對 stack 數(shù)組進行處理
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()
}這里就是所謂的"尾遞歸調(diào)用"，next 方法不斷的取出stack中的“中間件”函數(shù)進行調(diào)用，同時把next 本身傳遞給“中間件”作為第三個參數(shù)，每個中間件約定的固定形式為 (req, res, next) => {}, 這樣每個“中間件“函數(shù)中只要調(diào)用 next 方法即可傳遞調(diào)用下一個中間件。
之所以說是”尾遞歸“是因為遞歸函數(shù)的最后一條語句是調(diào)用函數(shù)本身，所以每一個中間件的最后一條語句需要是next()才能形成”尾遞歸“，否則就是普通遞歸，”尾遞歸“相對于普通”遞歸“的好處在于節(jié)省內(nèi)存空間，不會形成深度嵌套的函數(shù)調(diào)用棧。有興趣的可以閱讀下阮老師的尾調(diào)用優(yōu)化
至此，express 的中間件實現(xiàn)就完成了。
koa
不得不說，相比較 express 而言，koa 的整體設(shè)計和代碼實現(xiàn)顯得更高級，更精煉；代碼基于ES6 實現(xiàn)，支持generator(async await), 沒有內(nèi)置的路由實現(xiàn)和任何內(nèi)置中間件，context 的設(shè)計也很是巧妙。
整體
一共只有4個文件：
application.js 入口文件，koa應(yīng)用實例的類
context.js ctx 實例，代理了很多request和response的屬性和方法，作為全局對象傳遞
request.js koa 對原生 req 對象的封裝
response.js koa 對原生 res 對象的封裝
request.js 和 response.js 沒什么可說的，任何 web 框架都會提供req和res 的封裝來簡化處理。所以主要看一下 context.js 和 application.js的實現(xiàn)
// 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') 這條語句的作用就是：當(dāng)調(diào)用proto.setHeader時，會調(diào)用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方法中創(chuàng)建 web 服務(wù), 沒有使用 express 那么繞的方式，const server = http.createServer(this.callback()); 用this.callback()生成 web 服務(wù)的處理程序
callback 函數(shù)返回handleRequest, 所以真正的處理程序是this.handleRequest(ctx, fn)
中間件處理
構(gòu)造函數(shù) constructor 中維護全局中間件數(shù)組 this.middleware和全局的this.context 實例（源碼中還有request，response對象和一些其他輔助屬性）。和 express 不同，因為沒有router的實現(xiàn)，所有this.middleware 中就是普通的”中間件“函數(shù)而非復(fù)雜的 layer 實例，
this.handleRequest(ctx, fn); 中 ctx 為第一個參數(shù)，fn = compose(this.middleware) 作為第二個參數(shù), handleRequest 會調(diào)用 fnMiddleware(ctx).then(handleResponse).catch(onerror); 所以中間處理的關(guān)鍵在compose方法, 它是一個獨立的包koa-compose, 把它拿了出來看一下里面的內(nèi)容：
// 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) => {}, 執(zhí)行后返回的是一個promise, 第二個參數(shù) next的值為 dispatch.bind(null, i + 1) , 用于傳遞”中間件“的執(zhí)行，一個個中間件向里執(zhí)行，直到最后一個中間件執(zhí)行完，resolve 掉，它前一個”中間件“接著執(zhí)行 await next() 后的代碼，然后 resolve 掉，在不斷向前直到第一個”中間件“ resolve掉，最終使得最外層的promise resolve掉。
這里和express很不同的一點就是koa的響應(yīng)的處理并不在"中間件"中，而是在中間件執(zhí)行完返回的promise resolve后：
return fnMiddleware(ctx).then(handleResponse).catch(onerror);
通過 handleResponse 最后對響應(yīng)做處理，”中間件“會設(shè)置ctx.body, handleResponse也會主要處理 ctx.body ，所以 koa 的”洋蔥圈“模型才會成立，await next()后的代碼也會影響到最后的響應(yīng)。
至此，koa的中間件實現(xiàn)就完成了。
redux
不得不說，redux 的設(shè)計思想和源碼實現(xiàn)真的是漂亮，整體代碼量不多，網(wǎng)上已經(jīng)隨處可見redux的源碼解析，我就不細說了。不過還是要推薦一波官網(wǎng)對中間件部分的敘述 : redux-middleware
這是我讀過的最好的說明文檔，沒有之一，它清晰的說明了 redux middleware 的演化過程，漂亮地演繹了一場從分析問題到解決問題，并不斷優(yōu)化的思維過程。
總體
本文還是主要看一下它的中間件實現(xiàn), 先簡單說一下 redux 的核心處理邏輯, createStore 是其入口程序，工廠方法，返回一個 store 實例，store實例的最關(guān)鍵的方法就是 dispatch , 而 dispatch 要做的就是一件事：
currentState = currentReducer(currentState, action)
即調(diào)用reducer, 傳入當(dāng)前state和action返回新的state。
所以要模擬基本的 redux 執(zhí)行只要實現(xiàn) createStore , dispatch 方法即可。其它的內(nèi)容如 bindActionCreators, combineReducers 以及 subscribe 監(jiān)聽都是輔助使用的功能，可以暫時不關(guān)注。
中間件處理
然后就到了核心的”中間件" 實現(xiàn)部分即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 發(fā)起之后，到達 reducer 之前，它的實現(xiàn)思路就和express 、 koa 有些不同了，它沒有通過封裝 store.dispatch, 在它前面添加 中間件處理程序，而是通過遞歸覆寫 dispatch ，不斷的傳遞上一個覆寫的 dispatch 來實現(xiàn)。
每一個 redux 中間件的形式為 store => next => action => { xxx }
這里主要有兩層函數(shù)嵌套：
最外層函數(shù)接收參數(shù)store, 對應(yīng)于 applyMiddleware.js 中的處理代碼是 const chain = middlewares.map(middleware => middleware(middlewareAPI)), middlewareAPI 即為傳入的store 。這一層是為了把 store 的 api 傳遞給中間件使用，主要就是兩個api:
getState, 直接傳遞store.getState.
dispatch: (...args) => dispatch(...args)，這里的實現(xiàn)就很巧妙了，并不是store.dispatch, 而是一個外部的變量dispatch, 這個變量最終指向的是覆寫后的dispatch, 這樣做的原因在于，對于 redux-thunk 這樣的異步中間件，內(nèi)部調(diào)用store.dispatch 的時候仍然后走一遍所有“中間件”。
返回的chain就是第二層的數(shù)組，數(shù)組的每個元素都是這樣一個函數(shù)next => action => { xxx }, 這個函數(shù)可以理解為 接受一個dispatch返回一個dispatch, 接受的dispatch 是后一個中間件返回的dispatch.
還有一個關(guān)鍵函數(shù)即 compose, 主要作用是 compose(f, g, h) 返回 () => f(g(h(..args)))
現(xiàn)在在來理解 dispatch = compose(...chain)(store.dispatch) 就相對容易了，原生的 store.dispatch 傳入最后一個“中間件”，返回一個新的 dispatch , 再向外傳遞到前一個中間件，直至返回最終的 dispatch, 當(dāng)覆寫后的dispatch 調(diào)用時，每個“中間件“的執(zhí)行又是從外向內(nèi)的”洋蔥圈“模型。
至此，redux中間件就完成了。
其它關(guān)鍵點
redux 中間件的實現(xiàn)中還有一點實現(xiàn)也值得學(xué)習(xí)，為了讓”中間件“只能應(yīng)用一次，applyMiddleware 并不是作用在 store 實例上，而是作用在 createStore 工廠方法上。怎么理解呢？如果applyMiddleware 是這樣的
(store, middlewares) => {}
那么當(dāng)多次調(diào)用 applyMiddleware(store, middlewares) 的時候會給同一個實例重復(fù)添加同樣的中間件。所以 applyMiddleware 的形式是
(...middlewares) => (createStore) => createStore,
這樣，每一次應(yīng)用中間件時都是創(chuàng)建一個新的實例，避免了中間件重復(fù)應(yīng)用問題。
這種形式會接收 middlewares 返回一個 createStore 的高階方法，這個方法一般被稱為 createStore的 enhance 方法，內(nèi)部即增加了對中間件的應(yīng)用，你會發(fā)現(xiàn)這個方法和中間件第二層 (dispatch) => dispatch 的形式一致，所以它也可以用于compose 進行多次增強。同時createStore 也有第三個參數(shù)enhance 用于內(nèi)部判斷，自增強。所以 redux 的中間件使用可以有兩種寫法：
第一種：用 applyMiddleware 返回 enhance 增強 createStore
store = applyMiddleware(middleware1, middleware2)(createStore)(reducer, initState)
第二種: createStore 接收一個 enhancer 參數(shù)用于自增強
store = createStore(reducer, initState, applyMiddleware(middleware1, middleware2))
第二種使用會顯得直觀點，可讀性更好。
縱觀 redux 的實現(xiàn)，函數(shù)式編程體現(xiàn)的淋漓盡致，中間件形式 store => next => action => { xx } 是函數(shù)柯里化作用的靈活體現(xiàn)，將多參數(shù)化為單參數(shù)，可以用于提前固定 store 參數(shù)，得到形式更加明確的 dispatch => dispatch，使得 compose得以發(fā)揮作用。
總結(jié)
總體而言，express 和 koa 的實現(xiàn)很類似，都是next 方法傳遞進行遞歸調(diào)用，只不過 koa 是promise 形式。redux 相較前兩者有些許不同，先通過遞歸向外覆寫，形成執(zhí)行時遞歸向里調(diào)用。
總結(jié)一下三者關(guān)鍵異同點（不僅限于中間件）：
實例創(chuàng)建： express 使用工廠方法, koa是類
koa 實現(xiàn)的語法更高級，使用ES6，支持generator(async await)
koa 沒有內(nèi)置router, 增加了 ctx 全局對象，整體代碼更簡潔，使用更方便。
koa 中間件的遞歸為 promise形式，express 使用while 循環(huán)加 next 尾遞歸
我更喜歡 redux 的實現(xiàn)，柯里化中間件形式，更簡潔靈活，函數(shù)式編程體現(xiàn)的更明顯
redux 以 dispatch 覆寫的方式進行中間件增強
最后再次附上 模擬示例源碼 以供學(xué)習(xí)參考，喜歡的歡迎star, fork!
回答一個問題
有人說，express 中也可以用 async function 作為中間件用于異步處理? 其實是不可以的，因為 express 的中間件執(zhí)行是同步的 while 循環(huán)，當(dāng)中間件中同時包含 普通函數(shù) 和 async 函數(shù) 時，執(zhí)行順序會打亂，先看這樣一個例子：
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'
在普通函數(shù)中直接調(diào)用async函數(shù)， async 函數(shù)會同步執(zhí)行到第一個 await 后的代碼，然后就立即返回一個promise, 等到內(nèi)部所有 await 的異步完成，整個async函數(shù)執(zhí)行完，promise 才會resolve掉.
所以，通過上述分析 express中間件實現(xiàn)， 如果用async函數(shù)做中間件，內(nèi)部用await做異步處理，那么后面的中間件會先執(zhí)行，等到 await 后再次調(diào)用 next 索引就會超出！，大家可以自己在這里 express async 打開注釋，自己嘗試一下。
以上是“實現(xiàn)redux, koa, express中間件的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
