由于 js 起初定位的原因（刚开始没想到会应用在过于复杂的场景），所以它本身并没有提供模块系统，随着应用的复杂化，模块化成为了一个必须解决的问题。本着菲麦深入原理的原则，很有必要来揭开模块化的面纱
一、模块化需要解决的问题
要对一个东西进行深入的剖析，有必要带着目的去看。模块化所要解决的问题可以用一句话概括
在没有全局污染的情况下，更好的组织项目代码
举一个简单的栗子，我们现在有如下的代码：
我要评论
function dosomething () {
const a = 10;
const b = 11;
const add = function (a + b) {
return a + b
}
add (a + b)
}
在现实的应用场景中，dosomething 可能需要做很多很多的事情，add 函数可能也更为复杂，并且可以复用，那么我们希望可以将 add 函数独立到一个单独的文件中，于是：
// dosomething.js 文件
const add = require('add.js');
const a = 10;
const b = 11;
add(a+ b);
// add.js 文件
function add (a, b) {
return a + b;
}
module.exports = add;
这样做的目的显而易见，更好的组织项目代码，注意到两个文件中的 require 和 module.exports，从现在的上帝视角来看，这出自 commonjs 规范（后文会有一个章节来专门讲规范）中的关键字，分别代表导入和导出，抛开规范而言，这其实是我们模块化之路上需要解决的问题。另外，虽然 add 模块需要得到复用，但是我们并不希望在引入 add 的时候造成全局污染
二、引入的模块如何运行
在上述的例子中，我们已经将代码拆分到了两个模块文件当中，在不造成全局污染的情况下，如何实现 require，才能使得例子中的代码做到正常运行呢？
先不考虑模块文件代码的载入过程，假设 require 已经可以从模块文件中读取到代码字符串，那么 require 可以这样实现
function require (path) {
// lode 方法读取 path 对应的文件模块的代码字符串
// let code = load(path);
// 不考虑 load 的过程，直接获得模块 add 代码字符串
let code = 'function add(a, b) {return a+b}; module.exports = add';
// 封装成闭包
code = `(function(module) {$[code]})(context)`
// 相当于 exports，用于导出对象
let context = {};
// 运行代码，使得结果影响到 context
const run = new function('context', code);
run(context, code);
//返回导出的结果
return context.exports;
}
这有几个要点：
1） 为了不造成全局污染，需要将代码字符串封装成闭包的形式，并且导出关键字 module.exports ，module 是与外界联系的唯一载体，需要作为闭包匿名函数的入参，与引用方传入的上下文 context 进行关联
2） 使用 new function 来执行代码字符串，估计大部分同学对 new function 是不熟悉的，因为一般情况下定义一个函数无需如此，要知道，用 function 类可以直接创建函数，语法如下：
var function_name = new function(arg1, arg2, ..., argn, function_body)
在上面的形式中，每个 arg 都是一个参数，最后一个参数是函数主体（要执行的代码）。这些参数必须是字符串。也就是说，可以使用它来执行字符串代码，类似于 eval，并且相比 eval, 还可以通过参数的形式传入字符串代码中的某些变量的值
3）如果曾经你有疑惑过为什么规范的导出关键字只有 exports 而我们实际使用过程中却要使用module.exports（写过 node 代码的应该不会陌生），那在这段代码中就可以找到答案了，如果只用 exports 来接收 context，那么对 exports 的重新赋值对 context 不会有任何影响（参数的地址传递），不信将代码改成如下形式再跑一跑：
演示结果
三、代码载入方式
解决了代码的运行问题，还需要解决模块文件代码的载入问题，根据上述实例，我们的目标是将模块文件代码以字符串的形式载入
在 node 容器，所有的模块文件都在本地，只需要从本地磁盘读取模块文件载入字符串代码，再走上述的流程就可以了。事实证明，node 非内建、核心、c++ 模块的载入执行方式大体如此（虽然使用的不是 new function，但也是一个类似的方法）
在 rn/weex 容器，要载入一个远程 bundle.js，可以通过 native 的能力请求一个远程的 js 文件，再读取成字符串代码载入即可（按照这个逻辑，node 读取一个远程的 js 模块好像也无不可，虽然大多数情况下我们不需要这么做）
在浏览器环境，所有的 js 模块都需要远程读取，尴尬的是，受限于浏览器提供的能力，并不能通过 ajax 以文件流的形式将远程的 js 文件直接读取为字符串代码。前提条件无法达成，上述运行策略便行不通，只能另辟蹊径
这就是为什么有了 commonjs 规范了，为什么还会出现 amd/cmd 规范的原因
那么浏览器上是怎么做的呢？在浏览器中通过 js 控制动态的载入一个远程的 js 模块文件，需要动态的插入一个 <script> 节点：
// 摘抄自 require.js 的一段代码
var node = config.xhtml ?
document.createelementns('http://www.w3.org/1999/xhtml', 'html:script') :
document.createelement('script');
node.type = config.scripttype || 'text/javascript';
node.charset = 'utf-8';
node.async = true;
node.setattribute('data-requirecontext', context.contextname);
node.setattribute('data-requiremodule', modulename);
node.addeventlistener('load', context.onscriptload, false);
node.addeventlistener('error', context.onscripterror, false);
要知道，设置了 <script> 标签的 src 之后，代码一旦下载完成，就会立即执行，根本由不得你再封装成闭包，所以文件模块需要在定义之初就要做文章，这就是我们说熟知的 amd/cmd 规范中的 define，开篇的 add.js 需要重新改写一下
// add.js 文件
define ('add'，function () {
function add (a, b) {
return a + b;
}
return add;
})
而对于 define 的实现，最重要的就是将 callback 的执行结果注册到 context 的一个模块数组中：
context.modules = {}
function define(name, callback) {
context.modules[name] = callback && callback()
}
于是 require 就可以从 context.modules 中根据模块名载入模块了，是不是有了一种自己去写一个 “requirejs” 的冲动感
具体的 amd 实现当然还会复杂很多，还需要控制模块载入时序、模块依赖等等，但是了解了这其中的灵魂，想必去精读 require.js 的源码也不是一件困难的事情
四、webpack 中的模块化
webpack 也可以配置异步模块，当配置为异步模块的时候，在浏览器环境同样的是基于动态插入 <script> 的方式载入远程模块。在大多数情况下，模块的载入方式都是类似于 node 的本地磁盘同步载入的方式
嫑忘记，webpack 除了有模块化的能力，还是一个在辅助完善开发工作流的工具，也就是说，webpack 的模块化是在开发阶段的完成的，使用 webpack 构筑的工作环境，在开发阶段虽然是独立的模块文件，但是在运行时，却是一个合并好的文件
所以 webpack 是一种在非运行时的模块化方案（基于 commonjs），只有在配置了异步模块的时候对异步模块的加载才是运行时的（基于 amd）
五、模块化规范
通用的问题在解决的过程中总会形成规范，上文已经多次提到 commonjs、amd、cmd，有必要花点篇幅来讲一讲规范
js 的模块化规范的萌发于将 js 扩展到后端的想法，要使得 js 具备类似于 python、ruby 和 java 那样具备开发大型应用的基础能力，模块化规范是必不可少的。commonjs 规范的提出，为js 制定了一个美好愿景，希望 js 能在任何地方运行，包括但不限于：
commonjs 对模块的定义并不复杂，主要分为模块引用、模块定义和模块标识
模块示意
commonjs 规范在 node 中大放异彩并且相互促进，但是在浏览器端，鉴于网络的原因，同步的方式加载模块显然不太实用，在经过一段争执之后，amd 规范最终在前端场景中胜出（全称 asynchronous module definition，即“异步模块定义”）
什么是 amd，为什么需要 amd ？在前述模块化实现的推演过程中，你应该能够找到答案
除此之外还有国内玉伯提出的 cmd 规范，amd 和 cmd 的差异主要是，前者需要在定义之初声明所有的依赖，后者可以在任意时机动态引入模块。cmd 更接近于 commonjs
两种规范都需要从远程网络中载入模块，不同之处在于，前者是预加载，后者是延迟加载
五、总结
如果有心，可以参照本文的推演，来实现一个 “yourrequirejs”，没有什么比重复造轮子更能让知识沉淀~~
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持移动技术网。
如对本文有疑问， 点击进行留言回复！！
Android 入门第七讲01-数据存储（数据存储概述，文件存储（raw和asserts目录读写，data/data/包名目录读写，sdcard目录读写），SharedPreferences读写）
vue-axios系列:axios拦截器，配置请求头，配置请求参数
Vuejs 针对 安卓低版本 、ios9.x 不兼容 ES6语法导致失效解决方法
网友评论