Promise 关于 API 这块大家应该都能熟练使用，但是和微任务相关的你可能还存在知识盲区。

前置知识

在开始正文前，我们先把本文涉及到的一些内容提前定个基调。

Promise 哪些 API 涉及了微任务？

Promise 中只有涉及到状态变更后才需要被执行的回调才算是微任务，比如说 then、 catch 、finally ，其他所有的代码执行都是宏任务（同步执行）。

上图中蓝色为同步执行，黄色为异步执行（丢到微任务队列中）。

这些微任务何时被加入微任务队列？

这个问题我们根据 ecma 规范来看：

• 如果此时 Promise 状态为 pending，那么成功或失败的回调会分别被加入至 [[PromiseFulfillReactions]] 和 [[PromiseRejectReactions]] 中。如果你看过手写 Promise 的代码的话，应该能发现有两个数组存储这些回调函数。

• 如果此时 Promise 状态为非 pending 时，回调会成为 Promise Jobs，也就是微任务。

了解完以上知识后，正片开始。

同一个 then，不同的微任务执行

初级

Promise.resolve()
  .then(() => {
    console.log("then1");
    Promise.resolve().then(() => {
      console.log("then1-1");
    });
  })
  .then(() => {
    console.log("then2");
  });

以上代码大家应该都能得出正确的答案：then1 → then1-1 → then2。

虽然 then 是同步执行，并且状态也已经变更。但这并不代表每次遇到 then 时我们都需要把它的回调丢入微任务队列中，而是等待 then 的回调执行完毕后再根据情况执行对应操作。

基于此，我们可以得出第一个结论：链式调用中，只有前一个 then 的回调执行完毕后，跟着的 then 中的回调才会被加入至微任务队列。

中级

大家都知道了 Promise resolve 后，跟着的 then 中的回调会马上进入微任务队列。

那么以下代码你认为的输出会是什么？

let p = Promise.resolve();

p.then(() => {
  console.log("then1");
  Promise.resolve().then(() => {
    console.log("then1-1");
  });
}).then(() => {
  console.log("then1-2");
});

p.then(() => {
  console.log("then2");
}); 

按照一开始的认知我们不难得出 then2 会在 then1-1 后输出，但是实际情况却是相反的。

基于此我们得出第二个结论：每个链式调用的开端会首先依次进入微任务队列。

接下来我们换个写法：

let p = Promise.resolve().then(() => {
  console.log("then1");
  Promise.resolve().then(() => {
    console.log("then1-1");
  });
}).then(() => {
  console.log("then2");
});

p.then(() => {
  console.log("then3");
});

上述代码其实有个陷阱，then 每次都会返回一个新的 Promise，此时的 p 已经不是 Promise.resolve() 生成的，而是最后一个 then 生成的，因此 then3 应该是在 then2 后打印出来的。

顺便我们也可以把之前得出的结论优化为：同一个 Promise 的每个链式调用的开端会首先依次进入微任务队列。

高级

以下大家可以猜猜 then1-2 会在何时打印出来？

Promise.resolve()
  .then(() => {
    console.log("then1");
    Promise.resolve()
      .then(() => {
        console.log("then1-1");
        return 1;
      })
      .then(() => {
        console.log("then1-2");
      });
  })
  .then(() => {
    console.log("then2");
  })
  .then(() => {
    console.log("then3");
  })
  .then(() => {
    console.log("then4");
  });

这题肯定是简单的，记住第一个结论就能得出答案，以下是解析：

• 第一次 resolve 后第一个 then 的回调进入微任务队列并执行，打印 then1

• 第二次 resolve 后内部第一个 then 的回调进入微任务队列，此时外部第一个 then 的回调全部执行完毕，需要将外部的第二个 then 回调也插入微任务队列。

• 执行微任务，打印 then1-1 和 then2，然后分别再将之后 then 中的回调插入微任务队列

• 执行微任务，打印 then1-2 和 then3 ，之后的内容就不一一说明了

接下来我们把 return 1 修改一下，结果可就大不相同啦：

Promise.resolve()
  .then(() => {
    console.log("then1");
    Promise.resolve()
      .then(() => {
        console.log("then1-1");
        return Promise.resolve();
      })
      .then(() => {
        console.log("then1-2");
      });
  })
  .then(() => {
    console.log("then2");
  })
  .then(() => {
    console.log("then3");
  })
  .then(() => {
    console.log("then4");
  });

当我们 return Promise.resolve() 时，你猜猜 then1-2 会何时打印了？

答案是最后一个才被打印出来。

为什么在 then 中分别 return 不同的东西，微任务的执行顺序竟有如此大的变化？以下是笔者的解析。

PS：then** 返回一个新的 Promise，并且会用这个 Promise 去 resolve 返回值，这个概念需要大家先了解一下。**

根据 Promise A+ 规范

根据规范 2.3.2，如果 resolve 了一个 Promise，需要为其加上一个 then 并 resolve。

if (x instanceof MyPromise) {
  if (x.currentState === PENDING) {
  } else {
    x.then(resolve, reject);
  }
  return;
}

上述代码节选自手写 Promise 实现。

那么根据 A+ 规范来说，如果我们在 then 中返回了 Promise.resolve 的话会多入队一次微任务，但是这个结论还是与实际不符的，因此我们还需要寻找其他权威的文档。

根据 ECMA - 262 规范

根据规范 25.6.1.3.2，当 Promise resolve 了一个 Promise 时，会产生一个NewPromiseResolveThenableJob，这是属于 Promise Jobs 中的一种，也就是微任务。

This Job uses the supplied thenable and its then method to resolve the given promise. This process must take place as a Job to ensure that the evaluation of the then method occurs after evaluation of any surrounding code has completed.

并且该 Jobs 还会调用一次 then 函数来 resolve Promise，这也就又生成了一次微任务。

这就是为什么会触发两次微任务的来源。

最后

文章到这里就完结了，大家有什么疑问都可以在评论区提出。

推荐关注我的微信公众号【前端真好玩】，工作日推送高质量文章。

笔者就职于酷家乐，家装设计行业独角兽。一流的可视化、前端技术团队，有兴趣的可以简历投递至 [email protected]

本文使用 mdnice 排版

这是重学 JS 系列的第二篇文章，写这个系列的初衷也是为了夯实自己的 JS 基础。既然是重学，肯定不会从零开始介绍一个知识点，如有遇到不会的内容请自行查找资料。

原型

继承得靠原型来实现，当然原型不是这篇文章的重点，我们来复习一下即可。

其实原型的概念很简单：

• 所有对象都有一个属性 __proto__ 指向一个对象，也就是原型
• 每个对象的原型都可以通过 constructor 找到构造函数，构造函数也可以通过 prototype 找到原型
• 所有函数都可以通过 __proto__ 找到 Function 对象
• 所有对象都可以通过 __proto__ 找到 Object 对象
• 对象之间通过 __proto__ 连接起来，这样称之为原型链。当前对象上不存在的属性可以通过原型链一层层往上查找，直到顶层 Object 对象

其实原型中最重要的内容就是这些了，完全没有必要去看那些长篇大论什么是原型的文章，初学者会越看越迷糊。

当然如果你想了解更多原型的深入内容，可以阅读我 之前写的文章。

ES5 实现继承

ES5 实现继承总的来说就两种办法，之前写过这方面的内容，就直接复制来用了。

总的来说这部分的内容我觉得在当下更多的是为了应付面试吧。

组合继承

组合继承是最常用的继承方式，

function Parent(value) {
	this.val = value
}
Parent.prototype.getValue = function() {
	console.log(this.val)
}
function Child(value) {
	Parent.call(this, value)
}
Child.prototype = new Parent()

const child = new Child(1)

child.getValue() // 1
child instanceof Parent // true

以上继承的方式核心是在子类的构造函数中通过 Parent.call(this) 继承父类的属性，然后改变子类的原型为 new Parent() 来继承父类的函数。

这种继承方式优点在于构造函数可以传参，不会与父类引用属性共享，可以复用父类的函数，但是也存在一个缺点就是在继承父类函数的时候调用了父类构造函数，导致子类的原型上多了不需要的父类属性，存在内存上的浪费。

寄生组合继承

这种继承方式对组合继承进行了优化，组合继承缺点在于继承父类函数时调用了构造函数，我们只需要优化掉这点就行了。

function Parent(value) {
	this.val = value
}
Parent.prototype.getValue = function() {
	console.log(this.val)
}

function Child(value) {
	Parent.call(this, value)
}
Child.prototype = Object.create(Parent.prototype, {
	constructor: {
		value: Child,
		enumerable: false,
		writable: true,
		configurable: true
	}
})

const child = new Child(1)

child.getValue() // 1
child instanceof Parent // true

以上继承实现的核心就是将父类的原型赋值给了子类，并且将构造函数设置为子类，这样既解决了无用的父类属性问题，还能正确的找到子类的构造函数。

Babel 如何编译 ES6 Class 的

为什么在前文说 ES5 实现继承更多的是应付面试呢，因为我们现在可以直接使用 class 来实现继承。

但是 class 毕竟是 ES6 的东西，为了能更好地兼容浏览器，我们通常都会通过 Babel 去编译 ES6 的代码。接下来我们就来了解下通过 Babel 编译后的代码是怎么样的。

function _possibleConstructorReturn (self, call) { 
		// ...
		return call && (typeof call === 'object' || typeof call === 'function') ? call : self; 
}

function _inherits (subClass, superClass) { 
		// ...
		subClass.prototype = Object.create(superClass && superClass.prototype, { 
				constructor: { 
						value: subClass, 
						enumerable: false, 
						writable: true, 
						configurable: true 
				} 
		}); 
		if (superClass) Object.setPrototypeOf ? Object.setPrototypeOf(subClass, superClass) : subClass.__proto__ = superClass; 
}


var Parent = function Parent () {
		// 验证是否是 Parent 构造出来的 this
		_classCallCheck(this, Parent);
};

var Child = (function (_Parent) {
		_inherits(Child, _Parent);

		function Child () {
				_classCallCheck(this, Child);
		
				return _possibleConstructorReturn(this, (Child.__proto__ || Object.getPrototypeOf(Child)).apply(this, arguments));
		}

		return Child;
}(Parent));

以上代码就是编译出来的部分代码，隐去了一些非核心代码，我们先来阅读 _inherits 函数。

设置子类原型部分的代码其实和寄生组合继承是一模一样的，侧面也说明了这种实现方式是最好的。但是这部分的代码多了一句 Object.setPrototypeOf(subClass, superClass)，其实这句代码的作用是为了继承到父类的静态方法，之前我们实现的两种继承方法都是没有这个功能的。

然后 Child 构造函数这块的代码也基本和之前的实现方式类似。所以总的来说 Babel 实现继承的方式还是寄生组合继承，无非多实现了一步继承父类的静态方法。

继承存在的问题

讲了这么些如何实现继承，现在我们来考虑下继承是否是一个好的选择？

总的来说，我个人不怎么喜欢继承，原因呢就一个个来说。

我们先看代码。假如说我们现在要描述几辆不同品牌的车，车必然是一个父类，然后各个品牌的车都分别是一个子类。

class Car {
		constructor (brand) {
				this.brand = brand
		}
		wheel () {
				return '4 个轮子'
		}
		drvie () {
				return '车可以开驾驶'
		}
		addOil () {
				return '车可以加油'
		}
}
Class OtherCar extends Car {}

这部分代码在当下看着没啥毛病，实现了车的几个基本功能，我们也可以通过子类去扩展出各种车。

但是现在出现了新能源车，新能源车是不需要加油的。当然除了加油这个功能不需要，其他几个车的基本功能还是需要的。

如果新能源车直接继承车这个父类的话，就出现了第一个问题 ，大猩猩与香蕉问题。这个问题的意思是我们现在只需要一根香蕉，但是却得到了握着香蕉的大猩猩，大猩猩其实我们是不需要的，但是父类还是强塞给了子类。继承虽然可以重写父类的方法，但是并不能选择需要继承什么东西。

另外单个父类很难描述清楚所有场景，这就导致我们可能又需要新增几个不同的父类去描述更多的场景。随着不断的扩展，代码势必会存在重复，这也是继承存在的问题之一。

除了以上两个问题，继承还存在强耦合的情况，不管怎么样子类都会和它的父类耦合在一起。

既然出现了强耦合，那么这个架构必定是脆弱的。一旦我们的父类设计的有问题，就会对维护造成很大的影响。因为所有的子类都和父类耦合在一起了，假如更改父类中的任何东西，都可能会导致需要更改所有的子类。

如何解决继承的问题

继承更多的是去描述一个东西是什么，描述的不好就会出现各种各样的问题，那么我们是否有办法去解决这些问题呢？答案是组合。

什么是组合呢？你可以把这个概念想成是，你拥有各种各样的零件，可以通过这些零件去造出各种各样的产品，组合更多的是去描述一个东西能干什么。

现在我们把之前那个车的案例通过组合的方式来实现。

function wheel() {
	return "4 个轮子";
}
function drvie() {
	return "车可以开驾驶";
}
function addOil() {
	return "车可以加油";
}
// 油车
const car = compose(wheel, drvie, addOil)
// 新能源车
const energyCar = compose(wheel, drive)

从上述伪代码中想必你也发现了组合比继承好的地方。无论你想描述任何东西，都可以通过几个函数组合起来的方式去实现。代码很干净，也很利于复用。

最后

其实这篇文章的主旨还是后面两小节的内容，如果你还有什么疑问欢迎在评论区与我互动。

我所有的系列文章都会在我的 Github 中最先更新，有兴趣的可以关注下。今年主要会着重写以下三个专栏

• 重学 JS
• React 进阶
• 重写组件

最后，觉得内容有帮助可以关注下我的公众号 「前端真好玩」咯，会有很多好东西等着你。

为什么 0.1 + 0.2 != 0.3，请详述理由

因为 JS 采用 IEEE 754 双精度版本（64位），并且只要采用 IEEE 754 的语言都有该问题。

我们都知道计算机表示十进制是采用二进制表示的，所以 0.1 在二进制表示为

// (0011) 表示循环
0.1 = 2^-4 * 1.10011(0011)

那么如何得到这个二进制的呢，我们可以来演算下

小数算二进制和整数不同。乘法计算时，只计算小数位，整数位用作每一位的二进制，并且得到的第一位为最高位。所以我们得出 0.1 = 2^-4 * 1.10011(0011)，那么 0.2 的演算也基本如上所示，只需要去掉第一步乘法，所以得出 0.2 = 2^-3 * 1.10011(0011)。

回来继续说 IEEE 754 双精度。六十四位中符号位占一位，整数位占十一位，其余五十二位都为小数位。因为 0.1 和 0.2 都是无限循环的二进制了，所以在小数位末尾处需要判断是否进位（就和十进制的四舍五入一样）。

所以 2^-4 * 1.10011...001 进位后就变成了 2^-4 * 1.10011(0011 * 12次)010 。那么把这两个二进制加起来会得出 2^-2 * 1.0011(0011 * 11次)0100 , 这个值算成十进制就是 0.30000000000000004

下面说一下原生解决办法，如下代码所示

parseFloat((0.1 + 0.2).toFixed(10))

10 个 Ajax 同时发起请求，全部返回展示结果，并且至多允许三次失败，说出设计思路

这个问题相信很多人会第一时间想到 Promise.all ，但是这个函数有一个局限在于如果失败一次就返回了，直接这样实现会有点问题，需要变通下。以下是两种实现思路

// 以下是不完整代码，着重于思路 非 Promise 写法
let successCount = 0
let errorCount = 0
let datas = []
ajax(url, (res) => {
		 if (success) {
				 success++
				 if (success + errorCount === 10) {
						 console.log(datas)
				 } else {
						 datas.push(res.data)
				 }
		 } else {
				 errorCount++
				 if (errorCount > 3) {
						// 失败次数大于3次就应该报错了
						 throw Error('失败三次')
				 }
		 }
})
// Promise 写法
let errorCount = 0
let p = new Promise((resolve, reject) => {
		if (success) {
				 resolve(res.data)
		 } else {
				 errorCount++
				 if (errorCount > 3) {
						// 失败次数大于3次就应该报错了
						reject(error)
				 } else {
						 resolve(error)
				 }
		 }
})
Promise.all([p]).then(v => {
	console.log(v);
});

基于 Localstorage 设计一个 1M 的缓存系统，需要实现缓存淘汰机制

设计思路如下：

• 存储的每个对象需要添加两个属性：分别是过期时间和存储时间。
• 利用一个属性保存系统中目前所占空间大小，每次存储都增加该属性。当该属性值大于 1M 时，需要按照时间排序系统中的数据，删除一定量的数据保证能够存储下目前需要存储的数据。
• 每次取数据时，需要判断该缓存数据是否过期，如果过期就删除。

以下是代码实现，实现了思路，但是可能会存在 Bug，但是这种设计题一般是给出设计思路和部分代码，不会需要写出一个无问题的代码

class Store {
	constructor() {
		let store = localStorage.getItem('cache')
		if (!store) {
			store = {
				maxSize: 1024 * 1024,
				size: 0
			}
			this.store = store
		} else {
			this.store = JSON.parse(store)
		}
	}
	set(key, value, expire) {
		this.store[key] = {
			date: Date.now(),
			expire,
			value
		}
		let size = this.sizeOf(JSON.stringify(this.store[key]))
		if (this.store.maxSize < size + this.store.size) {
			console.log('超了-----------');
			var keys = Object.keys(this.store);
			// 时间排序
			keys = keys.sort((a, b) => {
				let item1 = this.store[a], item2 = this.store[b];
				return item2.date - item1.date;
			});
			while (size + this.store.size > this.store.maxSize) {
				let index = keys[keys.length - 1]
				this.store.size -= this.sizeOf(JSON.stringify(this.store[index]))
				delete this.store[index]
			}
		}
		this.store.size += size

		localStorage.setItem('cache', JSON.stringify(this.store))
	}
	get(key) {
		let d = this.store[key]
		if (!d) {
			console.log('找不到该属性');
			return
		}
		if (d.expire > Date.now) {
			console.log('过期删除');
			delete this.store[key]
			localStorage.setItem('cache', JSON.stringify(this.store))
		} else {
			return d.value
		}
	}
	sizeOf(str, charset) {
		var total = 0,
			charCode,
			i,
			len;
		charset = charset ? charset.toLowerCase() : '';
		if (charset === 'utf-16' || charset === 'utf16') {
			for (i = 0, len = str.length; i < len; i++) {
				charCode = str.charCodeAt(i);
				if (charCode <= 0xffff) {
					total += 2;
				} else {
					total += 4;
				}
			}
		} else {
			for (i = 0, len = str.length; i < len; i++) {
				charCode = str.charCodeAt(i);
				if (charCode <= 0x007f) {
					total += 1;
				} else if (charCode <= 0x07ff) {
					total += 2;
				} else if (charCode <= 0xffff) {
					total += 3;
				} else {
					total += 4;
				}
			}
		}
		return total;
	}
}

详细说明 Event loop

众所周知 JS 是门非阻塞单线程语言，因为在最初 JS 就是为了和浏览器交互而诞生的。如果 JS 是门多线程的语言话，我们在多个线程中处理 DOM 就可能会发生问题（一个线程中新加节点，另一个线程中删除节点），当然可以引入读写锁解决这个问题。

JS 在执行的过程中会产生执行环境，这些执行环境会被顺序的加入到执行栈中。如果遇到异步的代码，会被挂起并加入到 Task（有多种 task） 队列中。一旦执行栈为空，Event Loop 就会从 Task 队列中拿出需要执行的代码并放入执行栈中执行，所以本质上来说 JS 中的异步还是同步行为。

console.log('script start');

setTimeout(function() {
	console.log('setTimeout');
}, 0);

console.log('script end');

以上代码虽然 setTimeout 延时为 0，其实还是异步。这是因为 HTML5 标准规定这个函数第二个参数不得小于 4 毫秒，不足会自动增加。所以 setTimeout 还是会在 script end 之后打印。

不同的任务源会被分配到不同的 Task 队列中，任务源可以分为 微任务（microtask） 和 宏任务（macrotask）。在 ES6 规范中，microtask 称为 jobs，macrotask 称为 task。

console.log('script start');

setTimeout(function() {
	console.log('setTimeout');
}, 0);

new Promise((resolve) => {
		console.log('Promise')
		resolve()
}).then(function() {
	console.log('promise1');
}).then(function() {
	console.log('promise2');
});

console.log('script end');
// script start => Promise => script end => promise1 => promise2 => setTimeout

以上代码虽然 setTimeout 写在 Promise 之前，但是因为 Promise 属于微任务而 setTimeout 属于宏任务，所以会有以上的打印。

微任务包括 process.nextTick ，promise ，Object.observe ，MutationObserver

宏任务包括 script ， setTimeout ，setInterval ，setImmediate ，I/O ，UI rendering

很多人有个误区，认为微任务快于宏任务，其实是错误的。因为宏任务中包括了 script ，浏览器会先执行一个宏任务，接下来有异步代码的话就先执行微任务。

所以正确的一次 Event loop 顺序是这样的

1. 执行同步代码，这属于宏任务
2. 执行栈为空，查询是否有微任务需要执行
3. 执行所有微任务
4. 必要的话渲染 UI
5. 然后开始下一轮 Event loop，执行宏任务中的异步代码

通过上述的 Event loop 顺序可知，如果宏任务中的异步代码有大量的计算并且需要操作 DOM 的话，为了更快的 界面响应，我们可以把操作 DOM 放入微任务中。

Node 中的 Event loop

Node 中的 Event loop 和浏览器中的不相同。

Node 的 Event loop 分为6个阶段，它们会按照顺序反复运行

┌───────────────────────┐
┌─>│        timers         │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     I/O callbacks     │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
│  │     idle, prepare     │
│  └──────────┬────────────┘      ┌───────────────┐
│  ┌──────────┴────────────┐      │   incoming:   │
│  │         poll          │<──connections───     │
│  └──────────┬────────────┘      │   data, etc.  │
│  ┌──────────┴────────────┐      └───────────────┘
│  │        check          │
│  └──────────┬────────────┘
│  ┌──────────┴────────────┐
└──┤    close callbacks    │
	 └───────────────────────┘

timer

timers 阶段会执行 setTimeout 和 setInterval

一个 timer 指定的时间并不是准确时间，而是在达到这个时间后尽快执行回调，可能会因为系统正在执行别的事务而延迟。

下限的时间有一个范围：[1, 2147483647] ，如果设定的时间不在这个范围，将被设置为1。

I/O

I/O 阶段会执行除了 close 事件，定时器和 setImmediate 的回调

idle, prepare

idle, prepare 阶段内部实现

poll

poll 阶段很重要，这一阶段中，系统会做两件事情

1. 执行到点的定时器
2. 执行 poll 队列中的事件

并且当 poll 中没有定时器的情况下，会发现以下两件事情

• 如果 poll 队列不为空，会遍历回调队列并同步执行，直到队列为空或者系统限制
• 如果 poll 队列为空，会有两件事发生
  • 如果有 setImmediate 需要执行，poll 阶段会停止并且进入到 check 阶段执行 setImmediate
  • 如果没有 setImmediate 需要执行，会等待回调被加入到队列中并立即执行回调

如果有别的定时器需要被执行，会回到 timer 阶段执行回调。

check

check 阶段执行 setImmediate

close callbacks

close callbacks 阶段执行 close 事件

并且在 Node 中，有些情况下的定时器执行顺序是随机的

setTimeout(() => {
		console.log('setTimeout');
}, 0);
setImmediate(() => {
		console.log('setImmediate');
})
// 这里可能会输出 setTimeout，setImmediate
// 可能也会相反的输出，这取决于性能
// 因为可能进入 event loop 用了不到 1 毫秒，这时候会执行 setImmediate
// 否则会执行 setTimeout

当然在这种情况下，执行顺序是相同的

var fs = require('fs')

fs.readFile(__filename, () => {
		setTimeout(() => {
				console.log('timeout');
		}, 0);
		setImmediate(() => {
				console.log('immediate');
		});
});
// 因为 readFile 的回调在 poll 中执行
// 发现有 setImmediate ，所以会立即跳到 check 阶段执行回调
// 再去 timer 阶段执行 setTimeout
// 所以以上输出一定是 setImmediate，setTimeout

上面介绍的都是 macrotask 的执行情况，microtask 会在以上每个阶段完成后立即执行。

setTimeout(()=>{
		console.log('timer1')

		Promise.resolve().then(function() {
				console.log('promise1')
		})
}, 0)

setTimeout(()=>{
		console.log('timer2')

		Promise.resolve().then(function() {
				console.log('promise2')
		})
}, 0)

// 以上代码在浏览器和 node 中打印情况是不同的
// 浏览器中打印 timer1, promise1, timer2, promise2
// node 中打印 timer1, timer2, promise1, promise2

Node 中的 process.nextTick 会先于其他 microtask 执行。

setTimeout(() => {
	console.log("timer1");

	Promise.resolve().then(function() {
		console.log("promise1");
	});
}, 0);

process.nextTick(() => {
	console.log("nextTick");
});
// nextTick, timer1, promise1

白驹过隙，光阴似箭。时间，真的过得很快。

我是 17 年下半年开始正式学习前端的，到现在为止一年半也差不多了，借此新年之际，来个小小的总结。

很多人看到我才入门前端一年半会很诧异，我之前去大厂面试的时候，也有面试官评价我说，「写出来的东西不像是这个年限有的」，但是总归是因为自身项目经验不多的原因，去年的跳槽并没有如愿进入想去的公司。但是目前呆的「宋小菜」也很不错，这几个月的经历让我觉得没有做错决定。

在这一年半的时间中，我开源了一大一小的项目。大的项目获得了 14K 的 stars，小的项目也有近 1K 的 stars。上个礼拜也发售了自己的第一本「前端面试之道」小册，也因此结识了很多业内的大佬，同时也获得了多个大佬的推荐，小册目前的评价也很不错，这些算是这段时间的一个成就吧。

很多人对于我的学习经历很感兴趣，趁着这个机会我也分享一下自己的经历。

首先，先说一下个人理解的学习。学习的第一步是知道自己学习的这个知识问题是什么，答案是什么，然后找到这些问题和答案之间的关系，这个关系是我们需要学习的东西，最后能把这个关系通过通俗易懂的语言输出出来，那么这个知识你一定学会了。

很多人认为自己学了很多，看了很多，但是又说不出个所以然。其实这压根不算什么学习，充其量只是记忆了一些知识的描述，并没有学到问题和答案之间的关联是什么。就比如说 111 * 120 答案是多少，你可能并不能马上回答出来。但是你知道他和答案的关联，你就能通过这个关联找到答案。我们就是需要学习这个关联。

在学习的过程中，我并没有阅读很多书，或者说看完的书一只手都可以数过来，同时也没有一大早起床或者很晚睡觉。我也喜欢打游戏，也喜欢刷刷手机，大家喜欢的我应该都喜欢，并没有像很多学霸一样一直在学习。

总归来说，我和大部分人一样，那么你可能会诧异，你到底咋学的？

首先我可以流畅阅读点英文，也有不错的网络条件可以访问想访问的网站，这些条件能够让我接触到更高质量的资料，能够通过搜索引擎更快地解决问题可能是一个方面。

第二方面，我喜欢列点计划。对长远的事情会早早的考虑周全然后定好计划，对于短期的事情会设立一个 deadline 争取去完成。就比如我的开源是很早就有一个大的计划的，然后逐步分解这一个大的开源项目到具体的时间。管理好自己的时间，在可控的时间内完成预期的计划，其他的时间就是我打游戏、刷剧的时间了，毕竟劳逸结合还是很重要的，我始终做不到抛弃这些一直学习。

其他几个方面就是些很零散的东西了。比如说花钱买点知识付费的课程，不要把有限的时间都浪费在找寻资料的过程中；比如说在工作中发现需要学习的内容，解决不知道要学习什么的困惑；比如说时刻有一个危机感，有一个清楚的自我认知，知道自己现在还很弱。

另外，我并不打算列举一堆资料出来，我其实认为这个没什么必要。因为想学的自然找的到资料，不想学的，列举多少资料也只是徒增了一个书签而已。

更多的可能是找到一个适合自己学习的方式，而不是靠一堆资料来增加一个虚假感。毕竟时间就那么多，我们不可能学完那么多的东西，即使 React 核心团队的 Dan 也有很多知识盲区。我们应该先思考什么是自己适合的学习方式，然后再去找寻对应的资料学习。条条大路通罗马，只要找到了适合自己的学习方式，然后持续学习，那么迟早有一天你会成为别人口中的大牛。

有些人就是能 4，5 点起床学习，有些人就是一年能读很多书，但是这种途径强加于自己身上，可能就是不能坚持，那么这个途径就不是适合自己的。既然不适合自己，就不要强迫自己去干这件事情。可能这话有点丧，但是如果真的你能把一件不喜欢的事情持续坚持下去，你一定是极少数的那批人。但是，大部分的我们，真的很平庸，我也很平庸。程序员这个行业虽然工资看着光鲜，但是这绝对不是你牛逼的原因，也不是行业牛逼的原因，而是资本牛逼。

对于我个人而言，列好计划，知道自己需要学习什么，然后努力去完成，这样就对得起这些时间了。

选择，远比努力重要。

最后，19 年的展望是什么？虽然我立了几个 flag，但是并不打算写出来。毕竟做成了 flag 才有用，否则都是屁话，自我安慰罢了。

写到最后，好像也没总结个啥。其实并不怎么想把自己学了哪些资料，做了什么事情都一一列举出来，大概觉得这种形式并没有什么用吧。

毕竟学就行了。途径是怎么样的，谁关心呢？只要有结果就行了。

本文不会过多介绍基础知识，而是把重点放在原型的各个难点上。

大家可以先仔细分析下该图，然后让我们进入主题

prototype

首先来介绍下 prototype 属性。这是一个显式原型属性，只有函数才拥有该属性。基本上所有函数都有这个属性，但是也有一个例外

let fun = Function.prototype.bind()

如果你以上述方法创建一个函数，那么可以发现这个函数是不具有 prototype 属性的。

prototype 如何产生的

当我们声明一个函数时，这个属性就被自动创建了。

function Foo() {}

并且这个属性的值是一个对象（也就是原型），只有一个属性 constructor

constructor 对应着构造函数，也就是 Foo。

constructor

constructor 是一个公有且不可枚举的属性。一旦我们改变了函数的 prototype ，那么新对象就没有这个属性了（当然可以通过原型链取到 constructor）。

那么你肯定也有一个疑问，这个属性到底有什么用呢？其实这个属性可以说是一个历史遗留问题，在大部分情况下是没用的，在我的理解里，我认为他有两个作用：

• 让实例对象知道是什么函数构造了它
• 如果想给某些类库中的构造函数增加一些自定义的方法，就可以通过 xx.constructor.method 来扩展

_proto_

这是每个对象都有的隐式原型属性，指向了创建该对象的构造函数的原型。其实这个属性指向了 [[prototype]]，但是 [[prototype]] 是内部属性，我们并不能访问到，所以使用 _proto_ 来访问。

因为在 JS 中是没有类的概念的，为了实现类似继承的方式，通过 _proto_ 将对象和原型联系起来组成原型链，得以让对象可以访问到不属于自己的属性。

实例对象的 _proto_ 如何产生的

从上图可知，当我们使用 new 操作符时，生成的实例对象拥有了 _proto_属性。

function Foo() {}
// 这个函数是 Function 的实例对象
// function 就是一个语法糖
// 内部调用了 new Function(...)

所以可以说，在 new 的过程中，新对象被添加了 _proto_ 并且链接到构造函数的原型上。

new 的过程

1. 新生成了一个对象
2. 链接到原型
3. 绑定 this
4. 返回新对象

在调用 new 的过程中会发生以上四件事情，我们也可以试着来自己实现一个 new

function create() {
	// 创建一个空的对象
	let obj = new Object()
	// 获得构造函数
	let Con = [].shift.call(arguments)
	// 链接到原型
	obj.__proto__ = Con.prototype
	// 绑定 this，执行构造函数
	let result = Con.apply(obj, arguments)
	// 确保 new 出来的是个对象
	return typeof result === 'object' ? result : obj
}

对于实例对象来说，都是通过 new 产生的，无论是 function Foo() 还是 let a = { b : 1 } 。

对于创建一个对象来说，更推荐使用字面量的方式创建对象。因为你使用 new Object() 的方式创建对象需要通过作用域链一层层找到 Object，但是你使用字面量的方式就没这个问题。

function Foo() {}
// function 就是个语法糖
// 内部等同于 new Function()
let a = { b: 1 }
// 这个字面量内部也是使用了 new Object()

Function.proto === Function.prototype

对于对象来说，xx.__proto__.contrcutor 是该对象的构造函数，但是在图中我们可以发现 Function.__proto__ === Function.prototype，难道这代表着 Function 自己产生了自己?

答案肯定是否认的，要说明这个问题我们先从 Object 说起。

从图中我们可以发现，所有对象都可以通过原型链最终找到 Object.prototype ，虽然 Object.prototype 也是一个对象，但是这个对象却不是 Object 创造的，而是引擎自己创建了 Object.prototype 。所以可以这样说，所有实例都是对象，但是对象不一定都是实例。

接下来我们来看 Function.prototype 这个特殊的对象，如果你在浏览器将这个对象打印出来，会发现这个对象其实是一个函数。

我们知道函数都是通过 new Function() 生成的，难道 Function.prototype 也是通过 new Function() 产生的吗？答案也是否定的，这个函数也是引擎自己创建的。首先引擎创建了 Object.prototype ，然后创建了 Function.prototype ，并且通过 __proto__ 将两者联系了起来。这里也很好的解释了上面的一个问题，为什么 let fun = Function.prototype.bind() 没有 prototype 属性。因为 Function.prototype 是引擎创建出来的对象，引擎认为不需要给这个对象添加 prototype 属性。

所以我们又可以得出一个结论，不是所有函数都是 new Function() 产生的。

有了 Function.prototype 以后才有了 function Function() ，然后其他的构造函数都是 function Function() 生成的。

现在可以来解释 Function.__proto__ === Function.prototype 这个问题了。因为先有的 Function.prototype 以后才有的 function Function() ，所以也就不存在鸡生蛋蛋生鸡的悖论问题了。对于为什么 Function.__proto__ 会等于 Function.prototype ，个人的理解是：其他所有的构造函数都可以通过原型链找到 Function.prototype ，并且 function Function() 本质也是一个函数，为了不产生混乱就将 function Function() 的 __proto__ 联系到了 Function.prototype 上。

总结

• Object 是所有对象的爸爸，所有对象都可以通过 __proto__ 找到它
• Function 是所有函数的爸爸，所有函数都可以通过 __proto__ 找到它
• Function.prototype 和 Object.prototype 是两个特殊的对象，他们由引擎来创建
• 除了以上两个特殊对象，其他对象都是通过构造器 new 出来的
• 函数的 prototype 是一个对象，也就是原型
• 对象的 __proto__ 指向原型， __proto__ 将对象和原型连接起来组成了原型链

Vuex **

在解读源码之前，先来简单了解下 Vuex 的**。

Vuex 全局维护着一个对象，使用到了单例设计模式。在这个全局对象中，所有属性都是响应式的，任意属性进行了改变，都会造成使用到该属性的组件进行更新。并且只能通过 commit 的方式改变状态，实现了单向数据流模式。

Vuex 解析

Vuex 安装

在看接下来的内容前，推荐本地 clone 一份 Vuex 源码对照着看，便于理解。

在使用 Vuex 之前，我们都需要调用 Vue.use(Vuex) 。在调用 use 的过程中，Vue 会调用到 Vuex 的 install 函数

install 函数作用很简单

• 确保 Vuex 只安装一次
• 混入 beforeCreate 钩子函数，可以在组件中使用 this.$store

export function install(_Vue) {
  // 确保 Vuex 只安装一次
  if (Vue && _Vue === Vue) {
    if (process.env.NODE_ENV !== 'production') {
      console.error(
        '[vuex] already installed. Vue.use(Vuex) should be called only once.'
      )
    }
    return
  }
  Vue = _Vue
  applyMixin(Vue)
}

// applyMixin
export default function(Vue) {
  // 获得 Vue 版本号
  const version = Number(Vue.version.split('.')[0])
  // Vue 2.0 以上会混入 beforeCreate 函数
  if (version >= 2) {
    Vue.mixin({ beforeCreate: vuexInit })
  } else {
    // ...
  }
  // 作用很简单，就是能让我们在组件中
  // 使用到 this.$store
  function vuexInit() {
    const options = this.$options
    if (options.store) {
      this.$store =
        typeof options.store === 'function' ? options.store() : options.store
    } else if (options.parent && options.parent.$store) {
      this.$store = options.parent.$store
    }
  }
}

Vuex 初始化

this._modules

本小节内容主要解析如何初始化 this._modules

export class Store {
  constructor (options = {}) {
    // 引入 Vue 的方式，自动安装
    if (!Vue && typeof window !== 'undefined' && window.Vue) {
      install(window.Vue)
    }
    // 在开发环境中断言
    if (process.env.NODE_ENV !== 'production') {
      assert(Vue, `must call Vue.use(Vuex) before creating a store instance.`)
      assert(typeof Promise !== 'undefined', `vuex requires a Promise polyfill in this browser.`)
      assert(this instanceof Store, `store must be called with the new operator.`)
    }
    // 获取 options 中的属性
    const {
      plugins = [],
      strict = false
    } = options

    // store 内部的状态，重点关注 this._modules
    this._committing = false
    this._actions = Object.create(null)
    this._actionSubscribers = []
    this._mutations = Object.create(null)
    this._wrappedGetters = Object.create(null)
    this._modules = new ModuleCollection(options)
    this._modulesNamespaceMap = Object.create(null)
    this._subscribers = []
    this._watcherVM = new Vue()


    const store = this
    const { dispatch, commit } = this
    // bind 以下两个函数上 this 上
    // 便于 this.$store.dispatch
    this.dispatch = function boundDispatch (type, payload) {
      return dispatch.call(store, type, payload)
    }
    this.commit = function boundCommit (type, payload, options) {
      return commit.call(store, type, payload, options)
    }
}

接下来看 this._modules 的过程，以 以下代码为例

const moduleA = {
  state: { ... },
  mutations: { ... },
  actions: { ... },
  getters: { ... }
}

const moduleB = {
  state: { ... },
  mutations: { ... },
  actions: { ... }
}

const store = new Vuex.Store({
  state: { ... },
  modules: {
    a: moduleA,
    b: moduleB
  }
})

对于以上代码，store 可以看成 root 。在第一次执行时，会初始化一个 rootModule，然后判断 root 中是否存在 modules 属性，然后递归注册 module 。对于 child 来说，会获取到他所属的 parent, 然后在 parent 中添加 module 。

export default class ModuleCollection {
  constructor (rawRootModule) {
    // register root module (Vuex.Store options)
    this.register([], rawRootModule, false)
  }
  register (path, rawModule, runtime = true) {
    // 开发环境断言
    if (process.env.NODE_ENV !== 'production') {
      assertRawModule(path, rawModule)
    }
    // 初始化 Module
    const newModule = new Module(rawModule, runtime)
    // 对于第一次初始化 ModuleCollection 时
    // 会走第一个 if 条件，因为当前是 root
    if (path.length === 0) {
      this.root = newModule
    } else {
      // 获取当前 Module 的 parent
      const parent = this.get(path.slice(0, -1))
      // 添加 child，第一个参数是
      // 当前 Module 的 key 值
      parent.addChild(path[path.length - 1], newModule)
    }

    // 递归注册
    if (rawModule.modules) {
      forEachValue(rawModule.modules, (rawChildModule, key) => {
        this.register(path.concat(key), rawChildModule, runtime)
      })
    }
  }
}

export default class Module {
  constructor (rawModule, runtime) {
    this.runtime = runtime
    // 用于存储 children
    this._children = Object.create(null)
    // 用于存储原始的 rawModule
    this._rawModule = rawModule
    const rawState = rawModule.state

    // 用于存储 state
    this.state = (typeof rawState === 'function' ? rawState() : rawState) || {}
  }
}

installModule

接下来看 installModule 的实现

// installModule(this, state, [], this._modules.root)
function installModule(store, rootState, path, module, hot) {
  // 判断是否为 rootModule
  const isRoot = !path.length
  // 获取 namespace，root 没有 namespace
  // 对于 modules: {a: moduleA} 来说
  // namespace = 'a/'
  const namespace = store._modules.getNamespace(path)

  // 为 namespace 缓存 module
  if (module.namespaced) {
    store._modulesNamespaceMap[namespace] = module
  }

  // 设置 state
  if (!isRoot && !hot) {
    // 以下逻辑就是给 store.state 添加属性
    // 根据模块添加
    // state: { xxx: 1, a: {...}, b: {...} }
    const parentState = getNestedState(rootState, path.slice(0, -1))
    const moduleName = path[path.length - 1]
    store._withCommit(() => {
      Vue.set(parentState, moduleName, module.state)
    })
  }
  // 该方法其实是在重写 dispatch 和 commit 函数
  // 你是否有疑问模块中的 dispatch 和 commit
  // 是如何找到对应模块中的函数的
  // 假如模块 A 中有一个名为 add 的 mutation
  // 通过 makeLocalContext 函数，会将 add 变成
  // a/add，这样就可以找到模块 A 中对应函数了
  const local = (module.context = makeLocalContext(store, namespace, path))

  // 以下几个函数遍历，都是在
  // 注册模块中的 mutation、action 和 getter
  // 假如模块 A 中有名为 add 的 mutation 函数
  // 在注册过程中会变成 a/add
  module.forEachMutation((mutation, key) => {
    const namespacedType = namespace + key
    registerMutation(store, namespacedType, mutation, local)
  })

  module.forEachAction((action, key) => {
    const type = action.root ? key : namespace + key
    const handler = action.handler || action
    registerAction(store, type, handler, local)
  })

  // 这里会生成一个 _wrappedGetters 属性
  // 用于缓存 getter，便于下次使用
  module.forEachGetter((getter, key) => {
    const namespacedType = namespace + key
    registerGetter(store, namespacedType, getter, local)
  })

  // 递归安装模块
  module.forEachChild((child, key) => {
    installModule(store, rootState, path.concat(key), child, hot)
  })
}

resetStoreVM

接下来看 resetStoreVM 的实现，该属性实现了状态的响应式，并且将 _wrappedGetters 作为 computed 属性。

// resetStoreVM(this, state)
function resetStoreVM(store, state, hot) {
  const oldVm = store._vm

  // 设置 getters 属性
  store.getters = {}
  const wrappedGetters = store._wrappedGetters
  const computed = {}
  // 遍历 _wrappedGetters 属性
  forEachValue(wrappedGetters, (fn, key) => {
    // 给 computed 对象添加属性
    computed[key] = () => fn(store)
    // 重写 get 方法
    // store.getters.xx 其实是访问了
    // store._vm[xx]
    // 也就是 computed 中的属性
    Object.defineProperty(store.getters, key, {
      get: () => store._vm[key],
      enumerable: true, // for local getters
    })
  })

  // 使用 Vue 来保存 state 树
  // 同时也让 state 变成响应式
  const silent = Vue.config.silent
  Vue.config.silent = true
  // 当访问 store.state 时
  // 其实是访问了 store._vm._data.$$state
  store._vm = new Vue({
    data: {
      $$state: state,
    },
    computed,
  })
  Vue.config.silent = silent

  // 确保只能通过 commit 的方式改变状态
  if (store.strict) {
    enableStrictMode(store)
  }
}

常用 API

commit 解析

如果需要改变状态的话，一般都会使用 commit 去操作，接下来让我们来看看 commit 是如何实现状态的改变的

commit(_type, _payload, _options) {
  // 检查传入的参数
  const { type, payload, options } = unifyObjectStyle(
    _type,
    _payload,
    _options
  )

  const mutation = { type, payload }
  // 找到对应的 mutation 函数
  const entry = this._mutations[type]
  // 判断是否找到
  if (!entry) {
    if (process.env.NODE_ENV !== 'production') {
      console.error(`[vuex] unknown mutation type: ${type}`)
    }
    return
  }
  // _withCommit 函数将 _committing
  // 设置为 TRUE，保证在 strict 模式下
  // 只能 commit 改变状态
  this._withCommit(() => {
    entry.forEach(function commitIterator(handler) {
      // entry.push(function wrappedMutationHandler(payload) {
      //   handler.call(store, local.state, payload)
      // })
      // handle 就是 wrappedMutationHandler 函数
      // wrappedMutationHandler 内部就是调用
      // 对于的 mutation 函数
      handler(payload)
    })
  })
  // 执行订阅函数
  this._subscribers.forEach(sub => sub(mutation, this.state))
}

dispatch 解析

如果需要异步改变状态，就需要通过 dispatch 的方式去实现。在 dispatch 调用的 commit 函数都是重写过的，会找到模块内的 mutation 函数。

dispatch(_type, _payload) {
  // 检查传入的参数
  const { type, payload } = unifyObjectStyle(_type, _payload)

  const action = { type, payload }
  // 找到对于的 action 函数
  const entry = this._actions[type]
  // 判断是否找到
  if (!entry) {
    if (process.env.NODE_ENV !== 'production') {
      console.error(`[vuex] unknown action type: ${type}`)
    }
    return
  }
  // 触发订阅函数
  this._actionSubscribers.forEach(sub => sub(action, this.state))

  // 在注册 action 的时候，会将函数返回值
  // 处理成 promise，当 promise 全部
  // resolve 后，就会执行 Promise.all
  // 里的函数
  return entry.length > 1
    ? Promise.all(entry.map(handler => handler(payload)))
    : entry[0](payload)
}

各种语法糖

在组件中，如果想正常使用 Vuex 的功能，经常需要这样调用 this.$store.state.xxx 的方式，引来了很多的不便。为此，Vuex 引入了语法糖的功能，让我们可以通过简单的方式来实现上述的功能。以下以 mapState 为例，其他的几个 map 都是差不多的原理，就不一一解析了。

function normalizeNamespace(fn) {
  return (namespace, map) => {
    // 函数作用很简单
    // 根据参数生成 namespace
    if (typeof namespace !== 'string') {
      map = namespace
      namespace = ''
    } else if (namespace.charAt(namespace.length - 1) !== '/') {
      namespace += '/'
    }
    return fn(namespace, map)
  }
}
// 执行 mapState 就是执行
// normalizeNamespace 返回的函数
export const mapState = normalizeNamespace((namespace, states) => {
  const res = {}
  // normalizeMap([1, 2, 3]) => [ { key: 1, val: 1 }, { key: 2, val: 2 }, { key: 3, val: 3 } ]
  // normalizeMap({a: 1, b: 2, c: 3}) => [ { key: 'a', val: 1 }, { key: 'b', val: 2 }, { key: 'c', val: 3 } ]
  // function normalizeMap(map) {
  //   return Array.isArray(map)
  //     ? map.map(key => ({ key, val: key }))
  //     : Object.keys(map).map(key => ({ key, val: map[key] }))
  // }
  // states 参数可以参入数组或者对象类型
  normalizeMap(states).forEach(({ key, val }) => {
    res[key] = function mappedState() {
      let state = this.$store.state
      let getters = this.$store.getters
      if (namespace) {
        // 获得对应的模块
        const module = getModuleByNamespace(this.$store, 'mapState', namespace)
        if (!module) {
          return
        }
        state = module.context.state
        getters = module.context.getters
      }
      // 返回 State
      return typeof val === 'function'
        ? val.call(this, state, getters)
        : state[val]
    }
    // mark vuex getter for devtools
    res[key].vuex = true
  })
  return res
})

最后

以上是 Vue 的源码解析，虽然 Vuex 的整体代码并不多，但是却是个值得阅读的项目。如果你在阅读的过程中有什么疑问或者发现了我的错误，欢迎在评论中讨论。

根据文章提示扫码关注公众号并回复关键字了，但是文章并没有自动解锁。公公众号提示“提供的服务异常”。希望作者能尽快修复一下，感谢~~

组件 PureRender

class 组件中性能优化可以通过 shouldComponentUpdate 实现或者继承自 PureComponent，当然后者也是通过 shouldComponentUpdate 去做的，内部对 state 和 props 进行了 shallowEqual。

对于函数组件来说并没有这个生命周期可以调用，因此想实现性能优化只能通过 React.memo(<Component />) 来做，这种做法和继承 PureComponent 的原理一致。

另外如果你的函数组件需要拿到它的 ref，可以使用以下工具函数：

function memoForwardRef<N, P>(comp: RefForwardingComponent<N, P>) {
  return memo(forwardRef<N, P>(comp));
}

但是并不是以上做法以后性能就万事大吉了，你还得保证传递的 props 以及内部的状态的引用不发生预期之外的变化。

保持局部不变

对于函数组件来说，变量的引用是需要重点关注的问题，无论是函数亦或者对象。

const Child = React.memo(({ columns }) => {
  return <Table columns={columns} />
})
const Parent = () => {
  const data = [];
  return <Child columns={data} />
}

对于以上组件来说，每次 Parent 渲染的时候虽然 columns 内容没有变，但是 columns 的引用已经变了。当 props 传递给 Child 的时候，即使使用了 React.memo 但是性能优化也失效了。

对于这种情况，可以通过 useMemo 将引用存储起来，依赖不变引用也就不变。

const data = useMemo(() => [], [])

useMemo 的场景多是用于值的计算。比如密集型计算场景下你肯定不希望组件重新渲染的时候，依赖项没有变更缺重复执行计算函数得到相同的值。

对于函数来说，如果你想保存它的引用的话可以使用 useCallback 来做。

function Counter() {
  const [count, setCount] = useState(0)


  // 这样写函数，每次重新渲染都会再次创建一个新的函数
  const onIncrement = () => {
    setCount(count => count + 1)
  }

  const onIncrement = useCallback(() => {
    setCount(count => count + 1)
  }, [])

  return (
    <div>
      <button onClick={onIncrement}>INCREMENT</button>
      <p>{count}</p>
    </div>
  )
}

对于以上代码来说，组件每次渲染的时候使用了 useCallback 包裹的 onIncrement 函数引用不会改变，这也就意味着不需要频繁创建及销毁函数了。

但是在 useCallback 存在依赖的情况下函数引用并不一定按照你的想法正常保持不变，比如如下案例：

function Counter() {
  const [count, setCount] = useState(0)

  const onIncrement = useCallback(() => {
    setCount(count => count + 1)
  }, [])
  
  const onLog = useCallback(() => {
    console.log(count)
  }, [count])

  return (
    <div>
      <button onClick={onIncrement}>INCREMENT</button>
      <button onClick={onLog}>Log</button>
      <p>{count}</p>
    </div>
  )
}

当 count 每次改变造成组件重新渲染的时候，onLog 函数都会重新创建一次。两种常规方法可以保持在这种情况下函数引用不被改变。

1. 使用 useEventCallback
2. 使用 useReducer

function useEventCallback(fn, dependencies) {
  const ref = useRef(() => {
    throw new Error('Cannot call an event handler while rendering.');
  });

  useEffect(() => {
    ref.current = fn;
  }, [fn, ...dependencies]);

  return useCallback(() => {
    const fn = ref.current;
    return fn();
  }, [ref]);
}

useEventCallback 使用了 ref 不变的特性，保证回调函数的引用永远不变。另外在 Hooks 中，dispatch 也是不变的，所以把依赖 ref 改成 dispatch，然后在回调中调用 dispatch 就是另一种做法了。

性能优化并不是银弹

凡事都有两面性，在引入以上这些性能优化的时候你已经降低了原本的性能，毕竟它们都是有使用代价的，我们可以来阅读下 useCallback 及 useMemo 的核心源码：

function updateCallback(callback, deps) {
  const hook = updateWorkInProgressHook();
  const nextDeps = deps === undefined ? null : deps;
  const prevState = hook.memoizedState;
  if (prevState !== null) {
    if (nextDeps !== null) {
      const prevDeps = prevState[1];
      if (areHookInputsEqual(nextDeps, prevDeps)) {
        return prevState[0];
      }
    }
  }
  hook.memoizedState = [callback, nextDeps];
  return callback;
}

function updateMemo(nextCreate, deps) {
  const hook = updateWorkInProgressHook();
  const nextDeps = deps === undefined ? null : deps;
  const prevState = hook.memoizedState;
  if (prevState !== null) {
    if (nextDeps !== null) {
      const prevDeps = prevState[1];
      if (areHookInputsEqual(nextDeps, prevDeps)) {
        return prevState[0];
      }
    }
  }
  const nextValue = nextCreate();
  hook.memoizedState = [nextValue, nextDeps];
  return nextValue;
}

上述源码实现思路大致是从 fiber 中取出 memoizedState，然后对比前后 Deps，对比的实现也采用了 shallowEqual，最后如果有变化的话就重置 memoizedState。

可以看出来，本文中讲到的性能优化方案基本都是采用了 shallowEqual 来对比前后差异，所以没必要为了性能优化而优化。

Hooks 的坑

Hooks 的坑 99% 都是闭包引起的，我们通过一个例子来了解下什么情况下会因为闭包导致问题。

function App() {
  const [state, setState] = React.useState(0)
  // 连点三次你觉得答案会是什么？
  const handleClick = () => {
    setState(state + 1)
    setTimeout(() => {
      console.log(state)
    }, 2000)
  }

  return (
    <>
      <div>{state}</div>
      <button onClick={handleClick} />
    </>
  )
}

上述代码触发三次 handleClick 后你觉得答案会是什么？可能答案与你所想的不大一样，结果是：

0
1
2

因为每次 render 都有一份新的状态，因此上述代码中的 setTimeout 使用产生了一个闭包，捕获了每次 render 后的 state，也就导致了输出了 0、1、2。

如果你希望输出的内容是最新的 state 的话，可以通过 useRef 来保存 state。前文讲过 ref 在组件中只存在一份，无论何时使用它的引用都不会产生变化，因此可以来解决闭包引发的问题。

function App() {
  const [state, setState] = React.useState(0)
  // 用 ref 存一下
  const currentState = React.useRef(state)
  // 每次渲染后更新下值
  useEffect(() => {
    currentState.current = state
  })

  const handleClick = () => {
    setState(state + 1)
    // 这样定时器里通过 ref 拿到最新值
    setTimeout(() => {
      console.log(currentState.current)
    }, 2000)
  }

  return (
    <>
      <div>{state}</div>
      <button onClick={handleClick} />
    </>
  )
}

其实闭包引发的问题多半是保存了 old 的值，只要想办法拿到最新的值其实基本上就解决问题了。

写在最后

如果你觉得我有遗漏什么或者写的不对的，欢迎指出。

我很想听听你的想法，谢谢阅读。

微信扫码关注公众号，订阅更多精彩内容	加笔者微信群聊技术

程序员这行如果想一直做下去，那么持续学习是必不可少的。

大家找工作通常会喜欢技术氛围好点的团队，因为这样能够帮助自己更好的成长，但是并不是每个团队都拥有这样的氛围。于是萌发一个念头，想建立一个地方，让一些人能在这块地方记录自己学习到的内容。这些内容通常会是一个小点，可能并不足以写成一篇文章。但是这个知识点可能很多人也不知道，那么通过这种记录的方式让别人同样也学习到这个知识点就是一个很棒的事情了。

如果你也想参与这个记录的事情，欢迎贡献你的一份力量，地址在这里。

本周总共有 37 人贡献了他们所学到的知识，选取了一部分不错的分享并整合成文，更详细的内容推荐前往仓库阅读。

TS 中使用 typeof 关键字可以自动获取数据类型

在写 React 项目时，有些时候，你的 state 可能会有默认值，比如：

const initialState = {
   username: '',
   mobile: '',
   isVip: false,
   addresses: [],
}

type IState = typeof initialState

class Comp extends Component<any, IState> {
   constructor(props) {
        super(props);
        this.state = {
            ...initialState
        };
    }
}

这样就不用分开定义 state 的初始值和 state 的类型了。

交换数组指定位置元素位置

从掘金过来的，感觉这个项目挺有意思的，大家互相学习吧！
分享一下最近get到的一个小技巧。交换数组指定位置元素位置：

例如： [1 ,2, 3, 4] ===> [1, 2, 4, 3]

// x , y是要交换元素的位置(index+1)
function arrIndexExchange(array, x, y){
    array.splice(x - 1, 1, ...array.splice(y - 1, 1, array[x - 1]));
    return array;
};

位运算

请注意 位运算适用于 32 位整数，所以精度可能会丢失

• 用 "|" 取整

let num=1.5
num=num|0; // 1

• 用 ">>" 取半

let num=4;
num=num>>1; // 2

• 用 ">>" 加倍

let num=2;
num=num<<1; / / 4

• 用 "^" 两值交换

let a=1;
let b=2;

a^=b;
b^=a;
a^=b;
// a===2,b===1

• 用 "&" 判断奇数

let n=3;
let m=4;
n&1===1; // true 奇数
m&1===1; // false 偶数

• 用 "~" 判断项是否存在

let firstname="Ma";
let fullname="Jack Ma";
let isExist=!!~fullname.indexOf(firstname); // true

arguments 的坑

注意严格模式下，没有这个问题

• 当非严格模式中的函数 没有 包含 剩余参数、默认参数和解构赋值，那么arguments对象中的值会跟踪参数的值（反之亦然）

function sidEffecting(ary) {
  ary[0] = ary[2];
}
function bar(a,b,c) {
  c = 10 // 注意这里，其实它修改的就是 arguments 对象里的参数
  sidEffecting(arguments);
  return a + b + c;
}
bar(1,1,1);   // 21

• 当非严格模式中的函数 有 包含剩余参数、默认参数和解构赋值，那么arguments对象中的值不会跟踪参数的值（反之亦然）

function sidEffecting(ary) {
  ary[0] = ary[2];
}
function bar(a,b,c=3) {
  c = 10
  sidEffecting(arguments);
  return a + b + c;
}
bar(1,1,1); // 12

用canvas实现文字渐变效果

var context = canvas.getContext('2d')
var g = context.createLinearGradient(0,0,canvas.width,0)
g.addColorStop(0, 'red')
g.addColorStop(0.5, 'blue')
g.addColorStop(1, 'purple')
context.fillStyle = g
context.font = '36px fantasy'
context.fillText('hello canvas', 0, 100)

效果动图

ES6 proxy 深度代理一个对象

function deepProxy(object, handler) {
    if (isComplexObject(object)) {
        addProxy(object, handler);
    }
    return new Proxy(object, handler);
}

function addProxy(obj, handler) {
    for (let i in obj) {
        if (typeof obj[i] === 'object') {
            if (isComplexObject(obj[i])) {
                addProxy(obj[i], handler);
            }
            obj[i] = new Proxy(obj[i], handler);
        }
    }
}

function isComplexObject(object) {
    if (typeof object !== 'object') {
        return false;
    } else {
        for (let prop in object) {
            if (typeof object[prop] == 'object') {
                return true;
            }
        }
    }
    return false;
}

let person = {
    txt: 123,
    name: 'tnt',
    age: 26,
    status: {
        money: 'less',
        fav: [1, 2, 3]
    }
};
let proxyObj = deepProxy(person, {
    get(target, key, receiver) {
        console.log(`get--${target}--${key}`);
        return Reflect.get(target, key);
    },
    set(target, key, value, receiver) {
        console.log(`set--${target}--${key}-${value}`);
        return Reflect.set(target, key, value);
    }
});
proxyObj.status.test = 13;
proxyObj.status.fav.push('33');

格式化秒为 04:19 类型的小函数

const convertDuration = time => {
  let minutes = Math.floor(time / 60);
  let seconds = Math.floor(time - minutes * 60);
  minutes = String(minutes).length < 2 ? String(minutes).padStart(2,'0'): minutes;
  seconds = String(seconds).length < 2 ? String(seconds).padStart(2,'0'): seconds;
  return minutes + ":" + seconds;
}

convertDuration(252); // "04:12"

hooks 与 react-hot-loader 冲突

之前把老的 React 项目升级成了最新版，在使用 hooks 的时候遇到了一个问题。当时通过谷歌找到了问题所在，升级了 react-hot-loader 包以后就顺便解决了问题，为了继续做工作就没有具体去了解原因。

今天有时间了就搜索了一番资料，总结了一下内容：

在正确使用 hooks 的情况下出现了以下报错：

Uncaught Error: Hooks can only be called inside the body of a function component.

Hooks 确实有限制必须在函数组件中使用，但是我确实正确的使用了。于是搜索了一波资料，发现了一个 issus 出现了与我一样的问题：Incompatibility with react-hot-loader。

在阅读 issus 的过程中，发现 react-hot-loader 开发者给出了如下解答：

大致意思是无状态组件（也就是函数组件）会被转换成类组件，这是因为无状态组件没有更新的方法。

因此搜索了下 react-hot-loader 的工作原理，发现官方同样给出了一份文档：How React Hot Loader works。

内容中有说到为了渲染 react-tree，不得不把所有的无状态组件都转换成了无状态的类组件。

最后

这周的分享内容质量很高，我也从中汲取到了一些知识。

这是一个需要大家一起分享才能持续下去的事情，光靠我一人分享是做不下去的。欢迎大家参与到这件事情中来，地址在这里。

1. 创建3d上下文
   const gl = canvas.getContext('webgl');

2. 顶点着色器 vertexShader 和 片元着色器fragmentShader 共同组成 program 着色器
   // program可以有多个，这里只是创建对应的容器
   const program = gl.createProgram();
   const vertexShader = gl.createShader(gl.VERTEX_SHADER);
   const fragmentShader = gl.createShader(gl.FRAGMENT_SHADER);

3. 填充着色器内容(GLES代码)
   // 顶点着色器代码
   const VSHADER_SOURCE = attribute vec4 a_Position; attribute float a_PointSize; void main () { gl_Position = a_Position; gl_PointSize = a_PointSize; };

// 片元着色器代码
const FSHADER_SOURCE = #ifdef GL_ES precision mediump float; uniform vec4 u_FragColor; #endif void main () { float d = distance(gl_PointCoord, vec2(0.5, 0.5)); if (d < 0.5) { gl_FragColor = u_FragColor; } else { discard; } };

4. js代码连接GLES代码
   const connectShader = (program, shader, shaderCode) => {
   // 连接着色器与代码
   gl.shaderSource(shader, shaderCode);
   // 编译着色器
   gl.compileShader(shader);
   if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
   const info = gl.getShaderInfoLog(shader);
   console.log(info);
   }
   gl.attachShader(program, shader);
   }
   connectShader(program, vertexShader, VSHADER_SOURCE);
   connectShader(program, fragmentShader, FSHADER_SOURCE);

5. 使用program(因为program能存在多个，相当于激活当前工作着色器)
   gl.linkProgram(program);
   gl.useProgram(program);

6. 理解3d坐标系统
   一般以右手坐标系为主(从左 -> 右 为x轴正方向，从下 -> 上 为y轴正方向，从后 -> 前 为z轴正方向)，
   原点在canvas中心，
   无关canvas长，宽，x轴，y轴取值始终为[-1, 1]范围，需要我们自己归一化相应的坐标

7. 生成顶点数据
   function calculateX (width) {
   return (1 / (canvas.width / 2)) * x;
   }

function calculateY (height) {
return (1 / (canvas.height / 2)) * y;
}

function createData () {
let arr = [];
const max = 50;
const n = 20;
const m = 10;
for (let i = 0; i < n; i++) {
for (let j = 0; j < m; j++) {
const x = calculateX(-(canvas.width / 2) + i * 50);
const y = calculateY(-(canvas.height / 2) + j * 20 + max)
const item = [x, y];
arr = arr.concat(item);
}
}
return new Float32Array(arr);
}

8. 在GPU内，开辟一块缓冲区，存储数据
   const points = createData()
   const buffer = gl.createBuffer();
   gl.bindBuffer(gl.ARRAY_BUFFER, buffer);
   gl.bufferData(gl.ARRAY_BUFFER, points, gl.STATIC_DRAW);

9. 告知webgl如何解析数据
   const byte = points.BYTES_PER_ELEMENT;
   const a_Position = gl.getAttribLocation(program, 'a_Position');
   gl.vertexAttribPointer(a_Position, 2, this.gl.FLOAT, false, byte * 0, 0);
   gl.enableVertexAttribArray(a_Position);

10. 绘图
    gl.clearColor(0, 0, 0, 1);
    // 清空缓冲区
    gl.clear(gl.COLOR_BUFFER_BIT);
    // 画点
    gl.drawArrays(gl.POINTS, 0, size);

11. 绘制图形，只提供了三种 画点，画线，画三角形。 如果要绘制其它图形，需要我们提前计算好图形的顶点数据

每天看一遍

时间过得真快，转眼之间 19 年都已经快进入 9 月份了。

今天就来谈谈在这剩余的时间中我们还可以学点什么来充实自己，提高自己的竞争力。

前端基础

前端基础的重要性我觉得不需要多说了，无论是写出健壮的代码还是定位问题亦或者是面试中都是相当重要的一块内容。

如果你认为自身的前端基础还不过关的话，应该把大量的时间放在学习基础上。

计算机基础

计算机基础对于前端开发者来说最重要的是以下三点：

• 网络
• 数据结构
• 算法

以上这三点的共通性在于：你学了它们，在面试的时候总会带来不小的帮助。

这其中网络应该算是最重要的一块内容，毕竟性能优化常常需要你了解一点其中的知识。

另外两者虽然平时工作中很少用到，但是你保不准会遇到需要的时候。另外如果你以后想阅读源码的话，会发现源码中对于数据结构的运用会相当频繁。

框架

Angular 暂且不提，毕竟国内使用率是远不及 React 和 Vue 的。

如果你还没有熟悉框架的使用，在基础打好的前提下可以把精力优先放在这一块，通读文档是关键，因为很多你在开发中可能会遇到的问题在文档中都已经解释了。

如果你已经熟悉它们的使用，那么可以酌情考虑学习一下框架内部的原理。虽说工作上基本不需要你了解框架内部的机制，但是在面试的时间这经常是个必问点。

另外对于使用 Vue 的开发者来说。今年肯定会发布 Vue 3.0，那么新版本的学习应该是必经之路了。

对于使用 React 的开发者来说，切入 Hooks 或许会是一个不错的选择，当然要小心避免其中的坑。

跨端

跨域开发应该是今年热门的一个点，前有 React Native，后有火爆的 Flutter，另外还有各种小程序来横插一杠。

对于 React Native 或者 Flutter 来说。如果不是公司需要你去参与原生的开发，只是单纯的想自己玩一玩的话，那么学习它们我是持保留态度的。

因为学习这门技术并不能提升我的技术能力，充其量只是多具备了一门在原生上写 UI 的能力。如果你想玩转这个领域，那么一定会需要深入原生开发，这个成本就更大了。除非是公司需要，否则花费大量精力在其中个人是认为不值得的。

另外对于小程序来说，微信在这块应该算是龙头老大，当然还有其他的各种小程序。如果你只需要在微信上做小程序开发的话，那么选择余地会相对来说多点。比如 MpVue（千万别选，我踩了一大堆的坑）、Wepy、Taro 等等。

这些框架可以帮助我们快速进入小程序的开发。这些选择中 Taro 相对来说是个不错的选择，社区的活跃度以及反馈都是远远超过其他竞品的，另外也支持编译为多端小程序（其实还能编译成 React Native 和 H5）。唯一的问题应该是限制了你必须使用 React 技术栈。

热门点

列举几个在当下依旧热门的几个技术点：

• TypeScript
• GraphQL

TypeScript 应该算是当下相当热门的一个技术点了。很多框架要不已经 TypeScript 化，要不正在路上。

TypeScript 与 JS 最大的区别就在于增加了静态类型检查（当然一些语法糖也很舒服）。有个这个检查机制，对于开发和维护一个大型项目能带来极大的帮助，无论是修改老代码还是减少 Bug 的发生率。

当然如果你一直在开发小型项目，上不上 TypeScript 其实差别也没那么明显，但是学了并且用了肯定比写 JS 会舒服一点（前提是不要到处 any）。

对于 GraphQL 来说，了解过这块内容的应该都知道它能让请求接口变得相当舒适，当然它也会带来一定的成本，比如说调试困难。

当然虽说 GraphQL 不错，但是学习它最重要的一点我认为是能把它在团队中推动起来。如果推不动，还不如不学。

个人软技能

在这块我认为写 PPT 是个相当重要的软技能。无论评绩效、年终述职、晋升以及技术分享都会需要用到这个技能。

一个优秀的 PPT 是一个相当大的加分项，因为这能让你把想表达的东西更加清晰的呈现给对方。

最后

时间对于大家都是公平的，当下做了学习什么的决定后就不要再过虑了，毕竟没有什么决定在以后是一定正确的，其实决定以后马上行动起来才是正确的。

觉得内容有帮助可以关注下我的公众号 「前端真好玩」咯，定期分享以下主题内容：

• 前端小知识、冷知识
• 原理内容
• 提升工作效率
• 个人成长

在业务开发过程中，想必大家经常会需要查看一个元素的位置及大小并修改它的 CSS，因此就会频繁使用到 DevTools 中的选择元素功能。

其实我们可以使用一个 CSS 技巧给所有元素加上 outline，这样就能迅速了解自己所需的元素位置信息，无须再选择元素查看了。

我们只需要添加以下 CSS 就能为任何网站添加这样的效果

html * {
    outline: 1px solid red
}

需要注意的是这里我没有使用 border 的原因是 border 会增加元素的大小但是 outline 不会。

通过这个技巧不仅能帮助我们在开发中迅速了解元素所在的位置，还能帮助我们方便地查看任意网站的布局。

笔者最喜欢用这个技巧来查看元素是否对齐。

但是当下这个技巧需要我们手动添加 CSS 来实现，显得略微有点鸡肋，是否可以通过一个开关来实现任意网页开启关闭这个功能呢？

答案是有的，我们需要借助 Chrome 的书签功能。

1. 打开书签管理页
2. 右上角三个点「添加新书签」
3. 名称随意，粘贴以下代码到网址中

javascript: (function() {
	var elements = document.body.getElementsByTagName('*');
	var items = [];
	for (var i = 0; i < elements.length; i++) {
		if (elements[i].innerHTML.indexOf('html * { outline: 1px solid red }') != -1) {
			items.push(elements[i]);
		}
	}
	if (items.length > 0) {
		for (var i = 0; i < items.length; i++) {
			items[i].innerHTML = '';
		}
	} else {
		document.body.innerHTML +=
			'<style>html * { outline: 1px solid red }</style>';
	}
})();

然后我们就可以在任意网站上点击刚才创建的书签，内部会判断是否存在调试的 style。存在的话就删除，不存在的话就添加，通过这种方式我们就能很方便的通过这个技巧查看任意网页的布局了。

PS：以上书签的技巧参考自此处，原内容略微繁琐，笔者改动了 style 中的内容。

最后

觉得内容有帮助可以关注下我的公众号 「前端真好玩」咯，定期分享以下主题内容：

• 前端小知识、冷知识
• 原理内容
• 提升工作效率
• 个人成长

2018年总结

很荣幸成为了掘金的年度作者，小小的满足了一下虚荣心，当然我应该是年榜作者里最菜的一位了。

掘金年度回顾可以点击这里查看：http://2018.juejin.im/

认识我的人应该都知道，我是去年才正式转的前端，经验是远远比不过上榜的其他作者的。当然为了明年继续上榜，今年还会持续输出文章和开源。

在过去的一年中，我做了以下几件改变职业道路的事情：

• 年初开源了一个 React 的项目，积累了一点人气
• 在金三银四的时候发现各种面经文章层出不穷，但是套路都是对单个题目进行讲解，作用微乎其微。但是我也从这里发现了巨大的商机，面试的内容一定会有很多人感兴趣，何不将这些大厂面试题收集起来，然后从中提炼出常考知识点，然后针对每个知识点做详细的描述，毕竟只有理解了知识点，才能攻克各式的面试题。于是我花了近半年的时候，打造了一个十多万字的开源项目，至今已获得 14 K Stars
• 开源项目初期就获得了很好的成效，于是我趁热打铁，跳槽进了满意的公司
• 持续在掘金输出文章，提高自身的人气
• 出版了一本掘金小册，不到一个月的时间就发售了四千本，并且获得了很不错的评价，也有很多出版社联系我出书

从以上几件事情大家应该可以发现，我去年一年主体发力在打造个人的品牌上面，一旦提高了个人的影响力，很多在之前看起来很难的事情就能迎刃而解了。

现在我也逐渐喜欢上了写作，因为写作可以帮助我梳理巩固知识，也能帮助到别人，让别人认可自己，还能提高自己的影响力，这样的事情何乐而不为呢。

如果你也有一个写作的想法，我可以给出一点个人的小建议。首先前提是看得懂英文文章，然后你可以去阅读一些不错的文章，试着翻译文章或者理解文章并且将理解的内容输出出来，这样的方式能较好的度过一段写作的适应期，因为大部分的人可能空有这么一个写作的想法但却不知道该输出什么内容。

然后我想说一下这一年来我做出这些内容背后的一些思考，希望能对你有所启发。

首先我之前是做原生开发的，学习前端一开始也是因为想拓宽个人技术栈而已，所以就去学了。一开始当然是学习基础了，然后就开始接触框架的内容，为了提升自己的水平，也就去试着做了一个 React 的项目，当然后端也是自己实现的，总体来说还是偏向于 Demo 级别，并且也尝试着开源了出去，结果发现成效还不错，在这个时候就坚定了继续学习下去的决心。

接下来就到了金三银四的跳槽季了，发现面经文章实在是太火了，于是就想出了从知识点入手，开源一个项目的想法。对于这个想法我一开始的思考就是：从知识点入手，我能够持续夯实自己的基础，也会触碰到一些知识盲区，进而去弥补这些漏洞，这样的持续写作一定能让我打好一个不错的基础。

随着时间的推进，我更相信我这个想法一定是正确的，因为我自己都从持续的写作中弥补了一些知识盲区，更何况是广大的读者们，一旦开源必定会火，后续的结果也验证了我的想法。

开源项目一火，邮箱里就塞满了各种公司的面试邀请，我也就趁热打铁，直接转行，入职了一家满意的公司。

后续就是持续的一些写作继续提高个人的影响力，然后在十月份的时候开始书写 「前端面试之道」小册，内容从之前的开源项目中引申出来，知识点更全部也更加深度。

这本小册也经过了近十位大佬的审校，后续读者的评价也很好，就是当下更新的进度确实拖慢了，也是因为年前事情特别的多，写技术文章又不是一件很容易的事情，为了不滥竽充数，我也就只能拖慢进度了，也请广大读者谅解。

总的来说，我做的几件事情背后都有强有力的一个目的。

• 开源 React 是为了熟悉框架那套东西
• 开源面试项目是为了夯实基础以及提高影响力，进而顺利跳槽
• 写文章同样也是为了提升自己以及提高影响力
• 写小册同样也是为了提升自己以及提高影响力，当然还有附带的金钱利益

所以说，我们在业余中做的事情，最好每一件事情都有它背后的一个目的，并且确保这个目的大概率会达成，这样才值得花时间坚持去做一件事情，因为业余时间真的很宝贵，这样延迟满足的事情如果有，一定要尽力去完成。一年前，我还默默无闻；经过一年的努力，我起码拥有了一批自己的粉丝肯定了自己，那么我做的这些事情，就值得我继续做下去。

2019 的输出展望

趁着年轻，再多写点文章，老了就写不动了

• 计划输出一个系列，取名 「重学 JS」，内容偏向于底层
• 开源一个组件库，当然我知道一定比不过市面上的组件库，所以我会以另辟蹊径的方式去做这件事情
• 其他一些七七八八的碎片文章，内容可能会偏向于 Node 这块吧

一些链接

• 14 K Stars 的项目
• 前端面试之道小册

现在大部分搞前端的应该还是这样写 CSS 的：

.mock {
    margin: auto;
    font-size: 16px;
    // ...
}
<div class='mock'>mock</div>

以上代码就是举个例子，大部分情况应该都是写一个类，然后整一堆样式进去。

但是这种方式写多了以后，你应该会感受到一些痛点，比如说：

• 取名困难，节点结构一多，取名真的是个难事。当然了，我们可以用一些规范或者选择器的方式去规避一些取名问题。
• 需要用 JS 控制样式的时候又得多写一个类，尤其交互多的场景。
• 组件复用大家都懂，但是样式复用少之又少，这样就造成了冗余代码变多。
• 全局污染，这个其实现在挺多工具都能帮我们自动解决了。
• 死代码问题。JS 我们通过 tree shaking 的方式去除用不到的代码减少文件体积，但是 CSS 该怎么去除？尤其当项目变大以后，无用 CSS 代码总会出现。
• 样式表的插入顺序影响了 CSS 到底是如何生效的。
• 等等，不一一说明了。其实对于笔者而言，第一二块在开发中是最难受的两个点，尤其是刚写前端，需要做活动 / 产品页的时候。

当下，社区里有一些 CSS 方案，能够解决以上一些痛点：

• Atom CSS
• CSS-in-JS
• 上述两者的结合体

本文就来聊聊以上三种方案的优缺点以及各自方案的代表作。

Atom CSS

首先来聊聊啥叫做 Atom CSS：意思是一个类只干一件事，比如说：

.m-8 {
    margin: 8px;
}

想象一下你按照这样的**搞出一大堆类似的类名，就能整出一个践行 Atom CSS 方案的三方库了，tailwindcss 就是这个方案里的佼佼者。其实 Atom CSS 很多人应该早都用过了，栅格系统上就有它的身影，无非不清楚原来它就是 Atom CSS 罢了。

我们先来看看如果用 tailwindcss 的话，写好样式的 HTML 大概长啥样：

上图是人家官网上的，在这之前还有一段挺炫的动画。看起来好像挺方便的，写上一堆类名就能出左边好看的样式了，省了很多写样式的时间，但是读者们可以来想想这种方式它会有啥好处及弊端？

在说优缺点之前，我们先来聊聊 Atom CSS 的历史。其实它并不是一个新兴产物，这玩意你往前推个十年就能看到它的讨论。正所谓天道好轮回，苍天饶过谁。Atom CSS 以前火过，而且是被喷火的，沉寂了几年之后这几年又被拿出来说了。

接下来我们以 tailwindcss 为例来聊聊 Atom CSS 方案的优劣点。

优劣点

如果你想在团队内部推广这个产品，学习成本会是一个问题，毕竟需要大家都看得懂你这坨东西到底是啥意思，这算一个很明显的缺陷。但是对于语法问题你还真的不用怎么担心，tailwindcss 是有语法补全的工具链的，Webstorm 已经内置了，VSCode 需要大家自行装个插件，所以喷写 tailwindcss 语法麻烦的可以歇一歇。

样式复用，就像写组件一样，这次我们是把样式一个个抽离了出来，这样带来的一大好处是减少了 CSS 代码文件体积。

原本传统的写法是定义一个类，然后写上需要的样式：

.class1 {
    font-size: 18px;
    margin: 10px;
}
.class2 {
    font-size: 16px;
    color: red;
    margin: 10px;
}

这种写法是存在一部分样式重复的，换成 Atom CSS 就能减少一部分代码的冗余。

把 CSS 当成组件来写。大家乍一看 tailwindcss 官网肯定会觉得我在 HTML 里写个样式要敲那么多类是有病吧？

<figure class="md:flex bg-gray-100 rounded-xl p-8 md:p-0">
  <img class="w-32 h-32 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512">
  <div class="pt-6 md:p-8 text-center md:text-left space-y-4">
    <blockquote>
      <p class="text-lg font-semibold">
        “Tailwind CSS is the only framework that I've seen scale
        on large teams. It’s easy to customize, adapts to any design,
        and the build size is tiny.”
      </p>
    </blockquote>
    <figcaption class="font-medium">
      <div class="text-cyan-600">
        Sarah Dayan
      </div>
      <div class="text-gray-500">
        Staff Engineer, Algolia
      </div>
    </figcaption>
  </div>
</figure>

其实我们是可以利用 Atom CSS 一次只干一件事的特性，将这些类随意组装成我们想要的类，这样就可以提供出来一个更上层的通用样式来复用。

比如说项目中的按钮都是存在通用的圆角、内边距、字体等，这样我们就可以封装出这样一个类：

.btn {
    @apply p-8 rounded-xl font-semibold
}

效率工具。tailwindcss 用的好肯定是能提高写布局的效率的，尤其对于需要做响应式的页面而言。当然这东西其实也算是甲之蜜糖乙之砒霜，评价两极分化很严重，有人认为提高了效率，也有人认为反而是增加了成本，或者说是脱裤子放屁。

提供了一整套规范化的设计模式，直接点说就是 tailwindcss 给你内置好一套优秀的设计主题了。但是这玩意对于规范的视觉团队来说是个不小的福音，不规范的话就可能是火葬场了。下面我给大家举个例子：

// tailwind.config.js
const colors = require('tailwindcss/colors')

module.exports = {
  theme: {
    screens: {
      sm: '480px',
      md: '768px',
      lg: '976px',
      xl: '1440px',
    },
    colors: {
      gray: colors.coolGray,
      blue: colors.lightBlue,
      red: colors.rose,
      pink: colors.fuchsia,
    },
    fontFamily: {
      sans: ['Graphik', 'sans-serif'],
      serif: ['Merriweather', 'serif'],
    },
    extend: {
      spacing: {
        '128': '32rem',
        '144': '36rem',
      },
      borderRadius: {
        '4xl': '2rem',
      }
    }
  }
}

以上是 tailwindcss 的主题配置文件，大家可以按照视觉的要求来做调整。比如说今天视觉觉得屏幕的 lg 尺寸应该是 976px，过段时间又觉得需要改成 1000px。对于开发者而言我们只需要修改一行代码就能全局生效了，很舒服。

但是假如说视觉原本定义的边距规则如下：

// tailwind.config.js
module.exports = {
  theme: {
    spacing: {
      px: '1px',
      0: '0',
      0.5: '0.125rem',
      1: '0.25rem',
      1.5: '0.375rem',
      2: '0.5rem',
      2.5: '0.625rem',
      3: '0.75rem',
      3.5: '0.875rem',
      4: '1rem',
      5: '1.25rem',
      6: '1.5rem',
      7: '1.75rem',
      8: '2rem',
      // ...
    },
  }
}

现在需要我们把 6 换成 1.6rem，但是这个规则只需要作用在某些组件上，此时我们需要如何修改样式？新增一个 spacing 然后一个个去替换需要的地方么？

上述场景笔者认为还是不少见的，最起码在我们公司内部是存在这样的问题。已经定义了视觉规范并体现在内部的组件库上，但是在业务中还是有不少视觉会去动组件的基本样式，这里改个边距，那里改个颜色等等。原本组件库是为了帮助开发者提效的，但是在这种场景下开发者反而会抱怨改动样式极大提高了他们的成本，并且大部分情况下还不得不这样做。

再说回传统 CSS 的问题，其实 tailwindcss 也解决了一部分，但是仍旧存在没解决的点，比如说：

• 死代码问题没解决
• 样式表的插入顺序依旧有影响

以上说了那么多，其实对于我们使用 tailwindcss 而言，有利也有弊。它肯定是存在很好用的场景的，比如说写个人的产品页，或者说业务中样式变化不频繁的场景中，但是如果说需要业务中全量切换到 tailwindcss 的话，笔者肯定是持保留态度的。

对于 Atom CSS 来说，大家应该是不能否认它的优点的，但是我们是否有办法在尽可能避免它的缺点的情况下又获得它的优点呢？答案是有的，但是在讲答案之前我想先来聊聊 CSS-in-JS。

CSS-in-JS

CSS-in-JS（下文以 CIJ 缩写表示）核心就是在用 JS 写 CSS，这同样也是一个颇具争议的技术方案。

在这个领域下有两个库比较流行，分别为：styled-components（下文以 sc 缩写表示） 以及 Emotion。笔者目前已经用了一年多的 sc 了，来粗略谈谈它的优缺点。

我们先来了解下 sc 是怎么使用的。首先说下 sc 和 Emotion 的语法是趋于一致的，应该是为了 API 层面的统一吧，甚至前者还依赖了后者的一些包，以下是 sc 的常用写法：

const Button = styled.a`
  display: inline-block;

  ${props => props.primary && css`
    background: white;
    color: black;
  `}
`
render(
  <div>
    <Button
      href="https://github.com/styled-components/styled-components"
      target="_blank"
      rel="noopener"
      primary
    >
      GitHub
    </Button>

    <Button as={Link} href="/docs">
      Documentation
    </Button>
  </div>
)

用法我们不多展开，有兴趣的可以去官方看看，基本没有学习成本的，主要是一些样式组件上的使用。

另外 sc 并不是最终生成了内联样式，而是帮我们插入了 style 标签。

优劣点

笔者用了一年多的 sc，感觉这种方案对于 React 来说是很香的。并且解决了我很讨厌的传统写 CSS 的一些点，所以关于优劣点这段的讲述会有点主观。

首先 CSS-in-JS 这种方案不仅能让我们完整使用到 CSS 的功能，而且还扩充了一些用法。比如说选择器这块，在 sc 中我们能通过选择组件的方式来编写样式，如下代码：

const Button = styled.a`
  ${Icon} {
    color: green;
  }
`

另外既然我们通过 JS 来管理 CSS 了，那么我们就可以充分享受 JS 带来的工具链好处了。一旦项目中出现没有使用到的样式组件，那么 ESLint 就可以帮助我们找到那些死代码并清除，这个功能对于大型项目来说还是能减少一部分代码体积的。

除此之外，样式污染、取名问题、自动添加前缀这些问题也很好的解决了。

除了以上这些，再来聊两点不容易注意到的。

首先是动态切换主题。因为我们是通过 JS 来写 CSS 了，那么我们就可以动态地控制样式。如果你的项目有切换主题这种类似的大量动态 CSS 的需求，那么这个方案会是一个不错的选择。

还有个点是按需加载。因为我们是通过 JS 写的 CSS，现阶段打包基本都走的 code split，那么就可以实现 CSS 文件的按需加载，而不是传统方式的一次性全部加载进来（当然也是可以优化的，只是没那么方便）。

聊完了优点我们再来说说缺点。

第一个缺点很明显，有学习成本，当然笔者觉得这个学习曲线还是平缓的。

运行时成本，sc 本身就有文件体积，加上还需要动态生成 CSS，那么这其中必定有性能上的损耗。项目越大影响的也会越大，如果你的项目对于性能有很高的要求，那么需要谨慎考虑使用。另外因为 CSS 动态生成，所以不能像传统 CSS 一样缓存 CSS 文件了。

代码复用性和传统写 CSS 的方式没啥两样。

最后点是代码耦合问题。会有人觉得在大型项目中将 CSS 及 JS 写在一起会增加维护成本，并且也不符合 CSS 需要分离开来想法。

Atom CSS 加上 CSS-in-JS 的缝合怪

看了上文，如果你觉得两种方案都挺好的话，可以了解下 twin.macro，这个库（还有别的竞品）把这两种方案融合了起来。

import 'twin.macro'

const Input = () => <input tw="border hover:border-black" />
const Input = tw.input`border hover:border-black`

这种方案之上其实还有更好玩的方式，能帮助我们尽量取其精华而去其糟粕。

自动生成 Atom CSS 的 CSS-in-JS 方案

假如说我不仅想用 CSS-in-JS，还想把 Atom CSS 也给整上，但是又不想记 / 写一大堆类名，我这个想法能实现么？

答案是有的。利用运行时的方式把单个样式抽离出来，最后实现虽然我们写的是 CSS-in-JS，但是最终呈现的是 Atom CSS 的样子。

以 styletron 举个例子，开发时候的代码长这样：

import { styled } from "styletron-react";

export default () => {
  // Create a styled component by passing
  // an element name and a style object
  const Anchor = styled("a", {
    fontSize: "20px",
    color: "red"
  });
  return <Anchor href="/getting-started">Start!</Anchor>;
};

实际编译出来的时候长这样：

<html>
  <head>
    <style>
      .foo {
        font-size: 20px;
      }
      .bar {
        color: red;
      }
    </style>
  </head>
  <body>
    <a href="/getting-started" class="foo bar">Start!</a>
  </body>
</html>

这样的方式就能很好地享受到两种方案带来的好处了。但是这类方案笔者找了些竞品，觉得还没有前两者方案来的流行，大家了解一下即可。另外这种方式带来的运行时成本应该会更大，也许可以配套打包工具在本地先做一次预编译（一个不成熟的想法，说错勿喷）？

总结

说了那么多方案，可能读者会有疑问，那么我到底该用啥？这里笔者说下自己的想法。

首先对于 sc 来说，笔者觉得很香，在项目中大范围用起来未尝不可，当然我们还可以搭配着 Atom CSS 一起来写通用样式。

对于 Atom CSS，笔者个人认为不适合项目中大规模使用，起码在我们公司内部不会是一个好方案，毕竟视觉真的会来动某些通用样式。

大家也可以来说说各自的看法。

本文首发于公众号「前端真好玩」，欢迎关注。

这是我的剖析 React 源码的第四篇文章，之前的文章都是具体剖析代码，但是觉得这种方式可能并不是太好。因此从这篇文章开始，我打算把在源码中学习到的内容单独写成一篇文章，这样对于读者来说可能更加的友好。

文章相关资料

• React 16.8.6 源码中文注释，如果你想读源码但是又怕看不懂的话，可以通过我这个仓库来学习
• 之前的所有文章合集

为什么需要调度？

大家都知道 JS 和渲染引擎是一个互斥关系。如果 JS 在执行代码，那么渲染引擎工作就会被停止。假如我们有一个很复杂的复合组件需要重新渲染，那么调用栈可能会很长

调用栈过长，再加上如果中间进行了复杂的操作，就可能导致长时间阻塞渲染引擎带来不好的用户体验，调度就是来解决这个问题的。

React 会根据任务的优先级去分配各自的 expirationTime，在过期时间到来之前先去处理更高优先级的任务，并且高优先级的任务还可以打断低优先级的任务（因此会造成某些生命周期函数多次被执行），从而实现在不影响用户体验的情况下去分段计算更新（也就是时间分片）。

React 如何实现调度

React 实现调度主要靠两块内容：

1. 计算任务的 expriationTime
2. 实现 requestIdleCallback 的 polyfill 版本

接下来就让笔者为大家一一介绍着两块内容。

expriationTime

expriationTime 在前文简略的介绍过它的作用，这个时间可以帮助我们对比不同任务之间的优先级以及计算任务的 timeout。

那么这个时间是如何计算出来的呢？

当前时间指的是 performance.now()，这个 API 会返回一个精确到毫秒级别的时间戳（当然也并不是高精度的），另外浏览器也并不是所有都兼容 performance API 的。如果使用 Date.now() 的话那么精度会更差，但是为了方便起见，我们这里统一把当前时间认为是 performance.now()。

常量指的是根据不同优先级得出的一个数值，React 内部目前总共有五种优先级，分别为：