本文來自
所有系列文章都放在了。歡迎交流和Star ✿✿ ヽ(°▽°)ノ ✿

最近讀了 koa2 的原始碼，理清楚了架構設計與用到的第三方庫。本系列將分為 3 篇，分別介紹和 3 個核心庫，最終會。這是系列第 2 篇，關於 3 個核心庫的原理。

is-generator-function：判斷 generator

koa2 種推薦使用 async 函式，koa1 推薦的是 generator。koa2 為了相容，在呼叫use新增中介軟體的時候，會判斷是否是 generator。如果是，則用covert庫轉化為 async 函式。

判斷是不是 generator 的邏輯寫在了庫中，邏輯非常簡單，透過判斷Object.prototype.toString.call 的返回結果即可：

function* say() {}
Object.prototype.toString.call(say); // 輸出: [object GeneratorFunction]

delegates：屬性代理

和 koa 一樣，這個庫都是出自大佬 TJ 之手。它的作用就是屬性代理。這個代理庫常用的方法有getter，setter，method 和 access。

用法

假設準備了一個物件target，為了方便訪問其上request屬性的內容，對request進行代理：

const delegates = require("delegates");
const target = {
  request: {
    name: "xintan",
    say: function() {
      console.log("Hello");
    }
  }
};

delegates(target, "request")
  .getter("name")
  .setter("name")
  .method("say");

代理後，訪問request將會更加方便：

console.log(target.name); // xintan
target.name = "xintan!!!";
console.log(target.name); // xintan!!!
target.say(); // Hello

實現

對於 setter 和 getter方法，是透過呼叫物件上的 __defineSetter__ 和 __defineGetter__ 來實現的。下面是單獨拿出來的邏輯：

/**
 * @param {Object} proto 被代理物件
 * @param {String} property 被代理物件上的被代理屬性
 * @param {String} name
 */
function myDelegates(proto, property, name) {
  proto.__defineGetter__(name, function() {
    return proto[property][name];
  });
  proto.__defineSetter__(name, function(val) {
    return (proto[property][name] = val);
  });
}

myDelegates(target, "request", "name");
console.log(target.name); // xintan
target.name = "xintan!!!";
console.log(target.name); // xintan!!!

剛開始我的想法是更簡單一些，就是直接讓 proto[name] = proto[property][name]。但這樣做有個缺點無法彌補，就是之後如果proto[property][name]改變，proto[name]獲取不了最新的值。

對於method方法，實現上是在物件上建立了新屬性，屬性值是一個函式。這個函式呼叫的就是代理目標的函式。下面是單獨拿出來的邏輯：

/**
 *
 * @param {Object} proto 被代理物件
 * @param {String} property 被代理物件上的被代理屬性
 * @param {String} method 函式名
 */
function myDelegates(proto, property, method) {
  proto[method] = function() {
    return proto[property][method].apply(proto[property], arguments);
  };
}

myDelegates(target, "request", "say");
target.say(); // Hello

因為是“代理”，所以這裡不能修改上下文環境。proto[property][method]的上下文環境是 proto[property] ，需要apply重新指定。

koa 中也有對屬性的access方法代理，這個方法就是getter和setter寫在一起的語法糖。

koa-compose：洋蔥模型

模擬洋蔥模型

koa 最讓人驚豔的就是大名鼎鼎的“洋蔥模型”。以至於之前我在開發 koa 中介軟體的時候，一直有種 magic 的方法。經常疑惑，這裡await next()，執行完之後的中介軟體又會重新回來繼續執行未執行的邏輯。

這一段邏輯封裝在了核心庫裡面。原始碼也很簡單，算上各種註釋只有不到 50 行。為了方便說明和理解，我把其中一些意外情況檢查的程式碼去掉：

function compose(middleware) {
  return function(context) {
    return dispatch(0);

    function dispatch(i) {
      let fn = middleware[i];
      try {
        return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));
      } catch (err) {
        return Promise.reject(err);
      }
    }
  };
}

middleware 裡面儲存的就是開發者自定義的中介軟體處理邏輯。為了方便說明，我準備了 2 箇中介軟體函式：

const middleware = [
  async (ctx, next) => {
    console.log("a");
    await next();
    console.log("c");
  },

  async (ctx, next) => {
    console.log("b");
  }
];

現在，模擬在 koa 中對 compose 函式的呼叫，我們希望程式的輸出是：a b c（正如使用 koa 那樣）。執行以下程式碼即可：

const fns = compose(middleware);
fns();

ok，目前已經模擬出來了一個不考慮異常情況的洋蔥模型了。

為什麼會這樣？

為什麼會有洋蔥穿透的的效果呢？回到上述的compose函式，閉包寫法返回了一個新的函式，其實就是返回內部定義的dispatch函式。其中，引數的含義分別是：

i: 當前執行到的中介軟體在所有中介軟體中的下標
context: 上下文環境。所以我們在每個中介軟體中都可以訪問到當前請求的資訊。

在上面的測試用例中，fns 其實就是 dispatch(0)。在dispatch函式中，透過引數 i 拿到了當前要執行的中介軟體fn。

然後，將當前請求的上下文環境(context)和 dispatch 處理的下一個中介軟體(next)，都傳遞給當前中介軟體。對應的程式碼段是：

return Promise.resolve(fn(context, dispatch.bind(null, i + 1)));

那麼，在中介軟體中執行 await next()，其實就是執行：await dispatch.bind(null, i + 1)。因此看起來，當前中介軟體會停止自己的邏輯，先處理下一個中介軟體的邏輯。

因為每個dispatch，都返回新的 Promsise。所以async會等到 Promise 狀態改變後再回來繼續執行自己的邏輯。

async/await 改寫

最後，在不考慮 koa 的上下文環境的情況下，用 async/await 的提煉出了 compose 函式：

function compose(middleware) {
  return dispatch(0);

  async function dispatch(i) {
    let fn = middleware[i];
    try {
      await fn(dispatch.bind(null, i + 1));
    } catch (err) {
      return err;
    }
  }
}

下面是它的使用方法：

const middleware = [
  async next => {
    console.log("a");
    await next();
    console.log("c");
  },

  async next => {
    console.log("b");
  }
];

compose(middleware); // 輸出a b c

希望最後這段程式碼能幫助理解！

深入koa原始碼（二）：核心庫原理