Egg.js 中基於 Mongoose 的分頁

背景

分頁是 Web 開發中常見的功能，基本上所有 Web 框架都有分頁的實現，或內置於框架之內，或使用插件的形式。
最近在使用 Egg.js 做後端開發，由於數據庫用的是 MongoDB，所以自然選用官方的 egg-mongoose 作爲 ODM Plugin，在開發過程中恰好就遇到一個分頁問題。

Koa 中的實現

爲了便於理解，首先先講講 Koa 中的實現。
使用 Koa 框架時直接基於 Mongoose 本身的 Plugin 機制實現了一個（大家也可以選擇三方的實現：mongoose-paginate-v2）
分頁 Plugin 使用起來也很方便，在 Mongoose 初始化時加載該 Plugin 即可：

const mongoose = require('mongoose')
const config = require('config')
const paginate = require('../middlewares/paginate')

// 啓用分頁插件
mongoose.plugin(paginate)

mongoose.connect(config.get('db'), { useNewUrlParser: true })
mongoose.Promise = global.Promise
const db = mongoose.connection

這樣全局的 Model 中都可以使用此 Plugin，即：將 paginate 擴展成 Mongoose 模型的一個方法，如：

const apps = await AppModel.paginate({}, {page})

Egg 中的問題

在 Egg 中，由於使用了 egg-mongoose 插件，所以初始化過程已經被插件本身處理過了，那麼如果想讓插件生效，可以直接在對應的 Model 中增加：

module.exports = app => {
    const mongoose = app.mongoose
    // 啓用分頁插件
    mongoose.plugin(paginate)
    const Schema = mongoose.Schema

    const schema = new Schema({
    })

    return mongoose.model('App', schema);
}

這麼邏輯上是沒有問題的，也能夠全局生效，但是當有多個 Model時，加載 Plugin 的邏輯到底放在哪個 Model 中合適呢？
貌似放在哪個都不合適，畢竟這是個全局的設置，萬一加載 Plugin 的 Model 廢棄了，如果忘記將此邏輯遷移的話，就會造成一個 Bug，時間一長排查起來就比較麻煩。

那麼，要是放在所有的 Model 中呢，這樣不就解決問題了嗎？
其實這樣也不妥，太過冗餘，維護起來也不方便。

所以我們還是有必要找一個全局的地方放置，儘可能保證在 App 初始化階段就能生效，這樣只要服務處於運行狀態，該插件就必然生效，不會存在 paginate is not a function 的風險

解決問題

仔細看了一下 Egg 的文檔，發現 Egg 支持啓動時對各種生命週期的自定義（真心贊），應該可以解決我們的問題，於是在項目目錄下創建 app.js 文件：

class AppBootHook {
    constructor(app) {
        this.app = app;
    }

    configWillLoad() {
        // Ready to call configDidLoad,
        // Config, plugin files are referred,
        // this is the last chance to modify the config.
    }

    configDidLoad() {
        // Config, plugin files have been loaded.
    }

    async didLoad() {
        // All files have loaded, start plugin here.
    }

    async willReady() {
        // All plugins have started, can do some thing before app ready
    }

    async didReady() {
        // Worker is ready, can do some things
        // don't need to block the app boot.
    }

    async serverDidReady() {
        // Server is listening.
    }

    async beforeClose() {
        // Do some thing before app close.
    }
}

module.exports = AppBootHook

看着這麼多生命週期，新的問題再此出現：Mongoose 的 Plugin 應該放在哪個生命週期中呢？
一個個試太不科學了，要想解決此問題，勢必需要了解 egg-mongoose 的初始化過程，所以直接看源碼：
源碼很簡單，大概掃了一眼就找到如下行：

app.beforeStart(() => {
  loadModelToApp(app);
});

嗯，原來是在 beforeStart 方法中將 Model 們加載到 App 中的。
所以只要在 beforeStart 之前加載 Plugin 即可全局生效，但是上面的生命週期類貌似沒有 beforeStart 方法，倒是有一個 beforeClose 方法。

仔細找了一圈文檔，終於在文檔最下面找到一行字：

如果你的 Egg 框架的生命週期函數是舊版本的，建議你升級到類方法模式；詳情請查看升級你的生命週期事件函數。

難道是新舊版本問題？帶着問題繼續看文檔，哈，果然是因爲 Egg 升級導致的：

// app.js 或 agent.js 文件：
class AppBootHook {

  constructor(app) {
    this.app = app;
  }

  async didLoad() {
    // 請將你的插件項目中 app.beforeStart 中的代碼置於此處。
  }

  async willReady() {
    // 請將你的應用項目中 app.beforeStart 中的代碼置於此處。
  }
}

module.exports = AppBootHook;

後面的事就簡單了，爲了在此之前讓分頁插件生效，需要將對應的邏輯放在 didLoad 之前的生命週期中，即：configDidLoad，加上相關代碼

const paginate = require('./app/middleware/paginate')
class AppBootHook {
    constructor(app) {
        this.app = app;
    }

    configWillLoad() {
        // Ready to call configDidLoad,
        // Config, plugin files are referred,
        // this is the last chance to modify the config.
    }

    configDidLoad() {
        // Config, plugin files have been loaded.
        const mongoose = this.app.mongoose
        mongoose.plugin(paginate)
    }
    ...
}

module.exports = AppBootHook

大功告成