模块化编程想必都很熟悉了,而且使用起来很方便,但是为什么要模块化,模块化又是怎样演变而来的呢,我们通过几个编程时常见的问题导出模块化的发展历程.
首先看下模块的概念:
将一个复杂的程序系统依据一定的规则拆分成几个控件,每个控件都有着各自的功能,这些控件结合在一起形成一个可运行的系统。换句话来讲,每一个控件可以叫做系统的一个模块程序,即一个模块。
模块程序就像一个一个的个体成员,是一个独立的人,所以其内部数据(个人思想)与实现(个人行为)是私有的,对外只暴露一些接口或者方法(个人特征)与其他模块通信。
————————————————————————————————————————————————————————
模块化发展史及分类:
原始:全局function模式 => namespace模式 => IIFE模式 => IIFE 模式增强
IIFE (Immediately-Invoked Function Expression)
模块化规范:common.js、AMD、ES6、CMD
——————————————————————————————————————————————————————
原始模块设计场景及优缺点:
全局function模式:将不同的功能封装成不同的全局函数
污染全局命名空间,容易引起命名冲突或数据不安全,而且模块成员之间看不出直接关系。
function m1(){
//...
}
function m2(){
//...
}
namespace 模式:简单对象封装
-
作用: 减少了全局变量,解决命名冲突;
-
问题: 数据不安全 (外部可以直接修改模块内部的数据)。
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 模式:匿名函数自调用 (闭包)
-
作用: 数据是私有的, 外部只能通过暴露的方法操作;
-
编码: 将数据和行为封装到一个函数内部, 通过给 window 添加属性来向外暴露接口;
-
问题: 如果当前这个模块依赖另一个模块怎么办?
// 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)
// 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>
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)
引入多个<script></script>标签的弊端:
多次url请求;依赖模糊,不知道谁依赖谁;难以维护
————————————————————————————————————————————————————————
所以就有了模块化规范:
1·,common.js
基本语法:
-
暴露模块:
module.exports = value
或exports.xxx = value
; -
引入模块:require(xxx), 如果是第三方模块,xxx 为模块名;如果是自定义模块,xxx 为模块文件路径。
// example.js
var x = 5;
var addX = function (value) {
return value + x;
};
module.exports.x = x;
module.exports.addX = addX;
特点:方法,变量,属性,函数都是私有的,每个文件就是一个模块,有自己的作用域
加载:服务器端运行时同步加载,浏览器端需要先对模块进行编译;
模块加载的顺序,按照其在代码中出现的顺序;
只会在第一次加载时运行一次,然后运行结果就被缓存了,以后再加载,就直接读取缓存结果;
问题:CommonJS 暴露的模块到底是什么?
CommonJS 规范规定,每个模块内部,module 变量代表当前模块,这个变量是一个对象
对外接口:exports属性,加载某个模块,其实是加载该模块的 module.exports 属性。
——————————————————————————————————————————————————
2,AMD模块 : AMD 规范则是非同步加载模块,允许指定回调函数。
基本语法:
// 定义没有依赖的模块
define(function(){
return 模块
})
// 定义有依赖的模块
define(['module1', 'module2'], function(m1, m2){
return 模块
})
//引入使用模块:
require(['module1', 'module2'], function(m1, m2){
使用 m1/m2
})
node.js编程说明:(为什么适用于CommonJS规范)
Node.js 主要用于服务器编程,模块文件一般都已经存在于本地硬盘,所以加载起来比较快,不用考虑非同步加载的方式,所以 CommonJS 规范比较适用
浏览器端编程:
要从服务器端加载模块,当模块非常多或者比较大时,同步加载比较耗时,这时候就必须使用非同步加载的方法,所以浏览器端一般选用AMD规范
AMD 比commonjs在浏览器端实现早
require.js库:
RequireJS 是一个工具库,主要用于客户端的模块管理
它的模块管理遵守 AMD 规范,RequireJS 的基本思想是,
1,定义:通过 define 方法,将代码定义为模块;
2,加载:通过 require 方法,实现代码的模块加载。
AMD 规范在浏览器实现的步骤:
1,下载 require.js,并引入(自行百度)
2,创建项目结构
|-js
|-libs
|-require.js
|-modules
|-alerter.js
|-dataService.js
|-main.js
|-index.html
3,定义模块
定义AMD模块时,和IIFE模式是比较像的,将IIFE闭包换为define,然后将暴露给windows的模块返回,代码对比如下
//AMD模式
define(['dataService'], function(dataService) {
let name = 'Tom'
function showMsg() {
alert(dataService.getMsg() + ', ' + name)
}
// 暴露模块
return { showMsg }
})
// IIFE模式
(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)
除此之外,还要定义一个说明文件:
// main.js 文件
(function() {
require.config({
baseUrl: 'js/', // 基本路径 出发点在根目录下
paths: {
// 自定义模块
alerter: './modules/alerter', // 此处不能写成 alerter.js, 会报错
dataService: './modules/dataService',
// 第三方库模块
jquery: './libs/jquery-1.10.1' // 注意:写成 jQuery 会报错
}
})
require(['alerter'], function(alerter) {
alerter.showMsg()
})
})()
————————————————————————————————————————————————————————
三,CMD规范:
1,CMD 规范专门用于浏览器端,模块的加载是异步的,模块使用时才会加载执行
2,CMD 规范整合了 CommonJS 和 AMD 规范的特点。
在 Sea.js 中,所有 JavaScript 模块都遵循 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()
})
代表库:sea.js
使用步骤:
下载 sea.js, 并引入
创建目录结构
|-js
|-libs
|-sea.js
|-modules
|-module1.js
|-module2.js
|-module3.js
|-module4.js
|-main.js
|-index.html
定义 sea.js 的模块代码
// module1.js 文件
define(function (require, exports, module) {
// 内部变量数据
var data = 'atguigu.com'
// 内部函数
function show() {
console.log('module1 show() ' + data)
}
// 向外暴露
exports.show = show
})
// module2.js 文件
define(function (require, exports, module) {
module.exports = {
msg: 'I Will Back'
}
})
// module3.js 文件
define(function(require, exports, module) {
const API_KEY = 'abc123'
exports.API_KEY = API_KEY
})
// module4.js 文件
define(function (require, exports, module) {
// 引入依赖模块 (同步)
var module2 = require('./module2')
function show() {
console.log('module4 show() ' + module2.msg)
}
exports.show = show
// 引入依赖模块 (异步)
require.async('./module3', function (m3) {
console.log('异步引入依赖模块 3 ' + m3.API_KEY)
})
})
创建入口文件:
define(function (require) {
var m1 = require('./module1')
var m4 = require('./module4')
m1.show()
m4.show()
})
在html中引用:
<script type="text/javascript" src="js/libs/sea.js"></script>
<script type="text/javascript">
seajs.use('./js/modules/main')
</script>
四:ES6 模块化
1,设计思想:静态化
2,在编译时就能确定模块的依赖关系,以及输入和输出的变量
相比的优势:CommonJS 和 AMD 模块,都只能在运行时确定这些东西
基本语法:
import { react, Component } from 'react
class App extends Component {
}
class Test extends Component {
}
export default = App
export Test
ES6 模块与 CommonJS 模块的相同点:
1,一个文件是一个模块
2,最后输出,暴露接口
3,在文件内写模块的内容,不用定义函数和借助于第三方库
ES6 模块与 CommonJS 模块的差异
1,CommonJS 模块输出的是一个值的拷贝,ES6 模块输出的是值的引用。(commonjs值缓存,es6不缓存值)
2,CommonJS 模块是运行时加载,ES6 模块是编译时输出接口。
ES6 模块的运行机制与 CommonJS 不一样。ES6 模块是动态引用,并且不会缓存值,模块里面的变量绑定其所在的模块。
export let counter = 3;
export function incCounter() {
counter++;
}
// main.js
import { counter, incCounter } from './lib';
console.log(counter); // 3
incCounter();
console.log(counter); // 4
————————————————————————————————————————————————————————
总结:
CommonJs主要用于服务端编程(node.js),加载模块是同步的,不适合浏览器环境,因为会阻塞加载,
AMD CMD是异步加载的,主要用于浏览器环境
AMD 规范在浏览器环境中异步加载模块,而且可以并行加载多个模块。不过,AMD 规范开发成本高,代码的阅读和书写比较困难,模块定义方式的语义不顺畅。
CMD 规范与 AMD 规范很相似,都用于浏览器编程,依赖就近,延迟执行,可以很容易在 Node.js 中运行。不过,依赖 SPM 打包,模块的加载逻辑偏重 ES6 在语言标准的层面上,实现了模块功能,而且实现得相当简单,完全可以取代 CommonJS 和 AMD 规范,成为浏览器和服务器通用的模块解决方案。
引申:为了兼容AMD和Common.js规范,有了UMD兼容模式:
(function (root, factory) {
if (typeof define === 'function' && define.amd) {
// AMD
define(['jquery'], factory);
} else if (typeof exports === 'object') {
// Node, CommonJS-like
module.exports = factory(require('jquery'));
} else {
// Browser globals (root is window)
root.returnExports = factory(root.jQuery);
}
}(this, function ($) {
// methods
function myFunc(){};
// exposed public method
return myFunc;
}));