为什么需要模块化?
随着网站内容越来越复杂,浏览器和用户的交互越来越细腻,网站再也不是简单的内容呈现,更像是一个复杂的客户端软件,其中html/css/js代码越来越多,逻辑越来越复杂,越来越不便于管理,为了解决这个问题,才出现了模块化的概念,也就是说模块化更多的是工程方面的产出,为了应对更复杂的网站开发。
梳理下网站的发展过程,大家也就知道为什么模块化是必然出现的了:
- 早期一个html文件,通过style引入内联css,通过script引入内联js。
- 晚一点一个html,通过link引入外部css,通过script引入外部js。
- 再复杂一点,多个html,各自引入自己的css和js。
- 再复杂一点,多个html中有复用的css和js,怎么办呢?拆分文件呗,将css和js拆分成小文件,然后通过link和script分别引入或者手动合并之后引入。
- 再复杂一点,有很多js/css的小文件,手动解决会有缺陷或者容易出错,怎么办呢?引入自动化工具呗,自动合并,压缩等。
- 再复杂一点,想要按需合并js/css小文件,开发模式自动监听改动,甚至可以将图片等其他静态资源当做模块。
- 再复杂一点,...
到现在为止,都有哪些优秀的模块化方案呢?
非模块
通过多个script标签引入多个js文件,也即通过文件的方式来管理模块,这种原始的方案有很多显而易见的弊端:
- 污染全局作用域,多人协作必须主观的解决模块依赖关系。
- 手动维护script标签及其顺序,多页应用简直更惨。
- 大型项目资源难以管理,容易留下隐患。
CommonJs
该方案的核心思想就是允许模块通过require方案同步加载依赖的其他模块,然后通过exports或module.exports来导出需要暴露的接口。
优点:简单,容易复用
缺点:同步加载不适合浏览器
AMD
该方案只有一个主要接口define(id?, dependencies?, factory),他要在声明模块的时候指定所有的依赖dependencies,并传入到factory中,对于依赖的模块异步加载并执行。
优点:异步并行加载适合浏览器
缺点:模块定义方式不优雅,不符合标准模块化
ES6模块
该方案最大的特点就是静态化,静态化的优势在于可以在编译的时候确定模块的依赖关系以及输入输出的变量。上面提到的CommonJs和AMD都只能在运行时确定这些东西。
优点:面向未来,可进行静态分析
缺点:兼容性
webpack的模块化有什么特点?
可以兼容多模块风格,无痛迁移老项目
一切皆模块,js/css/图片/字体都是模块
静态解析,按需打包,动态加载
require("./style.css");
require("./style.less");
require("./template.jade");
require("./image.png");
静态分析的时候,webpack提供了很多loader来处理文件,这样我们可以实现更多功能。
webpack到底对模块代码做了什么?
非模块化代码
一行alert('hello world');代码,经过webpack打包后,会生成如下50行代码;
/******/ (function(modules) { // webpackBootstrap
/******/ // The module cache
/******/ var installedModules = {};
/******/ // The require function
/******/ function __webpack_require__(moduleId) {
/******/ // Check if module is in cache
/******/ if(installedModules[moduleId])
/******/ return installedModules[moduleId].exports;
/******/ // Create a new module (and put it into the cache)
/******/ var module = installedModules[moduleId] = {
/******/ exports: {},
/******/ id: moduleId,
/******/ loaded: false
/******/ };
/******/ // Execute the module function
/******/ modules[moduleId].call(module.exports, module, module.exports, __webpack_require__);
/******/ // Flag the module as loaded
/******/ module.loaded = true;
/******/ // Return the exports of the module
/******/ return module.exports;
/******/ }
/******/ // expose the modules object (__webpack_modules__)
/******/ __webpack_require__.m = modules;
/******/ // expose the module cache
/******/ __webpack_require__.c = installedModules;
/******/ // __webpack_public_path__
/******/ __webpack_require__.p = "";
/******/ // Load entry module and return exports
/******/ return __webpack_require__(0);
/******/ })
/************************************************************************/
/******/ ([
/* 0 */
/***/ function(module, exports) {
alert('hello world');
/***/ }
/******/ ]);
Runtime & 模块
上半部分是一个函数定义,也就是Runtime,作用是保证模块顺序加载和运行。
下半部分是我们的JS代码,包裹了一个函数,也就是模块。运行的时候模块是作为Runtime的参数被传进去的。
(function(modules) {
// Runtime
})([
// 模块数组
])
问题
- 模块不再暴露在全局作用域,模块的全局变量也不再是全局作用域。
- 模块被引入的时候只是执行代码而无法将模块赋值。因为非模块化规范的代码没有通过AMD的
return或者CommonJs的exports/this导出模块本身。
AMD模块
AMD的代码
define([], function() {
alert('hello world!');
});
经过webpack打包,会生成如下核心代码:
function(module, exports, __webpack_require__) {
var __WEBPACK_AMD_DEFINE_ARRAY__, // AMD依赖列表
__WEBPACK_AMD_DEFINE_RESULT__; // AMD factory函数的返回值,即模块内容
__WEBPACK_AMD_DEFINE_ARRAY__ = [];
// 执行factory函数,获取返回值作为模块内容
// 函数体使用.apply调用,函数体中this为exports
// 形参则分别对应依赖列表中的各个依赖模块
__WEBPACK_AMD_DEFINE_RESULT__ = function() {
alert('hello world!');
}.apply(exports, __WEBPACK_AMD_DEFINE_ARRAY__);
// 如果模块内容不为空,则通过module.exports返回
// 如果为空,则不处理,在Runtime中声明为{}
if (__WEBPACK_AMD_DEFINE_RESULT__ !== undefined) {
module.exports = __WEBPACK_AMD_DEFINE_RESULT__;
}
}
CommonJs
CommonJs的代码
var me = {
sayHello:function(){
alert('hello world!');
}
};
module.exports = me;
经过webpack打包,会生成如下核心代码:
function(module, exports) {
var me = {
sayHello: function() {
alert('hello world!');
}
};
module.exports = me;
}