wip

前言

前段时间在看这篇文章 [译] React性能优化-虚拟Dom原理浅析 时发现了一些非常有意思的知识点，之前并没有考虑过，大家可以先看一下这篇文章，写的非常好，翻译的也很好。本文将对其中涉及到 unmount & re-mount 的地方展开分析。

JSX的作用

在展开讲之前，我们先重新了解 JSX，JSX 并不审美，它只是一个弱弱的语法糖，所谓语法糖：

语法糖（Syntactic sugar），也译为糖衣语法，是由英国计算机科学家彼得·蘭丁发明的一个术语，指计算机语言中添加的某种语法，这种语法对语言的功能没有影响，但是更方便程序员使用。 语法糖让程序更加简洁，有更高的可读性。

看下 Babel 对 JSX 的转义就知道了。

JSX 代码如下：

const Button = (props) => <div>btn</div>

let x = <Button />

被转义后的 JS 代码如下（其实老版本的 React 就是这么写的）：

"use strict";

var Button = function Button(props) {
  return React.createElement(
    "div",
    null,
    "btn"
  );
};

var x = React.createElement(Button, null);

React.createElement 的函数签名如下

React.createElement(
  type,
  [props],
  [...children]
)

createElement 接受不限定个参数

• 第一个是元素的 type。对于HTML标签，它将是一个带有 标签名称 的字符串。对于自定义组件，它将是对应组件的引用（这点很重要，后面会讲到，语法糖在带来代码编写效率提升的同时，也会将细节隐藏掉，所以开发者有时会不理解其中的细节）。
• 第二个参数是所有传入的 props 的对象的集合。
• 剩下的参数都可以认为是元素的子元素（children）。最终所有的子元素都会被通过 … 组合成一个 children 的数组。

针对可以传入 children 的子元素，可以有以下值：

• 基本类型 false, null, undefined, true
• 数组
• React Components

这么一看，似乎 children 是很特殊的一个参数，但是我们经常会写出 this.props.children 这样的参数，也就是说在 React 内部，children 也是 props 的一部分，

为了简化理解，我们可以看 React 15.0 版本（之后的版本加入了 Fiber）的 VDOM 的结构，其中，绿色框内的就是一个 VDOM 的结构。

（这里要注意，最外面的那个 _MyNode 并不是 VDOM，它是组件中的 this，我们一般称之为实例化对象，它的 render 中返回的值将会被用来生成真正的 VDOM。如果你还不信，那么想一下，真正的 VDOM 会有 shouldComponentWillUpdate 这种生命周期函数吗？）

所以，一个简略版的 React 的 VDOM 模型大致可以描述为：

{
  type: 'div',
  props: {
    className: 'cn',
    children: [
      'Content 1!',
      'Content 2!'
    ]
  }
}

reconciler

再重复一下 React 的 reconciler 的原则，深入React技术栈 中这本书已经说得很好了，这里再整理一下。

• tree diff

  基于实际的浏览器中 DOM 变化的特点，我们可以认为 DOM 很少会跨层级移动，每次的变更都是某节点的变化，或者某节点的子节点的变化，所以基于次特点，diff 时只对相同层级的节点进行比较。

  

• component diff

  • 如果是同一类型的组件，按照原策略继续比较 virtual DOM tree。
  • 如果不是，则将该组件判断为 dirty component，从而替换整个组件下的所有子节点。
  • 对于同一类型的组件，有可能其 Virtual DOM 没有任何变化，如果能够确切的知道这点那可以节省大量的 diff 运算时间，因此 React 允许用户通过 shouldComponentUpdate() 来判断该组件是否需要进行 diff。

• element diff

  这里可以说是 diff 算的核心，通过 INSERT_MARKUP（插入），MOVE_EXISTING（移动） 和 REMOVE_NODE（删除）来完成最小化的更新，具体的不在这里展开。

key

我们都知道，在显示的返回一个数组时，数组中的每个子元素要有一个稳定的，独一无二的 key 来标明每个子元素的“身份”，标明身份是为了让 React 的 reconciler 的效率获得提升。

我们来看两个个例子：

同级变动，有 key

B C 是同级节点，并且都有独特的 key，如果我问从左到右真实 DOM 是如何变化的？那么你肯定能说出来 B 不变，C 被移除了。没错，VDOM 的变化最后会 patch 到真实 DOM 上，在这里由于有 key，所以 React 可以知道 B 是没有变化的，只需要移除一个 C 即可。

同级变动，无 key

还是上面的那个图，这一次，B 和 C 没有 key 了，真实 DOM 会如何变化？我改了一个小 DEMO，打印了它们的生命周期，我们先来看下打印的结果：

答案是：先创建一个新的 B，再将原来的 B 和 C 移除，最后将新的 B 放在 A 的下面，因为 B 和 C 对 React 来说根本就分别不出来，React 的 diff 算法就是会把他们先卸载掉再重新生成加载。

思考

你可能会说，我平时都会写 key 的。React 也会在控制台对数组形式的子元素提示需要添加 key。但是非数组形式的则完全不会提示，如下两个组件。可以是一模一样，从 Babel 转义来看也几乎相同，唯一的区别就是，Arr2 返回的子元素是以数组形式包裹的而 Arr1 则是一个个参数。但是没关系，他们最后都会被 … 打包成一个 children 的组件，数组形式的子元素一方面是方便我们的书写，一方面是可以让 React 提示我们要加 key。所以会不会有那么一种情况，就是虽然我们的本意不是写一个不带 key 的数组，但是无意中写出了这种反模式的代码呢？

避免 unmount & re-mount

不必要的 unmount & re-mount 不仅会让其丢失自身的 state，还会带来性能上的负担。因为它不仅会在 VDOM 上进行 diff（其实 VDOM 上 diff 的负担会变少，因为直接卸载再重装其实很简单，真正的负担是真实 DOM），还会 patch 到真实 DOM 上，违背了 diff 最小化更新的原则。试想，一个有 10000 个条目的列表的真实 DOM 在每次更新时被 unmount 和 re-mount 带来的开销有多可怕。

手动辅助 reconciler

开头提到的那篇文章中有一个很有意思的案例，我在这里简单再重复一下：

就是有这么个组件

<div>
  <Message />
  <Table />
  <Footer />
</div>

Table 是个有很多项目的列表（其实是什么无所谓，只是为了强调 Table 如果被 unmount & re-mount 是开销很大的操作）。现在呢，比如我们的用户读完一个通知了，那么就可以移除 Message 这个组件。

React会怎么处理呢？它会看作是一个 array 类型的 children，现在少了第一项，从前第一项是 Message 现在是 Table 了，也没有 key 作为索引，比较 type 的时候又发现它们俩不是同一个 function 或者 class 的同一个实例，于是会把整个 Table unmount，然后再 re-mount 回去，重新渲染它大量的子数据。

我们上面的 key 的 demo 中，也印证了在没有 key 时 React 会“傻傻得”去 unmount & re-mount。

作者还很贴心的给出了解决方案：

1. 主动添加 key 辅助 React 进行辨别元素身份。
2. 使用基础类型占位，比如 isShown && <Message />，我们可以使用 true, false, null, undefined ，这些都是 JSX 允许的，它们本身不会被渲染什么，但是确实合格的 “占位符”。

但是我们平时在写类似这种需要移除的组建时，往往会写成一个表达式的形式，拿这个案例举例的话就是

<div>
    {this.state.doesShow ? <Message onClickHandler={this.remove}/> : null}
    <Table />
    <Footer />
</div>

这种表达式的写法自然而然的符合原文作者通过添加一个基础类型占位符来辅助 diff 的思路，笔者之前只是认为 null 表达的是不渲染任何东西（当然用 false 什么的也可以的，但是这里 null 更符合语意），其实 null 还有另一个重要作用就是辅助 diff。

既然如此，那么什么时候我们会陷入作者写的这个坑中的呢？

笔者能想到的一个点是"更换样式"，比如很多网站都有，点击更换样式（不只是颜色，也会涉及到 DOM 的更改）。但是要注意，React 对相同位置不同类型的组件会直接卸载掉旧的组件然后加载一个新的组件，直接就没有子元素啥事了。

还是拿之前的那个例子举例，假设这是样式1

<Style1 data={...}>
  <Message />
  <Table />
  <Footer />
</Style1>

这是样式2

<Style2 data={...}>
  <Table />
  <Message />
</Style2>

如果直接替换掉，那么由于 Style1 和 Style2 类型不同，Style1 会被直接卸载掉，Style2 再重新加载。

如果不想被直接替换掉，我们可以剥离掉最外层的样式组件，在渲染时直接执行来展开子元素们：

  style1 = () => (
    <div data={...}>
      <Message key="message"/>
      <Table key="table"/>
      <Footer key="footer"/>
    </div>
  )

  style2 = () => (
    <div data={...}>
      <Table key="table"/>
      <Message key="message"/>
    </div>
  )

在父组件中：

{this.state.style === 'style1' ? this.style1() : this.style2() }

这样的确可以减少 unmount & re-mount 的次数，但是也会带来一些弊端：1. 如果嵌套的很复杂的组件将比较难分离出来。 2. 数据的传递变得更加复杂了。 3. 组件间的耦合变重了。

避免引用丢失

文中还提到了一个 HOC 的坑，这里再简要复述一下这个坑：

我们会经常这样写 HOC（事实上，这是很常见的一种 HOC，比如 react-router 的 withRouter 就是这样）

function withName(SomeComponent) {
  // Computing name, possibly expensive...
  return function(props) {
    return <SomeComponent {...props} name={name} />;
  }
}

然后在父组件中如此调用：

class App extends React.Component() {
  render() {
    // Creates a new instance on each render
    const ComponentWithName = withName(SomeComponent);
    return <ComponentWithName />;
  }
}

或者，如此调用：

// Creates a new instance just once
const ComponentWithName = withName(Component);

class App extends React.Component() {
  render() {
    return <ComponentWithName />;
  }
}

看起来差不多，但其实如果父组件 re-render，第一种方法创建的 HOC 是会 unmount & re-mount 的。有的朋友读到这里可能会说不对啊，根据前面的 component 的 diff 的原则，前后两次 render 在 React.createElement 中的 type 都是 ComponentWithName。但是仔细看啊，当 type 为一个自定义的组件的时候，type 将不是一个字符串，而是一个指向对应的函数的引用。所以虽然都是 ComponentWithName，但是 re-render 时的引用已经改变。这对 React 来说会认为是换了一个类型的节点，所以直接将旧节点 unmount，新节点 re-mount，突突突突，一堆老的真实 DOM 被卸载，一堆新的真实 DOM 被装载。

总结

还是那两句话。

• 80%的性能问题出现在20%的地方。（好像是这么说的，大概意思明白就好了，要对性能瓶颈进行优化）
• 过早的优化是万恶之源。（很可能你费了很长时间写了个性能超牛逼的组件然后发现：唉不对，写错了，这个组件没用了要换，那就白写了，不过在满足业务的同时造高性能轮子是很好的，不过那就是另外一件事了。就像画素描，也都是从轮廓草图开始一层层的让细节更丰富。以写业务代码来说的角度来说提前做性能优化很可能导致无用功，在写代码的时候尽可能遵循一些最佳实践即可。）

• 策略模式（Strategy）
• 状态模式（State）
• 责任链模式（Chain of Responsibility）
• 解释器模式（Interpreter）
• 命令模式（Command）
• 观察者模式（Observer）
• 备忘录模式（Memento）
• 迭代器模式（Iterator）
• 模板方法模式（Template Method）
• 访问者模式（Visitor）
• 中介者模式（Mediator）

前言

ES2015+ 有各种新特性（语法糖），尽管有很多特性尚未纳入标准或浏览器还没有原生支持，但是 Babel 的出现让前端可以不用担心兼容性问题而使用处于各种 stage 的 ES2015+ 语法。其实 class 关键字目前只是实现类的语法糖，但是可以帮助我们屏蔽掉每次实现类时的样本代码，逻辑更加清晰，并且阻止我们踩可能存在的坑，本篇文章从 ES5 的类实现到 ES6 中class 的 Babel 转码来分析类的实现与继承。

类

在 JavaScript 中，我们希望一个类能有以下特性：

1. 实例的属性是绑定在每个实例上的
2. 方法是绑定在这个类的 prototype 上的
3. 对实例进行 Object.getPrototypeOf 能拿到 constructor 的 prototype
4. 实例 instanceof 构造函数返回 true
5. 类的静态属性/方法

ES5 实现类

ES5 中的类是通过 构造函数模式 + 原型模式 实现的。

function Animal(name) {
  this.name = name // 不共享实例属性
}

Animal.prototype.barking = function() {
    console.log(this.name + ' : ah!') // 共享方法
 }

Animal.hello = function() {
    console.log('hello animal')
}

以上几点都是实现了的，但是缺点就是封装性不好，样本代码多，这只是简陋版的实现，不过思路就是这样。

ES6 的 class

class Animal {
    // 构造函数
    constructor(name){
    	this.name = name
    }
    // 类的实例属性
    age = 1
	// 类的实例方法
    sayAge = function(){
		console.log(this.age)
    }
    // 类的方法
    barking () {
    	console.log(this.name + ' : ah!')
    }
	// getter
	get description () {
    	return 'description: ' + this.name;
  	}
	// 类的静态属性
	static id = 27
 	// 类的静态方法
 	static hello() {
    	console.log('hello animal ' + this.id)
    }
}

相当简洁了，整个类的声明都在一起，接下来我们看一下 Babel 编译出来的代码：

'use strict';

var _createClass = function () {
  function defineProperties(target, props) {
    for (var i = 0; i < props.length; i++) {
      var descriptor = props[i];
      descriptor.enumerable = descriptor.enumerable || false;
      descriptor.configurable = true;
      if ("value" in descriptor) descriptor.writable = true;
      Object.defineProperty(target, descriptor.key, descriptor);
    }
  }
  return function (Constructor, protoProps, staticProps) {
    if (protoProps) defineProperties(Constructor.prototype, protoProps);
    if (staticProps) defineProperties(Constructor, staticProps);
    return Constructor;
  };
}();

function _classCallCheck(instance, Constructor) {
  if (!(instance instanceof Constructor)) {
    throw new TypeError("Cannot call a class as a function");
  }
}

var Animal = function () {
  // 构造函数
  function Animal(name) {
    _classCallCheck(this, Animal);

    this.age = 1;

    this.sayAge = function () {
      console.log(this.age);
    };

    this.name = name;
  }
  // 类的实例属性

  // 类的实例方法


  _createClass(Animal, [{
    key: 'barking',

    // 类的方法
    value: function barking() {
      console.log(this.name + ' : ah!')
    }
    // getter

  }, {
    key: 'description',
    get: function get() {
      return 'description: ' + this.name;
    }
    // 类的静态属性

  }], [{
    key: 'hello',

    // 类的静态方法
    value: function hello() {
      console.log('hello animal ' + this.id);
    }
  }]);

  return Animal;
}();

Animal.id = 27;

下面开始分析：

'use strict';

使用严格模式的原因阮老师在 ECMAScript 6 入门 中有解释，这里直接贴一下：

类和模块的内部，默认就是严格模式，所以不需要使用use strict指定运行模式。只要你的代码写在类或模块之中，就只有严格模式可用。
考虑到未来所有的代码，其实都是运行在模块之中，所以 ES6 实际上把整个语言升级到了严格模式。

先从主函数入手

  function Animal(name) {
    _classCallCheck(this, Animal);
    this.age = 1;
    this.sayAge = function () {
      console.log(this.age);
    };

    this.name = name;
  }

  _createClass(Animal, [{
    key: 'barking',
    value: function barking() {
      console.log(this.name + ' : ah!')
    }
  }, {
    key: 'description',
    get: function get() {
      return 'description: ' + this.name;
    }
  }], [{
    key: 'hello',
    value: function hello() {
      console.log('hello animal ' + this.id);
    }
  }]);

  return Animal;

先执行构造函数，首先调用 _classCallCheck 用来确保类是通过 new 作为构造函数调用而不是直接调用，如果是直接调用则直接报错。

然后是在构造函数里绑定实例的属性和方法 —— age（直接写入类的定义的实例属性），sayAge（直接写入类的定义的实例方法），name （构造函数中的实例属性）。这里要注意，直接写入类的定义的实例属性/方法要先于构造函数中的实例属性/方法执行，所以如果在直接写入类的定义的实例方法中获取构造函数中定义的属性/方法，会返回 undefined。

然后就是用 _createClass，接受两个参数：类、[绑定在类的prototype上的方法, 绑定在类上的静态方法]，作用是把方法绑定在对应的对象上。

var _createClass = function () {
  function defineProperties(target, props) {
    for (var i = 0; i < props.length; i++) {
      var descriptor = props[i];
      descriptor.enumerable = descriptor.enumerable || false; // 默认false，原型/静态方法不允许枚举
      descriptor.configurable = true; // 默认为false，设为true，否则一切属性都无法修改
      if ("value" in descriptor) descriptor.writable = true; // 默认false，设为true，方法都是可以可以被修改的
      Object.defineProperty(target, descriptor.key, descriptor);
    }
  }
  return function (Constructor, protoProps, staticProps) {
    if (protoProps) defineProperties(Constructor.prototype, protoProps);
    if (staticProps) defineProperties(Constructor, staticProps);
    return Constructor;
  };
}();

通过 Object.defineProperty 将各个方法绑定到 类的 prototype/类 上，Object.defineProperty 可以指定对象的属性，让类的原型方法/静态方法无法被枚举。

还有一点比较有意思的是，这里 _createClass 是 IIFE 的返回值，这样能做到不污染全局作用域，但是最后还是会有一个 _createClass，那是不是直接可以在声明一个 class 后调用 _createClass 呢？答案当然是不可以，如果你在源代码里访问或操作 _createClass，这个默认叫 _createClass 函数就会被改成 _createClass2，总之就是不让你访问到。

最后，再补上一个类的静态属性就完事大吉了：

Animal.id = 27;

但是类的静态属性也可以写成函数表达式的形式，这样的话类的静态方法就是可以枚举的了。

继承

ES5 的继承

function Animal(name) {
  this.name = name
}

Animal.prototype.barking = function() {
    console.log(this.name + ' : ah!')
 }

Animal.hello = function() {
    console.log('hello animal')
}

function Cat(name, breed) {
    Animal.call(this, name) // 已经生成了指向子类实例的this，再调用父类的构造函数
    this.breed = breed
}

// 直接拿到父类的prototype，避免多次调用父类的构造函数
Cat.prototype = Object.create(Animal.prototype, {
  constructor:{
    value: Square,
    enumerable: false,
    writeable: false,
    configurable: false
  }
}) 

Cat.prototype.barking = function(){
  var catPrototype = Object.getPrototypeOf(this) 
  var animalPrototype = Object.getPrototypeOf(catPrototype)
  animalPrototype.barking.call(this);
  console.log(this.name + ' : mew!')
}

var cat = new Cat('Tom', 'American shorthair')
console.log(cat.name) // "Tom"
console.log(cat.breed) // "American shorthair"
console.log(cat instanceof Animal) // "true"
console.log(cat instanceof Cat) // "true"
cat.barking() // "Tom : ah!" "Tom : mew!"

ES6 的继承

class Animal{
  constructor(name){
    this.name = name
  }
  
  barking () {
    console.log(this.name + ' : ah!')
  }
  
  static hello () {
    console.log('hello animal')
  }
}

class Cat extends Animal{
  constructor(name, breed){
    super(name)
	// 子类必须在constructor方法中调用super方法，否则新建实例时会报错。这是因为子类没有自己的this对象，而是继承父类的this对象，然后对其进行加工。如果不调用super方法，子类就得不到this对象。
    // ES5 的继承，实质是先创造子类的实例对象this，然后再将父类的方法添加到this上面（Parent.apply(this)）。
    // ES6 的继承机制完全不同，实质是先创造父类的实例对象this（所以必须先调用super方法），然后再用子类的构造函数修改this。 —— 阮老师的ES6教程
      // ↑↑↑ 这是按照ES6标准，但是目前的class只是语法糖，所以依旧是先创建一个子类的对象，在用父类的方法去加工 ↑↑↑
    this.breed = breed
  }
  
  barking(){
    super.barking()
    console.log(this.name + ' : mew!')
  }
  
  static hello () {
    super.hello()
    console.log('hello kitty')
  }
}

var cat = new Cat('Tom', 'American shorthair')
console.log(cat.name) // "Tom"
console.log(cat.breed) // "American shorthair"
console.log(cat instanceof Animal) // true
console.log(cat instanceof Cat) // true
cat.barking() // "Tom : ah!" "Tom : mew!"
Cat.hello() // "hello animal" "hello kitty"

Babel 编译后的代码太长了 ，我们只需要关注继承的类比不继承的类多了那些功能即可：

var Cat = function (_Animal) {  
	_inherits(Cat, _Animal); // 子类去继承父类，子类的原型去继承父类的原型

  function Cat(name, breed) {
    _classCallCheck(this, Cat);

    var _this = _possibleConstructorReturn(this, (Cat.__proto__ || Object.getPrototypeOf(Cat)).call(this, name)); // 先生成一个父类的构造函数返回 this

    _this.breed = breed; // 再用子类的构造函数去对这个 this 添加实例
    return _this;
  }

  _createClass(Cat, [{
    key: 'barking',
    value: function barking() {
      _get(Cat.prototype.__proto__ || Object.getPrototypeOf(Cat.prototype), 'barking', this).call(this); // 调用父类原型的barking方法
      console.log(this.name + ' : mew!'); // 再执行子类的barking方法
    }
  }], [{
    key: 'hello',
    value: function hello() {
      _get(Cat.__proto__ || Object.getPrototypeOf(Cat), 'hello', this).call(this); // 调用父类的hello静态方法
      console.log('hello kitty'); // 再执行子类的barking静态方法
    }
  }]);

  return Cat;
}(Animal);

所以一共就多了三个函数 _inherits、_possibleConstructorReturn 和 _get

先看_inherits

// 调用
_inherits(Cat, _Animal);

// 定义
function _inherits(subClass, superClass) {
  // 只能继承函数或者null
  if (typeof superClass !== "function" && superClass !== null) {
    throw new TypeError("Super expression must either be null or a function, not " + typeof superClass);
  }
  // subClass.prototype.__proto__ = superClass.prototype
  // 子类的原型继承父类的原型
  // subClass.prototype.constructor = subClass
  // 子类的构造函数指向子类
  subClass.prototype = Object.create(superClass && superClass.prototype, {
    constructor: {
      value: subClass,
      enumerable: false,
      writable: true,
      configurable: true
    }
  });
    // 子类继承父类
    // subClass.__proto__ = superClass
  if (superClass) Object.setPrototypeOf ? Object.setPrototypeOf(subClass, superClass) : subClass.__proto__ = superClass;
}

这个函数完成了三个重要的任务：

1. 子类的原型继承父类的原型
2. 子类原型的构造函数指向子类
3. 子类继承父类

至此，子类原型已近能够访问父类原型的方法了，子类也能够访问父类的静态方法。

再来看 _possibleConstructorReturn

//
var _this = _possibleConstructorReturn(this, (Cat.__proto__ || Object.getPrototypeOf(Cat)).call(this, name)); // 先生成一个父类的构造函数返回的this

// 两个参数，一个参数是指向子类实例的this，另一个参数是调用父类的构造函数返回的父类实例
function _possibleConstructorReturn(self, call) {
  if (!self) {
    throw new ReferenceError("this hasn't been initialised - super() hasn't been called");
  }
  // 如果父类返回的是对象或函数，则返回父类的构造函数生成的this，否则返回self
  return call && (typeof call === "object" || typeof call === "function") ? call : self;
}

作用是生成并返回一个调用父类的构造函数的this，再在主函数中用子类的构造函数进行加工。

再来看 _get

// 调用
_createClass(Cat, [{
    key: 'barking',
    value: function barking() {
      _get(Cat.prototype.__proto__ || Object.getPrototypeOf(Cat.prototype), 'barking', this).call(this);
      console.log(this.name + ' : mew!');
    }
  }] 
...

// 定义
var _get = function get(object, property, receiver) {
  if (object === null) object = Function.prototype;
  var desc = Object.getOwnPropertyDescriptor(object, property);
  if (desc === undefined) {
    var parent = Object.getPrototypeOf(object);
    if (parent === null) {
      return undefined;
    } else {
      return get(parent, property, receiver);
    }
  } else if ("value" in desc) { // 如果是普通方法
    return desc.value;
  } else { // 如果是getter
    var getter = desc.get;
    if (getter === undefined) {
      return undefined;
    }
    return getter.call(receiver);
  }
};

_get 接受三个参数，父类原型/父类，子类要 override 父类的方法，还有当前的子类实例。

但是要注意，再次强调，ES6 的 class 只是用 ES5 来实现的话就只是语法糖，因为还是无法完成原生构造函数的继承。

来自 Babel 的说明：

Built-in classes such as Date, Array, DOM etc cannot be properly subclassed due to limitations in ES5 (for the es2015-classesplugin). You can try to use babel-plugin-transform-builtin-extend based on Object.setPrototypeOf and Reflect.construct, but it also has some limitations.

测试：

class MyArray extends Array {
  constructor(...args) {
    super(...args);
  }
}

var arr = new MyArray();
arr[0] = 12;
console.log(arr.length) // 理想输出：1 实际输出：0

arr.length = 0;
console.log(arr[0]) // 理想输出：undefined 实际输出：12

总结

到这里，Babel 编译的代码就分析完了，下面来看一下阮老师的ES6教程中的知识点，看看是不是能做到完全理解：

• 在子类 constructor() 中，super 指向 Parent，super 中的 this 指向 Child 类的实例，所以相当于Parent.call(this)

• 在子类方法中，super 指向 Parent.prototype，super 中的 this 指向子类的实例，所以如果有 super 调用就是 Parent.prototype.func.call(this)

• super 在静态方法之中指向父类，而不是父类的原型对象。在子类的静态方法中通过 super 调用父类的方法时，方法内部的 this 指向当前的子类，而不是子类的实例。

• 子类的原型指向父类

  Child.proto === Parent // true

• 子类的 prototype 的原型指向父类的原型

  Child.prototype.__proto__ = Parent.prototype // true
  //相当于
  B.prototype = Object.create(A.prototype)

• // o1 是父类的实例，o2 是子类的实例
  o2.__proto__.__proto__ === o1.proto__ // true

吐槽

写到一半Typora崩溃了把我保存的内容都吞了是真的坑，在心态崩了的情况下再重写一次真是磨练心智 😭

一些疑点

request 中的 cache-control vs. response 中的 cache-control

cache-control 作为一个 general header，在 request 和 response 中都可以存在？那么如果假设我们在某 HTML 的 meta 中写了

<meta name="Cache-Control" content="no-cache">

但是和这个 HTML 的 response 中由服务器设定的 cache-control 不一致时，如下图，demo

下一次请求的 cache-control 该听谁的呢？
在这个例子中，重复访问页面，第二次访问的 HTML 是 from disk，也就是说缓存生效了。

MDN 中语焉不详，只是说 a given directive in a request is not implying that the same directive is to be given in the response。我也没在 HTTP 规范中找到对应的规则。

查了一下资料，发现这应该是一个由服务器来控制的规则：服务器可以选择是否忽略 request 中的 cache-control，如果不忽略就按 request 中的 cache-control 规则来，忽略了就按 response 中的 cache-control 规则来。

比如Apache

比如 Nginx

策略

不缓存

expires: 0
pragma: no-cache
cache-control: no-store, no-cache, must-revalidate, proxy-revalidate

• no-store: 告诉浏览器、缓存服务器不要保存副本，每次都要去向源服务器请求新的资源。
• no-cache：告诉浏览器、缓存服务器，不管本地副本是否过期，使用资源副本前，一定要到源服务器进行副本有效性校验。
• must-revalidate：告诉浏览器、缓存服务器，本地副本过期前，可以使用本地副本；本地副本一旦过期，必须去源服务器进行有效性校验。
• proxy-revalidate：告诉缓存服务器不要保存副本。

再加上兼容 HTTP/1.0 的 expires 和 pragma，即禁止一切缓存，请求每次都要发往源服务器。

长 max-age + 指纹

Cache-Control: max-age=31536000

将 Cache-Control 设定的很长，即在 Cache-Control 没有过期的情况下将直接从浏览器中取出缓存（from memory cache 或 from disk cache），但是这样也彻底限制了资源更新的可能。

通过给资源的 URL 添加一个“指纹”，可以是版本号，hash，MD5 或日期等。

<script src="/script-f93bca2c.js"></script>
<link rel="stylesheet" href="/styles-a837cb1e.css">
<img src="/cats-0e9a2ef4.jpg" alt="…">

通过 HTML 的更新来控制对应资源是否更新，这样做的好处是在 HTML 没更新的时候直接从浏览器中取缓存，有效避免 304，进一步减小服务器的压力；HTML 更新后也会更新资源文件的文件名，URI 变了浏览器自然会去向源服务器请求新的资源。

知乎 & 掘金 & GitHub

我们通过分析知乎和掘金的的 HTTP 缓存实践来看下这两个网站是如何进行缓存的：

知乎

• *.html

  

  知乎的主页是由服务端动态生成的，所以采用完全不缓存的策略。

• *.js, *.css

  

  .js 和 .css 采用的都是长 max-age + 指纹 的策略，由上面的 HTML 来控制是否更新。

• 静态资源

  

  图片等同样适用 max-age + 指纹 的策略。

• Ajax

  

  对于涉及到用户个人的信息，要特别在 cache-control 中指出 private 来防止缓存服务器缓存，然后再禁止掉所有本地缓存。

掘金

• *.html

  

  掘金的 HTML 只在 Cache-Control 中写了 private，禁止缓存服务器缓存，但是也没有指定 max-age，所以每次还是会去请求源服务器。

  不过根据 MSDN 中描述的，Cache-Control 默认值就是 private，所以不写应该也没问题。

• *.js, *.css

  

  对于加指纹的文件，与知乎的策略近似，这里多了一个 public，意欲何为？

• 静态资源

  

  资源文件有指纹，所以采用长 max-age + 指纹的策略，又多了个 public？

• Ajax

  

  采用长 max-age + 指纹的策略并且不允许缓存服务器缓存。

GitHub

• *.html

  

  采用 no-cache，这样可以利用缓存服务器，缓存服务器在发回备份前会先向源服务器确认缓存是否可用，如果可用则返回给浏览器备份，否则要再向源服务器发起请求。

• *.js, *.css

  

  同掘金

• 静态资源

  

  不同于前两者的资源 URI，github 的资源 URI 采用的是 {id}?s={size}&v={version} 的格式，没有 指纹的加持，就要保证资源在改变时及时更新，

  

  github 是默认给缓存五分钟，五分钟之内直接从本地浏览器缓存中拿，如果超过了五分钟则去比较 Etag，Last-Modified 和 Expires，如果改变了就向源服务器 200 一个新的，如果没改变就会返回一个 304。

• Ajax

  

  同 html。

总结

HTTP 缓存不存在银弹，只有根据当前业务特点还有后端资源的配置寻求最适合的配置。

参考

• web性能优化之：no-cache与must-revalidate深入探究
• Difference between no-cache and must-revalidate
• HTTP Cache Headers – A Complete Guide
• Response.CacheControl

前言

最近翻出了之前分析的 applyMiddleware 发现自己又看不懂了😳，重新看了一遍源代码，梳理了洋葱模型的实现方法，在这里分享一下。

applyMiddleware源码解析

applyMiddleware 函数虽短但却是 Redux 最精髓的地方，成功的让 Redux 在保持“自身函数式纯洁”的前提下，在 action 传递的过程中插入了提供了副作用的空间。
这个 middleware 的洋葱模型**是从 koa 的中间件拿过来的，用图来表示最直观。

上图之前先上一段用来示例的代码（via 中间件的洋葱模型），我们会围绕这段代码理解 applyMiddleware 的洋葱模型机制：

function M1(store) {
  return function(next) {
    return function(action) {
      console.log('A middleware1 开始');
      next(action)
      console.log('B middleware1 结束');
    };
  };
}

function M2(store) {
  return function(next) {
    return function(action) {
      console.log('C middleware2 开始');
      next(action)
      console.log('D middleware2 结束');
    };
  };
}

function M3(store) {
  return function(next) {
    return function(action) {
      console.log('E middleware3 开始');
      next(action)
      console.log('F middleware3 结束');
    };
  };
}
  
function reducer(state, action) {
  if (action.type === 'MIDDLEWARE_TEST') {
    console.log('======= G =======');  
  }
  return {};
}
  
var store = Redux.createStore(
  reducer,
  Redux.applyMiddleware(
    M1,
    M2,
    M3
  )
);

store.dispatch({ type: 'MIDDLEWARE_TEST' });

再放上 Redux 的洋葱模型的示意图（via 中间件的洋葱模型），以上代码中间件的洋葱模型如下图：

            --------------------------------------
            |            middleware1              |
            |    ----------------------------     |
            |    |       middleware2         |    |
            |    |    -------------------    |    |
            |    |    |  middleware3    |    |    |
            |    |    |                 |    |    |
          next next next  ———————————   |    |    |
dispatch  —————————————> |  reducer  | — 收尾工作->|
nextState <————————————— |     G     |  |    |    |
            | A  | C  | E ——————————— F |  D |  B |
            |    |    |                 |    |    |
            |    |    -------------------    |    |
            |    ----------------------------     |
            --------------------------------------


顺序 A -> C -> E -> G -> F -> D -> B
    \---------------/   \----------/
            ↓                ↓
      更新 state 完毕      收尾工作

我们将每个 middleware 真正带来副作用的部分（在这里副作用是好的，我们需要的就是中间件的副作用），称为 M?副作用，它的函数签名是 (action) => {}（记住这个名字）。

对这个示例代码来说，Redux 中间件的洋葱模型运行过程就是：

用户派发 action → action 传入 M1 副作用 → 打印 A → 执行 M1 的 next（这个 next 指向 M2 副作用）→ 打印 C → 执行 M2 的 next（这个 next 指向 M3 副作用）→ 打印 E → 执行 M3 的 next（这个 next 指向store.dispatch）→ 执行完毕返回到 M3 副作用打印 F → 返回到 M2 打印 E → 返回到 M1 副作用打印 B -> dispatch 执行完毕。

那么问题来了，M1 M2 M3的 next 是如何绑定的呢？

答：柯里化绑定，一个中间件完整的函数签名是 store => next => action {}，但是最后执行的洋葱模型只剩下了 action，外层的 store 和 next 经过了柯里化绑定了对应的函数，接下来看一下 next 是如何绑定的。

const store = createStore(...args)
let chain = []
const middlewareAPI = {
    getState: store.getState,
    dispatch: (...args) => dispatch(...args)
}
chain = middlewares.map(middleware => middleware(middlewareAPI)) // 绑定 {dispatch和getState}
dispatch = compose(...chain)(store.dispatch) // 绑定 next

关键点就是两句绑定，先来看第一句

chain = middlewares.map(middleware => middleware(middlewareAPI)) // 绑定 {dispatch和getState}

为什么要绑定 getState？因为中间件需要随时拿到当前的 state，为什么要拿到 dispatch？因为中间件中可能会存在派发 action 的行为（比如 redux-thunk），所以用这个 map 函数柯里化绑定了 getState 和 dispatch。

此时 chain = [(next)=>(action)=>{…}, (next)=>(action)=>{…}, (next)=>(action)=>{…}]，… 里闭包引用着 dispatch 和 getState。

接下来 dispatch = compose(...chain)(store.dispatch) ，先了解一下 compose 函数

compose(A, B, C)(arg) === A(B(C(arg)))

这就是 compose 的作用，从右至左依次将右边的返回值作为左边的参数传入，层层包裹起来，在 React 中嵌套 Decorator 就是这么写，比如：

compose(D1, D2, D3)(Button)
// 层层包裹后的组件就是
<D1>
    <D2>
        <D3>
        	<Button />
        </D3>
    </D2>
</D1>

再说回 Redux

dispatch = compose(...chain)(store.dispatch) 

在实例代码中相当于

dispatch = MC1(MC2(MC3(store.dispatch)))

MC 就是 chain 中的元素，没错，这又是一次柯里化。

至此，真相大白，dispatch 做了一点微小的贡献，一共干了两件事：1. 绑定了各个中间件的 next。2. 暴露出一个接口用来接收 action。其实说了这么多，middleware 就是在自定义一个dispatch，这个 dispatch 会按照洋葱模型来进行 pipe。

OK，到现在我们已经拿到了想要的 dispatch，返回就可以收工了，来看最终执行的灵魂一图流：

细节

然而可达鸭眉头一皱，发现事情还没这么简单，有几个问题要想一下

dispatch

    const middlewareAPI = {
      getState: store.getState,
      dispatch: (...args) => dispatch(...args)
    }

在这里 dispatch 使用匿名函数是为了能在 middleware 中调用 compose 的最新的 dispatch（闭包），必须是匿名函数而不是直接写成 store.dispatch。

如果直接写成 store.dispatch，那么在某个 middleware（除最后一个，最后一个middleware拿到的是原始的 store.dispatch）dispatch 一个 action，比如 redux-thunk

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => next => action => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

就是拦截函数类型的 action，再能够对函数形式的 action（其实是个 actionCreator）暴露 API 再执行一次，如果这个 actionCreator 是多层函数的嵌套，则必须每次执行 actionCreator 后的 actionCreator 都可以引用最新的 dispatch 才行。如果不写成匿名函数，那这个 actionCreator 又走了没有经过任何中间件修饰的 store.dispatch，这显然是不行的。所以要写成匿名函数的闭包引用。

还有，这里使用了 ...args 而不是 action，是因为有个 PR，这个 PR 的作者认为在 dispatch 时需要提供多个参数，像这样 dispatch(action, option) ，这种情况确实存在，但是只有当这个需提供多参数的中间件是第一个被调用的中间件时（即在 middlewares 数组中排最后）才肯定有效 ，因为无法保证上一个调用这个多参数中间件的中间件是使用的 next(action) 或是 next(...args) 来调用，所以被改成了 next(…args) ，在这个 PR 的讨论中可以看到 Dan 对这个改动持保留意见（但他还是改了），这个改动其实真的挺蛋疼的，我作为一个纯良的第三方中间件，怎么能知道你上个中间件传了什么乱七八糟的属性呢，再说传了我也不知道是什么意思啊大哥。感觉这就是为了某些 middleware 能够配合使用，不想往 action 里加东西，就加在参数中了，到底是什么参数只有这些有约定好参数的 middleware 才能知道了。

redux-logger

Note: logger must be the last middleware in chain, otherwise it will log thunk and promise, not actual actions (#20).

要求必须把自己放在 middleware 的最后一个，理由是

Otherwise it'll log thunks and promises but not actual actions.

试想，logger 想 log 什么？就是 store.dispatch 时的信息，所以 logger 肯定要在 store.dispatch 的前后 console，还记不记得上面哪个中间件拿到了 store.dispatch，就是最后一个，如果把 logger 放在第一个的话你就能打出所有的 action 了，比如 redux-thunk 的 actionCreator，打印的数量肯定比放在最后一个多，因为并不是所有的 action 都能走到最后，也有新的 action 在 middleware 在中间被派发。

参考

• redux middleware 详解

• Redux 进阶教程

• redux applyMiddleware 原理剖析

绘图

• ProcessOn

让 monorepo 的使用更加丝滑

全局的 TypeScript 类型

TypeScript 跳转

在开发模式下，经常会用到 Go To Definition 这个功能，但是对于 package 下的 library，它们虽然是用 TS 写的，但是实际中项目引用的是 tsc -w 产生的 JS 文件，所以即使开了 declaration: true，也只能跳转到对应 TS 文件产生的 d.ts 上。
**解决方法：**使用 tsconfig 的 paths，

{
  "compilerOptions": {
    "paths": {
      "@monodemo/service": ["../../service/src/index"],
      "@monodemo/permission-detail": ["../../permission-detail/src/index"],
      "@monodemo/check": ["../../check-detail/src/index"]
    }
  }
}

将 package 名直接映射给对应包的 index.tsx 文件，这其中有两个点需要注意

1. 要映射到 index.tsx 中，如果是深层文件的引入的话，还要再加 paths
2. 由于 IDE 默认找的是并且只能找的 tsconfig.json 这个文件，并且目前没有办法指定 IDE 去找其他指定的文件，所以现在的 paths 这可能会影响到 webpack 的打包，可以再创建一个 tsconfig.dev.json 文件，区别就是 tsconfig.dev.json 没有对其他 package 的映射，然后在 webpack 的 ts-loader 中指定

{
  test: /\.(ts|tsx)$/,
  include: paths.appSrc,
  loader: require.resolve('ts-loader'),
  options: {
    configFile: paths.appTsConfig,
  },
},

https://medium.com/@NiGhTTraX/how-to-set-up-a-typescript-monorepo-with-lerna-c6acda7d4559

• 解决 transition 对 display 无效，

  • 使用 visibility: visible 和 visibility: hidden 代替 display: block 和 display: none

    <div class="wrapper">
      <h3>title</h3>
      <p>Item</p>
    </div>

    .wrapper{
      position: relative;
    }
    
    .wrapper p {
      position: absolute;
      transition: all 0.3s ease-in 0s;
      visibility: hidden;
      opacity: 0;
    }
    
    .wrapper:hover p {
      visibility: visible;
      opacity: 1;
    }

  • 不使用 transition，而是使用 animation

    <div class="wrapper">
      <h3>title</h3>
      <p>Item</p>
    </div>

    @keyframes fadeIn {
        from { opacity: 0; }
          to { opacity: 1; }
    }
    
    .wrapper p {
      position: relative;
      display: none;
    }
    
    .wrapper:hover p {
      position: absolute;
      display: block;
      animation: fadeIn 1s;
    }

• 工厂方法模式（Factory Method）
• 抽象工厂模式（Abstract Factory）
• 创建者模式（Builder）
• 原型模式（Prototype）
• 单例模式（Singleton）

背景

由于某些原因，我们团队负责在 GitLab 上做二次开发，简单理解就是在 GitLab 上挂个 DOM 渲染用 React 写的一些组件，组件库选择了 antd，尴尬的是引入之后发现，GitLab 自身是带一套全局样式的，而 antd 又带了一套全局样式，导致 GitLab 的部分样式被覆盖，如图：
a 标签颜色被 antd 覆盖：

checkbox 细微的样式错乱及大小改变：

原因

antd 的全局样式也不是一天两天的问题了，在社区中已经有很多讨论（#4331 #9363
#13459），但直到今天也没有进展。因为 Ant-Design 是一套设计语言，所以 antd 会引入一套 fork 自 normalize.css 的浏览器默认样式重置库。

引入全局样式的这个文件是 style/core/base.less，就是这个 base.less 会对各种元素的默认样式一顿格式化，截取一段：

...
// remove inner border and padding from Firefox, but don't restore the outline like Normalize.
button::-moz-focus-inner,
[type='button']::-moz-focus-inner,
[type='reset']::-moz-focus-inner,
[type='submit']::-moz-focus-inner {
  padding: 0;
  border-style: none;
}

input[type='radio'],
input[type='checkbox'] {
  box-sizing: border-box; // 1. Add the correct box sizing in IE 10-
  padding: 0; // 2. remove the padding in IE 10-
}
...

下图为 antd 的 CSS 打包时的依赖关系，这张图有助于我们理清怎样才能避免把 base.less 引入。

解决核心问题

核心问题就是 base.less 这个文件对全局样式的侵入。那这个文件可以不要吗？不行，antd 的组件样式都是建立在这个格式化后的样式上的，不引这个文件样式就错位了（如下图），所以要在不影响全局样式的条件下引入。

并且，一般我们需要收敛 antd 全局样式时，都是因为当前页面存在另一套全局样式库（比如笔者遇到的 GitLab 的全局样式），我们需要达到的目的可以进一步变为 「收敛 base.less，并保证外部的全局样式无法轻易覆盖 antd 的样式」。

简单限定 base.less

之前社区中出现过将 base.less 外面套一层 .ant-container 的方案，但一个显著的缺陷就是提高了 base.less 中样式的权重导致样式错位。

全面提高 ant- 的优先级

但是限定 base.less 这个思路是没有错的，base.less 需要被套一层「作用域」，那再给所有已有的 antd 组件提高权重保证原有的选择器优先级不变就好了。

幸运的是，antd 相关的组件都至少会有一个以 ant- 开头的 class，我们只要利用好这个特点及 CSS 属性选择器即可达到目的。

流程如下：

1. 将 antd 中的 base.less 替换为（具体怎么见「使用方式」）魔改的 base.less，这个魔改的 base.less 外面会套一层 *[class*='ant-'] 限定其样式的「作用域」。这一步将全局样式限定在了所有有 ant- 的 class 的元素里。

*[class*='ant-'] {
  @import '~antd/lib/style/core/base.less';
}

2. 提高完了 base.less 的权重，再来提升组件的样式的权重，此举还能间接提升所有 antd 的样式的权重，避免外部的全局样式对 antd 造成侵入。

   既然是改样式，那就用 CSS 界的 babel —— PostCSS，写个 PostCSS 插件，https://github.com/fi3ework/postcss-rename-selector ，将所有 .ant 开头的类选择器都同样升高即可，利用的是 postcss-selector-parser 这个 PostCSS 官方提供的解析选择器的库，过滤出「第一个以 ant- 开头的类选择器」，在其前面添加一个属性选择器 [class*='ant-']，如果这个选择器排在当前 rule 的第一个或者前面是一个 combinator，则再加一个通配符 *，这个同上面给 base.less 添加的选择器，两者同时提高相同权重既维持原有优先级不变。

   另外，如果某些元素虽然不在 antd 的组件里，但是也想走 antd 的全局样式，只需在这些元素的最外层套一个 class className="ant-whatever"，只要是 ant- 开头的就可以。

import parser, { Node } from 'postcss-selector-parser'
import { SelectorReplace } from '../index'

export function antdScopeReplacerFn(node: Node) {
  if (node.type !== 'selector') return

  const firstAntClassNodeIndex = node.nodes.findIndex((n) => {
    return n.type === 'class' && n.value.startsWith('ant-')
  })
  if (firstAntClassNodeIndex < 0) return

  const firstAntClassNode = node.nodes[firstAntClassNodeIndex]
  const prevNode = node.nodes[firstAntClassNodeIndex - 1]

  // preserve line break
  const spaces = {
    before: firstAntClassNode.rawSpaceBefore,
    after: firstAntClassNode.rawSpaceAfter,
  }

  firstAntClassNode.setPropertyWithoutEscape('rawSpaceBefore', '')
  const toInsert = []

  if (firstAntClassNodeIndex === 0 || prevNode.type === 'combinator') {
    const universal = parser.universal({
      value: '*',
    })
    toInsert.push(universal)
  }

  const attr = parser.attribute({
    attribute: 'class',
    operator: '*=',
    value: `"ant-"`,
    raws: {},
  })

  toInsert.push(attr)
  toInsert[0].spaces = spaces

  firstAntClassNode.parent!.nodes.splice(firstAntClassNodeIndex, 0, ...toInsert)
}

export const antdReplacer: SelectorReplace = {
  type: 'each',
  replacer: antdScopeReplacerFn,
}

这个 antd 的配置已经作为 preset 提供了，如果想使用直接引入即可

const { replacer, presets } = require('postcss-rename-selector')

plugins: [
    replacer(presets.antdReplacer)
]

效果如图：

使用方式

建了 demo 仓库，下面几种的方式在 demo 仓库中都可以找到：https://github.com/fi3ework/restricted-antd-style-demo

方式 1：删除 base.less 一把梭

全量

思路是：在 post-install 阶段将 antd/lib/style/core/index.less 引入的 @import base; 这一行直接删掉，然后手动引入我们自己魔改的 base.less。

步骤：

1. 写一个 post-install 脚本，直接改写 antd/lib/style/core/index.less，这边已经有实现 ant-design/ant-design#9363 (comment)
2. PostCSS 中添加 postcss-rename-selector 插件并配置：

const { replacer, presets } = require('postcss-rename-selector')

plugins: [
    replacer(presets.antdReplacer)
]

3. 引入全量样式 import 'antd/dist/antd.less'
4. 额外引入一个 base.less，限定在一个「作用域」下

@import '~antd/lib/style/mixins/index.less';

*[class*='ant-'] {
  @import '~antd/lib/style/core/base.less';
}

看下效果，antd 的样式正常，并且最上方的一个 a 标签并没有被 antd 所影响：

按需引入

1. 同全量引入 1
2. 同全量引入 2
3. 配置 babel-plugin-import

  [
    'import',
    {
      libraryName: 'antd',
      style: true,
    },
  ],

4. 同全量引入 4

方式 2：手动拼接 antd.less

全量

post-install 的方法多少显得有些 hack，另一种方法是手动拼出 antd/dist/antd.less 的文件依赖然后引入。

@import '~antd/lib/style/themes/index.less';
@import '~antd/lib/style/mixins/index.less';

*[class*='ant-'] {
  @import '~antd/lib/style/core/base.less';
}

@import '~antd/lib/style/core/iconfont.less';
@import '~antd/lib/style/core/motion.less';

@import '~antd/lib/style/components.less';

结构与原本的引入相同，唯一不同的地方就是将 base.less 包裹了一层「作用域」，然后还需要在 webpack 的配置中添加 alias

alias: {
    'antd/dist/antd.less$': path.resolve(__dirname, '../src/custom-dist.less')
}

然后在整个文件的入口引入

import './custom-dist.less`

就好啦。

按需引入

很遗憾，在这种方式下，笔者折腾了半天也无法做到配合 babel-plugin-import 做按需引入。babel-plugin-import 提供了几种预置的样式加载方式及可定制化的方法，拿 Button 这个组件举例

1. 引 antd/lib/button/index.css，就是将 babel-plugin-import 配成这样：

  [
    'import',
    {
      libraryName: 'antd',
      customStyleName: (name) => {
        return `antd/lib/${name}/style/index.css`
      }
    }
  ],

Button 这个组件没有问题，但是有些组件，比如 Col 是放在 Layout 这个目录的，按照组件名拼名字会找不到文件直接报错。还有，比如 Input 这个组件是依赖 Button 的样式的，只按需引 Input 的样式是不行的，还要手动引入 Button 的样式。

2. 引 antd/lib/button/css.js，就是将 babel-plugin-import 配成这样：

  [
    'import',
    {
      libraryName: 'antd',
      style: 'css'
    }
  ],

这个文件长这个样子

'use strict'

require('../../style/index.css')

require('./index.css')

只需要把 require("../../style/index.less"); 的这个引入干掉即可。但是遗憾的是，笔者试了 IgnorePlugin 和 alias 均无效。尤其是 IgnorePlugin，按照官方文档给的对 Moment.js 的处理方式，理论上应该可以忽略。

new webpack.IgnorePlugin(/\.\.\/\.\.\/style\/index\.css/, /antd$/),

但实际没有任何效果，如果哪位知道是为什么请告知。

总结

目前笔者所用的 antd 的版本还是 3.x，还没有升级到 v4 验证过，不过看了下 v4 的代码，base.less 还安安静静的躺在那里，目测使用方法是类似的。

这套方案在我们自己的业务上已经跑了几个月了，暂时没有发现什么问题。Ant Design 作为一套设计规范提供全局样式也是合理的，但还是希望官方可以提供一种可选的限定范围的全局样式，毕竟隔壁的 Material-UI 可是没这个问题（逃），默默许愿 antd v5 中可以解决！

彩（广）蛋（告）

之前为 antd 写了个 VS Code 生产力插件，自认为是最好用的 antd VS Code 插件了，欢迎 Star，Issue。

vscode-antd-rush

Ref

• “优雅”的解决 Ant Design 全局样式问题
• ant-design/ant-design#4331
• ant-design/ant-design#9363
• ant-design/ant-design#13459

前言

本文整理自：Google Developers 及 高性能 JavaScript，再加上了一些个人对其中提到的知识点的理解与补充。前端性能优化涉及很多方面，本文仅针对高性能渲染进行分析。

单个帧的渲染流程 —— 像素管道

目前，大多数设备的刷新率都是 60 FPS，如果浏览器在交互的过程中能够时刻保持在 60FPS 左右，用户就不会感到卡顿，否则，就会影响用户的体验。

下图为浏览器运行的单个帧的渲染流水线，称为像素管道，如果其中的一个或多个环节执行时间过长就会导致卡顿。像素管道是作为开发者能够掌握的对帧性能有影响的部分，其他部分由浏览器掌握，我们无法控制。我们的目标就是就是尽快完成这些环节，以达到 60 FPS 的目标。

• JavaScript。通常来说，阻塞的发起都是来自于 JS ，这不是说不用 JS，而是要正确的使用 JS 。首先，JS 线程的运行本身就是阻塞 UI 线程的（暂不考虑 Web Worker）。从纯粹的数学角度而言，每帧的预算约为 16.7 毫秒（1000 毫秒 / 60 帧 = 16.66 毫秒/帧）。但因为浏览器需要花费时间将新帧绘制到屏幕上，只有 ~10 毫秒来执行 JS 代码，过长时间的同步执行 JS 代码肯定会导致超过 10ms 这个阈值，其次，频繁执行一些代码也会过长的占用每帧渲染的时间。此外，用 JS 去获取一些样式还会导致强制同步布局（后面会有介绍）。
• 样式计算（Style）。此过程是根据匹配选择器（例如 .headline 或 .nav > .nav__item）计算出哪些元素应用哪些 CSS 规则的过程，这个过程不仅包括计算层叠样式表中的权重来确定样式，也包括内联的样式，来计算每个元素的最终样式。
• 布局（Layout）。在知道对一个元素应用哪些规则之后，浏览器即可开始计算该元素要占据的空间大小及其在屏幕的位置。网页的布局模式意味着一个元素可能影响其他元素，一般来说如果修改了某个元素的大小或者位置，则需要检查其他所有元素并重排（re-flow）整个页面。
• 绘制（Paint）。绘制是填充像素的过程。它涉及绘出文本、颜色、图像、边框和阴影，基本上包括元素的每个可视部分。绘制一般是在多个表面（通常称为层）上完成的，绘制包括两个步骤： 1) 创建绘图调用的列表， 2) 填充像素，后者也被称作栅格化。
• 合成（Composite）。由于页面的各部分可能被绘制到多个层上，因此它们需要按正确顺序绘制到屏幕上，才能正确地渲染页面。尤其对于与另一元素重叠的元素来说，这点特别重要，因为一个错误可能使一个元素错误地出现在另一个元素的上层。

采用更好的 CSS 方法进行优化

上节渲染管道的每个环节都有可能引起卡顿，所以要尽可能减少通过的管道步骤。

修改不同的样式属性会有以下几种不同的帧流程，在这里就直接贴 Google Developers 的图了：

我们可以看到 JS，Style 和 Composite 是不可避免的，因为需要 JS 来引发样式的改变，Style 来计算更改后最终的样式，Composite 来合成各个层最终进行显示。Layout 和 Paint 这两个步骤不一定会被触发，所以在优化的过程中，如果是需要频繁触发的改变，我们应该尽可能避免 Layout 和 Paint。

尽量使用 transform 和 opacity 属性更改来实现动画

性能最佳的像素管道版本会避免 Layout 和 Paint：

为了实现此目标，需要坚持更改可以由合成器单独处理的属性。常用的两个属性符合条件：transform 和 opacity。

想知道每种 CSS 属性的更改是否会触发 Layout，Paint，Composite，可以通过 csstriggers.com 查看。

除了 transform 和 opacity，只会触发 composite 的 CSS 属性还有：pointer-events（是否响应鼠标事件）、perspective （透视效果）、perspective-origin（perspective 的灭点）、cursor（指针样式）、orphans（设置当元素内部发生分页时必须在页面底部保留的最少行数（用于打印或打印预览））、widows（设置当元素内部发生分页时必须在页面顶部保留的最少行数（用于打印或打印预览））。

减小选择器匹配的难度

通过上面的几种不同流程的管道图可以发现，只要是修改样式那么必不可少会经过 Style，计算样式的第一步是创建一组匹配选择器，这实质上是浏览器计算出给指定元素应用哪些类、伪选择器和 ID 。第二步是从对应的匹配选择器中获取所有样式规则，并计算出此元素的最终样式，简单的来说就是第一步先确定选择器都匹配哪些元素，第二步根据每个元素所匹配的选择器，通过权重计算出最终的样式。

对于要匹配相同的元素，.final-box-title 比 .box:nth-last-child(-n+1) .title 明显复杂度要来的小得多，浏览器不需要去判断要查找的元素是不是最后一个元素即可根据类名快速找到 .final-box-title 对应的元素，相比复杂的选择器，简单地将选择器与元素匹配开销要小得多，而且嵌套过深的 CSS 选择器依赖了过多的类名，很容易在改动依赖的类名时不小心被影响到。

这里推荐使用 BEM（块、元素、修饰符） 编码规则简化选择器规则，该方法实际上纳入了上述选择器匹配的性能优势，因为它建议所有元素都有单个类，并且在需要层次结构时也纳入了类的名称。

提升元素到新的层

有一种能有效减小 Layout 和 Paint 的方法是将元素提升，像 Photoshop 中层的概念一样，样式也有层的概念，不同的层根据不同顺序叠加起来，通过 Composite 最终显示出来。在每个层中对这个层进行 Layout 或者 Paint 是不会影响其他层的，一般会根据整个页面的语义将页面分为几个层。

但是不要滥用层，将每个元素都单独提升到一层， Composite 这个环节有两步，Update Layer Tree 和 Composite Layer Tree，前者负责计算页面中有多少个层，哪些层应该出现并应该按什么顺序叠加起来，后者负责将 layers 合成到屏幕上。层越多，这两个步骤花的时间越长，同时也会占用更多的内存，所以要在适当的地方提升元素而不是对所有元素都进行提升。

提升元素还有一个好处就是会将动画从 CPU 转移到 GPU 来完成，来实现硬件加速。

提升元素的两个方法：

.moving-element {
  will-change: transform;
}

.moving-element {
  transform: translateZ(0);
}

有些浏览器对 will-change 的支持还不够好，所以一般两个都写上。

参考：How (not) to trigger a layout in WebKit

使用 flexbox 而不是较早的布局模型

经过测试，flex 布局在现代浏览器上相比早期的浮动或者定位布局性能更好，而且到现在 flex 布局已经很好的得到了浏览器的支持（IE10- 手动再见）。

尽量避免 Layout

强制同步重排 - FSL (forced synchronous layout)

浏览器的工作原理：新式网络浏览器幕后揭秘 将布局分为异步布局和同步布局：

增量布局是异步执行的。Firefox 将增量布局的“reflow 命令”加入队列，而调度程序会触发这些命令的批量执行。WebKit 也有用于执行增量布局的计时器：对呈现树进行遍历，并对 dirty 呈现器进行布局。

请求样式信息（例如“offsetHeight”）的脚本可同步触发增量布局。
全局布局往往是同步触发的。

有时，当初始布局完成之后，如果一些属性（如滚动位置）发生变化，布局就会作为回调而触发。

除了影响所有呈现器的全局样式更改，例如字体大小更改和屏幕大小调整的更改都是增量修改，增量修改是异步的也就给了我们用 thunk 修改的机会。

再来看下单个帧的流程图

如果我们在 js 中这样写

let boxes = document.getElmentsByClassName('.box')
for(let i = 0; i < boxes.length; i++) {
    let width = document.getElementById('table')
    boxes[i].style.color = 'red'
}   

这种情况下，这一帧相比上一帧没有布局没有发生改变，那么直接用旧的 Layout 去赋值 width 就可以，也不需要对页面进行重排。

但是如果这样写：

let boxes = document.getElmentsByClassName('.box')
for(let i = 0; i < boxes.length; i++) {
    let width = document.getElementById('table').width
    boxes[i].style.width = width
}   

当下一次循环到来时浏览器还没进重排（因为一直处于 JS 阶段） ，为了获取正确的 width ，浏览器就不得不立刻重新 Layout 获取一个最新值，从而失去了浏览器自身的批量更新的优化，这就是强制同步布局。

为什么叫强制呢，大多数浏览器通过队列化修改并批量执行来优化重排过程（就是上面说的异步布局），但是如果触发了强制同步布局 ，每经过一次循环，都会要求浏览器强制刷新队列并要求计划任务立刻执行，这就失去了浏览器对重排的优化。

什么操作会触发强制同步布局 呢，这个 gist 里列出了对应的操作。

避免强制同步布局

1. 使用 requestAnimationFrame（后面有介绍），将获取 width 的操作推迟到下一帧，在经过浏览器正常的 Layout 之后，下一帧可以直接拿到 Layout 值。

   requestAnimationFrame(logBoxHeight);
   
   function logBoxHeight() {
     box.classList.add('super-big');
     // Gets the height of the box in pixels
     // and logs it out.
     console.log(box.offsetHeight);
   }

2. 缓存不动变量，对上面的那个强制同步布局的例子，避免在循环中进行可能会导致强制同步布局的操作

   let boxes = document.getElmentsByClassName('.box')
   let width = document.getElementById('table').width
   for(let i = 0; i < boxes.length; i++) {
       boxes[i].style.width = width
   }   

FLIP策略

在做某些动画时，有可能会有连续触发 Layout 步骤的属性，如下图的动画

如果凭直觉来做，很可能就是 click 之后加上一个类似于

.element.expanded {
    height: 100%;
    left: 0;
    position: absolute;
    transition: top 200ms ease-in , height 200ms ease-in 50ms;
    top: 0;
    width: 100%;
    z-index: 3;
} 

这样的类。但是，可以看到下图中用 Chrome devTools 打开显示 Paint 区域的功能，发现重绘的区域很大，并且肯定伴随着重排，帧数也很低，出现了卡顿的现象。

这时候，就用 transform 来代替对 width 和 height 的改变。

其实到这里，就已经可以满足 60 FPS 的效果了，但是为了做到内容与样式分离，将起始于终结的样式全部由 CSS 管理，而中间通过 transform 动画的行为有 CSS 控制，则需要使用 FLIP 方法：

接下来，介绍一下 Paul Lewis 发明的 FLIP 方法，FLIP 就是 F (first) L (last) I (invert) P (play) 的缩写。

• First: 在整个动画过程中元素的起始状态
• Last: 在整个动画过程中元素的终止状态
• Invert: 这一步是关键，通过 First 和 Last 计算出来的状态，得到一个从 Last 到 First 的变化倍率（比如大小或位置，是的，是从 Last 到 First），然后让元素具有终止状态的 class 及刚刚计算出来的 invert state 的 transform 属性，他们两个相抵消，元素在视觉上还是没有任何变化。举个例子，比如我们想让一个元素向右移动 10px，再放大两倍，那么这个计算出来的相反的 transfrom 属性就应该是 transform: translateX(-10px) scale(0.5)，再给他一个 left: 10px; width: 200px; height: 200px;（假设原来是 left: 0; width: 100px; height: 100px;），这两个属性视觉效果上抵消，好像元素从来没有改变过。
• Play: 给元素添加一个 transition 效果，再移除元素的 transform 属性，因为此时元素已经是终止状态了，所以就会 transition 到 0，整个过程只有 transform ，可以轻松达到 60FPS。

核心**就是 pre-calculation，用代码来表示就是这样，直接贴一下原作者的代码，已经很详细了：

// Get the first position.
var first = el.getBoundingClientRect();

// Now set the element to the last position.
el.classList.add('totes-at-the-end');

// Read again. This forces a sync
// layout, so be careful.
// 这里会触发强制同步，不过只有一帧，这是完全可以接受的
var last = el.getBoundingClientRect();

// You can do this for other computed
// styles as well, if needed. Just be
// sure to stick to compositor-only
// props like transform and opacity
// where possible.
var invert = first.top - last.top;

// Invert.
el.style.transform =
    `translateY(${invert}px)`;

// Wait for the next frame so we
// know all the style changes have
// taken hold.
// 要用rAF，不用的话el.style.transform = `translateY(${invert}px)`; 和
// 必须放到下一帧触发transfrom
// el.style.transform = '';就在一帧中同步执行了，就不会有动画效果了，
requestAnimationFrame(function() {

  // Switch on animations.
  el.classList.add('animate-on-transforms');

  // GO GO GOOOOOO!
  el.style.transform = '';
});

// Capture the end with transitionend
// 结束后要el.classList.remove('animate-on-transforms')
el.addEventListener('transitionend',
    tidyUpAnimations);

实际上，FLIP 是将复杂的计算放在了一开始（包括一次强制同步），根据 RAIL 规则，触发后 100ms 的反应时间是可以接受的，所以在 100ms 内完成为止的计算，之后的动画用 transform 来达到 60FPS。

附上一个自己写的小 demo，大家可以感受一下。

参考：

• FLIP Your Animations
• FLIP Your 60 FPS Animations, FLIP ’Em Good

高性能 JavaScript

昂贵的 DOM 操作

其实，JS 的执行速度是很快的，尤其是发展到了现在这个年代，像 V8 这样的解释器性能已经十分强悍了（吊打 Python），真正慢的是操作 DOM。浏览器请通常会将 DOM 和 JS 独立实现，DOM 是个与语言无关的 API，但是在浏览器中的接口却是用 JS 来实现的，这意味着通过 JS 去访问另一个模块实现提供的 API 时，会造成很大的开销，这就是造成操作 DOM 慢的原因。

小心 live HTMLCollection

使用 document.getElementsByName(), document.getElementsByClassName(), document.getElementsByTagName()时，返回值是一个实时的的 HTMLCollection，也就是所谓的 live，这些函数返回的集合是以一种 “假定实时态”，这意味着底层文档对象更新时，它也会自动更新，所以每次你获取这个集合中的信息时，这个集合都会重复执行查询的过程。所以，在不需要满足实时更新的情况下，推荐使用document.querySelectorAll()，它将返回一个非 live 的静态列表。

批量修改 DOM

在 JS 同步代码中操作（比如添加、删除或者修改尺寸等）DOM 会让浏览器进行重排，包括

• 添加或删除可见的 DOM 元素
• 元素位置改变
• 元素尺寸改变（包括：外边距、内边距、边框厚度、宽度、高度等属性改变）
• 内容改变，例如：文字改变或图片被另一个不同尺寸的图片替代。
• 页面渲染器初始化。
• 浏览器窗口尺寸改变。

其中 Layout 分为全局布局及增量布局，全局布局是指触发了整个呈现树范围的布局，触发原因可能包括：

1. 影响所有呈现器的全局样式更改，例如字体大小更改。
2. 屏幕大小调整。

布局可以采用增量方式，也就是只对 dirty 呈现器进行布局（这样可能存在需要进行额外布局的弊端）。当呈现器为 dirty 时，会异步触发增量布局。例如，当来自网络的额外内容添加到 DOM 树之后，新的呈现器附加到了呈现树中。

解决方法是让 DOM 脱离文档流再对其进行操作，所有操作完成后添加进文档流，这样可以将重排及重绘的次数降低到一次或两次（脱离文档流及回归文档流的时候），以下方法可以让元素脱离文档流：

• 隐藏元素 —— display: none;（事实上 display：none 不会让元素出现在 layout tree 中）。
• 使用 DocumentFragment（推荐，只有一次 re-flow）。
• 将原始元素拷贝到一个脱离文档的节点中，修改这个副本，完成后再�替换掉原始元素。

事件委托

利用事件冒泡的机制来处理子元素事件的绑定，将子元素的 DOM 事件，交由它们的父元素来进行处理，可以有效降低页面的开销 —— 由于事件的冒泡特性，只需要给父组件添加一个监听事件，就能够捕获到冒泡自子元素的事件，再通过 e.target 来获取真正被操作的子元素。

避免微优化

现在浏览器都有 JIT（just in time）即时编译的引擎，所以会在运行中编译代码

附上一段 知乎 上对 JIT 带来的优化的解释：

动态编译之于静态编译，缺点是它需要即时编译代码，但是有一个优点---编译器可以获得静态编译期所没有的信息。比如：通过运行时的profiling可以知道哪些函数是被大量使用的。在哪些execution path上哪些函数的参数一直都没有变，等等。不要小看这些信息，当即时编译器了解这些信息之后可以在短时间内编译出比静态编译器更优质的二进制码。举例来说，一般程序也遵循90-10原则，即运行时的90%里计算机是在处理其中10%的代码，寻找到这些执行热点代码进行深度优化能得到比静态编译更好的性能（因为已知更多信息量）。

所以我们没有必要再去手工的做一些优化，比如在 for 循环中缓存 length，或者像 《高性能JavaScript》 （这已经是2010年的书了，好多结论都是拿 IE 来说的）中介绍的 for (var i=items.length; i--; ) 来减少每次迭代经过的步骤，我们无法知道这样的代码在经过 JIT 后，是否会带来任何好处，甚至是否会给 JIT 带来一个负面效果，并且这样做肯定会在一定程度上降低代码的可读性。

举个例子，Redux中，在执行 subscribe 的函数时，用的是 for (let i = 0; i < listeners.length; i++)，listeners.length 本身是可以缓存的（不存在运行过程中 length 改变的情况），但是作者给出的理由是 V8 足够智能来做更好的优化，具体可以看我写的 通过GitHub Blame深入分析Redux源码 。

Web Worker

Web Worker 还暂时没研究过，按照MDN的解释

Web Workers is a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface. In addition, they can perform I/O using XMLHttpRequest (although the responseXML and channel attributes are always null). Once created, a worker can send messages to the JavaScript code that created it by posting messages to an event handler specified by that code (and vice versa.) This article provides a detailed introduction to using web workers.

Web Worker 是提供一种在主线程之外的多线程能力，我们可以将耗时的、阻塞的js操作放在 Web Worker 中，PWA 也是基于 Web Worker 来实现，并已经成为了前端的未来趋势之一。

使用 requestAnimationFrame

在某个单个帧中，有可能发生这种情况，在某一帧中会被多次触发某个事件（比如 scroll），这个事件又会频繁的触发样式的修改，导致可能需要多次 Layout 或者 Paint，这是一种浪费，过于频繁的 Layout 和 Paint 会造成卡顿，而且实际上一帧中并不需要重复 Layout 或者 Paint 那么多次。

这个时候就可以用到 rAF 了，先放上一段 MDN 上对 rAF 的解释：

window.requestAnimationFrame() 方法告诉浏览器您希望执行动画并请求浏览器在下一次重绘之前调用指定的函数来更新动画。该方法使用一个回调函数作为参数，这个回调函数会在浏览器重绘之前调用。

简单来说，rAF 的作用就是将传给 rAF 的回调函数，安排在下一帧的一开始执行。这样就能保证这个回调函数最先执行，并且因为绝大多数浏览器都是 60FPS，所以 rAF 自带节流效果。

这里要提一下浏览器的事件循环，在浏览器的一轮事件循环中，会有 task -> microtask -> UI render，这么的一个循序，rAF 将回调函数放在下一帧的开头，就是已经让其所在的那一轮的 UI 先 render，然后再在下一帧的最开始去执行（关于 event loop 的更多介绍，可以看我写的 这篇文章）。

rAF 的一般调用方法为：

let scheduledAnimationFrame = false;

function readAndUpdatePage(){
    doSomething()
    scheduledAnimationFrame = false;
}

function onScroll (evt) {

  // Store the scroll value for later.
  lastScrollY = window.scrollY;

  // Prevent multiple rAF callbacks.
  if (scheduledAnimationFrame)
    return;

  scheduledAnimationFrame = true;
  requestAnimationFrame(readAndUpdatePage);
}

window.addEventListener('scroll', onScroll);

在调用 rAF 时，有一点切记：不要在 rAF 的回调函数中先修改样式，再查询样式，这样就失去了 rAF 的作用。可以将对样式的查询提前到回调函数中或者 rAF 中尽量靠前的位置。

举个例子：

function logBoxHeight() {

  box.classList.add('super-big'); // 1
  // Gets the height of the box in pixels
  // and logs it out.
  console.log(box.offsetHeight); // 2
}

JS 连续执行，rAF 还没能等到下一帧在同一个流水线里被触发强制同步布局了，解决方法也很简单：将 1 和 2 换一下即可，直接用上一帧的样式，再去修改样式。

内存管理

JavaScript 是自动管理内存的，浏览器引擎会自动 GC，作为开发者我们无需去操心内存（只需要别泄漏内存）。但是 GC 同样是需要消耗时间的（可以从 Chrome devTools 里的 Performance 里看到，GC 需要一段很短的时间），如果数据结构使用不当，造成了内存泄漏或者导致频繁的 GC，也是会对页面流畅度造成影响的。

下面是一些写出 GC 友好的代码的教程：

• 编写快速且节省内存的 JavaScript
• MDN 上的内存管理
• Build New Games 上的高性能垃圾收集器友好代码

总结

前端性能优化是个大话题，渲染部分的内容也远不止文章中写出的这些，就拿 Composite 来说，就有 无线性能优化：Composite | Taobao FED | 淘宝前端团队) 这样深入的文章，先在这里挖个坑，以后遇到可以补充的再继续更新，欢迎留言👏

英文一般般，看起来还蛮吃力的

目的

在开发时，经常会需要从命令行中启用各种环境 (express, webpack, gulp 等等)，而且大多数项目需要同时开启数个环境，如果每次开发时都一遍遍的开终端然后 cd 到指定目录再执行，难免有些繁琐，直接使用 shell 脚本来完成这些自动化的工作即可。

举个例子

比如我在开发 hexo-theme-archer 时，需要以下几个步骤

1. cd 到 hexo 的目录
2. 执行 hexo s 来开启 hexo 的本地服务器
3. 再开启一个新的 iterm2 的 tab
4. cd 到 hexo/themes/archer
5. 执行 gulp dev 来开启 gulp 的 watch

理想的解决方案就是将这些步骤写在一个 shell 脚本里，然后直接执行这个脚本即可。

解决方案

• 解决方案1：

  安装 ttab 这个包来提供打开新的 tab 页的命令，然后我们的 zsh / bash 就可以如下写法，代码很简单就不解释了（一般 mac 上都是使用 iterm2 + zsh + oh-my-zsh，所以我是用 zsh 写的，在自带的 terminal 下也能正常运行，不过要在 安全性与隐私 - 隐私 - 辅助 中设置允许 terminal 控制）

  #!/bin/zsh
  cd ~/Project/archer-demo
  ttab -d themes/archer gulp dev
  hexo s

• 解决方案2：
  目前来说解决方案1足够了，如果发现更好的解决办法（比如不是开启 new tab 而是 split）的话，再来补充。

参考

• Open new Terminal Tab from command line (Mac OS X)

1. Parcel 不能直接 console 出 process.env 的所有内容，parcel-bundler/parcel#2299 (comment)

2. 下载历史版本的 Chrome：

• https://www.chromium.org/getting-involved/download-chromium
• https://raw.githubusercontent.com/Bugazelle/chromium-all-old-stable-versions/master/chromium.stable.json
• https://www.slimjet.com/chrome/google-chrome-old-version.php

目的

在 heroku 上部署 React App 的展示页，并且这个 React App 需要 node 来做转发。

思考

基本的 heroku 配置可以直接参照 文档。
如果是不需要 node 来做转发的单纯的 react 项目，可以直接参照官方文档的 Deploying React with Zero Configuration，顺便附上 GitHub项目地址。
但是需要 node 做转发的项目，这个老哥同样给出了解决方案：heroku-cra-node。
下面来分析一下究竟是如何配置的。

分析

先放上目录结构

.
├── LICENSE
├── README.md
├── package-lock.json
├── package.json
├── react-ui
│   ├── LICENSE
│   ├── README.md
│   ├── build
│   ├── config
│   ├── doc
│   ├── node-proxy
│   ├── package.json
│   ├── public
│   ├── scripts
│   ├── src
│   └── tsconfig.json
└── server
    └── index.js

简单来说，就是外面的 package.json 对 node 的包，react-ui 文件夹对应的是整个 react 项目。

外面的 package.json

在我的项目中外面的 package.json 如下

{
  "name": "heroku-cra-node",
  "version": "1.0.0",
  "description": "How to use create-react-app with a custom Node API on Heroku",
  "engines": {
    "node": "6.11.x"
  },
  "scripts": {
    "start": "node server",
    "heroku-postbuild": "cd react-ui/ && npm install && npm run build"
  },
  "cacheDirectories": [
    "node_modules",
    "react-ui/node_modules"
  ],
  "dependencies": {
    "express": "^4.14.1",
    "superagent": "^3.8.2"
  },
  "repository": {
    "type": "git",
    "url": "https://github.com/mars/heroku-cra-node.git"
  },
  "keywords": [
    "node",
    "heroku",
    "create-react-app",
    "react"
  ],
  "license": "MIT",
  "devDependencies": {}
}

对 heroku 起作用的是以下两句

  "scripts": {
    "start": "node server",
    "heroku-postbuild": "cd react-ui/ && npm install && npm run build"
  },

heroku 在检测到这是一个 nodejs 项目后，会自动执行 npm start，开启转发服务

这里的 heroku-postbuild 用到了 npm 的 post- 钩子，在安装完依赖后，在 npm start 之前，heroku 环境下应该会执行 npm run heroku，此时会调用 heroku-postbuild 这个命令。官方解释 在此

还有

  "cacheDirectories": [
    "node_modules",
    "react-ui/node_modules"
  ],

根据 文档，作用是在 heroku 上缓存下载好的 npm 包，就不必每次更新的时候再重新 npm i 了

server/index.js

app.set('port', (process.env.PORT || 8081))
app.use(express.static(path.resolve(__dirname, '../react-ui/build')));

重点是这两句话，第一句是指定端口，如果是在 heroku 中部署的话，端口是动态分配的，所以要使用 process.env.PORT，本地的话自动变为 8081。
第二句是指定静态文件的位置。

总结

把上述文件配置好之后，推送到 heroku，再 heroku open 就可以啦。

1. 有的时候 VSCode 的 TS langserver 会卡死，或者在修改了 tsconfig 后需要重启确保修改生效，可以通过 VSCode 提供的 command TypeScript: Restart TS server 重启即可（要在 TS/TSX 的文件中唤起控制台才会有对应的 command）。
2. 如果 tsconfig 中没有制定 include / exclude / files 的话，会默认包含进所有的 TS 支持的文件

If the "files" and "include" are both left unspecified, the compiler defaults to including all TypeScript (.ts, .d.ts and .tsx) files in the containing directory and subdirectories except those excluded using the "exclude" property. JS files (.js and .jsx) are also included if allowJs is set to true. If the "files" or "include" properties are specified, the compiler will instead include the union of the files included by those two properties. Files in the directory specified using the "outDir" compiler option are excluded as long as "exclude" property is not specified.

进而导致 VSCode 提示包含文件过多的 warning(issue)，所以 include 或 exclude如果有 node_modules 的话一定要指定。

3. rootDir 的作用：就是控制生成的 JS 的层级目录

There is rootDir compiler option, which is not used to specify input to a compiler. It’s used to control the output directory structure alongside with outDir.

根据官方对 rootDir 的默认值的解释：

(common root directory is computed from the list of input files)

如果不指定 rootDir 的话，自动计算的 rootDir 可能会是包含了所有 TS 文件的的顶层文件夹

比如 es 文件夹指定的 rootDir 为 src，es2 指定的 rootDir 为 ./

参考：https://stackoverflow.com/questions/41007001/output-and-directory-structure-in-typescript

4. 遇到 @types 包之间类型重复导致冲突的时候，可以简单粗暴的通过 yarn autoclean 来将不需要的 @types 包干掉解决冲突。https://yarnpkg.com/lang/zh-hans/docs/cli/autoclean/

5. magic TypeScript

type K = 'foo' | 'bar'

// ❌
interface SomeInterface1 {
  [prop: K]: any
}
// An index signature parameter type cannot be a union type. Consider using a mapped object type instead.

// ❌
type SomeType1 = {
  [prop: K]: any
}
// An index signature parameter type cannot be a union type. Consider using a mapped object type instead.

// ❌
interface SomeInterface2 {
  [prop in K]: any
}
// A computed property name in an interface must refer to an expression whose type is a literal type or a 'unique symbol' type.
// A computed property name in an interface must refer to an expression whose type is a literal type or a 'unique symbol' type.
// Cannot find name 'prop'.

// ✅
type SomeType2 = {
  [prop in K]: any
}

// ✅
type Workaround = Record<K, any>

microsoft/TypeScript#24220

6. 在 ambient 的声明文件中引入其他 types

https://stackoverflow.com/a/51114250
https://devblogs.microsoft.com/typescript/announcing-typescript-2-9-rc/

关键路径

浏览器加载流程

浏览器在渲染页面时需要将 HTML 标记转化成 DOM 对象

CSS 则会被转化成 CSSOM 对象

DOM 和 CSSOM 是独立的树形结构，

当 DOM 树和 CSSOM 树都构建完成的时候，他们就会合并在一起构建 render tree，因为要在页面上渲染不仅需要这个页面的结构，也需要知道整个页面的样式，所以 render tree 是 DOM 树和 CSSOM 树的结合体，有了 render tree，浏览器才能知道把什么内容按照什么样式渲染在屏幕上。

浏览器从获取 HTML 到最终在屏幕上显示内容需要完成以下步骤：

1. 处理 HTML 标记并构建 DOM 树。
2. 处理 CSS 标记并构建 CSSOM 树。
3. 将 DOM 与 CSSOM 合并成一个 render tree。
4. 根据渲染树来布局，以计算每个节点的几何信息。
5. 将各个节点绘制到屏幕上。

经过以上整个流程我们才能看见屏幕上出现渲染的内容，优化关键渲染路径就是指最大限度缩短执行上述第 1 步至第 5 步耗费的总时间，让用户最快的看到首次渲染的内容。

另外，这是一个渐进的过程。为达到更好的用户体验，呈现引擎会力求尽快将内容显示在屏幕上。它不必等到整个 HTML 文档解析完毕之后，就会开始构建呈现树和设置布局。在不断接收和处理来自网络的其余内容的同时，呈现引擎会将部分内容解析并显示出来，因为 HTML 采用基于流的布局模型，这意味着大多数情况下只要一次遍历就能计算出几何信息。处于流中靠后位置元素通常不会影响靠前位置元素的几何特征，因此布局可以按从左至右、从上至下的顺序遍历文档。但是也有例外情况，比如 HTML 表格的计算就需要不止一次的遍历。

阻塞渲染的因素

外部样式表

从上面的整个流程我们已经知道，浏览器的渲染需要 render tree， render tree 需要 CSSOM 树才行，所以样式表的加载是会阻塞页面的渲染的，如果有一个外部的样式表处于下载中，那么即使 HTML 已经下载完毕，也会等待外部样式表下载并解析完毕才会开始构建 render tree。

脚本

脚本就更麻烦了，先明确一点， JS 引擎和 UI 的渲染引擎是互斥的，所以当脚本在执行的时候浏览器要将控制权就给 JS 引擎，等到 JS 执行完毕再还给 UI 引擎，不论这个脚本是以何种形式加载的，在执行时均会阻塞 UI 的渲染。

接下来分别看不同形式加载的脚本对页面渲染的阻塞情况：

内联脚本

<script>...</script>

内联的脚本随着 HTML 一起下载，在开始执行时已经完成了 字节 → 字符 → 令牌 → 节点 → 对象模型 的整个过程，所以不存在下载的时间（其实也不能这么说，下载的时间算在了 HTML 的下载时间中），执行时是会阻塞关键渲染路径的。

外部脚本

<script src="sample.js"></script>

外部脚本的整个加载过程及执行过程都是阻塞关键渲染路径的。

带 defer 和 async 的外部脚本

<script src="sample.js" defer></script>
<script src="sample.js" async></script>

带 defer/async 的脚本会与 HTML 并行下载，下载的过程不会阻塞 DOM 的构建，但是执行是会的，不同的是 defer 是在 DomContentLoaded 之前执行，async 是加载完之后立刻执行。

defer/async 的脚本在下载期间不会阻塞页面解析不是一个技术原因而是一个选择，因为内联脚本/外部脚本是要等待他们执行，所以不得不等待他们下载。而页面并不需要等待 defer/async 的脚本，所以他们的下载与页面的解析是并行的。

动态生成的脚本

var dynamicScript = document.creatElement('script')
dynamicScript.src = 'sample.js'
document.head.appendChild(dynamicScript)
dynamicScript.onload = function(){...}

动态生成的脚本的下载过程不会阻塞页面的解析，执行会阻塞解析，有点 async 的感觉。

脚本与样式表的依赖关系

脚本不仅能够访问 DOM 元素，还能访问 DOM 的样式，如果将要执行脚本时浏览器尚未完成 CSSOM 的下载及构建，浏览器将延迟脚本执行和 DOM 构建，直至其完成 CSSOM 的下载和构建。

所以，CSSOM 的构建会阻塞 HTML 的渲染，也会阻塞 JS 的执行，JS 的下载与执行（内联及外部样式表）也会阻塞 HTML 的渲染。

优化方法

为尽快完成首次渲染，我们需要最大限度减小以下三种可变因素：

• 关键资源的数量：可能阻止网页首次渲染的资源。
• 关键路径长度：获取所有关键资源所需的往返次数或总时间。
• 关键字节的数量：实现网页首次渲染所需的总字节数，它是所有关键资源传送文件大小的总和。我们包含单个 HTML 页面的第一个示例包含一项关键资源（HTML 文档）；关键路径长度也与 1 次网络往返相等（假设文件较小），而总关键字节数正好是 HTML 文档本身的传送大小。

优化关键渲染路径的常规步骤如下：

1. 对关键路径进行分析和特性描述：资源数、字节数、长度。
2. 最大限度减少关键资源的数量：删除它们，延迟它们的下载，将它们标记为异步等。
3. 优化关键字节数以缩短下载时间（往返次数）。
4. 优化其余关键资源的加载顺序：您需要尽早下载所有关键资产，以缩短关键路径长度。

关键 CSS

上面已经分析过了，样式表会阻塞渲染，在加载完毕之前是不会显示的，为了让用户以最快的速度看到页面上的内容，可以将页面的某一部分的样式抽离出来，单独放在一个样式表中或者内联在页面中，这样的样式称为关键样式，这部分样式会优先它可以是页面的骨架屏或者是用户刚加载进页面时看到的首屏的内容。

<!doctype html>
<head>
  <style> /* inlined critical CSS */ </style>
  <script> loadCSS('non-critical.css'); </script>
</head>
<body>
  ...body goes here
</body>
</html>

预加载 —— preload & prefetch

使用 preload meta 来提升资源加载的优先级。preload 的定义

preload is a declarative fetch, allowing you to force the browser to make a request for a resource without blocking the document’s onload event.

注意和 prefetch 的区别

<link rel=“prefetch”> is a directive that tells a browser to fetch a resource that will probably be needed for the next navigation. That mostly means that the resource will be fetched with extremely low priority

preload 会提升资源的优先级因为它标明这个资源是本页肯定会用到 —— 本页优先

prefetch 会降低这个资源的优先级因为它标明这个资源是下一页可能用到的 —— 为下一页提前加载

preload 最大的作用就是将下载与执行分离，并且将下载的优先级提到了一个很高的地步，再由我们去控制资源执行的位置。

加速样式表下载

样式表是阻塞页面呈现的（注意是呈现，不是解析），正常通过 link 加载的外部样式表要等下载，构建 CSSOM 树才会让页面呈现完成，但是 preload 能够让样式表的下载和呈现分离。

试想，当你在页面的 head 中写了如下的两个样式表：

<link href="critial.css" rel="stylesheet" />
<link href="non-critial.css" rel="stylesheet" />

第一个是关键 CSS，第二个不是关键 CSS，当页面解析了这两个 link 标签后开始下载，但是即使 critical.css 下载解析完毕也不会呈现页面，因为页面还要下载和解析 non-critical.css。

这时候，就要将 non-critial.css 作为预加载，当样式表作为被 preload 后，他就不会再阻塞页面的呈现，也就是所谓的异步下载，修改后的代码如下：

<link href="critial.css" rel="stylesheet" />
<link rel="preload" href="non-critial.css" as="style" />
<link href="non-critial.css" rel="stylesheet" />

如此一来，页面在解析完 critical.css 之后就会呈现（暂不考虑脚本），而 non-critial 也在下载，但是并不阻塞页面，指导它下载和解析完毕后才会应用到页面上。

现在并不是所有的浏览器都支持 preload，我们可以用 loadCSS 这个库来做 polyfill，其实现的思路也是遍历所有带 preload 和 as 的标签，然后修改标签的 media 为不匹配任何条件并开始下载，在下载完毕后再还原该 link 原来的 media 标签将它应用。

加速脚本下载

preload 将脚本的加载及执行分离，加了 preload 的 <link> 标签的作用是将脚本提到高优先级尽快完成下载，但并未执行。

<link rel="preload" href="//cdn.staticfile.org/jquery/3.2.1/jquery.min.js" as="script" />

还需要在你想要他执行的地方引入一个正常的 <script> 标签执行这个脚本

<script src="//cdn.staticfile.org/jquery/3.2.1/jquery.min.js"></script>

否则 chrome 大约会在 3s 后报一个 warning 来提醒你这个资源被浪费了完全没有被使用到。

preload 的功能听起来很像被 defer 的脚本，但是：

1. defer 无法控制脚本执行的时机，是在 DOMContentLoaded 执行前触发
2. defer 会阻塞 DOMContentLoaded 事件
3. defer 会阻塞 onload 事件，preload 不会阻塞 onload 事件
4. defer 的脚本下载的优先级是 low，preload 的脚本优先级是 high

根据脚本在文档中的位置不同和他们是否是 async，defer 和阻塞，它们会有不同的优先级：

• 阻塞脚本在第一个图片前发起请求的优先级为：Medium（DevTools 中为 high）
• 阻塞脚本在第一个图片后发情请求的优先级为：Low（DevTools 中为 Medium）
• async/defer/动态插入的脚本（不论他们在文档中的什么位置）的优先级为：Lowest（DevTools 中为 Low）

我们以掘金的首页为例：

可以看到 high 的全是写在 HTML 中进行加载的静态资源，Low 的都是 thunk 在 JS 中的脚本，是为其他页面预加载的。

加速字体下载

自定义的字体在加载之前会处于 FOIT（Flash of Invisible Text）现象，具体的可以看 这篇文章，虽然我们可以使用类似 webFont 一类的库来控制字体的闪现和添加钩子函数，但最佳解决方法还是让字体的加载达到最快的速度。

使用 preload 也可以来加速字体的下载，在 head 中声明 preload，比先下载样式表再从中读到 @font-face 的 src 再去加载要快得多。

<link rel="preload" as="font" href="https://at.alicdn.com/t/font_zck90zmlh7hf47vi.woff">

但是要注意

preload 字体不带 crossorigin 也将会二次获取！ 确保你对 preload 的字体添加 crossorigin 属性，否则他会被下载两次，这个请求使用匿名的跨域模式。这个建议也适用于字体文件在相同域名下，也适用于其他域名的获取(比如说默认的异步获取)。

preload 如果不带 crossorigin meta ，默认情况下 （即未指定 crossorigin 属性时）, CORS 根本不会使用，这样 http 的 request header 中就不会有 origin，默认不去跨域，但是 @font-face 中去加载字体是默认跨域请求的，所以会造成两次的 request header 不同，无法命中缓存，造成重复请求。

解决方法就是带上 crossorigin，

<link rel="preload" as="font" href="//at.alicdn.com/t/font_327081_19o9k2m6va4np14i.woff" crossorigin>
<link rel="preload" as="font" href="//at.alicdn.com/t/font_327081_19o9k2m6va4np14i.woff" crossorigin="anonymous">
<link rel="preload" as="font" href="//at.alicdn.com/t/font_327081_19o9k2m6va4np14i.woff" crossorigin="fi3ework">

空关键字和无效关键字都会被当做 anonymous。

其他资源

preload 不仅可以将这些在 head 中的资源加速，还可以提前加载一些隐藏在 CSS 和 JS 中的资源，比如刚才隐藏在 CSS 中的字体资源，或者 JS 中请求的资源。

preload 的标签可以动态生成，这意味着在任何时候你都可以在页面中提前加载但不执行一个脚本，然后通过动态脚本来立刻执行它。

var preload = document.createElement("link");
link.href = "myscript.js";
link.rel = "preload";
link.as = "script";
document.head.appendChild(link);

var script = document.createElement("script");
script.src = "myscript.js";
document.body.appendChild(script);

媒体查询

现在的页面基本上都具有响应式设计，即针对移动端或桌面端会采用 media 进行媒体查询，有两种包含媒体查询的 CSS 代码的方法：1. 将需要媒体查询的代码和基础样式代码放在同一文件中，使用 @media 来使媒体查询生效。 2. 将需要媒体查询的代码放在单独的一个外部样式表中，使用 media meta 对需要媒体查询的 link 进行控制。

这两种方法各有好处，如果需要媒体查询的代码量很小，那么和基础样式放在一起也没有关系，可以节省一次 HTTP 请求。如果比较大的话，那么就会让样式表的体积增加，造成 FOUC 的时间变长，这时候更适合使用第二种。

另外请注意“阻塞渲染”仅是指浏览器是否需要暂停网页的首次渲染，直至该资源准备就绪。无论哪一种情况，浏览器仍会下载 CSS 资源，但是不阻塞渲染的资源优先级较低。

优先级较低意味着浏览器在解析 HTML 时发现要下载这个样式表，但并不一定会立刻开始下载，而是可能会将它滞后一段时间再下载（等级低没人权），从 DevTools 上也可以看到 Highest 和 Lowest 的区别。

如果媒体查询的样式表符合当前的页面，那么媒体查询的样式表也会阻塞关键路径渲染（就好像他是个正常的一样），同时，它的下载优先级也会恢复到最高（恢复人权）。

media 配合 preload 能做到响应式加载资源，如下代码，分别是两副图片适配移动端与 PC 端，如果不加 preload 的话，那么其中一幅就会以 Lowest 的等级延迟加载，但是如果我们是一个移动端优先的网站，不希望用户浪费流量及网速下载PC 端的大图的话，就在每个 link 上加上 preload 即可，只有在打开网页时符合 media 的资源会被加载，不符合 media 的资源始终不会被加载，即使后面将浏览器的宽度拉宽也不会加载。

<link rel="preload" href="bg-image-narrow.png" as="image" media="(max-width: 600px)">
<link rel="preload" href="bg-image-wide.png" as="image" media="(min-width: 601px)">

如果用户真的拉宽了屏幕，或者切换端设备，可以使用 Window.matchMedia，来进行 media 的匹配。

var mediaQueryList = window.matchMedia("(max-width: 600px)");
var header = document.querySelector('header');

if(mediaQueryList.matches) {
    header.style.backgroundImage = 'url(bg-image-narrow.png)';
} else {
    header.style.backgroundImage = 'url(bg-image-wide.png)';
}

DNS 预解析 —— dns-prefetch

dns-prefetch 的使用方法更加简单：

<link rel="dns-prefetch" href="//host_name_to_prefetch.com">

link 标签的 rel 设定为 dns-prefetch，href 设定为需要预加载的主机域名即可。

在讲 dns-prefetch 之前，先复习一遍 DNS 的作用及可以优化的点才能了解 dns-prefetch 带来的好处。

网络通讯大部分是基于TCP/IP的，而TCP/IP是基于IP地址的，所以计算机在网络上进行通讯时只能识别如“202.96.134.133”之类的IP地址，而不能认识域名。我们无法记住10个以上IP地址的网站，所以我们访问网站时，更多的是在浏览器地址栏中输入域名，就能看到所需要的页面，这是因为有一个叫“DNS服务器”的计算机自动把我们的域名“翻译”成了相应的IP地址，然后调出IP地址所对应的网页。

一图流表达如下，其中 3, 4, 5, 6, 7 都属于 DNS 解析的过程，也是 dns-prefetch 发挥作用的地方。

dns-prefetch 主要用来在用户点击一个链接之前解析对应的域名，这会自动去调用用户浏览器的解析机制。浏览器会在用户浏览网页时多线程完成预加载，当用户真正点击的时候就节省了用户等待域名解析的时间。

Chromium 的官方文档中很详细的介绍了 pre-fetch：

1. Chromium 会根据页面中超链接的 href 去寻找主机名自动去 prefetch

2. 如果访问的链接被重定向，那么浏览器可能无法自动识别出真正的主机进行 prefetch，此时需要我么手工预加载，也就是使用 prefetch 标签来指定主机。（这也是决定是否使用 dns-prefetch 的判断方法）

3. 预加载不会对页面渲染造成损害，因为 Chromium 有8个专门用来预加载的线程。

4. dns-prefetch 带来的网络消耗是很小的

   Each request typically involves sending a single UDP packet that is under 100 bytes out, and getting back a response that is around 100 bytes

   但是用最小的网络开销代价可以换来较好的用户体验。

5. 默认情况下，Chromium 和 Firefox 出于安全考虑会关闭在 https 下的自动预加载，可以通过指定 meta http-equiv 来开启自动预加载。

   <meta http-equiv="x-dns-prefetch-control" content="on">

   PS: 如果通过 meta 显示的关闭了预加载，之后将无法再次开启预加载。

拿知乎举个例子，打开知乎，进入控制台，搜索 dns-prefetch

发现知乎用了如下的 link，都是知乎的静态资源服务器，因为在没有缓存（假设没有打开过知乎）时打开某个知乎页面，如果该页面有图片，并且是从以上的域名获取的话 dns-prefetch 就不会起作用。如果没有图片，那么上面的 dns-prefetch 就会解析域名，等到打开一个有图的知乎页面时 DNS 解析已经完成了。

DNS 预解析 + TCP + TLS —— preconnect

提前加载整个页面 —— prerender

以上两者详见：

• [译] 资源提示 —— 什么是 Preload，Prefetch 和 Preconnect？
• [译] Prefetch & preconnect-dns 的优先级 性能优化

参考

• Preload: What Is It Good For?

• 用 preload 预加载页面资源

• [译]Preload，Prefetch 和它们在 Chrome 之中的优先级

• Preload, Prefetch And Priorities in Chrome

• CORS settings attributes

• Understanding Critical CSS

• 通过rel="preload"进行内容预加载

• DNS Prefetching

• 预加载系列一：DNS Prefetching 的正确使用姿势

• 浏览器的工作原理：新式网络浏览器幕后揭秘

前言

在 上一篇文章 中介绍了前端路由的实现及 react-router-v4（以下简称 rr4） 的源码分析，目前阶段 rr4 已经基本垄断了 react 生态圈的路由，虽然 v4 版本成功完成了一切皆组件的蜕变，但其实它本身还有诸多问题，比如 keep-alive。

keep-alive 的叫法取自 vue-keep-alive，在 vue 中，可以将某组件暂存于内存，然后跳转到其他页面再从内存中将这个组件拿出来。换算到路由中，我们可以想象这样一个情景 —— 有一个商品列表页，每个商品点进去都跳转到对应的商品详情页面，用户每次浏览完一个商品详情之后回退，列表页会重新渲染，那么如果用户已经往下划了几屏之后回退，那么每次返回后都要先滑到上次浏览的位置，这种体验可以说是灾难性的。

现在的浏览器非常贴心的实现了 Scroll Restoration（后退时恢复滚动位置），这在非 SPA 页面有非常好的体验效果，但是在 SPA 中，会有以下问题：

1. 浏览器试图恢复滚动距离时，页面可能还没有加载完毕。因为回退的页面需要重新 mount，可能存在异步加载的部分，导致页面出现跳动。
2. 点击链接进入页面就不会应用滚动恢复这一行为。只有在点击浏览器按钮的前进后退按钮时，才会触发 popstate 事件并触发 scroll restoration，通过点击链接无法触发滚动恢复。
3. 这是非规范的一个 API（详见），所以各个浏览器的实现并不完全一致。

其实 iOS 和 Android 端的路由转换是十分理想的 —— 支持转场动画，手势返回，keep-alive。

本文中我们试图解决为 rr4 实现一个可以缓存的 Route 来解决上面例子中的问题，并借此探索一下 rr4 目前阶段的不足之处及可以加强的地方。说句题外话，rr4 的核心开发者又新搞了一个 reach-router 路由库，针对 rr4 的缺点进行了针对性的改进，已经钦点了是下一代的路由旗舰管理库。

轮子

先放上我造的轮子的仓库地址 react-live-route 感受一下本文的最终目的，react-live-route 可以使路由在路径不匹配时隐藏而不被卸载，在匹配路径时完全恢复离开页面时的样子。欢迎 star 和提 issue。

PC 端可以预览 demo

移动端扫码试玩 （点一下玩一年）

思路

我们先重新将要解决的问题整理一下：

我们有列表页面和详情页，在列表页点击项目进入对应的详情页时，尽量保留列表页的视图与数据状态（包括滚动位置）。在从详情页回退到列表页的时候，希望列表页能恢复到上次离开时的状态。

其中我们要恢复的状态：

1. 页面的滚动位置。
2. 路由组件的一切状态，包括路由的组件的所有子元素的状态。

并且要做到无痛兼容 rr4，侵入性越小越好。我们的目标是为 react-router 设计一个增强型的 Route 组件，可以像 iOS 和 Android 端的路由切换一样“隐藏”上一个导航的页面，在这里有两种解决问题的思路：

思路1

unmount 时储存状态，re-mount 时取回状态

在列表页将要 unmount 的时候，将需要保留的数据状态存在 context（或者 window.sessionStorage 等等）

**优点：**可以在 unmount 和 re-mount 时利用生命周期。

缺点：

1. 需要自己选择要存储的信息。
2. 父组件无法拿到子组件的状态进行保存。
3. 会重新 unmount 和 re-mount，这其实是不应该发生的，被隐藏的列表页应该是“潜伏”在详情页的下面，等到重新进入列表页时才出现，而不是已经被 unmount 了。

思路2

不 unmount，只是根据路由隐藏/显示对应页面

在切换到详情页的路径时，不将列表页 unmount，而是 display: none 掉它，在从详情页返回列表页的时候，再 display: block 将列表页显示回来。

优点： 简单粗暴，因为没有卸载组件，所以可以不用管页面的数据状态的保存情况。只需要管理好恢复显示、隐藏与正常 re-render，再恢复滚动位置即可。

缺点： 配合转场动画可能会有问题。

由于思路 1 的实现有很大的局限性，所以按照思路 2 来进行实现。

实现

增强的 Route 组件称为 LiveRoute，我们首先要确定，这个增强组件在什么情况下起作用，以及它有哪几种状态，react-router 有一篇关于 Scroll Restoration 的文章 ，是关于 react-router 去除了滚动恢复的功能的原因，其中有提到原因：

What got tricky for me was defining an "opt-out" API for when I didn't want the window scroll to be managed.

就是因为实际的应用情况太多变，他们无法合适的判断什么时候需要进行滚动恢复的管理。

在一开始我是打算使用成对的路由来实现，其中一个 LiveRoute 的存活状态去控制另一个需要保留存活的 LiveRoute：

<LiveRoute path='/list' liveKey='listToItem' component={List}/>
<LiveRoute path='/item/:id' onLiveKey='listToItem' component={Item}/>

但是路由间需要在 router 上创建 context 来辅助通信，如下是 react-router 正常更新一次的流程，路由间的通信会再一次触发被通知的路由的 setState，这是无法避免的，但是 Route 作为整个应用中非常靠上的组件，副作用要尽可能的小。

换个思路，其实缓存页面的匹配规则就是控制页面的隐藏/恢复显示与正常卸载，而 rr4 正常的路由匹配规则就是控制渲染/卸载，通过 path 这个 props 来完成。那么我们直接给 LiveRoute 一个额外的来控制隐藏/恢复显示的 livePath 的路径即可，其规则就可以直接套用 path，当路由 livePath 匹配时，则处于隐藏状态，其他路径则按照 rr4 的规则正常渲染/卸载。调用方法：

<LiveRoute path='/list' livePath='/item/:id' component={List}/>

如此一来，LiveRoute 显示状态的依赖变为 context.router，这样做的好处是依赖变的简单，所有的路由都会“同时”获得依赖的更新，并且相互之间没有耦合。

LiveRoute 状态

LiveRoute 内部有一个状态机，有三种渲染组件的状态：

• HIDE_RENDER：livePath 匹配则需要将 LiveRoute 渲染的组件隐藏掉。进入此状态时需要备份页面的滚动位置，然后通过 ReactDOM.findDOMNode 来获取路由渲染的组件的 DOM，将 dom.style.display = 'none'，并备份修改之前的 display 的属性。

• NORMAL_RENDER_MATCH：路由正常渲染并且匹配上了。调用原版 Route 的渲染方法即可

  if (component) return match ? React.createElement(component, props) : null;
  if (render) return match ? render(props) : null;

但是在每次正常匹配渲染的时候都要保存当前的 context.router，作为之后隐藏渲染时需要保持渲染所需的 router，在 componnetDidUpdate 后查看有没有备份的滚动位置，如果有就恢复滚动位置并清除备份的滚动位置。

• NORMAL_RENDER_UNMATCH：正常渲染但是不匹配，即要卸载当前路由的组件。要做的就比较简单了，清空 LiveRoute 中保存的 DOM 的引用，清除掉保存的滚动位置，然后调用原版的的 Route 的渲染方法（卸载）即可。

实现细节

如何保护路由渲染的组件存活

当 router 与 livePath 匹配 的时候需要将 LiveRoute 置为隐藏状态。

但是新的 router 传入必然会计算出一个新的 match 去 setState，而新的 setState 与当前的 path 并不匹配，所以 LiveRoute 每次隐藏渲染时需要在 componentWillReceiveProps 中计算上次的 prevMatch。
在 render 的部分，需要当前的 router 在计算传递给组件的 props，所以需要在最后一次正常渲染的时候保存当前的 router。
最后，将 prevMatch 作为 setState 的 match，再拿出之前保存的 _prevRoute 完成渲染，一句话说就是将最后一次正常渲染的参数给保留了下来并在需要隐藏的时候拿出来伪装成最后一次正常渲染，再将 DOM 隐藏就完成了核心功能。

保存滚动位置

由于 LiveRoute 拦截了路由的卸载，所以滚动位置不需要再存储在全局的 sessionStorage 中，LiveRoute 会一直存活，滚动位置直接可以保存为 LiveRoute 的属性。并且，相比 sessionStorage 必须先 JSON.stringify() 保存对象的操作，有了更高的可拓展性。

Switch

有一个问题就是与 Switch 的不兼容性，这个是采用 display:none 这种方法无法避免的，我也在 文档 中写到了。因为 Switch 的目的就是仅渲染第一个匹配的子元素，而 LiveRoute 的目的是强行渲染不匹配的子元素，所以不能在 Switch 中直接嵌套一个 LiveRoute 来使用。解决方法也简单，就是将 LiveRoute 从 Switch 中拿到外面来，不要让 LiveRoute 和 Switch 相互干扰，但是要注意此时 LiveRoute 的渲染与否也失去了 Switch 的跳过功能了。

滚动位置的不变性

在一些情况下 LiveRoute 的 DOM 将会被直接修改，所以在切换路由时滚动位置将不会改变而界面已经发生改变。这并不是 react-live-route 带来的问题，你可以手动将页面滚动到顶部，这篇 react-router 提供的 教学文章 中可以提供一些帮助。另外，如果 LiveRoute 将要恢复滚动位置，由于 React 的渲染顺序，它将发生在 LiveRoute 渲染的组件的滚动操作之后发生（滚动操作发生在 componentDidMount 或 componentDidUpdate 中）。

总结

react-live-route 实现了路由的缓存及复原，但是还有一些其他的问题需要解决，比如与转场动画的兼容性及给 LivePath 传入一个数组来实现多规则匹配的问题。（因为使用的是 react-router 的 computePath 方法解析 path，所以默认支持传入数组，具体详见 path-to-regexp 的 文档）

最后再放上 react-live-route 的仓库地址 react-live-route，欢迎 star 和提出 issue。

参考

• 浏览器的恢复滚动行为
• Custom Scroll Restoration - History-based API

前言

react-router 目前作为 react 最流行的路由管理库，已经成为了某种意义上的官方路由库（不过下一代的路由库 reach-router 已经蓄势待发了），并且更新到了 v4 版本，完成了一切皆组件的升级。本文将对 react-router v4（以下简称 rr4） 的源码进行分析，来理解 rr4 是如何帮助我们管理路由状态的。

路由

在分析源码之前，先来对路由有一个认识。在 SPA 盛行之前，还不存在前端层面的路由概念，每个 URL 对应一个页面，所有的跳转或者链接都通过 <a> 标签来完成，随着 SPA 的逐渐兴盛及 HTML5 的普及，hash 路由及基于 history 的路由库越来越多。

路由库最大的作用就是同步 URL 与其对应的回调函数。对于基于 history 的路由，它通过 history.pushState 来修改 URL，通过 window.addEventListener('popstate', callback) 来监听前进/后退事件；对于 hash 路由，通过操作 window.location 的字符串来更改 hash，通过 window.addEventListener('hashchange', callback) 来监听 URL 的变化。

SPA 路由实现

hash 路由

class Router {
  constructor() {
    // 储存 hash 与 callback 键值对
    this.routes = {};
    // 当前 hash
    this.currentUrl = '';
    // 记录出现过的 hash
    this.history = [];
    // 作为指针,默认指向 this.history 的末尾,根据后退前进指向 history 中不同的 hash
    this.currentIndex = this.history.length - 1;
    this.backIndex = this.history.length - 1
    this.refresh = this.refresh.bind(this);
    this.backOff = this.backOff.bind(this);
    // 默认不是后退操作
    this.isBack = false;
    window.addEventListener('load', this.refresh, false);
    window.addEventListener('hashchange', this.refresh, false);
  }

  route(path, callback) {
    this.routes[path] = callback || function() {};
  }

  refresh() {
    console.log('refresh')
    this.currentUrl = location.hash.slice(1) || '/';
    this.history.push(this.currentUrl);
    this.currentIndex++;
    if (!this.isBack) {
      this.backIndex = this.currentIndex
    }
    this.routes[this.currentUrl]();
    console.log('指针:', this.currentIndex, 'history:', this.history);
    this.isBack = false;
  }
  // 后退功能
  backOff() {
    // 后退操作设置为true
    console.log(this.currentIndex)
    console.log(this.backIndex)
    this.isBack = true;
    this.backIndex <= 0 ?
      (this.backIndex = 0) :
      (this.backIndex = this.backIndex - 1);
    location.hash = `#${this.history[this.backIndex]}`;
  }
}

完整实现 hash-router，参考 hash router 。

其实知道了路由的原理，想要实现一个 hash 路由并不困难，比较需要注意的是 backOff 的实现，包括  hash router 中对 backOff 的实现也是有 bug 的，浏览器的回退会触发 hashChange 所以会在 history 中 push 一个新的路径，也就是每一步都将被记录。所以需要一个 backIndex 来作为返回的 index 的标识，在点击新的 URL 的时候再将 backIndex 回归为 this.currentIndex。

基于 history 的路由实现

class Routers {
  constructor() {
    this.routes = {};
    // 在初始化时监听popstate事件
    this._bindPopState();
  }
  // 初始化路由
  init(path) {
    history.replaceState({path: path}, null, path);
    this.routes[path] && this.routes[path]();
  }
  // 将路径和对应回调函数加入hashMap储存
  route(path, callback) {
    this.routes[path] = callback || function() {};
  }

  // 触发路由对应回调
  go(path) {
    history.pushState({path: path}, null, path);
    this.routes[path] && this.routes[path]();
  }
  // 后退
  backOff(){
    history.back()
  }
  // 监听popstate事件
  _bindPopState() {
    window.addEventListener('popstate', e => {
      const path = e.state && e.state.path;
      this.routes[path] && this.routes[path]();
    });
  }
}

参考 H5 Router

相比 hash 路由，h5 路由不再需要有些丑陋去的去修改 window.location 了，取而代之使用 history.pushState 来完成对 window.location 的操作，使用 window.addEventListener('popstate', callback) 来对前进/后退进行监听，至于后退则可以直接使用 window.history.back() 或者 window.history.go(-1) 来直接实现，由于浏览器的 history 控制了前进/后退的逻辑，所以实现简单了很多。

react 中的路由

react 作为一个前端视图框架，本身是不具有除了 view （数据与界面之间的抽象）之外的任何功能的，为 react 引入一个路由库的目的与上面的普通 SPA 目的一致，只不过上面路由更改触发的回调函数是我们自己写的操作 DOM 的函数；在 react 中我们不直接操作 DOM，而是管理抽象出来的 VDOM 或者说 JSX，对 react 的来说路由需要管理组件的生命周期，对不同的路由渲染不同的组件。

源码分析

预备知识

在前面我们了解了创建路由的目的，普通 SPA 路由的实现及 react 路由的目的，先来认识一下 rr4 的周边知识，然后就开始对 react-router 的源码分析。

history

history 库，是 rr4 依赖的一个对 window.history 加强版的 history 库。

match

源自 history 库，表示当前的 URL 与 path 的匹配的结果

match: {
    path: "/", // 用来匹配的 path
	url: "/", // 当前的 URL
	params: {}, // 路径中的参数
	isExact: pathname === "/" // 是否为严格匹配
}

location

还是源自 history 库，是 history 库基于 window.location 的一个衍生。

hash: "" // hash
key: "nyi4ea" // 一个 uuid
pathname: "/explore" // URL 中路径部分
search: "" // URL 参数
state: undefined // 路由跳转时传递的 state

我们带着问题去分析源码，先逐个分析每个组件的作用，在最后会有回答，在这里先举一个 rr4 的小 DEMO

1. 页面初始化时的渲染过程？
2. 点击一个 Link 跳转及渲染更新的过程？

packages

rr4 将路由拆成了几个包 —— react-router 负责通用的路由逻辑，react-router-dom 负责浏览器的路由管理，react-router-native 负责 react-native 的路由管理，通用的部分直接从 react-router 中导入，用户只需引入 react-router-dom 或 react-router-native 即可，react-router 作为依赖存在不再需要单独引入。

Router

import React from 'react'
import { render } from 'react-dom'
import { BrowserRouter } from 'react-router-dom'
import App from './components/App';

render(){
    return(
		<BrowserRouter>
			<App />
		</BrowserRouter>
	)
)}

这是我们调用 Router 的方式，这里拿 BrowserRouter 来举例。

BrowserRouter 的源码在 react-router-dom 中，它是一个高阶组件，在内部创建一个全局的 history 对象（可以监听整个路由的变化），并将 history 作为 props 传递给 react-router 的 Router 组件（Router 组件再会将这个 history 的属性作为 context 传递给子组件）

  render() {
    return <Router history={this.history} children={this.props.children} />;
  }

其实整个 Router 的核心是在 react-router 的 Router 组件中，如下，借助 context 向 Route 传递组件，这也解释了为什么 Router 要在所有 Route 的外面。

  getChildContext() {
    return {
      router: {
        ...this.context.router,
        history: this.props.history,
        route: {
          location: this.props.history.location,
          match: this.state.match
        }
      }
    };
  }

这是 Router 传递给子组件的 context，事实上 Route 也会将 router 作为 context 向下传递，如果我们在 Route 渲染的组件中加入

  static contextTypes = {
    router: PropTypes.shape({
      history: PropTypes.object.isRequired,
      route: PropTypes.object.isRequired,
      staticContext: PropTypes.object
    })
  };

来通过 context 访问 router，不过 rr4 一般通过 props 传递，将 history, location, match 作为三个独立的 props 传递给要渲染的组件，这样访问起来方便一点（实际上已经完全将 router 对象的属性完全传递了）。

在 Router 的 componentWillMount 中， 添加了

  componentWillMount() {
    const { children, history } = this.props;

    invariant(
      children == null || React.Children.count(children) === 1,
      "A <Router> may have only one child element"
    );

    // Do this here so we can setState when a <Redirect> changes the
    // location in componentWillMount. This happens e.g. when doing
    // server rendering using a <sStaticRouter>.
    this.unlisten = history.listen(() => {
      this.setState({
        match: this.computeMatch(history.location.pathname)
      });
    });
  }

history.listen 能够监听路由的变化并执行回调事件。

在这里每次路由的变化执行的回调事件为

this.setState({
    match: this.computeMatch(history.location.pathname)
});

相比于在 setState 里做的操作，setState 本身的意义更大 —— 每次路由变化 -> 触发顶层 Router 的回调事件 -> Router 进行 setState -> 向下传递 nextContext（context 中含有最新的 location）-> 下面的 Route 获取新的 nextContext 判断是否进行渲染。

之所以把这个 subscribe 的函数写在 componentWillMount 里，就像源码中给出的注释：是为了 SSR 的时候，能够使用 Redirect。

Route

Route 的作用是匹配路由，并传递给要渲染的组件 props。

在 Route 的 componentWillReceiveProps 中

  componentWillReceiveProps(nextProps, nextContext) {
    ...
    this.setState({
      match: this.computeMatch(nextProps, nextContext.router)
    });
  }

Route 接受上层的 Router 传入的 context，Router 中的 history 监听着整个页面的路由变化，当页面发生跳转时，history 触发监听事件，Router 向下传递 nextContext，就会更新 Route 的 props 和 context 来判断当前 Route 的 path 是否匹配 location，如果匹配则渲染，否则不渲染。

是否匹配的依据就是 computeMatch 这个函数，在下文会有分析，这里只需要知道匹配失败则 match 为 null，如果匹配成功则将 match 的结果作为 props 的一部分，在 render 中传递给传进来的要渲染的组件。

接下来看一下 Route 的 render 部分。

  render() {
    const { match } = this.state; // 布尔值，表示 location 是否匹配当前 Route 的 path
    const { children, component, render } = this.props; // Route 提供的三种可选的渲染方式
    const { history, route, staticContext } = this.context.router; // Router 传入的 context
    const location = this.props.location || route.location;
    const props = { match, location, history, staticContext };

    if (component) return match ? React.createElement(component, props) : null; // Component 创建

    if (render) return match ? render(props) : null; // render 创建

    if (typeof children === "function") return children(props); // 回调 children 创建

    if (children && !isEmptyChildren(children)) // 普通 children 创建
      return React.Children.only(children);

    return null;
  }

rr4 提供了三种渲染组件的方法：component props，render props 和 children props，渲染的优先级也是依次按照顺序，如果前面的已经渲染后了，将会直接 return。

• component (props) —— 由于使用 React.createElement 创建，所以可以传入一个 class component。
• render (props) —— 直接调用 render() 展开子元素，所以需要传入 stateless function component。
• children (props) —— 其实和 render 差不多，区别是不判断 match，总是会被渲染。
• children（子元素）—— 如果以上都没有，那么会默认渲染子元素，但是只能有一个子元素。

这里解释一下官网的 tips，component 是使用 React.createElement 来创建新的元素，所以如果传入一个内联函数，比如

<Route path='/' component={()=>(<div>hello world</div>)}

的话，由于每次的 props.component 都是新创建的，所以 React 在 diff 的时候会认为进来了一个全新的组件，所以会将旧的组件 unmount，再 re-mount。这时候就要使用 render，少了一层包裹的 component 元素，render 展开后的元素类型每次都是一样的，就不会发生 re-mount 了（children 也不会发生 re-mount）。

Switch

我们紧接着 Route 来看 Switch，Switch 是用来嵌套在 Route 的外面，当 Switch 中的第一个 Route 匹配之后就不会再渲染其他的 Route 了。

  render() {
    const { route } = this.context.router;
    const { children } = this.props;
    const location = this.props.location || route.location;

    let match, child;
    React.Children.forEach(children, element => {
      if (match == null && React.isValidElement(element)) {
        const {
          path: pathProp,
          exact,
          strict,
          sensitive,
          from
        } = element.props;
        const path = pathProp || from;

        child = element;
        match = matchPath(
          location.pathname,
          { path, exact, strict, sensitive },
          route.match
        );
      }
    });

    return match
      ? React.cloneElement(child, { location, computedMatch: match })
      : null;
  }

Switch 也是通过 matchPath 这个函数来判断是否匹配成功，一直按照 Switch 中 children 的顺序依次遍历子元素，如果匹配失败则 match 为 null，如果匹配成功则标记这个子元素和它对应的 location、computedMatch。在最后的时候使用 React.cloneElement 渲染，如果没有匹配到的子元素则返回 null。

接下来我们看下 matchPath 是如何判断 location 是否符合 path 的。

matchPath

matchPath 返回的是一个如下结构的对象

{
    path, // 用来进行匹配的路径，其实是直接导出的传入 matchPath 的 options 中的 path
    url: path === "/" && url === "" ? "/" : url, // 整个的 URL
    isExact, // url 与 path 是否是 exact 的匹配
    // 返回的是一个键值对的映射
    // 比如你的 path 是 /users/:id，然后匹配的 pathname 是 /user/123
    // 那么 params 的返回值就是 {id: '123'}
    params: keys.reduce((memo, key, index) => {
      memo[key.name] = values[index];
      return memo;
    }, {}) 
  }

这些信息将作为匹配的参数传递给 Route 和 Switch（Switch 只是一个代理，它的作用还是渲染 Route，Switch 计算得到的 computedMatch 会传递给要渲染的 Route，此时 Route 将直接使用这个 computedMatch 而不需要再自己来计算）。

在 matchPath 内部 compilePath 时，有个

const patternCache = {};
const cacheLimit = 10000;
let cacheCount = 0;

作为 pathToRegexp 的缓存，因为 ES6 的 import 模块导出的是值的引用，所以将 patternCache 可以理解为一个全局变量缓存，缓存以 {option:{pattern: }} 的形式存储，之后如果需要匹配相同 pattern 和 option 的 path，则可以直接从缓存中获得正则表达式和 keys。

加缓存的原因是路由页面大部分情况下都是相似的，比如要访问 /user/123 或 /users/234，都会使用 /user/:id 这个 path 去匹配，没有必要每次都生成一个新的正则表达式。SPA 在页面整个访问的过程中都维护着这份缓存。

Link

实际上我们可能写的最多的就是 Link 这个标签了，我们从它的 render 函数开始看

render() {
    const { replace, to, innerRef, ...props } = this.props; // eslint-disable-line no-unused-vars

    invariant(
      this.context.router,
      "You should not use <Link> outside a <Router>"
    );

    invariant(to !== undefined, 'You must specify the "to" property');

    const { history } = this.context.router;
    const location =
      typeof to === "string"
        ? createLocation(to, null, null, history.location)
        : to;

    const href = history.createHref(location);
    // 最终创建的是一个 a 标签
    return (
      <a {...props} onClick={this.handleClick} href={href} ref={innerRef} />
    );
  }

可以看到 Link 最终还是创建一个 a 标签来包裹住要跳转的元素，但是如果只是一个普通的带 href 的 a 标签，那么就会直接跳转到一个新的页面而不是 SPA 了，所以在这个 a 标签的 handleClick 中会 preventDefault 禁止默认的跳转，所以这里的 href 并没有实际的作用，但仍然可以标示出要跳转到的页面的 URL 并且有更好的 html 语义。

在 handleClick 中，对没有被 “preventDefault的 && 鼠标左键点击的 && 非 _blank 跳转 的&& 没有按住其他功能键的“ 单击进行 preventDefault，然后 push 进 history 中，这也是前面讲过的 —— 路由的变化 与 页面的跳转 是不互相关联的，rr4 在 Link 中通过 history 库的 push 调用了 HTML5 history 的 pushState，但是这仅仅会让路由变化，其他什么都没有改变。还记不记得 Router 中的 listen，它会监听路由的变化，然后通过 context 更新 props 和 nextContext 让下层的 Route 去重新匹配，完成需要渲染部分的更新。

  handleClick = event => {
    if (this.props.onClick) this.props.onClick(event);

    if (
      !event.defaultPrevented && // onClick prevented default
      event.button === 0 && // ignore everything but left clicks
      !this.props.target && // let browser handle "target=_blank" etc.
      !isModifiedEvent(event) // ignore clicks with modifier keys
    ) {
      event.preventDefault();

      const { history } = this.context.router;
      const { replace, to } = this.props;

      if (replace) {
        history.replace(to);
      } else {
        history.push(to);
      }
    }
  };

withRouter

const withRouter = Component => {
  const C = props => {
    const { wrappedComponentRef, ...remainingProps } = props;
    return (
      <Route
        children={routeComponentProps => (
          <Component
            {...remainingProps}
            {...routeComponentProps}
            ref={wrappedComponentRef}
          />
        )}
      />
    );
  };

  C.displayName = `withRouter(${Component.displayName || Component.name})`;
  C.WrappedComponent = Component;
  C.propTypes = {
    wrappedComponentRef: PropTypes.func
  };

  return hoistStatics(C, Component);
};

export default withRouter;

withRouter 的作用是让我们在普通的非直接嵌套在 Route 中的组件也能获得路由的信息，这时候我们就要 WithRouter(wrappedComponent) 来创建一个 HOC 传递 props，WithRouter 的其实就是用 Route 包裹了 SomeComponent 的一个 HOC。

创建 Route 有三种方法，这里直接采用了传递 children props 的方法，因为这个 HOC 要原封不动的渲染 wrappedComponent（children props 比较少用得到，某种程度上是一个内部方法）。

在最后返回 HOC 时，使用了 hoistStatics 这个方法，这个方法的作用是保留 SomeComponent 类的静态方法，因为 HOC 是在 wrappedComponent 的外层又包了一层 Route，所以要将 wrappedComponent 类的静态方法转移给新的 Route，具体参见 Static Methods Must Be Copied Over。

理解

现在回到一开始的问题，重新理解一下点击一个 Link 跳转的过程。

有两件事需要完成：

1. 路由的改变
2. 页面的渲染部分的改变

过程如下：

1. 在最一开始 mount Router 的时候，Router 在 componentWillMount 中 listen 了一个回调函数，由 history 库管理，路由每次改变的时候触发这个回调函数。这个回调函数会触发 setState。
2. 当点击 Link 标签的时候，实际上点击的是页面上渲染出来的 a 标签，然后通过 preventDefault 阻止 a 标签的页面跳转。
3. Link 中也能拿到 Router -> Route 中通过 context 传递的 history，执行 hitsory.push(to)，这个函数实际上就是包装了一下 window.history.pushState()，是 HTML5 history 的 API，但是 pushState 之后除了地址栏有变化其他没有任何影响，到这一步已经完成了目标1：路由的改变。
4. 第1步中，路由改变是会触发 Router 的 setState 的，在 Router 那章有写道：每次路由变化 -> 触发顶层 Router 的监听事件 -> Router 触发 setState -> 向下传递新的 nextContext（nextContext 中含有最新的 location）
5. 下层的 Route 拿到新的 nextContext 通过 matchPath 函数来判断 path 是否与 location 匹配，如果匹配则渲染，不匹配则不渲染，完成目标2：页面的渲染部分的改变。

总结

看到这里相信你已经能够理解前端路由的实现及 react-router 的实现，但是 react-router 有很多的不足，这也是为什么 reach-router 的出现的原因。

在下篇文章，我会介绍如何做一个可以缓存的 Route —— 比如在列表页跳转到详情页再后退的时候，恢复列表页的模样，包括状态及滚动位置等。

先放上仓库的地址： react-live-route，喜欢可以 star，欢迎提出 issue。

path vs. publicPath vs. contentBase

output.path

一个绝对路径，代表打包在本地磁盘上的物理位置。

比如：

  output: {
    filename: '[name].js',
    path: path.resolve(__dirname, '../dist'),
    publicPath: '/dev/'
  },

这个配置项在生产模式下是必须的（因为你要打包至少要指定打包到哪吧..），但是在开发模式下不是必须的，因为 webpackDevServer 打包出来的文件都在内存中而没有打包到磁盘中。

output.publicPath

打包出来的资源的 URL 前缀（虽然名为打包，但是这个配置项在生产模式和开发模式中都很重要，因为开发模式就是打包在内存中），即在浏览器中访问的路径的前缀。可以填写相对路径或者绝对路径：

• 相对路径会被解析为相对 HTML 的路径
• 也可以填写绝对路径，比如将资源托管在 CDN 上时

这个配置项会加到每个 runtime 或 loader （和 webpack 相关的路径）产生的 URL 中，所以这个配置项在大多数情况下都是以 / 结尾

The webpack-dev-server also takes a hint from publicPath, using it to determine where to serve the output files from.

devServer.contentBase

决定了 webpackDevServer 启动时服务器资源的根目录，默认是项目的根目录。

在有静态文件需要 serve 的时候必填，contentBase 不会影响 path 和 publicPath，它唯一的作用就是指定服务器的根目录来引用静态文件。

可以这么理解 contentBase 与 publicPath 的关系：contentBase 是服务于引用静态文件的路径，而 publicPath 是服务于打包出来的文件访问的路径，两者是不互相影响的。

devServer.publicPath

在开启 webpackDevServer 时浏览器中可通过这个路径访问 bundled 文件，静态文件会加上这个路径前缀，若是devServer里面的publicPath没有设置，则会认为是output里面设置的publicPath的值。

和 output.publicPath 非常相似，都是为浏览器制定访问路径的前缀。但是不同的是 devServer.publicPath 只影响于 webpackDevServer（一般来说就是 html），但各种 loader 打出来的路径还是根据 output.publicPath。

htmlWebpackPlugin

htmlWebpackPlugin 可以用来在 html 中插入打包好的 js，那么这个插入的 js 的路径是什么样的呢？

文档中有写这么一句：

If you've set a publicPath in your webpack config this will be reflected correctly in this assets hash.

答案是路径会根据 output.publicPath 来确定，这也就是为什么

It is recommended that devServer.publicPath is the same as output.publicPath.

因为如果不一样的话，因为打包出来的 js 资源在 html 中会去 output.publicPath 找，但是这个 js 实际上会被 serve 到 devServer.publicPath 的位置，所以这两个在开发环境下强烈推荐一致。

参考

• Webpack中publicPath详解

• Webpack — The Confusing Parts

• Webpack — Understanding the ‘publicPath’ mystery

• DevServer

• Output

• What does “publicPath” in Webpack do?

• 【webpack】webpack-dev-server生猛上手——让我们来搭一个webpack的微服务器吧！

• webpack中的path、publicPath和contentBase

• 理解 Webpack3 路径配置项

WIP 🚧
TEMPORARILY CLOSED

1. React 订阅了 Context.Provieder 的 Consumer 会忽略 shouldComponentUpdate 这个生命周期直接强制更新（类似 forceUpdate），官方文档：

All consumers that are descendants of a Provider will re-render whenever the Provider’s value prop changes. The propagation from Provider to its descendant consumers is not subject to the shouldComponentUpdate method, so the consumer is updated even when an ancestor component bails out of the update.

所以如果需要通过 shouldComponentUpdate 进行性能优化的话，需要再在需要性能优化的组件外套一层 HOC，HOC 可以跟随 context.Provider 的更新并传递 props 给组件。

2. react-router 的 Route 组件的 component 这个 props 使用的是 React.createElement 来创建 react element，所以如果传递的是内联函数，如下

const SomeCom = () => <br />
<Route path="/some-path" component={()=> <SomeCom />} />

在调用 React.createElement 时机会变成（如下为 babel 转义的 JSX）

_react.default.createElement(function () {
  return SomeCom;
});

可以看到 createElement 的第一个参数 type 是一个「临时生成」的函数，所以会导致在每次 render 的时候这个 type 都会对应不同的函数，所以 Route 在每次 render 时就会 unmount 再 mount 一次组件，导致性能问题。
解决办法是使用 Route 的 render 这个 props，render 会直接调用传递的函数作为 element。

3. react-router 的 path 其实支持很多正则的表达式，底层使用的是 path-to-regexp 这个库，比如：

• /:foo/:bar? 来匹配可选字符
• /:foo* 来匹配零个存在字符
• /:foo+ 来匹配一个或多个字符
• /:foo(\\d+) 来匹配纯数字字符

4. React + TS 的类型推导似乎在某些边缘 case 下有问题，比如加入了自定义守卫类型之后，无法检测出 return undefined 会导致返回的类型不匹配
   

5. componetWillUnmount 是异步的，比如给组件换个 key 强行 re-mount 这种操作，可能老组件的 componentWillUnmount 是发生在新组件的 constructor 之前的，容易产生竞态的问题。
   facebook/react#11106

前言

本文适合有一定 Promise 使用基础的读者，如果你还没有使用过 Promise，建议先通过以下教程了解 Promise 的使用方法

1. JavaScript Promise迷你书（中文版）
2. Promise 对象 - ECMAScript 6 入门

本篇文章中我们要分析的 Promise 实现库的源码是 es6-promise，一个通过了 Promises/A+ Tests 的 polyfill，源码通过 ES6 书写比较简洁。为方便理解，放上我已经写了注释的仓库地址：es6-promise-annotated，可以配合阅读。

源码分析

思路

在正式进入源码分析之前，我们先明确 Promise 的一些基本准则：

1. Promise 是一个类，那么每次调用 new Promise() 自然都会返回一个 Promise 实例对象，调用 .then() Promise.resolve() Promise.reject() 返回的也都是一个被包装好的 Promise 对象。
2. Promise.prototype.then 和 Promise.prototype.catch 的参数中的回调函数虽然是异步执行的，但是向 promise 对象注册执行成功时和失败时相应的回调函数的行为是同步执行的。
3. Promise 在完成所有的同步注册之后，会在下一个 event loop 启动链式调用注册的回调函数。
4. 因为要注册的是回调事件，所以 then 的参数必须传递一个或两个函数，否则会发生值穿透，即这个 then 会被直接无视掉，就算是给 then 传递一个 Promise 对象也要通过一个函数来返回这个对象。
5. then 中的回调函数在被执行时是同步的，想要通过 then 将多个异步函数串联起来要在每个 then 中传递一个返回 Promise 的函数。

Promise 的工作主要分为两个阶段，一是同步注册，二是异步触发链式调用。

同步注册

一般来说在调用 Promise 时都是多个 Promise 对象串联起来的，then 中函数的调用是异步的， 但是 Promise 对象的创建是同步的，如下例子中：

const p1 = new Promise(function(resolve, reject){
    setTimeout(()=>{
        resolve('a', 'b')
        }, 1000)
})

p1.then((value1, value2)=>{
    console.log(value1, value2)
})

p1 和 p1 被 then 包装出来的 Promise 对象是会在整个 script 脚本的执行过程中同步完成，这个过程就是注册，每个子 promise 都会添加到父 promise 的属性上来完成注册，以便在接下来的链式调用中按照顺序执行。

链式调用

Promise 可以链式调用关键的一点就是确定好每个节点的调用接口（有点像递归的递归入口），这样每个 Promise 对象就可以通过相同的接口串联起来调用，Promise 对象的模型如下图：

每个父 promise 传递给子 promise 们它的 settled 状态来指示该触发子 promise 成功或失败的回调函数，并传递给子 promise 它的 settled 值。

构造函数

每个 Promise 对象都有三个状态：pending fulfilled rejected，所以需要有一个内部属性来标识状态。向 Promise 对象注册的回调函数也会被同步存在一个内部属性中，在执行子 promise 的时候取出进行异步调用。