模块化方案esl以及amd的依赖方式

来自AMD设计思想的总结和思考

• 在之前了解es6模块化的时候有遇到过依赖循环的问题，在es6中对于模块是引用性的，而当时于es6模块化做对比的commonjs(CMD规范)对于模块是值类型(会将其缓存下来)，所以面对循环依赖的时候，利用es6的模块化机制并不会报错。

AMD中依赖的种类

• 装载时依赖，在模块化初始阶段久需要将依赖加载完成

  // 装载时依赖
  define('a',function (require) {
      require('b').init();
  })
  

  这种方式加载模块的时候需要b模块初始化完成才能加载成功，如果b模块也已这种方式依赖于a(或者以装载时依赖的方式构成了一个循环)那么这个循环就是死的(无法成功加载)
• 运行时依赖，在模块初始化的时候不需要，但是在后面运行的时候需要用到，这种依赖就是运行时依赖

  // 运行时依赖
  define('b',function(require)) {
      return {
          foo : require('b').foo();
      }
  }
  

  对于循环依赖，只要其中有一项采用对是运行时依赖则这个循环依赖就是‘合法’的。（这也是requirejs当中提倡的对于循环依赖的解决办法）

依赖提前声明时如何判定依赖方式

我们知道在define中我们可以将以来直接声明到第二个参数里（数组），也可以利用require直接在需要时声明（要将require作为默认参数传给factory），那么当依赖前置的时候我们如何判断依赖方式？在我们在第二个参数声明了依赖之后，通常会将需要的用道（初始化）的模块名当作参数传入factory，当传入的参数个数（length）于第二个参数中数组的length不相等时，我们就会认为它存在运行时依赖。

The dependencies argument is optional. If omitted, it should default to [“require”, “exports”, “module”]. However, if the factory function’s arity (length property) is less than 3, then the loader may choose to only call the factory with the number of arguments corresponding to the function’s arity or length.

• 存在的疑问：什么是「用时定义」，暂时的理解：像commonjs那样，使用模块时进行require然后初始化，但是好像这个想法和异步加载是相悖的，后续再来学习。

为什么使用esl

esl是AMD规范下的一个应用，它是一个浏览器端、符合AMD的标准加载器，适合用于现代Web浏览器端应用的入口与模块管理。

相比于Require：

• 体积更小
• 性能更高
• 更健壮
• 不支持在非浏览器端使用
• 依赖模块「用时定义」（lazy define）

关于esl加载（初始化）模块的方式

前面有提到我们声明依赖的时候有两种方式：

• 在dependencies中声明，然后顺序传入factory中（这里有特别情况）
• 不要dependencies，直接将require作为参数传入factory中，当需要某个模块时直接require进来。

但是这两种方式中模块初始化的时机不同，需要注意：

• 当我们使用第一种方式加载时，esl会像requirejs一样去工作，依赖的模块会提前初始化，但是这里存在一种特殊情况，当我们不完全将dependencies数组中的项传入factory时，esl会这样做

  当factory的形式参数数目少于3时，loader可以根据参数数量的前几个dependencies模块，去call factory。也就是说，dependencies数组里，后面一些模块的初始化时机，是可以自由把握的；在call factory的时候，dependencies数组中位于形式参数length后面index的模块，不一定要初始化完毕。

• 当我们使用第二种方式时，esl会像seajs一样去工作，当我们require一个模块的时候它才会去进行初始化，需要注意的是，如果requirejs以这种方式去加载依赖，它仍然会和原来一样的方式去工作（提前初始化好）。
• 个人感悟：通过了解和学习，个人感觉cmd规范像是amd的一个子集，而requirejs&seajs分别实现了amd规范的一部分，而esl是根据编写的方式决定了初始化方案（按照requirejs还是seajs）。