说到劫持，第一反应可能是什么不好的东西。函数劫持并不邪恶，关键是看使用的人。虽然这个概念在前端领域使用较少，但是在安全领域、自定义业务等场景下还是有一定的使用价值的。所以，这一篇文章将会和大家一起去了解一下JS中的函数劫持是什么，有什么用。

基本概念

函数劫持，顾名思义，即在一个函数运行之前把它劫持下来，添加我们想要的功能。当这个函数实际运行的时候，它已经不是原本的函数了，而是带上了被我们添加上去的功能。这也是我们常见的钩子函数的原理之一。

乍一看上去，这很像是函数的改写。函数的改写也可以理解为是函数劫持的一种，但是这种方式太恶心了。作为一个劫持者，在绑票获得好处以后也应该遵守职业道德，把人原封不动地还回去，所以我们得在合适的地方把函数原本的功能给重新调用回来。

推而广之，其实“劫持”这一概念我们经常会遇到，比方说某网站被运营商劫持了，在浏览该网站的时候会弹出运营商的广告。

举例分析

现在我们来举个简单的例子，劫持一下alert()函数，为它增添一点小小的功能：

1
2
3
4
5
6

let warn = alert
window.alert = (t) => {
    if (confirm('How are you?')) warn(t)
}

alert('Help me...!!!')

可以打开开发者工具尝试一下这个例子，你会发现只有你在 confirm 里面点击了OK，才会弹出 Help me...!!!

接下来我们把这部分的内容封装一下，成为一个通用的函数：

1
2
3
4

const hijack = (obj, method, fun) => {
  let orig = obj[method]
  obj[method] = fun(orig)
}

首先我们定义了一个 hijack 函数，它会先把原函数给保存下来，然后执行自定义函数，而原函数将会在自定义函数内部进行调用。

然后我们来劫持 confirm() 函数：

1
2
3
4
5
6
7
8
9
10

hijack(window, 'confirm', (orig) => {
  return (text) => {
    alert('HELP ME PLZ!!!')
    if (orig.call(this, text)) {
      alert('YOU SEEMS FINE AND I AM LEAVING, GOOD BYE!')
    } else {
      alert('HOLD ON! I AM COMING!!')
    }
  }
})

反劫持

新建一个页面，打开你的开发者工具控制台，输入 alert，你会看到这样的输出：

1

function alert() { [native code] }

然后使用本文开头的那段代码，把alert()劫持一下，再重新在控制台输入alert，你会看到这样的输出：

1
2
3

function (t) => {
    if (confirm('How are you?')) warn(t)
}

通过上述的例子可以知道，要看一个函数是否被劫持了，只需要直接把它打印出来即可。针对系统原生的函数，[native code]即代表它是纯净无污染的。

函数劫持的作用

除了为函数增加功能以外，还能够利用函数劫持去追踪恶意用户的信息。一般的XSS攻击会先利用alert()等能够输出信息的方法进行测试，这时候我们可以先对原生alert()进行劫持，向其输入追踪信息的代码，最后才把原函数释放出去。当恶意用户在测试alert()的时候就会立即被我们追踪，而他本人却无从察觉。

补充说明: Mac 下通过 brew install nvm 所安装的 nvm ，由于安装路径不同，无法正确启用。建议使用 brew uninstall nvm 卸载掉之后，通过本文的方案重新安装一次。

最近 NodeJS 的版本更新速度有点 Chrome 的迹象，4.0 版本没发布多久，又推出了 5.0 。升级 NodeJS 之后可以很方便的开始使用一些 ES6 的语言特性，但又会导致团队内部的 mz-fis 框架无法更新，因为它暂时只支持 v0.12 版本。于是团队开始试用管理 node 版本的工具 nvm，试用后发现 Mac 下很好用，推荐大家尽快用起来。

nvm 是 Mac 下的 node 管理工具，有点类似管理 Ruby 的 rvm，如果是需要管理 Windows 下的 node，官方推荐是使用 nvmw 或 nvm-windows 。

以下具体说下 Mac 系统中的安装与使用细节（Windows 系统仅供类比参考）。

一、卸载已安装到全局的 node/npm

如果之前是在官网下载的 node 安装包，运行后会自动安装在全局目录，其中

node 命令在 /usr/local/bin/node ，npm 命令在全局 node_modules 目录中，具体路径为 /usr/local/lib/node_modules/npm

安装 nvm 之后最好先删除下已安装的 node 和全局 node 模块：

1
2
3
4
5

npm ls -g --depth=0 #查看已经安装在全局的模块，以便删除这些全局模块后再按照不同的 node 版本重新进行全局安装

sudo rm -rf /usr/local/lib/node_modules #删除全局 node_modules 目录
sudo rm /usr/local/bin/node #删除 node
cd  /usr/local/bin && ls -l | grep "../lib/node_modules/" | awk '{print $9}'| xargs rm #删除全局 node 模块注册的软链

二、安装 nvm

1

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash

安装完成后请重新打开终端环境，Mac 下推荐使用 oh-my-zsh 代替默认的 bash shell。

三、安装切换各版本 node/npm

1
2
3
4
5
6
7
8
9
10
11

nvm install stable #安装最新稳定版 node，现在是 5.0.0
nvm install 4.2.2 #安装 4.2.2 版本
nvm install 0.12.7 #安装 0.12.7 版本

# 特别说明：以下模块安装仅供演示说明，并非必须安装模块
nvm use 0 #切换至 0.12.7 版本
npm install -g mz-fis #安装 mz-fis 模块至全局目录，安装完成的路径是 /Users/<你的用户名>/.nvm/versions/node/v0.12.7/lib/mz-fis
nvm use 4 #切换至 4.2.2 版本
npm install -g react-native-cli #安装 react-native-cli 模块至全局目录，安装完成的路径是 /Users/<你的用户名>/.nvm/versions/node/v4.2.2/lib/react-native-cli

nvm alias default 0.12.7 #设置默认 node 版本为 0.12.7

四、使用 .nvmrc 文件配置项目所使用的 node 版本

如果你的默认 node 版本（通过 nvm alias 命令设置的）与项目所需的版本不同，则可在项目根目录或其任意父级目录中创建 .nvmrc 文件，在文件中指定使用的 node 版本号，例如：

1
2
3
4

cd <项目根目录>  #进入项目根目录
echo 4 > .nvmrc #添加 .nvmrc 文件
nvm use #无需指定版本号，会自动使用 .nvmrc 文件中配置的版本
node -v #查看 node 是否切换为对应版本

五、nvm 与 n 的区别

node 版本管理工具还有一个是 TJ 大神的 n 命令，n 命令是作为一个 node 的模块而存在，而 nvm 是一个独立于 node/npm 的外部 shell 脚本，因此 n 命令相比 nvm 更加局限。

由于 npm 安装的模块路径均为 /usr/local/lib/node_modules ，当使用 n 切换不同的 node 版本时，实际上会共用全局的 node/npm 目录。 因此不能很好的满足『按不同 node 版本使用不同全局 node 模块』的需求。

因此建议各位尽早开始使用 nvm ，以免出现全局模块无法更新的问题。

当然，如果你用的是 windows 操作系统，我只能说 …… 朋友，能不能早点换个 Mac ，做一个有品位的程序猿呢：P

前言

源码：https://github.com/Unitech/pm2

这里的pm2并不是大气污染物啊

事实上，pm2 是一个带有负载均衡功能的Node应用的进程管理器，Node实现进程管理的库有很多，forever也是其中一个很强大但是也相对较老的进程管理器。

为什么要使用pm2

对于这个问题，先说说我的看法，最基本的原因是因为node本身是一个单线程应用，它的特点就是所有方法都是串行一次执行，并且node并没有能力像Java一样独自去创建一个新的线程来实现异步操作，如果在执行I/O中遇到了阻塞就会降低整个应用的执行效率，导致CPU使用率高等不利原因。

因此在这种模式下，一个线程只能处理一个任务，要想提高吞吐量必须通过多线程。虽然单线程的好处有很多比如避免了线程同步或者死锁、状态同步等等之类的问题，但是在应用和计算能力要求日益倍增的今天，单线程最大的弊端就是无法利用多核CPU带来的优势来提升运行效率。

我们知道node可以利用异步I/O来避免线程阻塞，提高利用率等优点:

同时为了弥补单线程无法利用多核CPU的问题，提供了“子进程”这个概念，Node.js 实际上是 Javascript 执行线程的单线程，真正的的 I/O 操作，底层 API 调用都是通过多线程执行的。当然在这里我只是指出了这一背景，那么为什么我们要用pm2？

我总结了两个比较简洁的答案：1、pm2可以把你的应用部署到服务器所有的CPU上（$ pm2 start app.js -i max），有效的解决了之前背景里提出的问题。 2、同样是进程管理器，为什么不用forever？我认为最大的区别是在监控欠缺，进程和集群管理有限。在监控以及log方面可以认为forever完败于pm2，为什么，一张图你就知道答案。

这是pm2官网给出的Demo，我们可以清晰地看见整个集群的模式、状态，CPU利用率甚至是内存大小，而forever给出的是什么呢？null

如果我要实时监控所有的进程状态呢？

这就是pm2的强大之处，多进程管理、监控、负载均衡……

pm2主要特点

• 内建负载均衡（使用Node cluster 集群模块、子进程，可以参考朴灵的《深入浅出node.js》一书第九章）
• 线程守护，keep alive
• 0秒停机重载，维护升级的时候不需要停机.
• 现在 Linux (stable) & MacOSx (stable) & Windows (stable).多平台支持
• 停止不稳定的进程（避免无限循环）
• 控制台检测
• 提供 HTTP API
• 远程控制和实时的接口API ( Nodejs 模块,允许和PM2进程管理器交互 )

用法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

$ npm install pm2 -g     # 命令行安装 pm2
$ pm2 start app.js -i 4  #后台运行pm2，启动4个app.js
                         # 也可以把'max' 参数传递给 start
                         # 正确的进程数目依赖于Cpu的核心数目
$ pm2 start app.js --name my-api # 命名进程
$ pm2 list               # 显示所有进程状态
$ pm2 monit              # 监视所有进程
$ pm2 logs               #  显示所有进程日志
$ pm2 stop all           # 停止所有进程
$ pm2 restart all        # 重启所有进程
$ pm2 reload all         # 0秒停机重载进程 (用于 NETWORKED 进程)
$ pm2 stop 0             # 停止指定的进程
$ pm2 restart 0          # 重启指定的进程
$ pm2 startup            # 产生 init 脚本 保持进程活着
$ pm2 web                # 运行健壮的 computer API endpoint (http://localhost:9615)
$ pm2 delete 0           # 杀死指定的进程
$ pm2 delete all         # 杀死全部进程

运行进程的不同方式：
$ pm2 start app.js -i max  # 根据有效CPU数目启动最大进程数目
$ pm2 start app.js -i 3      # 启动3个进程
$ pm2 start app.js -x        #用fork模式启动 app.js 而不是使用 cluster
$ pm2 start app.js -x -- -a 23   # 用fork模式启动 app.js 并且传递参数 (-a 23)
$ pm2 start app.js --name serverone  # 启动一个进程并把它命名为 serverone
$ pm2 stop serverone       # 停止 serverone 进程
$ pm2 start app.json        # 启动进程, 在 app.json里设置选项
$ pm2 start app.js -i max -- -a 23                   #在--之后给 app.js 传递参数
$ pm2 start app.js -i max -e err.log -o out.log  # 启动 并 生成一个配置文件
你也可以执行用其他语言编写的app  ( fork 模式):
$ pm2 start my-bash-script.sh    -x --interpreter bash
$ pm2 start my-python-script.py -x --interpreter python

附上keymetrics实时监控

地址：https://app.keymetrics.io/#/register

pm2官方也结合pm2管理提供了一套可视化在线监控平台，有多牛？上图：

注册完毕后创建自己的第一个项目工程成功后会得到如图所示口令：

系统分配的public key 和secret key。然后，在安装有pm2的服务器端输入以下命令

1

pm2 interact your-secret-key your-public-key

接下来的事情就交给可视化去做吧。

最近github上出现了一个神器ajax-hook，它可以拦截所有ajax请求并允许修改请求数据和响应数据！实际项目中它可以用于请求添加统一签名、协议自动解析、接口调用统计等。本文主要分析其源码实现，抛砖引玉了。

如果你还不知道ajax-hook，请先了解一下：
github : https://github.com/wendux/Ajax-hook
中文介绍：http://www.jianshu.com/p/9b634f1c9615

整体思路－代理模式

Ajax-hook实现的整体思路是实现一个XMLHttpRequest的代理对象，然后覆盖全局的XMLHttpRequest，这样一但上层调用 new XMLHttpRequest这样的代码时，其实创建的是Ajax-hook的代理对象实例。具体原理图如下：

上图中青色部分为Ajax-hook实现的代理XMLHttpRequest，内部会调用真正的XMLHttpRequest。我们看一下hookAjax的部分源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

ob.hookAjax = function (funs) {
  //保存真正的XMLHttpRequest对象
  window._ahrealxhr = window._ahrealxhr || XMLHttpRequest
  //1.覆盖全局XMLHttpRequest，代理对象
  XMLHttpRequest = function () {
    //创建真正的XMLHttpRequest实例
    this.xhr = new window._ahrealxhr;
    for (var attr in this.xhr) {
      var type = "";
      try {
        type = typeof this.xhr[attr]
      } catch (e) {}
      if (type === "function") {
        //2.代理方法
        this[attr] = hookfun(attr);
      } else {
        //3.代理属性
        Object.defineProperty(this, attr, {
          get: getFactory(attr),
          set: setFactory(attr)
        })
      }
    }
  }
  ......

Ajax-hook 一开始先保存了真正的XMLHttpRequest对象到一个全局对象，然后在注释1处，Ajax-hook覆盖了全局的XMLHttpRequest对象，这就是代理对象的具体实现。在代理对象内部，首先创建真正的XMLHttpRequest实例,记为xhr,然后遍历xhr所有属性和方法，在2处hookfun为xhr的每一个方法生成一个代理方法，在3处，通过defineProperty为每一个属性生成一个代理属性。下面我们重点看一看代理方法和代理属性的实现。

代理方法

代理方法通过hookfun函数生成，我们看看hookfun的具体实现：

1
2
3
4
5
6
7
8
9
10

function hookfun(fun) {
 return function () {
    var args = [].slice.call(arguments)
    //1.如果fun拦截函数存在，则先调用拦截函数
    if (funs[fun] && funs[fun].call(this, args, this.xhr)) {
      return;
    }
   //2.调用真正的xhr方法
   this.xhr[fun].apply(this.xhr, args);
 }

为了叙述清晰，我们假设fun为 send函数，其中funs为用户提供的拦截函数对象。代码很简单，首先会根据用户提供的funs判断用户是否要拦截send, 如果提供了send的拦截方法，记为send_hook, 则上层调用代理对象send方法时，则会先调用send_hook，同时将调用参数和当前的xhr对象传递给send_hook，如果send_hook返回了true, 则调用终止，直接返回，相当于调用被终止了，如果没有返回或返回的是false,则会走到注释2处，此处调用了xhr的send方法，至此ajax send被调用成功。 所以，我们在send_hook中可以拿到调用的参数并修改，因为参数是以数组形式传递，改变会被记录，当然，我们也可以返回true直接终止调用。

代理属性

属性如onload、onreadystatechange等，上层在调用ajax时通常要设置这些回调以处理请求到的数据，Ajax-hook也能够实现在请求返回时先拿到数据第一个进行处理，然后将处理过的数据传递给用户提供的回调。要实现这个功能，直接的思路就是用户设置回调时将用户提供的回调保存起来，然后设置成代理回调，当数据返回时，代理回调会被调用，然后在代理回调中首先将返回的数据提供给拦截函数处理，然后再将处理后的数据传递给用户真正的回调。那么问题来了，如何捕获用户设置回调的动作？一段典型的用户调用代码如下：

1
2
3
4
5

var xh=new XMLHttpRequest;
xh.open("https://xxx")
xh.onload=function(data){ //1
  //处理请求到的数据
}

也就是说上面代码1处的赋值时机代理对象怎么捕获？如果在赋值的时候有机会执行代码就好了。我们回过头来看看上面原理图，有没有注意到proxy props后面的小括号里的 es5，答案就在这里！ es5中对于属性引入了setter、getter,详细内容请参考：
Javascript getter: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/get
Javascript setter: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/set

Ajax-hook通过getFactory和setFactory生成setter、getter方法。我们来看看它们的实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

function getFactory(attr) {
    return function () {
        return this[attr + "_"] || this.xhr[attr]
    }
}

function setFactory(attr) {
    return function (f) {
        var xhr = this.xhr;
        var that = this;
        //区分是否回调属性
        if (attr.indexOf("on") != 0) {
            this[attr + "_"] = f;
            return;
        }
        if (funs[attr]) {
            xhr[attr] = function () {
                funs[attr](that) || f.apply(xhr, arguments);
            }
        } else {
            xhr[attr] = f;
        }
    }
}

代码比较简单，值得注意的是里面的属性加下划线是什么意思？请继续往下看。

属性修改

1

xhr.responseText = JSON.parse(xhr.responseText)

但是，这里有坑，因为xhr的responseText属性并不是writeable的（详情请移步 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty ),这也就意味着你无法直接更改xhr.responseText的值，而Ajax-hook也代理了这些原始属性，内部生成了一下原始属性名＋下滑线的代理属性。

至此，Ajax-hook源码分析完毕。下面我们总结一下：

Ajax-hook使用代理的方式对原生XMLHttpRequest的方法及属性进行代理，然后覆盖全局XMLHttpRequest，实现拦截所有Ajax-hook的功能。从代码角度来看，逻辑清晰，思维巧妙，简洁优雅，值得学习。

HTML & CSS 部分1

• css常用布局
  定位布局，流布局，浮动布局，flex和grid布局，包括还有三栏布局中的圣杯和双飞翼
  使用flex实现垂直水平居中

• BFC
  盒模型包括怪异盒模型，如何转换 box-sizing

• session、cookie、sessionStorage、localStorage等区别

• animation和transiton的相关属性
  为什么动画推荐用c3而不是js，主要是性能方面….浏览器怎么优化的动画

JavaScript部分

• JavaScript闭包

• 前端跨域
  CORS怎么实现的

• JavaScript继承
  原型继承、构造函数继承、组合继承、寄生组合继承优缺点和实现方式，es5如何实现super关键字

• JavaScript的节流和防抖

• js事件执行机制
  event loop，microtask，task queue : 任务队列、执行栈
  然后事件委托、捕获、冒泡、目标阶段
  target和currentTarget

• this指向的问题
  四种绑定规则，new的执行过程以及箭头函数注意事项

• es6相关知识点
  promise的实现方式；
  generator怎么实现；

• JavaScript 中的匿名递归

  阅读全文 »

概念解释

函数节流和函数防抖，两者都是优化高频率执行js代码的一种手段。
 大家大概都知道旧款电视机的工作原理，就是一行行得扫描出色彩到屏幕上，然后组成一张张图片。由于肉眼只能分辨出一定频率的变化，当高频率的扫描，人类是感觉不出来的。反而形成一种视觉效果，就是一张图。就像高速旋转的风扇，你看不到扇叶，只看到了一个圆一样。
 同理，可以类推到js代码。在一定时间内，代码执行的次数不一定要非常多。达到一定频率就足够了。因为跑得越多，带来的效果也是一样。倒不如，把js代码的执行次数控制在合理的范围。既能节省浏览器CPU资源，又能让页面浏览更加顺畅，不会因为js的执行而发生卡顿。这就是函数节流和函数防抖要做的事。

 函数节流是指一定时间内js方法只跑一次。比如人的眨眼睛，就是一定时间内眨一次。这是函数节流最形象的解释。
 函数防抖是指频繁触发的情况下，只有足够的空闲时间，才执行代码一次。比如生活中的坐公交，就是一定时间内，如果有人陆续刷卡上车，司机就不会开车。只有别人没刷卡了，司机才开车。

引言

UI 组件中有很多弹出式组件，常见的如 Dialog，Tooltip 以及 Select 等。这些组件都有一个特点，它们的弹出层通常不是渲染在当前的 DOM 树中，而是直接插入在 body （或者其它类似的地方）上的。这么做的主要目的是方便控制这些弹出层的 z-index ，确保它们能够处于合适的层级上，不至于被遮挡。

我们都知道 React App 的顶层某个地方肯定有这么一行代码：ReactDOM.render(<App />, mountNode)，这个 API 调用的作用是在 mountNode 的位置创建一棵 React 的渲染树，React 会接管 mountNode 开始的这棵 DOM 树。

在 React 的这种管理模式下，会发现使用弹层似乎不太方便，因为组件树是逐层往下生长的，但React 的 API 中并没有直接提供跳出这棵组件树的方法。

所以，为了实现弹层组件，我们需要先实现一个 Portal 组件，这个组件只做一件事：将组件树中某些节点移出当前的DOM 树，并且渲染到指定的 DOM 节点中, 并且可以维持组件的上下文和事件冒泡。

Ant Design(AntD)是React的一种UI组件。开发中使用AntD的Modal,在处理用户处理事务,在当前页面弹出一个对话框,承载相应的操作。现在来看看AntD的实现原理

先写列出部分Modal基本用法:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

render() {
    return (
      <div>
        <Button type="primary" onClick={this.showModal}>Open a modal dialog</Button>
        <Modal title="Basic Modal" visible={this.state.visible}
          onOk={this.handleOk} onCancel={this.handleCancel}
        >
          <p>some contents...</p>
          <p>some contents...</p>
          <p>some contents...</p>
        </Modal>
      </div>
    );
  }
//----------------
ReactDOM.render(<App />,mountNode)

这样即可使用模态对话框组件。
打开浏览器的开发者功能可以看到对话框的div始终在body内层中，而不是在mountNode内部。当然模态对话框本就应该存在body内存中，而不是任意其他组件元素内部,否则嵌套效果不好，添加动画会招来性能问题。
这是为什么？
从AntD的Modal组件源码中(components/modal/index.tsx)，可以看到如下代码：

1
2
3
4
5
6
7
8
9

import confirm from './confirm';
Modal.success = function (props: ModalFuncProps) {
  const config = assign({}, {
    type: 'success',
    iconType: 'check-circle',
    okCancel: false,
  }, props);
  return confirm(config);
};

当Modal加载成功后，还需要进一步从confirm(config)获取组件。
我们进一步查看confirm,在confirm.tsx(components/modal/confirm.tsx)可以看到如下源码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

let div = document.createElement('div');
document.body.appendChild(div);
//......
ReactDOM.render(
  <Dialog
    className={classString}
    onCancel={close.bind(this, { triggerCancel: true })}
    visible
    title=""
    transitionName="zoom"
    footer=""
    maskTransitionName="fade"
    maskClosable={maskClosable}
    style={style}
    width={width}
  >
    <div className={`${prefixCls}-body-wrapper`}>
      {body} {footer}
    </div>
  </Dialog>
, div);

最后再次使用ReactDOM.render()在创建的div内部添加对话框。
同时这是说明,ReactDOM.render()并不是只有在顶层要嵌入的div中使用。内部同样可以再次使用。

！！！但是，ReactDOM.render()方法，虽然可以实现组件的挂载点脱离父组件，但是组件的事件无法通过冒泡机制传递给父组件，也就是说如果挂载点div脱离了顶层root组件(<App />)，那么挂载在div上面的组件也没办法使用redux。

那么为什么Antd-Modal到底是怎么实现的呢？ 原因是Antd-Modal里面使用了rc-dialog 组件，里面的DialogWrap组件使用了rc-util这个库的ContainerRender.js和Portal.js方法，这个库解决了 ‘组件的挂载点虽然可以脱离父组件，但组件的事件通过冒泡机制仍可以传给父组件’ 问题

详情请看下一篇博客>>

webpack 是模块打包系统, 代码分割, 加载器, 聪明的解析, 以及插件系统是它的特色
https://webpack.github.io/docs/configuration.html //config配置

cli 参数

• –hot 代码热更新
• –progress 有tab栏
• –watch 实时监控
• -debug 调试

loaders

加载器的使用, 加载器可以配置query参数并可以链式调用, 本质上是纯函数, 遵循单一职责原则
https://webpack.github.io/docs/list-of-loaders.html
https://webpack.github.io/docs/loader-conventions.html

devTools

webpack-dev-server / webpack-dev-middleware / koa-webpack-dev

codeSplitting 代码分割

定义分割点
CommonJS: require.ensure
AMD: require

1
2
3
4
5
6
7
8
9
10

require.ensure(["./file"], function(require) {
  require("./file2");
});

// is equal to

require.ensure([], function(require) {
  require.include("./file");
  require("./file2");
});

一些优化

最小化

new webpack.optimize.UglifyJsPlugin() // 压缩
new webpack.optimize.OccurrenceOrderPlugin() //排序输出

删除重复数据

new webpack.optimize.DedupePlugin()

设置分块传输大小和数目

new webpack.optimize.LimitChunkCountPlugin({maxChunks: 15})
new webpack.optimize.MinChunkSizePlugin({minChunkSize: 10000})

增量更新

webpack-dev-server/webpack-dev-middleware/webpack –watch or watch: true

不解析

noParse

SourceMap (使调试更容易）

• devtool: “source-map” 在一个单独的文件中产生一个完整且功能完全的文件。这个文件具有最好的source map，但是它会减慢打包速度；
• devtool: “cheap-module-source-map” 在一个单独的文件中生成一个不带列映射的map，不带列映射提高了打包速度，但是也使得浏览器开发者工具只能对应到具体的行，不能对应到具体的列（符号），会对调试造成不便；
• devtool: “eval-source-map” 使用eval打包源文件模块，在同一个文件中生成干净的完整的source map。这个选项可以在不影响构建速度的前提下生成完整的sourcemap，但是对打包后输出的JS文件的执行具有性能和安全的隐患。在开发阶段这是一个非常好的选项，在生产阶段则一定不要启用这个选项；
• devtool: “cheap-module-eval-source-map” 这是在打包文件时最快的生成source map的方法，生成的Source Map 会和打包后的JavaScript文件同行显示，没有列映射，和eval-source-map选项具有相似的缺点；

正如上表所述，上述选项由上到下打包速度越来越快，不过同时也具有越来越多的负面作用，较快的打包速度的后果就是对打包后的文件的的执行有一定影响。

cheap-module-eval-source-map方法构建速度更快，但是不利于调试，推荐在大型项目考虑时间成本时使用。

对小到中型的项目中，eval-source-map是一个很好的选项，再次强调你只应该开发阶段使用它

模块 和 依赖位置

RESOLVE.ROOT VS RESOLVE.MODULESDIRECTORIES

单页应用

初始加载的应该是路由和首页, 然后再加载其他页

1
2

<script src="entry-chunk.js" type="text/javascript" charset="utf-8"></script>
<script src="3.chunk.js" type="text/javascript" charset="utf-8"></script>

多页应用

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

var CommonsChunkPlugin = require("webpack/lib/optimize/CommonsChunkPlugin");
module.exports = {
    entry: {
        p1: "./page1",
        p2: "./page2",
        p3: "./page3",
        ap1: "./admin/page1",
        ap2: "./admin/page2"
    },
    output: {
        filename: "[name].js"
    },
    plugins: [
        new CommonsChunkPlugin("admin-commons.js", ["ap1", "ap2"]),
        new CommonsChunkPlugin("commons.js", ["p1", "p2", "admin-commons.js"])
    ]
};

或

1
2
3
4
5
6
7
8
9
10
11
12

//  commons chunk
var CommonsChunkPlugin = require("webpack/lib/optimize/CommonsChunkPlugin");
module.exports = {
    entry: {
        p1: "./page1",
        p2: "./page2",
        commons: "./entry-for-the-commons-chunk"
    },
    plugins: [
        new CommonsChunkPlugin("commons", "commons.js")
    ]
};

官方建议场景

应用性能

• 尽量使用UglifyJsPlugin减少文件体积
• 使用代码分割, 使首次加载尽可能快速
• 对于React, 使用 react-proxy-loader
• 添加 hash 到文件, 并尽可能长时间缓存
• 使 module/chunk 的ID尽可能保持一致
• 如果有静态页面, 使用 html-webpack-plugin
• 不要立即删除无用的资源(等待数周), 以免长时间保持浏览器窗口打开的用户 404
• 使用DefinePlugin来配置应用(是否内联, 各种条件配置)
• 使用EnvironmentPlugin来传递process.env到应用
• 使用包分析工具来检查问题, 减小下载时间, 改进内聚性
• 使用stats-webpack-plugin获取状态
• 使用配置文件option来获取更多性能数据
• 提取通用模块到单独的script文件(多页应用)
• 使用DedupePlugin来删除与NPM重复的数据
• 对CSS做处理
• 对静态资源做处理(font/image)
• 内联静态资源url-loader,减少加载时间
• 用extract-text-webpack-plugin来分割CSS资源(有很多css资源的应用)
• LimitChunkCountPlugin MinChunkSizePlugin AggressiveMergingPlugin来改善chunk传输
• 通过添加script标签来异步chunk的加载

开发性能

• 使用 webpack.config.js 代替 CLi
• 不要重写不兼容的JS, 使用 imports-loader/exports-loader 使之兼容, 并且更易升级
• 使用 webpack devtools 来在浏览器调试
• 尽可能使用 ES6 模块加载方式, 这更易于未来的优化(webpack2支持)
• 使用 output.library 来声明依赖
• 使用 externals 来对外声明依赖
• 使用 HMR 代码热更新
• 对于 React 使用 react-hot-loader 或 react-transform
• 自定义路由, 最好在路由级别更新
• 使用Javascript来书写配置文件
• 使用resolve.root来配置应用模块的路径, 允许较短的引用关系
• 使用karma 通过 karma-webpack来在浏览器测试模块
• 面向环境构建, 而不是面向浏览器构建
• 使用BannerPlugin来放置Licensing
• 通过debug来获取更多的出错信息
• 在module.loaders中使用include而不是exclude, 这样更不容易出错更加清晰

构建性能

• 使用增量备份 如果 watch 网络或VM内部的代码,请使用 watchOptions.poll
• 使用 web-dev-server 可以快速构建发布
• 使用多个 入口点 , 而不是多次运行 webpack(多页应用)
• 通过配置一个数组配置, 使webpack可以并行编译(大型配置复杂的应用)
• 大型无依赖的模块要配置module.noParse, 可以更快构建

应用

分割App中的共有模块和代码模块

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var webpack = require("webpack");

module.exports = {
  entry: {
    app: "./app.js",
    vendor: ["jquery", "underscore", ...],
  },
  output: {
    filename: "bundle.js"
  },
  plugins: [
    new webpack.optimize.CommonsChunkPlugin(/* chunkName= */"vendor", /* filename= */"vendor.bundle.js")
  ]
};

1
2

<script src="vendor.bundle.js"></script>
<script src="bundle.js"></script>

多入口文件分割

1
2
3
4
5
6

var webpack = require("webpack");
module.exports = {
    entry: { a: "./a", b: "./b" },
    output: { filename: "[name].js" },
    plugins: [ new webpack.optimize.CommonsChunkPlugin("init.js") ]
}

1
2
3

<script src="init.js"></script>
<script src="a.js"></script>
<script src="b.js"></script>

CSS样式单独切成独立文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

// webpack.config.js
var ExtractTextPlugin = require("extract-text-webpack-plugin");
module.exports = {
    // The standard entry point and output config
    entry: {
        posts: "./posts",
        post: "./post",
        about: "./about"
    },
    output: {
        filename: "[name].js",
        chunkFilename: "[id].js"
    },
    module: {
        loaders: [
            // Extract css files
            {
                test: /\.css$/,
                loader: ExtractTextPlugin.extract("style-loader", "css-loader")
            },
            // Optionally extract less files
            // or any other compile-to-css language
            {
                test: /\.less$/,
                loader: ExtractTextPlugin.extract("style-loader", "css-loader!less-loader")
            }
            // You could also use other loaders the same way. I. e. the autoprefixer-loader
        ]
    },
    // Use the plugin to specify the resulting filename (and add needed behavior to the compiler)
    plugins: [
        new ExtractTextPlugin("[name].css")
    ]
}

// posts.js posts.css
// post.js post.css
// about.js about.css
// 1.js 2.js (包含嵌入式的样式)

所有的CSS文件合并成1个文件, allChunks设置成true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

module.exports = {
    // ...
    plugins: [
        new ExtractTextPlugin("style.css", {
            allChunks: true
        })
    ]
}
// You’ll get these output files:

// posts.js
// post.js
// about.js
// 1.js 2.js (don’t contain embedded styles)
// style.css

公共样式会被抽出来

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

module.exports = {
    // ...
    plugins: [
        new webpack.optimize.CommonsChunkPlugin("commons", "commons.js"),
        new ExtractTextPlugin("[name].css")
    ]
}
// You’ll get these output files:

// commons.js commons.css
// posts.js posts.css
// post.js post.css
// about.js about.css
// 1.js 2.js (包含内置样式)

// 如果 allChunks: true
// 1.js 2.js (不含内置样式)

场景

文件过大

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

entry: {
    topic:'./src/components/app/topic.js'
    activity: './src/components/app/activity.js',
    react: ['react'],
    jquery: ['jquery']
},
plugins:[
    new CommonsChunkPlugin({
        name: ['jquery', 'react'], //提取公共模块
        minChunks: Infinity //提取所有entry依赖模块
        }),
    new webpack.optimize.UglifyJSPlugin({
        compress: {
            warinings: false
        }
        })
]

文件缓存

1
2
3
4
5

output: {
    path: __dirname + '/release/',
    filename: '[chunkFilename:8].[name].js',
    chunkFilename: '[name].[chunkFilename:8].js'
}

自动生成页面

使用 HtmlWebpackPlugin 和 ExtractTextPlugin 插件可以解决此问题。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

plugins: [
    new HtmlWebpackPlugin({
        filename: 'topic.html',
        template: __dirname + '/src/app.html',
        inject: true,
        chunks: ['react', 'jquery', 'topic'],
        //排序
        chunksSortModel: function (a, b) {
            var index = {'topic': 1, 'react': 3, 'jquery': 2},
              aI = index[a.origins[0].name],
              bI = index[b.origins[0].name];
            return aI && bI ? bI - aI : 1;
        }
    }),
    new ExtractTextPlugin('comm.[contenthash:8].css')
]

异步加载

1
2
3
4

require.ensure([], function()){
    var dialog = require('../../widget/dialog'),
    $ = require('jquery')
}

真正学会 React 是一个漫长的过程。

你会发现，它不是一个库，也不是一个框架，而是一个庞大的体系。想要发挥它的威力，整个技术栈都要配合它改造。你要学习一整套解决方案，从后端到前端，都是全新的做法。

举例来说，React 不使用 HTML，而使用 JSX 。它打算抛弃 DOM，要求开发者不要使用任何 DOM 方法。它甚至还抛弃了 SQL ，自己发明了一套查询语言 GraphQL 。当然，这些你都可以不用，React 照样运行，但是就发挥不出它的最大威力。
这样说吧，你只要用了 React，就会发现合理的选择就是，采用它的整个技术栈。
本文介绍 React 体系的一个重要部分：路由库[React-Router](https://github.com/reactjs/react-router)。它是官方维护的，事实上也是唯一可选的路由库。它通过管理 URL，实现组件的切换和状态的变化，开发复杂的应用几乎肯定会用到。

（[说明] 本文写作时，React-router 是 2.x 版，本文的内容只适合这个版本，与最新的 4.x 版不兼容。目前，官方同时维护 2.x 和 4.x 两个版本，所以前者依然可以用在项目中。2017年3月）

基本用法

React Router 安装命令如下。

1

$ npm install -S react-router

使用时，路由器Router就是React的一个组件。

1
2

import { Router } from 'react-router';
render(<Router/>, document.getElementById('app'));

Router组件本身只是一个容器，真正的路由要通过Route组件定义。

1
2
3
4
5
6
7

import { Router, Route, hashHistory } from 'react-router';

render((
  <Router history={hashHistory}>
    <Route path="/" component={App}/>
  </Router>
), document.getElementById('app'));

上面代码中，用户访问根路由/（比如http://www.example.com/），组件APP就会加载到document.getElementById('app')。
你可能还注意到，Router组件有一个参数history，它的值hashHistory表示，路由的切换由URL的hash变化决定，即URL的#部分发生变化。举例来说，用户访问http://www.example.com/，实际会看到的是http://www.example.com/#/。

Route组件定义了URL路径与组件的对应关系。你可以同时使用多个Route组件。

1
2
3
4
5

<Router history={hashHistory}>
  <Route path="/" component={App}/>
  <Route path="/repos" component={Repos}/>
  <Route path="/about" component={About}/>
</Router>

上面代码中，用户访问/repos（比如http://localhost:8080/#/repos）时，加载Repos组件；访问/about（http://localhost:8080/#/about）时，加载About组件。