背景

分頁是 Web 開發(fā)中常見的功能，基本上所有 Web 框架都有分頁的實(shí)現(xiàn)，或內(nèi)置于框架之內(nèi)，或使用插件的形式。
最近在使用 Egg.js 做后端開發(fā)，由于數(shù)據(jù)庫用的是 MongoDB，所以自然選用官方的 egg-mongoose 作為 ODM Plugin，在開發(fā)過程中恰好就遇到一個分頁問題。

Koa 中的實(shí)現(xiàn)

為了便于理解，首先先講講 Koa 中的實(shí)現(xiàn)。
使用 Koa 框架時直接基于 Mongoose 本身的 Plugin 機(jī)制實(shí)現(xiàn)了一個（大家也可以選擇三方的實(shí)現(xiàn)：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 擴(kuò)展成 Mongoose 模型的一個方法，如：

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

Egg 中的問題

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

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

    const schema = new Schema({
    })

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

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

那么，要是放在所有的 Model 中呢，這樣不就解決問題了嗎？
其實(shí)這樣也不妥，太過冗余，維護(hù)起來也不方便。

所以我們還是有必要找一個全局的地方放置，盡可能保證在 App 初始化階段就能生效，這樣只要服務(wù)處于運(yùn)行狀態(tài)，該插件就必然生效，不會存在 paginate is not a function 的風(fēng)險(xiǎn)

解決問題

仔細(xì)看了一下 Egg 的文檔，發(fā)現(xiàn) Egg 支持啟動時對各種生命周期的自定義（真心贊），應(yīng)該可以解決我們的問題，于是在項(xiàng)目目錄下創(chuàng)建 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

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

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

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

仔細(xì)找了一圈文檔，終于在文檔最下面找到一行字：

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

難道是新舊版本問題？帶著問題繼續(xù)看文檔，哈，果然是因?yàn)?Egg 升級導(dǎo)致的：

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

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

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

  async willReady() {
    // 請將你的應(yīng)用項(xiàng)目中 app.beforeStart 中的代碼置于此處。
  }
}

module.exports = AppBootHook;

后面的事就簡單了，為了在此之前讓分頁插件生效，需要將對應(yīng)的邏輯放在 didLoad 之前的生命周期中，即：configDidLoad，加上相關(guān)代碼

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

大功告成