前端模块化开发简介

前端模块化开发简介

---

历史上，JavaScript 一直没有模块（module）体系，无法将一个大程序拆分成互相依赖的小文件，再用简单的方法拼装起来。其他语言都有这项功能，比如 Ruby 的require、Python 的import，甚至就连 CSS 都有@import，但是 JavaScript 任何这方面的支持都没有，这对开发大型的、复杂的项目形成了巨大障碍。

---

开始之前

我们先用几个问题, 探讨下, 在没有模块化的情况下, 我们如何解决这些问题

---

Q1

如何解决JS全局变量/函数冲突?

---

A1

自执行函数

// b.js
var a = 1;
// a.js
(function(args){
  var a = 2;
  console.log(a); // 2
  console.log(window.a); // 1
}).call(context,args);

---

Q2

依赖顺序&&重复引入问题

• a.js 依赖 b.js 如何保证顺序?

• a.js, b.js 都依赖 c.js, 如何保c不被重复引入?

---

A2

• 检查标签,确保依赖顺序

• 将所有文件按依赖顺序合并

---

Q3

按需加载问题

• 如果只使用某个库的其中一个功能, 不得不把整个库引入

---

A3

手动分离所需代码

---

模块化所解决的问题

1. 模块作用域: 安全的包装一个模块的代码--不污染模块外的任何代码
2. 模块唯一性: 唯一标识一个模块--避免重复引入
3. 模块的导出: 优雅的把模块的API暴漏给外部--不增加全局变量
4. 模块的引入: 方便的使用所依赖的模块

---

目前模块化的解决方案

1. CommonJS -- Node.js
2. AMD -- RequireJS
3. CMD -- SeaJS
4. UMD
5. ES6 Module

---

CommonJS

1. 一个单独的JS文件就是一个模块,每一个模块都是一个单独的作用域
2. 定义全局函数require，通过传入模块标识来引入其他模块，执行的结果即为别的模块暴漏出来的API
3. 如果被require函数引入的模块中也包含依赖，那么依次加载这些依赖
4. 如果引入模块失败，那么require函数应该报一个异常
5. 模块通过变量exports来向外暴漏API，exports只能是一个对象，暴漏的API须作为此对象的属性。

---

CommonJS 例子

//a.js
exports.foo = function() {
  console.log('foo')
}

//b.js
var a = require('./a.js')
a.foo()

---

CommonJS 缺点

1. 只能在服务端(Node.js)使用, 不能在浏览器直接使用
2. 模块是同步加载的, 如果加载过慢会阻塞进程

---

AMD(Asyncchronous Module Definition)

1. 专门为浏览器量身定制,兼容IE6+(在node.js中使用适配器也可以用)
2. 模块是异步加载的
3. 用全局函数define来定义模块，用法为：define(id?, dependencies?, factory)
4. 使用全局函数require来引入模块, 用法为: require(dependencies?, callback)

---

AMD 例子

//a.js
define(function(){
  return {
    hello: function(){
      console.log('hello, a.js')
    }
  }
})
// main.js
require(['a', 'other'], function(a, other){
  a.hello() // hello, a.js
  other.foo()
})

---

AMD缺点

1. 预下载, 预解释, 带来额外性能消耗
2. 书写复杂
3. 回调地狱

define(['a', 'b', 'c', 'd', 'e', 'f', 'g'], function(a, b, c, d, e, f, g){ })

---

AMD演示

---

AMD演示:目录结构

source_tree.png

---

AMD演示:主页文件/project.html

---

AMD演示:JS入口文件/scripts/main.js

requirejs(["helper/util"], function(util) {
  if(!condition){
    util.foo()
  }
});

---

AMD演示:模块/scripts/helper/util.js

define(function(require, factory) {
    'use strict';
    return {
        foo: function(){
            console.log("hello util.js");
        }
    };  
});

---

AMD演示:运行结果

console.png

network.png

---

CMD(Common Module Definition)

SeaJS

SeaJS集各家所长, 融合了太多的东西，已经无法说它遵循哪个规范了，所以干脆就自立门户，起名曰CMD（Common Module Definition）规范

比较

• AMD推崇(但不强制)依赖前置，在定义模块的时候就要用require声明其依赖的
• CMD推崇(但不强制)就近依赖，只有在用到某个模块的时候再去require
• CMD不需要AMD那样的回调写法, 可以像CommonJS一样的同步写法(但加载其实还是异步的)
• AMD模块是提前执行的, 而CMD模块默认是延迟执行的
• 由于延迟加载, CMD用户体验稍差

---

UMD(Universal Module Definition)

同时兼容AMD, CommonJS的模块化定义

• 写法丑陋复杂, 但是能够支持多种规范

  (function (root, factory) {
  if (typeof define === 'function' && define.amd) {
    define(['jquery'], factory); // AMD
  } else if (typeof exports === 'object') {
    module.exports = factory(require('jquery'));// CommonJS
  } else {
    root.returnExports = factory(root.jQuery); // 浏览器全局变量
  }
  }(this, function ($) {
  function foo(){$()};
  return foo;
  }));
  

---

ES6 Module -- 面向未来的模块标准

ES6 在语言标准的层面上，实现了模块功能，而且实现得相当简单，完全可以取代 CommonJS 和 AMD 规范，成为浏览器和服务器通用的模块解决方案

• 但是到目前为止, 浏览器对ES6 Module的支持还是相当不完善

ES6 模块的设计思想，是尽量的静态化，使得编译时就能确定模块的依赖关系，从而进行一些优化。CommonJS 和 AMD 模块，都只能在运行时确定依赖

• 在ES8的stage-3提案中, 出现了动态import即import()方法,它返回一个Promise对象, 允许动态导入模块

---

ES6 Module 基本用法

• 定义模块

  //变量, module.js
  export var bar = 'bar'
  
  // 函数, module.js
  export function foo(){}
  
  // 统一导出&重命名, module.js
  var bar = 'bar'
  function foo(){}
  export { bar as myBar, foo }
  
  // 默认导出, module.js
  function foo(){}
  export default foo
  

---

ES6 Module 基本用法

• 引用模块

  // 从模块中导入指定对象, 支持重命名, main.js
  import { foo, bar as myBar } from './module.js'
  
  // 从模块中导入默认对象(名称可跟原名称不一样)
  import myFoo from './module.js'
  
  // 执行模块, 但不导入任何值
  import './module.js'
  
  // 整体导入
  
  import * as myModule from './module.js'
  

• 注意: ES6 import导入的模块都是原模块的引用

---

ES6 Module 基本用法

• 浏览器使用: 在入口JS文件加上type="module"就可以在该文件内使用ES6 Module 语法

---

ES6 Module 浏览器支持情况

caniuse.png

---

总结

-	加载机制	缺点	评价
CommonJS	同步加载	加载时会阻塞线程,仅适用于后端	NodeJS首创,具有先导意义
AMD	异步加载, 依赖前置	写法冗余,依赖多的时候很痛苦	前端残留势力
CMD	异步加载, 依赖后知	体验略差,需要配合SPM打包工具,配置复杂	被创始人说"已死"的规范
UMD	根据运行环境判断选用合适的方式	写法臃肿难看	前后端跨平台跨平台的解决方案
ESM	编译时静态确定	浏览器支持乏力,需要配合转译或打包工具使用	未来前端模块管理的规范

---

模块化与打包工具

由于模块化方案多样, 且浏览器支持不一, 再加上上述模块化方案仅仅支持JavaScript本身, 对 于复杂的前端应用来说远远不够用, 因此出现了各种打包工具来解决这些问题

• 早期打包工具

  1. r.js -- RequireJS提供的打包工具,仅仅支持RequireJS
  2. SPM -- SeaJS提供的打包工具,仅仅支持SeaJS
  3. browserify -- 让浏览器使用Node.js的NPM模块
  4. gulp/grunt/fis -- 前端自动化构建, 用来测试,压缩,检错,合并前端代码, 不支持模块化(类似Maven/Gradle)

• 现代打包工具

  1. webpack -- 高度可配置的静态资源打包器, 有着强大的插件和生态
  2. rollup -- 小巧高效的前端资源打包器, 适合用来编写库或框架
  3. parcel -- 后起之秀, 极速零配置Web应用打包工具

---

webpack 简介

webpack.png

---

webpack 简介

webpack并不强制你使用某种模块化方案，而是通过兼容所有模块化方案让你无痛接入项目，当然这也是webpack牛逼的地方。 有了webpack，你可以随意选择你喜欢的模块化方案，至于怎么处理模块之间的依赖关系及如何按需打包，webpack会帮你处理好的

---

webpack 优点

• 可以兼容多模块风格，无痛迁移老项目
• 一切皆模块，js/css/图片/字体/音视频 等都是模块, 都可被打包
• 配合插件/加载器可以进行各种操作: 转译, 代码检查, 压缩等等
• 静态解析，按需打包，动态加载,
• 支持抽离公共模块
• 支持进行代码分隔, 按需下载
• 扩展性强，插件机制强大, 生态完善
• 强大的webpack-dev-server: 检测代码改变, 进行代码热重载, 无需浏览器刷新

参考

• http://es6.ruanyifeng.com/#docs/module
• http://web.jobbole.com/83761/
• https://www.jianshu.com/p/283d4b6bd380
• http://requirejs.org/docs/start.html