前言
Koa
是當下主流 NodeJS 框架,以輕量見長,而它中介軟體機制與相對傳統的 Express
支援了非同步,所以編碼時經常使用 async/await
,提高了可讀性,使程式碼變得更優雅,上一篇文章 NodeJS 進階 —— Koa 原始碼分析,也對 “洋蔥模型” 和實現它的 compose
進行分析,由於個人覺得 compose
的程式設計思想比較重要,應用廣泛,所以本篇藉著 “洋蔥模型” 的話題,打算用四種方式來實現 compose
。
洋蔥模型案例
如果你已經使用 Koa
對 “洋蔥模型” 這個詞一定不陌生,它就是 Koa
中介軟體的一種序列機制,並且是支援非同步的,下面是一個表達 “洋蔥模型” 的經典案例。
const Koa = require("koa");
const app = new Koa();
app.use(asycn (ctx, next) => {
console.log(1);
await next();
console.log(2);
});
app.use(asycn (ctx, next) => {
console.log(3);
await next();
console.log(4);
});
app.use(asycn (ctx, next) => {
console.log(5);
await next();
console.log(6);
});
app.listen(3000);
// 1
// 3
// 5
// 6
// 4
// 2複製程式碼
上面的寫法我們按照官方推薦,使用了 async/await
,但如果是同步程式碼不使用也沒有關係,這裡簡單的分析一下執行機制,第一個中介軟體函式中如果執行了 next
,則下一個中介軟體會被執行,依次類推,就有了我們上面的結果,而在 Koa
原始碼中,這一功能是靠一個 compose
方法實現的,我們本文四種實現 compose
的方式中實現同步和非同步,並附帶對應的案例來驗證。
準備工作
在真正建立 compose
方法之前應該先做些準備工作,比如建立一個 app
物件來頂替 Koa
建立出的例項物件,並新增 use
方法和管理中介軟體的陣列 middlewares
。
// 模擬 Koa 建立的例項
const app = {
middlewares: []
};
// 建立 use 方法
app.use = function(fn) {
app.middlewares.push(fn);
};
// app.compose.....
module.exports = app;複製程式碼
上面的模組中匯出了 app
物件,並建立了儲存中介軟體函式的 middlewares
和新增中介軟體的 use
方法,因為無論用哪種方式實現 compose
這些都是需要的,只是 compose
邏輯的不同,所以後面的程式碼塊中會只寫 compose
方法。
Koa 中 compose 的實現方式
首先介紹的是 Koa
原始碼中的實現方式,在 Koa
原始碼中其實是通過 koa-compose
中介軟體來實現的,我們在這裡將這個模組的核心邏輯抽取出來,用我們自己的方式實現,由於重點在於分析 compose
的原理,所以 ctx
引數就被去掉了,因為我們不會使用它,重點是 next
引數。
1、同步的實現
app.compose = function() {
// 遞迴函式
function dispatch(index) {
// 如果所有中介軟體都執行完跳出
if (index === app.middlewares.length) return;
// 取出第 index 箇中介軟體並執行
const route = app.middlewares[index];
return route(() => dispatch(index + 1));
}
// 取出第一個中介軟體函式執行
dispatch(0);
};複製程式碼
上面是同步的實現,通過遞迴函式 dispatch
的執行取出了陣列中的第一個中介軟體函式並執行,在執行時傳入了一個函式,並遞迴執行了 dispatch
,傳入的引數 +1
,這樣就執行了下一個中介軟體函式,依次類推,直到所有中介軟體都執行完畢,不滿足中介軟體執行條件時,會跳出,這樣就按照上面案例中 1 3 5 6 4 2
的情況執行,測試例子如下(同步上、非同步下)。
const app = require("./app");
app.use(next => {
console.log(1);
next();
console.log(2);
});
app.use(next => {
console.log(3);
next();
console.log(4);
});
app.use(next => {
console.log(5);
next();
console.log(6);
});
app.compose();
// 1
// 3
// 5
// 6
// 4
// 2複製程式碼
const app = require("./app");
// 非同步函式
function fn() {
return new Promise((resolve, reject) => {
setTimeout(() => {
resolve();
console.log("hello");
}, 3000);
});
}
app.use(async next => {
console.log(1);
await next();
console.log(2);
});
app.use(async next => {
console.log(3);
await fn(); // 呼叫非同步函式
await next();
console.log(4);
});
app.use(async next => {
console.log(5);
await next();
console.log(6);
});
app.compose();複製程式碼
我們發現如果案例中按照 Koa
的推薦寫法,即使用 async
函式,都會通過,但是在給 use
傳參時可能會傳入普通函式或 async
函式,我們要將所有中介軟體的返回值都包裝成 Promise 來相容兩種情況,其實在 Koa
中 compose
最後返回的也是 Promise,是為了後續的邏輯的編寫,但是現在並不支援,下面來解決這兩個問題。
compose
的其他實現方式中,都是使用 sync-test.js
和 async-test.js
驗證,所以後面就不再重複了。2、升級為支援非同步
app.compose = function() {
// 遞迴函式
function dispatch(index) {
// 如果所有中介軟體都執行完跳出,並返回一個 Promise
if (index === app.middlewares.length) return Promise.resolve();
// 取出第 index 箇中介軟體並執行
const route = app.middlewares[index];
// 執行後返回成功態的 Promise
return Promise.resolve(route(() => dispatch(index + 1)));
}
// 取出第一個中介軟體函式執行
dispatch(0);
};複製程式碼
我們知道 async
函式中 await
後面執行的非同步程式碼要實現等待,帶非同步執行後繼續向下執行,需要等待 Promise,所以我們將每一箇中介軟體函式在呼叫時最後都返回了一個成功態的 Promise,使用 async-test.js
進行測試,發現結果為 1 3 hello(3s後) 5 6 4 2
。
Redux 舊版本 compose 的實現方式
1、同步的實現
app.compose = function() {
return app.middlewares.reduceRight((a, b) => () => b(a), () => {})();
};複製程式碼
上面的程式碼看起來不太好理解,我們不妨根據案例把這段程式碼拆解開,假設 middlewares
中儲存的三個中介軟體函式分別為 fn1
、fn2
和 fn3
,由於使用的是 reduceRight
方法,所以是逆序歸併,第一次 a
代表初始值(空函式),b
代表 fn3
,而執行 fn3
返回了一個函式,這個函式再作為下一次歸併的 a
,而 fn2
作為 b
,依次類推,過程如下。
// 第 1 次 reduceRight 的返回值,下一次將作為 a
() => fn3(() => {});
// 第 2 次 reduceRight 的返回值,下一次將作為 a
() => fn2(() => fn3(() => {}));
// 第 3 次 reduceRight 的返回值,下一次將作為 a
() => fn1(() => fn2(() => fn3(() => {})));複製程式碼
由上面的拆解過程可以看出,如果我們呼叫了這個函式會先執行 fn1
,如果呼叫 next
則會執行 fn2
,如果同樣呼叫 next
則會執行 fn3
,fn3
已經是最後一箇中介軟體函式了,再次調 next
會執行我們最初傳入的空函式,這也是為什麼要將 reduceRight
的初始值設定成一個空函式,就是防止最後一箇中介軟體呼叫 next
而報錯。
經過測試上面的程式碼不會出現順序錯亂的情況,但是在 compose
執行後,我們希望進行一些後續的操作,所以希望返回的是 Promise,而我們又希望傳入給 use
的中介軟體函式既可以是普通函式,又可以是 async
函式,這就要我們的 compose
完全支援非同步。
2、升級為支援非同步
app.compose = function() {
return Promise.resolve(
app.middlewares.reduceRight(
(a, b) => () => Promise.resolve(b(a)),
() => Promise.resolve();
)()
);
};複製程式碼
參考同步的分析過程,由於最後一箇中介軟體執行後執行的空函式內一定沒有任何邏輯,但為遇到非同步程式碼可以繼續執行(比如執行 next
後又呼叫了 then
),都處理成了 Promise,保證了 reduceRight
每一次歸併的時候返回的函式內都返回了一個 Promise,這樣就完全相容了 async
和普通函式,當所有中介軟體執行完畢,也返回了一個 Promise,這樣 compose
就可以呼叫 then
方法執行後續邏輯。
Redux 新版本 compose 的實現方式
1、同步的實現
app.compose = function() {
return app.middlewares.reduce((a, b) => arg => a(() => b(arg)))(() => {});
};複製程式碼
Redux
新版本中將 compose
的邏輯做了些改動,將原本的 reduceRight
換成 reduce
,也就是說將逆序歸併改為了正序,我們不一定和 Redux
原始碼完全相同,是根據相同的思路來實現序列中介軟體的需求。
個人覺得改成正序歸併後更難理解,所以還是將上面程式碼結合案例進行拆分,中介軟體依然是 fn1
、fn2
和 fn3
,由於 reduce
並沒有傳入初始值,所以此時 a
為 fn1
,b
為 fn2
。
// 第 1 次 reduce 的返回值,下一次將作為 a
arg => fn1(() => fn2(arg));
// 第 2 次 reduce 的返回值,下一次將作為 a
arg => (arg => fn1(() => fn2(arg)))(() => fn3(arg));
// 等價於...
arg => fn1(() => fn2(() => fn3(arg)));
// 執行最後返回的函式連線中介軟體,返回值等價於...
fn1(() => fn2(() => fn3(() => {})));複製程式碼
所以在呼叫 reduce
最後返回的函式時,傳入了一個空函式作為引數,其實這個引數最後傳遞給了 fn3
,也就是第三個中介軟體,這樣保證了在最後一箇中介軟體呼叫 next
時不會報錯。
2、升級為支援非同步
下面有個更艱鉅的任務,就是將上面的程式碼更改為支援非同步,實現如下。
app.compose = function() {
return Promise.resolve(
app.middlewares.reduce((a, b) => arg =>
Promise.resolve(a(() => b(arg)))
)(() => Promise.resolve())
);
};複製程式碼
實現非同步其實與逆序歸併是一個套路,就是讓每一箇中介軟體函式的返回值都是 Promise,並讓 compose
也返回 Promise。
使用 async 函式實現
這個版本是我在之前在學習 Koa
原始碼時偶然在一位大佬的一篇分析 Koa
原理的文章中看到的(翻了半天實在沒找到連結),在這裡也拿出來和大家分享一下,由於是利用 async
函式實現的,所以預設就是支援非同步的,因為 async
函式會返回一個 Promise。
app.compose = function() {
// 自執行 async 函式返回 Promise
return (async function () {
// 定義預設的 next,最後一箇中介軟體內執行的 next
let next = async () => Promise.resolve();
// middleware 為每一箇中介軟體函式,oldNext 為每個中介軟體函式中的 next
// 函式返回一個 async 作為新的 next,async 執行返回 Promise,解決非同步問題
function createNext(middleware, oldNext) {
return async () => {
await middleware(oldNext);
}
}
// 反向遍歷中介軟體陣列,先把 next 傳給最後一箇中介軟體函式
// 將新的中介軟體函式存入 next 變數
// 呼叫下一個中介軟體函式,將新生成的 next 傳入
for (let i = app.middlewares.length - 1; i >= 0; i--) {
next = createNext(app.middlewares[i], next);
}
await next();
})();
};複製程式碼
上面程式碼中的 next
是一個只返回成功態 Promise 的函式,可以理解為其他實現方式中最後一箇中介軟體呼叫的 next
,而陣列 middlewares
剛好是反向遍歷的,取到的第一個值就是最後一箇中介軟體,而呼叫 createNext
作用是返回一個新的可以執行陣列中最後一箇中介軟體的 async
函式,並傳入了初始的 next
,這個返回的 async
函式作為新的 next
,再取到倒數第二個中介軟體,呼叫 createNext
,又返回了一個 async
函式,函式內依然是倒數第二個中介軟體的執行,傳入的 next
就是上次新生成的 next
,這樣依次類推到第一個中介軟體。
因此執行第一個中介軟體返回的 next
則會執行傳入的上一個生成的 next
函式,就會執行第二個中介軟體,就會執行第二個中介軟體中的 next
,就這樣直到執行完最初定義的的 next
,通過案例的驗證,執行結果與洋蔥模型完全相同。
至於非同步的問題,每次執行的 next
都是 async
函式,執行後返回的都是 Promise,而最外層的自執行 async
函式返回的也是 Promise,也就是說 compose
最後返回的是 Promise,因此完全支援非同步。
總結
或許你看完這幾種方式會覺得,還是 Koa
對於 compose
的實現方式最容易理解,你也可能和我一樣在感慨 Redux
的兩種實現方式和 async
函式實現方式是如此的巧妙,恰恰 JavaScript 在被別人詬病 “弱型別”、“不嚴謹” 的同時,就是如此的具有靈活性和創造性,我們無法判斷這是優點還是缺點(仁者見仁,智者見智),但有一點是肯定的,學習 JavaScript 不要被強型別語言的 “墨守成規” 所束縛(個人觀點,強型別語言開發者勿噴),就是要吸收這樣巧妙的程式設計思想,寫出 compose
這種優雅又高逼格的程式碼,路漫漫其修遠兮,願你在技術的路上 “一去不復返”。