文章目录

一、前端模块化概要1.1、模块概要1.2、函数封装1.3、对象封装1.4、立即执行函数表达式（IIFE）1.5、模块化规范1.5.1、CommonJS1.5.2、AMD((Asynchromous Module Definition) 异步模块定义1.5.3、CMD（Common Module Definition）通用模块定义1.5.4、UMD

一、前端模块化概要

1.1、模块概要

JavaScript在早期的设计中就没有模块、包、类的概念，开发者需要模拟出类似的功能，来隔离、组织复杂的JavaScript代码，我们称为模块化

模块就是一个实现特定功能的文件，有了模块我们就可以更方便的使用别人的代码，要用什么功能就加载什么模块。

模块化开发的四点好处：

（1）、 避免变量污染，命名冲突

（2）、提高代码复用率

（3）、提高了可维护性

（4）、方便依赖关系管理

1.2、函数封装

我们在讲函数的时候提到，函数一个功能就是实现特定逻辑的一组语句打包，而且JavaScript的作用域就是基于函数的，所以把函数作为模块化的第一步是很自然的事情，在一个文件里面编写几个相关函数就是最开始的模块了

这样在需要的以后夹在函数所在文件，调用函数就可以了

1.3、对象封装

为了解决上面问题，对象的写法应运而生，可以把所有的模块成员封装在一个对象中

var myModule = { var1: 1, var2: 2, fn1: function(){ }, fn2: function(){ } }

这样我们在希望调用模块的时候引用对应文件，然后

myModule.fn2();

这样避免了变量污染，只要保证模块名唯一即可，同时同一模块内的成员也有了关系

缺陷：外部可以随意修改内部成员，这样就会产生意外的安全问题

myModel.var1 = 100;

1.4、立即执行函数表达式（IIFE）

可以通过立即执行函数表达式（IIFE），来达到隐藏细节的目的

var myModule = (function(){ var var1 = 1; var var2 = 2; function fn1(){ } function fn2(){ } return { fn1: fn1, fn2: fn2 }; })();

这样在模块外部无法修改我们没有暴露出来的变量、函数

缺点：功能相对较弱，封装过程增加了工作量、仍会导致命名空间污染可能、闭包是有成本的。

JavaScript最初的作用仅仅是验证表单，后来会添加一些动画，但是这些js代码很多在一个文件中就可以完成了，所以，我们只需要在html文件中添加一个script标签。

后来，随着前端复杂度提高，为了能够提高项目代码的可读性、可扩展性等，我们的js文件逐渐多了起来，不再是一个js文件就可以解决的了，而是把每一个js文件当做一个模块。那么，这时的js引入方式是怎样的呢？大概是下面这样：

<script src="jquery.js"></script> 　　<script src="jquery.artDialog.js"></script> 　　<script src="main.js"></script> 　　<script src="app1.js"></script> 　　<script src="app2.js"></script> 　　<script src="app3.js"></script>

即简单的将所有的js文件统统放在一起。但是这些文件的顺序还不能出错，比如jquery需要先引入，才能引入jquery插件，才能在其他的文件中使用jquery。 优点：

相比于使用一个js文件，这种多个js文件实现最简单的模块化的思想是进步的。

缺点：

污染全局作用域。 因为每一个模块都是暴露在全局的，简单的使用，会导致全局变量命名冲突，当然，我们也可以使用命名空间的方式来解决。

对于大型项目，各种js很多，开发人员必须手动解决模块和代码库的依赖关系，后期维护成本较高。

依赖关系不明显，不利于维护。 比如main.js需要使用jquery，但是，从上面的文件中，我们是看不出来的，如果jquery忘记了，那么就会报错。

1.5、模块化规范

常见的的JavaScript模块规范有：CommonJS、AMD、CMD、UMD、原生模块化

1.5.1、CommonJS

CommonJs 是服务器端模块的规范，Node.js采用了这个规范。

根据CommonJS规范，一个单独的文件就是一个模块。加载模块使用require方法，该方法读取一个文件并执行，最后返回文件内部的exports对象。

// foobar.js //私有变量 var test = 123; //公有方法 function foobar () { this.foo = function () { // do someing ... } this.bar = function () { //do someing ... } } //exports对象上的方法和变量是公有的 var foobar = new foobar(); exports.foobar = foobar; //require方法默认读取js文件，所以可以省略js后缀 var test = require('./foobar').foobar; test.bar();

CommonJS 加载模块是同步的，所以只有加载完成才能执行后面的操作。像Node.js主要用于服务器的编程，加载的模块文件一般都已经存在本地硬盘，所以加载起来比较快，不用考虑异步加载的方式，所以CommonJS规范比较适用。但如果是浏览器环境，要从服务器加载模块，这是就必须采用异步模式。所以就有了 AMD CMD 解决方案。

1.5.2、AMD((Asynchromous Module Definition) 异步模块定义

AMD 是 RequireJS 在推广过程中对模块定义的规范化产出

AMD异步加载模块。它的模块支持对象 函数 构造器 字符串 JSON等各种类型的模块。

适用AMD规范适用define方法定义模块。

//通过数组引入依赖 ，回调函数通过形参传入依赖 define(['someModule1', ‘someModule2’], function (someModule1, someModule2) { function foo () { /// someing someModule1.test(); } return {foo: foo} });

AMD规范允许输出模块兼容CommonJS规范，这时define方法如下：

define(function (require, exports, module) { var reqModule = require("./someModule"); requModule.test(); exports.asplode = function () { //someing } });

1.5.3、CMD（Common Module Definition）通用模块定义

CMD是SeaJS 在推广过程中对模块定义的规范化产出

CMD和AMD的区别有以下几点：

1.对于依赖的模块AMD是提前执行，CMD是延迟执行。不过RequireJS从2.0开始，也改成可以延迟执行（根据写法不同，处理方式不通过）。

2.CMD推崇依赖就近，AMD推崇依赖前置。

//AMD define(['./a','./b'], function (a, b) { //依赖一开始就写好 a.test(); b.test(); }); //CMD define(function (requie, exports, module) { //依赖可以就近书写 var a = require('./a'); a.test(); ... //软依赖 if (status) { var b = requie('./b'); b.test(); } });

1.5.4、UMD

UMD是AMD和CommonJS的综合产物。

AMD 浏览器第一的原则发展 异步加载模块。

CommonJS 模块以服务器第一原则发展，选择同步加载，它的模块无需包装(unwrapped modules)。

这迫使人们又想出另一个更通用的模式UMD （Universal Module Definition）。希望解决跨平台的解决方案。

UMD先判断是否支持Node.js的模块（exports）是否存在，存在则使用Node.js模块模式。

在判断是否支持AMD（define是否存在），存在则使用AMD方式加载模块。

(function (window, factory) { if (typeof exports === 'object') { module.exports = factory(); } else if (typeof define === 'function' && define.amd) { define(factory); } else { window.eventUtil = factory(); } })(this, function () { //module ... });

完整版