一、模块化简介
随着前端js代码复杂度的进步,JavaScript模块化这个概念便被提出来,前端社区也一直地实现前端模块化,直到es6对其进行了标准。
1.什么是模块化
一个模块就是一个文件
包 : 一堆模块
包 组成我的项目
二、第一阶段:无模块化
JavaScript最后的作用仅仅是验证表单,起初会增加一些动画,然而这些js代码很多在一个文件中就能够实现了,所以,咱们只须要在html文件中增加一个script标签。
起初,随着前端复杂度进步,为了可能进步我的项目代码的可读性、可扩展性等,咱们的js文件逐步多了起来,不再是一个js文件就能够解决的了,而是把每一个js文件当做一个模块。那么,这时的js引入形式是怎么的呢?大略是上面这样:
<script src="jquery.js"></script> <script src="jquery_scroller.js"></script> <script src="main.js"></script> <script src="other1.js"></script> <script src="other2.js"></script> <script src="other3.js"></script>
即简略的将所有的js文件通通放在一起。然而这些文件的程序还不能出错,比方jquery须要先引入,能力引入jquery插件,能力在其余的文件中应用jquery。
1.长处:
相比于应用一个js文件,这种多个js文件实现最简略的模块化的思维是提高的。
2.毛病:
净化全局作用域。 因为每一个模块都是裸露在全局的,简略的应用,会导致全局变量命名抵触,当然,咱们也能够应用命名空间的形式来解决。
对于大型项目,各种js很多,开发人员必须手动解决模块和代码库的依赖关系,前期保护老本较高。
依赖关系不显著,不利于保护。 比方main.js须要应用jquery,然而,从下面的文件中,咱们是看不出来的,如果jquery遗记了,那么就会报错。
三、第二阶段: CommonJS标准
CommonJS就是一个JavaScript模块化的标准,该标准最后是用在服务器端的node的,前端的webpack也是对CommonJS原生反对的。
依据这个标准,每一个文件就是一个模块,其外部定义的变量是属于这个模块的,不会对外裸露,也就是说不会净化全局变量。
CommonJS的核心思想就是通过 require 办法来同步加载所要依赖的其余模块,而后通过 exports 或者 module.exports 来导出须要裸露的接口。如下所示:
// a.jsvar x = 5;var addX = function (value) { return value + x;};module.exports.x = x;module.exports.addX = addX;
这里的a.js就是一个CommonJS标准的模块了。 这里的module就代表了这个模块,module的exports属性就是对外裸露的接口,能够对外导出内部能够拜访的变量,比方这里的x和addX。
exports 是对 module.exports 的援用。比方咱们能够认为在一个模块的顶部有这句代码:
exports = module.exports
所以,咱们不能间接给exports赋值,比方number、function等。
而后咱们就能够在其余模块中引入这个模块应用了:
vara = require('./a.js');console.log(example.x); // 5console.log(example.addX(1)); // 6
这里的require就会获取到a.js所裸露的module.exports变量,而后就能够应用其裸露的x和addX了。
1.长处:
CommonJS标准在服务器端率先实现了JavaScript的模块化,解决了依赖、全局变量净化的问题,这也是js运行在服务器端的必要条件。
2.毛病:
此文次要是浏览器端js的模块化, 因为 CommonJS 是同步加载模块的,在服务器端,文件都是保留在硬盘上,所以同步加载没有问题,然而对于浏览器端,须要将文件从服务器端申请过去,那么同步加载就不实用了,所以,CommonJS是不适用于浏览器端的。
四、第三阶段: AMD标准
之前提到: CommonJS标准加载模块是同步的,也就是说,只有加载实现,能力执行前面的操作。AMD标准则是非同步加载模块,容许指定回调函数。因为Node.js次要用于服务器编程,模块文件个别都曾经存在于本地硬盘,所以加载起来比拟快,不必思考非同步加载的形式,所以CommonJS标准比拟实用。然而,如果是浏览器环境,要从服务器端加载模块,这时就必须采纳非同步模式,因而浏览器端个别采纳AMD标准。而AMD标准的实现,就是赫赫有名的require.js了。
AMD规范中,定义了上面两个API:
1.require([module], callback) 2\. define(id, [depends], callback)
即通过define来定义一个模块,而后应用require来加载一个模块。 并且,require还反对CommonJS的模块导出形式。
定义alert模块:
define(function () { var alertName = function (str) { alert("I am " + str); } var alertAge = function (num) { alert("I am " + num + " years old"); } return { alertName: alertName, alertAge: alertAge }; });引入模块:require(['alert'], function (alert) { alert.alertName('JohnZhu'); alert.alertAge(21);});
然而,在应用require.js的时候,咱们必须要提前加载所有的依赖,而后才能够应用,而不是须要应用时再加载。
1.长处:
适宜在浏览器环境中异步加载模块。能够并行加载多个模块。
2.毛病:
进步了开发成本,并且不能按需加载,而是必须提前加载所有的依赖。
五、第四阶段:CMD标准
CMD标准是阿里的玉伯提出来的,实现js库为sea.js。 它和requirejs十分相似,即一个js文件就是一个模块,然而CMD的加载形式更加优良,是通过按需加载的形式,而不是必须在模块开始就加载所有的依赖。如下:
define(function(require, exports, module) { var $ = require('jquery'); var Spinning = require('./spinning'); exports.doSomething = ... module.exports = ...})
1.长处:
同样实现了浏览器端的模块化加载。
能够按需加载,依赖就近。
2.毛病:
依赖SPM打包,模块的加载逻辑并重。
其实,这时咱们就能够看出AMD和CMD的区别了,前者是对于依赖的模块提前执行,而后者是提早执行。 前者推崇依赖前置,而后者推崇依赖就近,即只在须要用到某个模块的时候再require。 如下:
// AMDdefine(['./a', './b'], function(a, b) { // 依赖必须一开始就写好 a.doSomething() // 此处略去 100 行 b.doSomething() ...});// CMDdefine(function(require, exports, module) { var a = require('./a') a.doSomething() // 此处略去 100 行 var b = require('./b') // 依赖能够就近书写 b.doSomething() // ... });
六、第五阶段: ES6模块化
之前的几种模块化计划都是前端社区本人实现的,只是失去了大家的认可和宽泛应用,而ES6的模块化计划是真正的标准。 在ES6中,咱们能够应用 import 关键字引入模块,通过 export 关键字导出模块,性能较之于前几个计划更为弱小,也是咱们所推崇的,然而因为ES6目前无奈在浏览器中执行,所以,咱们只能通过babel将不被反对的import编译为以后受到广泛支持的 require。
尽管目前import和require的区别不大,然而还是举荐应用应用es6,因为将来es6必然是支流,对于代码的迁徙老本还是非常容易的。 如:
import store from '../store/index' import {mapState, mapMutations, mapActions} from 'vuex' import axios from '../assets/js/request' import util from '../utils/js/util.js' export default { created () { this.getClassify(); this.RESET_VALUE(); console.log('created' ,new Date().getTime()); }