模块化方案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）。