JS 异步插件系统方案研究

在我们开发设计的 js 项目中,我们经常会设计一套插件系统,用以可选的加载某些功能模块,在使用时,需要某个功能,就加载对应的插件。以 jquery 举例,它的插件生态极其丰富,要使用一个 jquery 插件非常简单,只需要引入 jquery 再引入 jquery 插件,就可以利用插件提供的功能了。插件提供的功能可能是增加了一个事件绑定,或者提供了新的 $  方法,等等。总之,你不需要插件,你就不需要加载该插件,而你一旦加载一个插件,就必须按照插件作者提供的文档来写代码。

我们这篇文章并不详细阐述,什么样的一个插件系统是好的插件系统(起码我认为 jquery 的插件系统就非常优秀)。我们这篇文章要来阐述一个插件的异步方案。

什么是异步插件?

首先,我们要指明,怎样的一种行为方式是异步插件。以及,我们为什么需要异步插件。

像 jquery 加载插件那样未尝不可,但直接从 cdn 引入插件会阻塞浏览器渲染。而且 2020 年的前端,避不开构建、打包等等工程化过程。异步插件解决减小 bundle 文件的问题,同时,由于异步加载,因此,也不会阻塞界面渲染。带来的问题就比较复杂,如何异步渲染,并且同时能够按需要的顺序执行。

对于插件的使用者而言,更关注这个异步插件的 cdn 地址,以及插件的使用方法。我们用代码来看下具体的情况是怎么样的。来看下一个同步插件:

<script src="my-lib.min.js"></script>
<script src="my-lib.some-plugin.min.js"></script>
<script>
const myLib = new MyLib()
// some 这个方法是加载了 some-plugin 之后才有的
myLib.some()
</script>

同步插件的问题在于会阻塞渲染,在加载插件的时候,界面渲染会阻塞,而且如果插件文件执行过程中出了问题,报错了,还会导致所有的脚本都无法执行,最终导致应用坏死。而我们来看下异步插件:

<script src="my-lib.min.js"></script>
<script>
MyLib.registerPlugin('some-plugin', 'http://cdn.xxx.com/some-plugin.min.js') // 这句话将会自动去 cdn 异步加载插件

const myLib = new MyLib()
myLib.usePlugin('some-plugin', function() {
  // 异步插件由于异步加载,所以不能立即在程序中去调用 some 方法,而是必须在插件加载完成之后才能做这件事
  this.some()
})
</script>

异步插件会有一些局限性。包括但不限于:

  • 由于是异步加载的,所以实例化的时候,插件可能还没有加载呢,所以插件所提供的功能都还没有加载完成,因此,在编程上和同步调用会有一些不同
  • 如果一个项目,需要通过异步的方式加载插件,那么项目本身的代码会变得更复杂
  • 异步插件存在依赖关系怎么办?例如 A 插件依赖 B 插件,怎么解决执行顺序问题?

对于插件开发者的心智是一个挑战,我们需要找到更好的异步加载方案,和写代码的正确方式,这样才能保证开发者用最简单的方式开发插件。所以本文接下来,就要探讨一下,怎样的 js 插件系统的异步加载方案更优秀,更值得我们推崇。

异步插件加载方式

我们将异步加载插件分解为两个问题:1)如何异步加载 js 脚本?2)如何在该脚本中定义插件?

异步加载脚本

异步加载脚本的方式有很多。总结起来主要分为 3 大类:一类是通过创建 script DOM 实例的 src 实现脚本加载;二类是通过 xhr 获取脚本内容,再在当前环境中运行脚本内容;三类是通过创建 iframe 来实现同于脚本运行。这些知识可以通过搜索引擎来学习。

我们应该如何选择呢?我们想到的原则是,既要保证插件系统本身的代码量不要太大,也要保证最终插件的使用者代码写起来不别扭(学习成本低)。之所以带来学习成本,最大的问题在于“异步”所带来的副作用。插件脚本在加载完时,我们很有可能已经完成自己类库的实例化,甚至有些情况下已经做了很多事。然后,在做这些事情的时候,我们可能会忽略插件还没有加载完。而另一方面,如果等到插件加载完再执行所有代码,那会使得实例化过程变得非常漫长,导致错过一些重要时间节点上的操作。

在我自己的实践中,我选择了通过 script.src 来加载脚本的方式,这种方式中,需要设置 script.async 属性为 true,甚至为了兼容,同时设置 script.defer 属性为 true。在 onload 中,通知插件系统,该插件加载好了,需要做一些处理。

插件的定义

作为插件,而非类库的主要部分,它只是将自己的功能附加到主库中去。如何将插件插入主库的功能列表中呢?这需要一个合理的设计。

实际上,我们需要很简单的一个操作。例如 MyLib.addPlugin(plugin) 即可,其中的操作由开发者自己去想象。现在的问题是,作为插件的开发者,我们应该怎么去定义一个插件?在异步加载过程中,我们可能会有一些需求,例如,我们当前这个插件需要依赖另外一个插件,但是由于插件是异步加载的,所以对于当前这个插件而言,并不能保证被依赖的插件已经加载好了。所以,我们需要有一个依赖列表,用来表示自己所依赖的其他插件。在真正运行的时候,插件系统,应该保证,该插件的依赖被运行之后,才运行当前这个插件。

既然提到了“依赖”,那就不得不说新晋的前端开发者不知道的 AMD 模块加载规范。遵循 AMD 的 require.js 曾经流行一时,它通过约定模块加载路径,从而使得加载的内容可以根据需要实现 lazyload(这个词大家应该都懂)。而 AMD 规范中,规定了一个模块定义的方法,最主要的用法是

define(name: string, dependencies: string[], function(...deps: any[]): any {
  // ...
  return exports
})

通过这样一个 define 函数来定义一个模块,其中 define 的第二个参数,就是告诉 require.js 当前这个模块需要依赖哪些模块,在运行当前这个模块之前,要确保 dependencies 这些模块已经运行过了。对于 require.js 而言,在运行当前这个模块时,会自动检查依赖,如果依赖没有准备好,required.js 会按照自己的模块加载机制,先加载被依赖的模块(加载模块脚本,同时运行模块函数),然后才运行当前这个模块。而在加载依赖时,模块会并行加载和运行(当然,如果依赖内部还有依赖,它也会安装依赖顺序进行执行,但可以肯定的是,模块脚本的加载是并行的)。

AMD 方案不能说最好,但是却非常适用我所面临的问题——如何高效合理的加载异步插件。

因此,最终,我选择了类似 AMD 这样的模块定义方案来定义我们的插件:

MyLib.defineAsyncPlugin('some', [], function() {
  // 和 AMD 不同,插件的模块函数并非全局执行,而是针对每一个 MyLib 实例运行,所以,在本函数内,插件作者可以调用 this 来指向 MyLib 的实例
  this.some = function() {
    console.log('some is invoked')
  }
})

这样,对于一个 MyLib 的实例而言,就拥有了一个 some 方法。

这里需要有一个更深入的理解。我们的插件虽然在 MyLib 上定义,但是定义的时候,并不执行插件函数,而是被记录在 MyLib 内部,真正拥有插件能力的,是 MyLib 的实例 myLib。这样设计和 require.js 的巨大差别在于,require.js 是模块系统,本身就是在全局执行,每一个模块在加载的时候,就需要执行模块函数,而插件则不同,插件是要提供功能,而这些功能,往往都是针对实例,因此,它不是全局执行,而是在实例化时执行。

定义一个插件只是提供了它的定义,并不立即运行它。真正的运行是在实例中,这样才能保证实例拥有插件提供的方法。

异步插件的注册和使用

和 jquery 插件一样,我们要先注册插件,然后才能使用它。但是和同步加载插件不同,我们不能马上加载和运行异步插件文件,这样会阻塞进程,达不到我们要的效果。我们得使用一种合理的方法来注册插件,这样技能不阻塞界面渲染,同时又能得到想要的效果。

插件的注册

为什么要先注册再使用呢?为什么不直接在使用的时候自动注册呢?就像 require.js 一样,使用的时候自己去加载,加载完马上使用。这样做未尝不可以,例如,我们用一段伪代码来表示:

const myLib = new MyLib()
myLib.useAsyncPlugin(url).then(function() {
  this.some()
})

这样的代码非常简洁,甚至你会觉得这才是正解。

但是,想象一下,你的系统中可能存在多个 MyLib 的实例。那是不是意味着每一个实例都要传入 url 进行加载?其实这个加载是没有必要的,因为同一个 script 脚本被加载之后,没有必要再去运行第二次,否则每次使用一个插件都要走加载+执行两个步骤,严重拖长了执行时间。

我最终选择的方式是,你需要在全局注册需要的插件,在实例上,使用这些插件即可。

MyLib.registerPlugin(url)

const myLib = new MyLib()
myLib.usePlugin('some', options)

这样的好处是,同一个插件,一旦完成加载和注册,那么就不需要再进行第二次加载。对于实例而言,可以在最快的时间,进入插件的执行阶段,从而拥有该插件提供的功能。

插件的使用

但是,一定要记住,插件的加载和执行都是异步的。为什么执行也是异步的呢?比如上面的代码中 myLib.usePlugin('some', options) 并不能在执行当前这一句代码的时候,就真正执行插件的定义函数,而是要等待插件加载完之后才会执行。为什么?因为我们在调用 usePlugin 的时候,这个插件可能还没有加载完呢。

而且,我们的一些操作,必须等到插件加载执行完之后才去运行,因此,我们需要将我们的程序分段执行,例如:

myLib.usePlugin('some', options, function() {
  this.some()
})

这段代码的意思是,当插件 some 已经准备好(加载完,并执行完)之后,执行回调函数中的内容。通过传入一个回调函数,表示当插件真正加载完之后再运行这个函数,而在这个函数内部,可以使用 this 表示当前这个实例。但是,在一些情况下,我们可能需要同时等待多个插件加载完之后,才运行某个回调。我们可以这样子:

myLib.onPlugin(['a', 'b'], function() {
  this.a()
  this.b()
})

由于异步的加载和执行,给我们的插件使用带来了麻烦,但是这就是代价,异步编程让我们没有那么方便的使用按照同步思维进行。不过,为了更好的符合我们的编程习惯,我们可以设计成 async/await 的模式。

;(async function() {
  const myLib = new MyLib()

  await myLib.usePlugin('some', options) // 使用 await 等待插件加载和执行完
  await myLib.usePlugin('plugin2', options)

  myLib.some()
  myLib.b()
})()

我们将异步插件系统设计为返回一个 Promise,这样就可以使用 async/await 进行编程,当然,这也不是必须的选择。

插件的命名

一个问题是,我们让插件开发者命名自己的插件,还是让插件的使用者在注册插件时命名插件?这里需要关心的一个问题是,如果两个插件的开发者使用了相同的插件名,而插件的使用者可能同时需要这两个插件。因此,我更倾向让插件的使用者给插件命名。

然而,这也会带来一些副作用。实际上,我们使用异步插件的目的,是希望减小项目本身的打包代码,加快代码初始化速度。但是,倘若我们给了插件使用者更多选择,那么势必我们的目的会遭受调整,项目的代码可能会由于这些逻辑,多出一些原本可能不必要的逻辑代码。这是取舍两难的话题。

为了和 AMD 契合,我最终选择了让插件的开发者来定义自己的插件名字。

让插件开发者定义插件的名字,这样,一个插件拥有什么名字,就是固定的了。这样的好处非常多,除了可能的命名冲突之外,全是好处。当然,作为插件系统,最好对该命名有一个规范要求,例如要求插件名有一个 scope,这样就可以通过 scope 来区分不同开发者提供的不同插件。

而且,这样的更大的好处在于,对依赖的确定更加有利。插件的开发者可以非常明确,自己的插件是依赖哪一个插件的,这个插件在当前插件中运行起来没有任何问题。但假如插件名不是有插件开发者自己规定,而是插件使用者在自己系统中动态规定,那么就会导致当前这个插件完全不知道自己该使用什么样的依赖,以及是否正确加载了依赖的插件。

而且,这样的好处还在于,可以更大限度的节省项目初始化脚本文件的大小,让插件可以容纳更多代码,从而达到我们异步加载的目的。

插件预处理

在一些使用场景中,插件还会尝试在加载之前收集一些信息,加载结束的时候利用这些信息进行下一步操作。因此,插件的注册,还需要安装一定的方式进行重新设计。在同步任务中,插件需要收集数据,如下:

MyLib.registerPlugin({
  url, // 插件的 url
  options, // 插件的基础参数,后续启用插件时所传入的参数会和这个 options 进行合并
  onReady, // 插件注册完成之后立即运行的函数
  onInit, // 实例化时运行的函数,支持 this
  onLoad, // 插件加载完成时运行的函数
  onPlugin, // 插件函数被调用后运行的函数,支持 this
  onDestroy, // 实例销毁时运行的函数
})

通过这样的配置,可以更全面的控制插件。在 onReady 和 onInit 中,可以进行一些数据收集。对于插件的作者而言,不需要再暴露 url 给插件的使用者,而是直接提供一个封装好的 js 模块给使用者调用。例如:

import SomePlugin from './some-plugin.js'
MyLib.registerPlugin(SomePlugin)

而这个 some-plugin.js 的实际内容可能是:

let count = 0
const SomePlugin = {
  url,
  onInit() {
    this.count = count
    count ++
  }
}

这个插件的作用,就是在实例上面添加了一个 count 属性,而这个 count 属性,正好在我们的插件的定义函数中使用。总之,这种方式帮助插件的开发者更好的做一些处理。

插件注册的实现

这一节,我们用实际的代码来实现异步插件的加载。前文实际上已经分析过了,我们可以使用 script 标签来做异步加载,只需要开启 script.async 属性即可,这也是为什么我们不使用 xhr + script.text 的原因,因为使用 script.text 是同步执行的,也就是说,插件的内容会在当前线程环境中立即执行。因此,我们使用 src 来实现更好。

让我们回到真实的场景中,对于用户而言,可能是这样使用插件:

<!DOCTYPE html>
<head>
  <script src="http://cdn.xxx.com/my-lib.min.js"></script>
  <script>
    MyLib.registerPlugin('http://cdn.xxx.com/plugins/@tomy/touch.min.js')
    MyLib.registerPlugin('http://cdn.xxx.com/plugins/@pony/touch.min.js') // 虽然插件名相同,但是 scope 不同
  </script>
</head>

我们来实现这个 registerPlugin 方法:

MyLib._instances = []
MyLib._plugins = []
MyLib.registerPlugin = function(def) {
  // 如果是直接传入 url
  if (typeof def === 'string') {
    def = { url: def }
  }
  
  const { url, required, options, onReady, onInit, onPlugin, onLoaded, onDestroy } = def
  const id = 'plugin' + Math.random()
  
  const plugin = {
    id,
    required,
    options,
    onInit,
    onPlugin,
    onDestroy
  }

  if (typeof onReady === 'function') {
    onReady()
  }

  const script = document.createElement('script')
  script.async = true
  script.defer = true
  script.id = id
  script.src = url
  script.onload = () => {
    if (typeof onLoad === 'function') {
      onLoad()
    }

    // 决定依赖关系,并按依赖关系排序
    this._plugins.sort((a, b) => {
      const aName = a.name
      const aDeps = a.deps
      const bName = b.name
      const bDeps = b.deps
      
      if (aDeps.includes(bName)) {
        return -1
      }
      else if (bDeps.includes(aName)) {
        return 1
      }
      else {
        return 0
      }
    })

    MyLib._instances.forEach((mylib) => {
      // TODO: 当一个插件加载之后,要去检查所有实例是否已经使用了插件,如果使用了插件,就直接启用插件
      mylib._runPlugins()
    })
  }

  this._plugins.push(plugin)
}

对于插件的开发者而言,要在异步脚本中使用 MyLib.defineAsyncPlugin 来定义插件,他可能这么写:

MyLib.defineAsyncPlugin('@someone/count', [], function() {
  console.log(this.count)
})

那么,这个 defineAsyncPlugin 怎么实现呢?

MyLib.defineAsyncPlugin = function(name, deps, define) {
  const id = document.currentScript.id
  const plugin = this._plugins.find(item => item.id === id)
  if (!plugin) {
    return
  }

  Object.assign(plugin, {
    name,
    deps,
    define,
  })
}

这样,当开发者在自己的项目中注册了这个插件,就可以正常的加载到项目系统中了。而且,我们还有一个 runPlugins 的方法,这个方法会去检查所有实例上应该被执行的插件。当然,如果这些插件的依赖没有执行完,那么它们自己本身也不会被执行。

插件启用的实现

我们已经完成了插件的注册,那么,接下来,我们在实例中启用这个插件,会遇到哪些需要解决的问题呢?启用插件因为是在实例上进行,因此它有两种选择,一种是为实例的初始化参数设计一个配置选项,另一种是使用方法发起命令。而在使用配置参数时,实际上也可以是调用发起命令完成的。因此,我们需要定义发起调用插件的方法:

class MyLib {
  _pluginQueue = []
  _pluginModules = {}

  constructor(options = {}) {
    const { plugins } = options
    if (plugins) {
      const names = Object.keys(plugins)
      names.forEach((name) => {
        const options = plugins[name]
        this.usePlugin(name, options)
      })
    }

    MyLib._instances.push(this)
  }
  
  usePlugin(name, options = {}) {
    // 实际上,代码非常非常简单,就是将该插件的启用信息,加入到一个队列中
    this._pluginQueue.push({ name, options })
    this._runPlugins()
    return this
  }

  onPlugin(names, fn) {
    if (typeof names === 'string') {
      names = [names]
    }

    this._pluginQueue.push({ names, fn })
    this._emitPlugins()
  }

  // 这个方法用于检查全部的插件是否已经被运行,如果没有被运行,那么根据其依赖,执行它
  _runPlugins() {
    const queue = this._pluginQueue
    const modules = this._pluginModules
    const plugins = MyLib._plugins
    
    if (!Object.keys(queue).length) {
      return
    }

    plugins.forEach((plugin) => {
      const { name, deps, define, onPlugin, options: basicOptions } = plugin
      if (name in modules) {
        return
      }

      const request = queue.find(item => item.name === name)
      if (!request) {
        return
      }

      // 检查所有依赖是否已经加载好了
      if (deps.find(item => !(item in modules)) {
        return
      }

      // 记录真正的 options
      const requestOptions = request.options
      const options = { ...basicOptions, ...requestOptions }

      const injects = deps.map(item => item === '$options' ? options : modules[item])
      const module = define.apply(this, injects)
      modules[name] = module
      
      if (typeof onPlugin === 'function') {
        onPlugin.call(this, module)
      }

      this._emitPlugins()
    })
  }

  _emitPlugins() {
    const queue = this._pluginQueue
    const modules = this._pluginModules
    queue.forEach((item) => {
      if (item.done || !item.names) {
        return
      }
      if (item.names.find(name => !modules[name])) {
        return
      }
      item.fn.call(this)
      item.done = true
    })
  }
}

这样,插件的使用者,就可以使用我们提供的这些方法,启动插件,使得当前这个实例,拥有插件提供的功能。

<script>
const myLib = new MyLib()
myLib.usePlugin('@tomy/touch')
  .usePlugin('@pony/touch', { debounce: 2000 })
  .onPlugin(['@tomy/touch', '@pony/touch'], function() {
    this.on('touch', e => console.log(e))
    this.touch()
  })
</script>

我们没有实现 async/await 方案,因为这样又会多出一些代码,我们尽可能的减少代码量。

结束语

本文分析并实现了一个异步插件系统的骨架方案,这个异步插件系统立足于“类-实例”的结构方式,而非单例模式,因此设计上会比单例模式的系统更麻烦一些。回到文章开头,我们这样做的目的,是为了将一些插件拆分出来,根据实际的需要来定制需要加载的脚本,从而减少页面初始脚本的大小,以及初始执行所占用的时间。但这也不可避免的带来了编程上的一些麻烦。有舍才有得,这不一定是最好的方案,更不是放之四海而皆准的方案,只有在你的项目需要通过这种方式加载更有利的情况下,才使用这种方案,才是正确的选择。

2020-01-12 83 ,

为价值买单

本文价值0.83RMB