前言
模块化是什么?有什么作用?对于一个前端新人来说为什么要学习模块化?我相信这样的疑问一定会出现在很多小白的脑海中。可能有人会像,不学怎么通过面试啊,不学哪里找的到工作呀,这样的思想是错误的,不要为了学习而学习,既然我们已经决定从事前端工程师这一职业,那么就必须为了成为一门合格的前端而努力。不仅学习前端模块化是如此,学习其他知识也是如此。
一.模块化的前世
为什么需要模块化?
你如果和十年前或者甚至3年前的前端说,项目需要用模块化,那么你可能会遭到嘲笑,因为在那个时候的前端工程师的任务并像今天一样如此的繁杂,这也对应了JS出现的意义,那就是实现简单的页面交互逻辑。而随着科技的发展以及技术的不断迭代更新。浏览器的性能得到了极大的提升,电脑CPU的处理能力也越来越强,更甚的是层出不穷的前端库以及框架的出现使得前端代码日益膨胀。这个时候前端工程师就不得不去想办法来组织这些代码,不然整个程序的前端代码看起来会显得杂乱无章,更别说维护了。
什么是模块化?
- 模块化就是将一个复杂的程序按照一定的规则封装成几个块,并组合到一起。
- 块的内部数据与实现是私有的,只是向外暴露一些接口与外部模块进行通信。
模块化的前世
全局function模式:将不同的功能封装成不同的全局函数
- 模块化的最早雏形是在全局定义一个个函数以实现一个个不同的功能
- 缺点:
- 污染全局变量,容易引起变量冲突
- 数据容易被修改不安全
- 模块之间看不出直接联系
function add(){
//...
}
function delete(){
//...
}
namespace模式 : 简单对象封装
既然全局function模式会污染全局变量,那么我将这些函数都放在一个对象中进行管理不就行了。
- 优点:解决了污染全局变量的问题。
- 缺点:
- 数据依然不安全容易被修改(外部可以直接修改内部数据)
let myModule = {
data: 'www.baidu.com',
foo() {
console.log(`foo() ${this.data}`)
},
bar() {
console.log(`bar() ${this.data}`)
}
}
myModule.data = 'other data' //能直接修改模块内部的数据
myModule.foo() // foo() other data
这样的写法会暴露所有模块成员,内部状态可以被外部改写。
IIFE模式:匿名函数自调用(闭包)
我猜大家其实在看到模块化的定义时就想到了闭包吧。是的,为了不让内部状态被轻易改写,使用闭包来实现代码封装。
- 优点:数据私有化,外部只能通过暴露的方法进行操作
- 缺点:
- 这样做虽然使得外部无法修改内部数据但是同时也无法体现模块与模块之间的联系。
// index.html文件
<script type="text/javascript" src="module.js"></script>
<script type="text/javascript">
myModule.foo()
myModule.bar()
console.log(myModule.data) //undefined 不能访问模块内部数据
myModule.data = 'xxxx' //不是修改的模块内部的data
myModule.foo() //没有改变
</script>
// module.js文件
(function(window) {
let data = 'www.baidu.com'
//操作数据的函数
function foo() {
//用于暴露有函数
console.log(`foo() ${data}`)
}
function bar() {
//用于暴露有函数
console.log(`bar() ${data}`)
otherFun() //内部调用
}
function otherFun() {
//内部私有的函数
console.log('otherFun()')
}
//暴露行为
window.myModule = { foo, bar } //ES6写法
})(window)
最后得到的结果:
IIFE模式增强 : 引入依赖
现代模块化的基石,解决之前无法体现模块与模块之间联系的方式就是引入依赖。
// module.js文件
(function(window, $) {
let data = 'www.baidu.com'
//操作数据的函数
function foo() {
//用于暴露有函数
console.log(`foo() ${data}`)
$('body').css('background', 'red')
}
function bar() {
//用于暴露有函数
console.log(`bar() ${data}`)
otherFun() //内部调用
}
function otherFun() {
//内部私有的函数
console.log('otherFun()')
}
//暴露行为
window.myModule = { foo, bar }
})(window, jQuery)
// index.html文件
<!-- 引入的js必须有一定顺序 -->
<script type="text/javascript" src="jquery-1.10.1.js"></script>
<script type="text/javascript" src="module.js"></script>
<script type="text/javascript">
myModule.foo()
</script>
上例子通过jquery方法将页面的背景颜色改成红色,所以必须先引入jQuery库,就把这个库当作参数传入。这样做除了保证模块的独立性,还使得模块之间的依赖关系变得明显。
当前模块化的好处
从上面的发展史可以看出模块化有以下好处
- 避免命名冲突
- 更好的分离,按需加载
- 更高的复用性
- 更好的维护性
当前模块化的缺点
可以看出我们现在要实现模块化就不得不通过script引入多个的外部依赖。当项目变得更大时,显然这样是会出现问题的。
- 请求过多
首先我们要依赖多个模块,那样就会发送多个请求,导致请求过多
- 依赖模糊
我们不知道他们的具体依赖关系是什么,也就是说很容易因为不了解他们之间的依赖关系导致加载先后顺序出错。
- 难以维护
以上两种原因就导致了很难维护,很可能出现牵一发而动全身的情况导致项目出现严重的问题。 模块化固然有多个好处,然而一个页面需要引入多个js文件,就会出现以上这些问题。而这些问题可以通过模块化规范来解决,下面介绍开发中最流行的commonjs, AMD, ES6, CMD规范。
二.模块化的今生
现在实现前端模块化一般都是通过某种模块化规范。目前比较知名的前端模块化规范有CommonJS,AMD,CMD以及ES6,模块化。
我们依旧按照层层递进的方法来解释这些模块化规范。
CommonJS
相信接触过node的同学一定知道,node应用的模块化就是CommonJS规范。webpack也是如此。
概述
在CommonJS规范中。
- 一个文件就是一个模块,有自己的作用域。
- 在一个文件里面定义的变量、函数、类,都是私有的,对其他文件不可见
- 在服务器端,模块的加载是运行时同步加载的;在浏览器端,模块需要提前编译打包处理。
特点
- 所有代码都运行在模块作用域,不会污染全局作用域。
- 模块可以多次加载,但是只会在第一次加载时运行一次,然后运行结果就被缓存了,以后再加载,就直接读取缓存结果。要想让模块再次运行,必须清除缓存。
- 模块加载的顺序,按照其在代码中出现的顺序。
基本语法
- 暴露模块:
module.exports = value或exports.xxx = value - 引入模块:
require(xxx),如果是第三方模块,xxx为模块名;如果是自定义模块,xxx为模块文件路径
知其然还要知其所以然,那么这个module和export究竟代表什么呢?
CommonJS内部规定,每个模块内部module代表当前变量,这个变量是当前对象。它的exports是当前变量的属性表示向外暴露的接口。加载某个模块实际是在加载这个模块的module.exports属性。
// example.js
var x = 5;
var addX = function (value) {
return value + x;
};
module.exports.x = x;
module.exports.addX = addX;
上面代码通过module.exports输出变量x和函数addX。
var example = require('./example.js');//如果参数字符串以“./”开头,则表示加载的是一个位于相对路径
console.log(example.x); // 5
console.log(example.addX(1)); // 6
require命令用于加载模块文件。require命令的基本功能是,读入并执行一个JavaScript文件,然后返回该模块的exports对象。如果没有发现指定模块文件,会报错。
模块加载机制‘
在CommonJS规范中,输入值是被输出值的拷贝。也就是说,一旦输入一个值,模块内部的变化不会再影响这个值了。
上面代码输出内部变量counter和改写这个变量的内部方法incCounter。
// main.js
var counter = require('./lib').counter;
var incCounter = require('./lib').incCounter;
console.log(counter); // 3
incCounter();
console.log(counter); // 3
上面代码说明,counter输出以后,lib.js模块内部的变化就影响不到counter了。这是因为counter是一个原始类型的值,会被缓存。除非写成一个函数,才能得到内部变动后的值。
AMD
CommonJS的加载是同步的,也就是说只有加载完成才能进行后面的操作。AMD规范则是非同步加载模块,允许指定回调函数。
在服务端,由于Node.js主要用于服务器编程,模块文件一般都已经存在于本地硬盘,所以加载起来比较快,不用考虑非同步加载的方式,所以CommonJS规范比较适用。
但是,如果是浏览器环境,要从服务器端加载模块,这时就必须采用非同步模式,因此浏览器端一般采用AMD规范。此外AMD规范比CommonJS规范在浏览器端实现要来着早。
AMD规范基本语法
定义暴露模块:
//定义没有依赖的模块
define(function(){
return 模块
})
//定义有依赖的模块
define(['module1', 'module2'], function(m1, m2){
return 模块
})
引入使用模块:
require(['module1', 'module2'], function(m1, m2){
使用m1/m2
})
CMD
CMD规范专门用于浏览器端,模块的加载是异步的,模块使用时才会加载执行。CMD规范整合了CommonJS和AMD规范的特点。在 Sea.js 中,所有 JavaScript 模块都遵循 CMD模块定义规范。
CMD规范基本语法
定义暴露模块:
//定义没有依赖的模块
define(function(require, exports, module){
exports.xxx = value
module.exports = value
})
//定义有依赖的模块
define(function(require, exports, module){
//引入依赖模块(同步)
var module2 = require('./module2')
//引入依赖模块(异步)
require.async('./module3', function (m3) {
})
//暴露模块
exports.xxx = value
})
引入使用模块:
define(function (require) {
var m1 = require('./module1')
var m4 = require('./module4')
m1.show()
m4.show()
})
ES6模块化
ES6 模块的设计思想是尽量的静态化,使得编译时就能确定模块的依赖关系,以及输入和输出的变量。CommonJS 和 AMD 模块,都只能在运行时确定这些东西。比如,CommonJS 模块就是对象,输入时必须查找对象属性。
ES6模块化语法
export命令用于规定模块的对外接口,import命令用于输入其他模块提供的功能。
/** 定义模块 math.js **/
var basicNum = 0;
var add = function (a, b) {
return a + b;
};
export { basicNum, add };
/** 引用模块 **/
import { basicNum, add } from './math';
function test(ele) {
ele.textContent = add(99 + basicNum);
}
如上例所示,使用import命令的时候,用户需要知道所要加载的变量名或函数名,否则无法加载。为了给用户提供方便,让他们不用阅读文档就能加载模块,就要用到export default命令,为模块指定默认输出。
// export-default.js
export default function () {
console.log('foo');
}```
// import-default.js
import customName from './export-default';
customName(); // 'foo'
模块默认输出, 其他模块加载该模块时,import命令可以为该匿名函数指定任意名字。
ES6 模块与 CommonJS 模块的差异
它们有两个重大差异:
① CommonJS 模块输出的是一个值的拷贝,ES6 模块输出的是值的引用。
② CommonJS 模块是运行时加载,ES6 模块是编译时输出接口。
-
运行时加载: CommonJS 模块就是对象;即在输入时是先加载整个模块,生成一个对象,然后再从这个对象上面读取方法,这种加载称为“运行时加载”。
-
编译时加载: ES6 模块不是对象,而是通过
export命令显式指定输出的代码,import时采用静态命令的形式。即在import时可以指定加载某个输出值,而不是加载整个模块,这种加载称为“编译时加载”。
CommonJS 加载的是一个对象(即module.exports属性),该对象只有在脚本运行完才会生成。而 ES6 模块不是对象,它的对外接口只是一种静态定义,在代码静态解析阶段就会生成。
下面重点解释第一个差异,我们还是举上面那个CommonJS模块的加载机制例子:
// lib.js
export let counter = 3;
export function incCounter() {
counter++;
}
// main.js
import { counter, incCounter } from './lib';
console.log(counter); // 3
incCounter();
console.log(counter); // 4```
ES6 模块的运行机制与 CommonJS 不一样。**ES6 模块是动态引用,并且不会缓存值,模块里面的变量绑定其所在的模块**。
三.小结
- CommonJS规范主要用于服务端编程,加载模块是同步的,这并不适合在浏览器环境,因为同步意味着阻塞加载,浏览器资源是异步加载的,因此有了AMD CMD解决方案。
- AMD规范在浏览器环境中异步加载模块,而且可以并行加载多个模块。不过,AMD规范开发成本高,代码的阅读和书写比较困难,模块定义方式的语义不顺畅。
- CMD规范与AMD规范很相似,都用于浏览器编程,依赖就近,延迟执行,可以很容易在Node.js中运行。不过,依赖SPM 打包,模块的加载逻辑偏重
- ES6 在语言标准的层面上,实现了模块功能,而且实现得相当简单,完全可以取代 CommonJS 和 AMD 规范,成为浏览器和服务器通用的模块解决方案。