前言

类型与文法，在两个月以前其实已经看完了，但看完‘this与对象原型’和‘类型与文法’章节后，却自以为早已经掌握，没有什么可以谈的，于是便束之高阁。直到前一阵子，部门分享python基础的时候，提到python没有变量声明，拿来就用。着不是和JS很像？JS为什么没有变量声明呢？记得C语言都用变量声明，为何JS没有呢？变量声明有什么作用？好不好？

知乎问题为什么像 Java、C、C++ 这样的静态语言会比 Python、Ruby 这样的动态语言流行得多？

再结合另外一个知乎问题弱类型、强类型、动态类型、静态类型语言的区别是什么？里面介绍到：

Program Errors
• trapped errors。导致程序终止执行，如除0，Java中数组越界访问
• untrapped errors。 出错后继续执行，但可能出现任意行为。如C里的缓冲区溢出、Jump到错误地址

Forbidden Behaviours
语言设计时，可以定义一组forbidden behaviors. 它必须包括所有untrapped errors, 但可能包含trapped errors.
Well behaved、ill behaved
• well behaved: 如果程序执行不可能出现forbidden behaviors, 则为well behaved。
• ill behaved: 否则为ill behaved…

强、弱类型
• 强类型strongly typed: 如果一种语言的所有程序都是well behaved——即不可能出现forbidden behaviors，则该语言为strongly typed。
• 弱类型weakly typed: 否则为weakly typed。比如C语言的缓冲区溢出，属于trapped errors，即属于forbidden behaviors..故C是弱类型

动态、静态类型
• 静态类型 statically: 如果在编译时拒绝ill behaved程序，则是statically typed;
• 动态类型dynamiclly: 如果在运行时拒绝ill behaviors, 则是dynamiclly typed。

可以发现像JS这样的动态语言弱类型，没有如JAVA这样明显的编译过程，只是在浏览器或者Node运行时存在解析过程，并且在解析的时候检查有无forbidden behaviors。这样的动态语言有什么好处了，如部分答主所说的动如脱兔，如同草书般洒脱，不像其他语言一笔一划，讲求中正平稳。看看几年前JavaScript文件，程序如果比较大，几百行JavaScript都可以看得人头晕脑胀，也有没有IDE这样跳转工具，虽然现在有webStorm，对于大规模开发自然是不友好的，这种乱的感觉自然让很多人避开它。
到现在ECMAscript已经发展到ES7甚至ES8了，在Vue-router的开发里面，甚至都用上了Facebook的flow，来验证变量类型，提高代码质量，现在的JS已经是越来越旺盛了。
于是对变量声明的更进一步理解，于是又开始看‘类型与文法’这一章，没想到收获很多

开始

在JavaScript中，变量没有类型 -- 值才有类型。变量可以在任何时候，持有任何值

这句话深入我心，JS里面有var的变量声明，后面又有let和const。声明的变量可以是任何值，从基本变量到Object都是木有问题的，甚至在非严格模式下，不声明直接使用变量也不会报错，而且变量还可以随意更改，从number变到Object，完全没有问题，那为何要称变量为类型呢？明明说的就是变量背后的值是什么类型；

强制转换

falsy列表：

1. undefined
2. null
3. false
4. +0， 0， NaN
5. ''
   这些在Boolean强制转换的时候都会变成false，值得注意的是String类型里面仅有唯一一个空字符串('')会被转换为false。
   同时，类似的如[], {}以及-1等等的都是true值，这些简单有用的true/false还是值得注意的。

明确的强制转换

一元操作符'+'能将String明确的转换为number，同样能将Date类型变为number如：

var d = new Date( "Mon, 18 Aug 2014 08:53:06 CDT" );
+d; // 1408369986000

但是通常都不会这么做，没有语义，容易误解，不如常用的'getTime()'好使

需要小心的是parseInt传入非string类型的时候产生的bug。

隐含的强制转换

下面的都是是这一章的重点了，明确的强制转换大多好懂，而且不容易犯错。相比之下，隐含的强制转换就深邃的多了。

var a = [1,2];
var b = [3,4];

a + b; // "1,23,4"

上面例子中当操作数不是number的时候，它们都被强制转换为String类型，我们知道'42' + '1' = '420'通过String来实现字符串拼接，但是Array为什么也会这么做？有深度的内容来了：

根据ES5语言规范的11.6.1部分，+的算法是（当一个操作数是object值时），如果两个操作数之一已经是一个string，或者下列步骤产生一个string表达形式，+将会进行连接。所以，当+的两个操作数之一收到一个object（包括array）时，它首先在这个值上调用ToPrimitive抽象操作（9.1部分），而它会带着number的上下文环境提示来调用[[DefaultValue]]算法（8.12.8部分）。

如果你仔细观察，你会发现这个操作现在和ToNumber抽象操作处理object的过程是一样的（参见早先的“ToNumber”一节）。在array上的valueOf()操作将会在产生一个简单基本类型时失败，于是它退回到一个toString()表现形式。两个array因此分别变成了"1,2"和"3,4"。现在，+就如你通常期望的那样连接这两个string："1,23,4"。

这上面两段话以为着什么？说的是当你用object做加法操作的时候，object会调用其valueOf方法并返回基本类型，如果valueOf返回的基本类型失败（如没有valueOf方法或则返回的是object），那么就退回去用toString()方法，如果object没有toString()方法，那就返回错误；当然对象自然都是有toString方法的。
其他的String到number的常见的转换就是如'42' + 2 = 44通过字符串和数字直接相加。

上面提到的都是'+'加法计算，那减法呢？
字符串相加可以理解为拼接的过程，但是相减就完全不一样了，如下：

[3] + [1] // '31'
[3] - [1] // 2

恐怖吧？减法直接将其强制转为String，再由String转换为Number类型。

||和&&操作符

||和&&操作符其实没有特别的，只是当你去研究它的时候，又会发现它很特别
在判断的时候如if语言或则是三目判断，常会用到||和&&操作符。但是：

引用ES5语言规范的11.11部分：
一个&&或||操作符产生的值不见得是Boolean类型。这个产生的值将总是两个操作数表达式其中之一的值。

||和&&操作符只是意味着选择，而不是其他语言那样的逻辑判断！
想想确实也用过||和&&来做选择，比如以前很常用的：

e = event || window.event

用来做兼容处理。这里用的就是选择，而常见的cb&&cb()也是做选择。那我们所谓的逻辑判断呢？这个时候用选择的思维考虑一下，马上豁然开朗，逻辑的意思也就是返回最后被选择的数，如果这个数是true那就是真咯。

宽松等价与严格等价

提到== 和 ===操作，大多数开发者对前者经常是避而不及，省心的选择就是用后者，做严格的判断，毕竟前者太过花哨了。。。。。。还是先用心了解一下吧:
这里不得不提几条规范：

4.如果Type(x)是Number而Type(y)是String， 返回比较x == ToNumber(y)的结果。
5.如果Type(x)是String而Type(y)是Number， 返回比较ToNumber(x) == y的结果。
6.如果Type(x)是Boolean， 返回比较 ToNumber(x) == y 的结果。
7.如果Type(y)是Boolean， 返回比较 x == ToNumber(y) 的结果。

当String类型和Number比较的时候，String类型会被ToNumber为数字进行对比。同样的Boolean类型会被ToNumber，转换为0或者1。于是就有了如下：

'42' == false // false
'42' == true // false

可以看出'42'既不是0也不1，但是上面表达式却显得42不true也不false。

2.如果x是null而y是undefined，返回true。
3.如果x是undefined而y是null，返回true。
8.如果Type(x)是一个String或者Number而Type(y)是一个Object， 返回比较 x == ToPrimitive(y) 的结果。
9.如果Type(x)是一个Object而Type(y)是String或者Number， 返回比较 ToPrimitive(x) == y 的结果。

对于null和undefined自然是自身不true也不false，就等于null或则undefined，这个还是很容易理解的；那Object呢？
前面在'+'加法操作的时候提到过Object的转换问题，能通过valueOf返回基本类型就返回，不能就通过toString()方法，这里也是适用的。
值得一提的是形如{}这样的对象，其toString()之后是[Object Object]而不是'0'，和平时用的Object.prototype.toString.call还是很接近的。
来看看下面例子

Number.prototype.valueOf = function() {
    return 3;
};

new Number( 2 ) == 3;   // true

这种就是业界毒瘤了，希望不要有**这么写。。。。。哈哈哈哈

抽象关系比较

前面提到了加法和双等于判断，接下来怎么可以不提到大于小于判断呢？有了前面的基础，对于强制转换还是很容易理解的。看一下例子

var a = { b: 42 };
var b = { b: 43 };

a < b;  // false
a > b;  // false
a == b;  // false

a <= b; // true
a >= b; // true

这里Object对象自然都是被强制转换为[object Object]，那肯定是不是大小于关系的，那==呢？[object Object]难道不等于[object Object]？这个时候就不要陷入思维误区了，就像'' == '0'为false一样，明明转换后都是数字0为何不成立？因为他俩都是String，不用强制转换直接对比。同样的Object和Object用==判断自然也不用强制转换。值得一提的是Object只有和自己做==判断的时候才为true。
那后面的小于等于和大于等于呢？妈呀，看着都要乱了，这个要根据语言规范了，谁叫他是老大呢？

因为语言规范说，对于a <= b，它实际上首先对b < a求值，然后反转那个结果。因为b < a也是false，所以a <= b的结果为true。

原来是反转。。。。。。JS的逻辑还真会玩

文法

语句是有完成值的，比如你打开浏览器的控制台，输入var a = 1回车，这个时候，显示的下一行是undefined，而不是1，但你敲入a会车的时候，才显示1，这里的undefined和1就是语句的完成值。
关于强制转换，一个经常被引用的坑是[] + {}和{} + []，这两个表达式的结果分别是[object Object]和0，因为后面的{}表示的是缺省';'的语句于是变成{}; + []自然是0了。
另外文中还提到结构解析，操作优先级，自动分号(ASI)和错误的问题，这些都是基础部分，这里就不介绍了。

概论

不可变结构是一种很便利的函数式编程的数据结构，也是现代语言标准库如 Clojure 和 Scala 的一部分。其相同的部分是基于有固定数量的子节点的多阶树，允许快速查询和更新操作。在本文中我们采用了一种新的潜在的 vector 结构 Relaxed Radix Balanced Trees（RRB-Trees）。并展示了这种数据结构在 O(logN) 的时间里进行不可变数据 vector 的串联，插入和分割操作，同时维持着和原始 vector 数据结构的查询、更新和迭代接近的速度。

1 介绍

不可变数据结构可以便利地处理在多核并发的环境中存在的问题。不可变数据像 List 可以在函数式编程中很有作用，但是他们的顺序性使其不适用于并发处理。Guy Steele 在总结其 ICFP 09 的主题时用到的一句很出名的话 “去除弊端”。新的数据结构有有效的渐进行为和良好的常数因子，这种数据结构要能在并行处理时，分解输入的数据，同时可以有效的组合计算结果。

在可变数据里面，数组通常是以列表的形式的，这样访问元素的时间复杂度为常数，而不是线性，同时同一数组的不相交部分也可以并行处理。对常见的可变数据，构建一个高效的不可变数据模型，即一个可索引的有序序列，不是件容易的事。因为幼稚的创建不可变数据行为是在更新独立的元素时，时间复杂度采用不能接受的线性时间。不可变 vector 数据结构由编程语言 Clojure 首创，并在读写性能上有良好的平衡性，有效的支持多种常用的编程模式。在 Clojure，不可变结构有一个至关重要的语言实现设计，Ideal Hash Tries(HAMTs) 用在不可变结构的基本哈希字典上和同样结构的 32 分叉树上。这样设计的使得有效的迭代和单元素添加的时间复杂度都是常数级别，查询的时间复杂度在 log32 N = (1/5)lg N，更新的时间复杂度在(32/5)lg N。使用宽为 32 的数组作为树的节点可以使得数据结构的缓存更加友好。一个索引的更新只会在间接内存的访问里消耗 (1/5)lg N 时间，这意味着，为了实用的目的，程序员可以考虑将所有的操作都当作 “有效的常数时间”。

然而并行操作需要数据结构的高效的 vector 串联，给定序号分割和插入，而这种的结构并不能简单的实现。本文介绍的方式扩展了潜在的 vector 结构来支持 O(logN) 的串联和插入操作，而不是线性时间，同时不会影响现有业务。这种新的数据结构适用于常见理解类型的并行处理。一个 vector 进行拆分，可以认为是等效并行的。对于很多常见的操作例如 filter，拆分大小是能不预先知道。一个子 vector 可以串联并返回一个 vector，并且不是线性拷贝。这种方式下，并行处理在汇总的时候不会遗失数据。

尽管现在的研究是针对在编程语言 Scala 里的，但是该数据结构也适用于其他语言环境，例如 Clojure，C，C++等等。其他用例如：字符串的特别实现等也都促进基于模板的网页生成。

在本文的其他部分，我们会用术语 vector (结构容器) 来指代 Scala 和 Clojure 创建的 32分叉的数据结构。

1.1 相关内容

以前的研究已经阐述了，不可变数据结构对串联问题有所改进，特别是 Ropes、2-3 finger tree、平衡树等结构。然而每个都有限制的地方。Ropes，这个数据结构原本就是创建来支持字符串串联的，其实现方式是，简单的创建一个有两个子字符串的二叉树。通过向节点添加两个字符串的大小，在串联后可以有效的排序。至于分割，可以通过在 Rope 上创建一个分割的节点，并使用上下分割边界值就能实现。然而进行重复的串联和分割时候，性能会下降。索引的时间复杂度，变成 s + lg c，其中 c 是串联的数量，而 s 是沿着 Rope 树的路径的拆分数量。这里需要考虑平衡性，以免导致最坏的情况。如果不拷贝，分割也会导致内存泄漏，因为原始字符串的分割后排除的部分若不被引用，将不会被收集回收。

2-3 finger tree 的查询和更新的时间都是 lg N，同时添加到 vector 的操作保持在平均常数的时间内。串联也是在 lg N 的时间内完成。尽管挺吸引人的，但是使用这种数据结构对于 (1/5) lg N 查询的折中方法，理论中还是要慢5倍。在 Okasaki 的书中，数据结构的不同在于常数因子。

在本文中，我们介绍 Relaxed Radex Balanced Trees(RRB-Trees)，一种新的数据结构，扩展了 vector 结构，并保持了其基本特性，同时允许高效的串联，分割和插入操作。

1.2 Vectors

如图所示，我们用 4 分叉树来作为所有 m 阶树的替代。除了特别的说明外，这个方式都适用于所有 m 阶树结构，包括 32 阶--这个有趣的不可变结构。如图1 就是用这种替代的方式来说明基础的 vector 结构。我们可以想象一个 32 阶版本，只要通过将 4 阶替换为32阶。

在为 Clojure 开发不可变哈希字典时，开发组长 Rich Hickey 用了 Hash Array Mapped Tries(HAMT) 做底子。HAMT's 用 32 阶分支结构来实现一个可变的哈希字典。这个由 Clojure 首创的可变版本中，当项目被添加或移除字典的时候，树的路径才会被重写。同样的 32 阶分支结构被用来提供一个不可变数据的 vecter。在这里，对于项目来说 ‘key’ 是其在 vector 中的索引，而不仅仅是键名的哈希值。不可变性的实现是在修改和添加的时候拷贝或升级树的路径，这使得 32 阶分叉的查询时间复杂度是 (1/5) lgN。
选择 32 作为 m 阶分叉的 vector，是从结构的不同使用来权衡确定的。分叉因子的提高会提高查询和迭代的性能，同时趋向于降低更新和扩展的性能。当 m 变化的时候，原则上查询时间等比与 logm N，而更新用时等比喻 m logm N。而实际上，由于高速缓冲行的原因，在64-128位的现代处理器下，使得复制了该大小的小块非常便宜。

正如我们在图2 看到的， m = 32 是在查询和更新耗时中有良好的平衡，尤其是平时使用查询和迭代的次数要远多于更新。

选择 m 为 2 的乘方可以允许位操作，从而在索引中得到分支值序号，而不是昂贵的模运算。尽管这是在过去需要的考虑的重要问题，如今现代计算机使得其额外的有优势。

图 2 演示了使用 m 阶结构要比二叉树或 2-3 finger tree 要有优势。使用 32 阶的数据结构要是他们的 4 倍，而更新时间是相似的。这个原则上五倍的优势，被上层节点的缓存给稀释减少了。

1.3 串联

在图 3 中展示了两个 vector。一个幼稚的方式是将一个 vector 向左移动，然后将所有的右手边的 vector 的节点复制到被串联的 vector 上合适的位置，根据右手边的 vector 的大小，决定处理的线性时间长短。或者可以遍历右手边的 vector 并将其添加到左侧的 vector 中，这也是线性处理。在本文的剩余部分，我们将会提出 RRB-Trees 是如何有效的进行串联。

2. RRB-Trees

RRB-Trees 通过调整固定的分叉数 m 来扩展已有的结构。为了实现该方法，关键是要防止树退化到线性列表，同时要维持树高度为 lg N。

2.1 B-树

B-树维持每一级中的最大分叉数 Mm 和最小分叉数 Ml。相应的最大高度 Hm，和最小高度 Hl，可以通过给定的项数 N 来表示：

平衡性好的有一个高度比：Hr，并且这个值接近 1 的是玩美的平衡。

Ml 越是接近 Mm，则树的平衡性越好。对于B-树，如果 Ml 是 Mm 的一半，则：

当 Mm 变大的时候，B-树那就更平衡，这是总所周知的特性。

2.2 Relaxed Radix Search

在这个结构下，分叉数 m 一直是 32，同时树也完美的平衡。索引的时候可以直接使用基数查询的方式。当两个这样的树串联的时候要放宽约束来避免线性的复制。少于 m 的项或子树可能存储在同一个节点中。这也意味着我们不能再使用任何简单的基数查询了。

基数查询依赖于每个给定的层级的子树上希望的节点数是刚好 m 的 h-1 次方个。因此对于索引 i， 在该节点的子树中被找到的概率是 [i/(m 的 h-1 次方)]（ps：索引和节点都是基于 0 偏移）。如果节点少于希望的，我们需要用另外一个方式，我们称之为宽松的基数查询。

在B-树，通过在父节点中存储一定区间 key，使用线性或则二进制查询父节点来找到包含目标 key 的子节点。在 RRB-树，当叉数少于 m 的时候，使用相似的方法，然而存储在父节点的数组中的是索引的区间而不是 keys 的区间。

图 4 展示了RRB树的基本结构。树节点 A 包含了一个指向子树的数组， C, D, 和 E。该数组包含了这些子树的总的累计的子叶的数量。为了方便，我们将一个指向及该数组的相关区间称之为槽，例如，槽位 0 指向节点 C，该数组的区间说明了其包含了三个子树，这些子树同时也是子叶。

假设我们想要获取序号为 3 的节点，也就是节点 D 的第一个项。该序号被 4 整除，将会落在槽位 0。然而我们发现当查找的序号等于或大于该槽位的区间时，需要查找下一个槽位 1。索引少于槽位 1 的区间的话，可以在槽位 1 的子树 D 中继续查询。在这之前，我们需要用查询的序号减掉槽位 0 的 3 个序号，使得后续是从零开始的新索引查询。可以发现想要查询的索引在节点 D 的第 0 个位置。

通常的，如果 Ml 接近 m，父节点上的基数查询将会快速接近希望的槽位。例如，如果 Ml = m -1，树高为 2时，最差的情况下，只会有 (m-1)平方 个项。为了查询第 m 个槽位，希望在选中的槽位中找到相应的子树，然而有时候，下一个槽位也必须被检查到。

在查询的时候，必须要先检查子树的区间来确定进入哪个子树查询（没有必要回溯查询）。区间值是该槽位的子叶的实际项目数量。我们可能需要检查两个可能的区间值。而不是直接查询正确的路径。这个额外的检测在现代计算机中是很简便的。读取第一个值就会引起缓冲行的加载，接着相邻的几个值会和第一个同样速度的进入缓冲。进行一个短的线性查询有较小的开销。接着，如果考虑所有可能的序号，并且槽位上节点数量也是均匀 m 或者 m - 1，我们可以预计这次的基数查询的成功率是 3/4。

槽位的平均节点数是 (m - 1)/2。（接下来这段文字都看懂了，但是不知道什么意思。。就不翻译了。。。）。

2.3 缓存行意识和二进制查询

缓存行加载可以通过短暂的线性查询，对基数查询带来上面的益处。对于二进制查询，这个是很合适的，因为其在串联算法中需要较少的约束。然而，32 阶的二进制查询可能在缓存行加载的时候导致多个缓存丢失，并且不能简单的预取缓存。经测试表明，宽松的基数查询要比二进制或纯线性查询要块三倍。

前言

Immutable.js 出来已经有很长一段时间了，只是日常项目中一直用不上。一个是平时没有怎么接触，不了解，另外一个是团队的开发节奏和习惯已经稳定下来了，要改变也不容易。当然了解一下也不差。

不可变的数据一旦生成，就无法被改变，这就要求数据可持久化。可是日常中的引用类型的数据，一旦改变了，就改变了，谈什么持久化数据结构呢？

接触immutable

感受一下immutable的不同：

// 原本写法：
let a = [1, 2];
let b = a;
b[0] = 0;
console.log(a[0]); // 0
console.log(a === b); // true

// immutable 里面的写法
import { List } from 'immutable';
let a = List([1, 2]);
let b = a.set(0, 0);
console.log(a.get(0)); // 1
console.log(b.equals(a)) // false

可以直观的看到在没有使用 immutable 之前， a 与 b 都是同一引用，一旦其中的数据修改了，另一个也会跟着变化，毕竟 a 是等于 b 的。而到了 immutable，就不一样了，当你设置 a.set(0, 0) 的时候，并不会修改 a ，而是返回一个新的数组赋予到 b，所以 a 还是原来的 a。

**这就是 immutable 致力解决的疼点：持久化数据解构。**平时使用数据的时候，可能一不小心就会把引用类型数据修改了，导致一些隐藏比较深的问题。尤其是对后来的开发者/维护者而言，意义就更重大了。

在 immutable 里面常见的数据类型有：

1. List： 有序可重复列表，类似于 Javascript 的 Arry；
2. Map：键值对，类似于 Javascript 的 Object；

其 API 还是很亲民的，基本上字如其名，大致接触一下就能够了解了。常用的用法这里就不做介绍了，需要了解，请移步官方文档。

List 类型

Liit 类型可以说是常用的了，尤其是和 Javascript 里面的 Arry 类似。看一下 List 里面的主要部分：

function makeList(origin, capacity, level, root, tail, ownerID, hash) {
  const list = Object.create(ListPrototype);
  list.size = capacity - origin;
  list._origin = origin;
  list._capacity = capacity;
  list._level = level;
  list._root = root;
  list._tail = tail;
  list.__ownerID = ownerID;
  list.__hash = hash;
  list.__altered = false;
  return list;
}

一个空内容的 List，也就是 List()，是 makeList(0, 0, SHIFT)) 生成的，而 SHIFT 的值为 5。传入 List 括号里面的值会被存储在 _root 和 _tail 里面，只是 _root 和 _tail 里面的数据又有以下结构：

// @VNode class
constructor(array, ownerID) {
  this.array = array;
  this.ownerID = ownerID;
}

在 List 列表的生成里，就可以看到，持久化数据的形成，比如看看为何将数据分别保持在 _tail 和 _root 里面，以及又是用何种方式保存；

以设置一个数据为例子，如： List([1]).set(0, 0):

set(index, value) {
  return updateList(this, index, value);
}

function updateList(list, index, value) {
  ...
  let newTail = list._tail;
  let newRoot = list._root;
  const didAlter = MakeRef(DID_ALTER);
  if (index >= getTailOffset(list._capacity)) {
    newTail = updateVNode(newTail, list.__ownerID, 0, index, value, didAlter);
  } else {
    newRoot = updateVNode(
      newRoot,
      list.__ownerID,
      list._level,
      index,
      value,
      didAlter
    );
  }
  ...
  return makeList(list._origin, list._capacity, list._level, newRoot, newTail);
}
// SIZE = 1 << SHIFT，而 SHIFT = 5
function getTailOffset(size) {
  return size < SIZE ? 0 : ((size - 1) >>> SHIFT) << SHIFT;
}

可以看出在 updateList 里面，通过 _capacity 来判断，以 32位 为尺度将 _capacity 切分开来，当 index 大于 ((size - 1) >>> SHIFT) << SHIFT 时候，更新 _trail, 否则更新 _root。例如： 当 _capacity 为 33，index 为 32 及其以下的时候，修改的都是 _root，否之则修改 _tail。这个是很好理解的，当数据量达到一定程度的时候，针对靠后的数据单独存储，而靠前的数据放在 _tail，分类处理。只是特别之处在与 _tail 的设计。

List 里面的 32 阶 RRB-Tree

_tail 里面采用的是 RRB-Tree 的形式存储数据。这个什么树的先不介绍，先看看看怎么形成，形成的是什么，继续看上面的 updateList 方法，里面用到了 updateVNode 方法来生成 _tail:

function updateVNode(node, ownerID, level, index, value, didAlter) {
  // MASK = 31;
  const idx = (index >>> level) & MASK;
  ...
  let newNode;
  if (level > 0) {
    const lowerNode = node && node.array[idx];
    const newLowerNode = updateVNode(
      lowerNode,
      ownerID,
      level - SHIFT,
      index,
      value,
      didAlter
    );
    if (newLowerNode === lowerNode) {
      return node;
    }
    newNode = editableVNode(node, ownerID);
    newNode.array[idx] = newLowerNode;
    return newNode;
  }
  ...
  newNode = editableVNode(node, ownerID);
  if (value === undefined && idx === newNode.array.length - 1) {
    newNode.array.pop();
  } else {
    newNode.array[idx] = value;
  }
  return newNode;
}
function editableVNode(node, ownerID) {
  if (ownerID && node && ownerID === node.ownerID) {
    return node;
  }
  return new VNode(node ? node.array.slice() : [], ownerID);
}
// @VNode class
constructor(array, ownerID) {
  this.array = array;
  this.ownerID = ownerID;
}

在这里可以看到 value/newLowerNode 是赋值给 newNode.array[idx]， 而 idx 并不是等于 index。以 _capacity 为 65 的 List 为例子，其 _level 为 5。当 index 为 60 的时候，有以下行为：

1. 第一次进入 idx = 1，level = 5，将会有 _tail.array[1] = newLowerNode;
2. 计算 1 里面的 newLowerNode，第二次进入，此时 level = 0，idx = 28，于是有 newLowerNode.array[28] = value；
   可以看出这里生成个二维的数组，其中每个子节点的长度最大为 32，于是这就构成了一个 32阶的树结构。至于为什么阶长是 32，在代码中是这么解释的：

Resulted in best performance after ______?

这不是逗我嘛。。。什么都没有写好吧，而且 github 里面最早的版本也是这么写的。。。。最后还好找到是有测试实验数据证明 32 也就是 SHIFT 为 5 是最佳实践。至于为什么要采用这种结构，不是本文要考虑的，将在下篇中给出来。

最后数据生成的结构如下如所示：

get 方法里面也是差不多的，通过 _capacity 来判断。

Map 类型结构

同样的先看看一个空的 Map() 的结构：

function makeMap(size, root, ownerID, hash) {
  const map = Object.create(MapPrototype);
  map.size = size;
  map._root = root;
  map.__ownerID = ownerID;
  map.__hash = hash;
  map.__altered = false;
  return map;
}

这里就没有 _tail 结构的，所有数据都放在 _root 里面。只是 _root 里面的数据并非总是简单，采用了 Trie Nodes 的方式存储数据。 immutable 里面将对象的键值对转换为数组表示，即 [key, value] 的形式。

存储的数据分为以下级别：

1. ArrayMapNode，最简单方式，当键值对不超过8个的时候(不含嵌套的键值对)，采用这种方式，所有键值对保存在 entries 里面。同时 get/set 方法都较为简单，直接遍历一下获取就好了；
2. BitmapIndexedNode，当 ArrayMapNode 里面元素超过8个的时候，_root 会转变为 BitmapIndexedNode，BitmapIndexedNode 的子节点是 ValueNode。在 BitmapIndexedNode 里面查/增/改元素，都需要用到 bit-map(位图)算法，BitmapIndexedNode.bitmap 存储的是键名和存储顺序的位图信息。例如 get 方法，通过 BitmapIndexedNode.bitmap，以及 key 名就可以获取该键值对的排列序号，从而获取到相应的 ValueNode；
3. HashArrayMapNode，ValueNode 个数超过 16 个的时候，_root 会转变为 HashArrayMapNode 对象，其子元素为 ValueNode。而当 ValueNode 个数超过 32 个的情况时，HashArrayMapNode 的亲子元素就会出现 HashArrayMapNode/BitmapIndexedNode，而 BitmapIndexedNode 的亲子元素可以是 BitmapIndexedNode/ValueNode。由此看来巨量的键值对，将有 HashArrayMapNode/BitmapIndexedNode/ValueNode 组合而成，而每个 HashArrayMapNode 最多有32个亲子元素，BitmapIndexedNode 最多有16个亲子元素。 HashArrayMapNode 类对应带的 count，代表其子元素的数量。当需要读取的时候，直接键名的哈希值，就能够实现了。。。。好像有点简单呀；
4. HashCollisionNode，这种情况相当少，比如当 {null: 1} 和 {undefined: 2} 的键名是完全不同的，但是他们的键名的哈希值却是一样的。这使得后者 {undefined: 2} 创建的时候才会有 HashCollisionNode。HashCollisionNode 包含了这两个相同哈希值的键名下的数据；

// The hash code for a string is computed as
// s[0] * 31 ^ (n - 1) + s[1] * 31 ^ (n - 2) + ... + s[n - 1],
(多键值的整个读写离不开键名哈希计算，而其关键步骤如上，n为键名从左到右字母的 charCodeAt)。

withMutations 操作

每次对 immutable 的数据类型操作的时候，都会返回一个新的数据，这样就存在一个问题，如果需要像原本一样对一个数据不断0操作，如不断的向Arry 里面 push 新值。对于 List，每次都返回一个新 List 岂不是多了很多中间变量，多了很多蹩脚的操作？于是就有了 withMutations 操作。如：

let a = List();
Array.apply(null, { length: 10 }).forEach(item => a = a.push(item));
// 上面可以用withMutations操作
a = a.withMutations(list => 
  Array.apply(null, { length: 10 }).forEach(item => list.push(item))
)

上面为原先不使用 withMutations 的方法，每次 push 之后都需要重新对 a 重新赋值，才能保证正确性。而用了 withMutations 方法之后，不再需要创建中间 List，减少了复杂度，基本上运行时间比前一种快上好几倍。当然 withMutations 不会修改 a，所以需要将中间 List 赋值到 a。

为什么 withMutations 会有这样的效果呢？以 A(List) 为例子，当使用 withMutations 时候，其首先，生成的中间变量 B(List)，其属性值就是 A 的属性值，没有任何更改，当然如果 A 没有 __ownerID， B 的 __ownerID 会被设置上。但是对 B 进行 push/pop/set 等等操作的时候，A 其实是没有受到任何影响的。

function editableVNode(node, ownerID) {
  if (ownerID && node && ownerID === node.ownerID) {
    return node;
  }
  return new VNode(node ? node.array.slice() : [], ownerID);
}

如在 withMutations 操作里面 set 数据的时候， 上面 if 语句是无法通过的，因为 A 的数据里面是没后 ownerID 的，相当于给 A 的数据浅拷贝一次到 B 里面，但是在 withMutations 里面再次 set 的时候，这时上面的 if 语句是可以通过的，于是又能节省不少运行时间。类似的 Map 也是相似的，这里就不再提到了。

其他

immutable.js 类型的一层层继承关系，刚开始的看的时候会觉得有点乱，不管哪里都有 extends。细细看下来还是挺不错的。Immutable.js 还有个 Seq 类型，其特点就是懒。懒的意思是，直到获取使用了才开始计算。一开始觉得很神奇，居然有用数据的时候才计算的。。。well，后来一看这得益于一系列的 API，主要就是把调用方法函数数据什么的统统用闭包给存起来。。。。。。。好吧。

ps：immutable.js 最神奇的地方还是在于其数据结构，下篇文章将会好好讲数据结构。

最近为了新版官网，一直在学习 iphone 11 的效果图，结果越研究发现其复杂度实在远超想象，还要支持各种兼容问题。而我们这次的官网则是要向其学习，其中类似 apple 的翻页的布局是结构的重中之重。

sticky的翻页效果

苹果官网上采用的是 sticky 的效果，就是 position: sticky 这个属性的兼容性比较一般，基本只有现代浏览器都支持。只是 apple 都用了，其在 ie 等浏览器也做了兼容处理，那为什么我们不试一试翻页效果呢？

没有找到合适的第三方库，于是采用自己摸索的方式，按照苹果的方式按葫芦画瓢，具体的结构大致如下

<main>
  <section class="sticky-container">
    <div class="sticky-inner"></div>
  </section>
</main>
.sticky-container {
  margin-top: -100vh;
  height: 200vh;
}
.sticky-inner {
  position: sticky;
  top: 0;
  height: 100vh;
}

每个模块翻页的模块都是一个 sticky-container 模块，并且通过 margin-top 往前上移一个屏幕的高度。内部模块再采用 sticky 的方式，使得上一个模块翻过的时候，下一个模块已经出现了，并且其内部模块牢牢的固定在顶部，达到翻页的效果。

同时这个 sticky 的方案满足长模块的要求，普通模块高度为 100vh，当模块的内容较多，100vh 不够的时候可以扩展开。同时 H5 也可以采用这种方式。

sticky 兼容效果

ie 浏览器毫无意外是不支持的，考虑到2019年11月份 ie 浏览器的**份额已经接近 0.8% 的水平，于是采用简单的兼容方式，将 sticky 统统改为普通布局。只是在移动端，本来以为兼容效果是最好的，caniuse 里面基本移动端都是没问题，没有想到现实中有各种问题：

oppo 浏览器最新版不支持 sticky，uc 浏览器对嵌套 sticky 支持效果非常差，会出现大块的白屏情况，chrome 浏览器是最好的。可以通过简单的判断 $('.sticky-inner').css('position') === 'stikcy' 或者是 -webkit-stikcy 来判断是否支持。而 uc 的嵌套问题只能通过修改代码结构来实现。只是 UC 浏览器对 sticky 的滑动效果不太好，底部边缘会出现颤抖的情况，通过 GPU 加速的方式也无法消除问题，最后考虑还是将 UC 浏览器同样降级为非支持 sticky 的模式。

为了兼容非支持 sticky 模式的机型，特意查询了一下主流的代替方案，采用 fixed 和 absolute 来代替 stikcy，其中效果最好的要数 stickybits 和 stickyfill 这两个 Polyfill 方案了，但是其对长模块内容的 sticky 支持却不好。最后还是自己调试生成兼容版本。

sticky 翻页

sticky 已经可以很好的解决翻页问题了，奈何领导提出这样的翻页效果不符合要求，滚动或者滑动过程存在可以看到其他页的效果（难道苹果不是也有同样的问题？），于是在上线前两天临时改了方案，经过评估最好的方案是用 swiper，只是由于整个功能页改为 swiper 需要时间较多，于是折中使用 sticky 翻页时，自动整体往上滑动的效果。

主要技术难点为页面定位问题，这个需要维护一个锚点位置的列表，在初始化和 resize 时候更新，而长模块内容的自动上划以及其自然翻滚要做区分处理，这个区分处理就很麻烦，需要耐心调试。而更加麻烦的是在 mac 下面表现很差，到处乱飞，以及 H5 的滑动也是乱飞的情况，需要一个个适配，于是在上线前一天理所当然的放弃了 H5 以及 mac 的效果，也好给领导交差。

swiper 版本的翻页效果

对于垂直翻页的效果，如果长模块内容复杂，可以下个定论，是不适合用 swiper 的，只能用 sticky 的方案，swiper 在长短屏切换时需要处理各种逻辑兼容问题，如果长模块内容复杂，则会增加复杂度。

相比较于 stikcy 的翻页模式，swiper 的翻页需要自己搭建，其本身自带的切换效果只有 fade cube 这些模式。pc 端用到的是 wheel 滚动，在事件 transitionStart 触发的时候修改 swiper 动画就可以了。需要注意的是由于是翻页效果，所以每个页面都要绝对定位，并设置 z-index；由于长模块内容在 wheel 触发的时候，不能直接翻页，需要判断是不是长模块内容本身的滚动，于是要动态设置 mousewheel.enabled。

移动端则比 pc 端复杂不少，由于其翻页是触摸式翻页，需要在 progress 里面同步修改翻页的 transform，同时由于长模块问题，需要动态设置 allowTouchMove，类似 pc 端的 mousewheel.enabled；

由于长模块的内容，存在 fixed 元素，而 swiper 的翻页效果为了达到顺滑，采用的 transform 动画，这样将导致长模块内的 fixed 失效。为此有两个方案可以实现：

1. 将长模块内容高度限制在 100vh，支持 overflow-y: scroll；长模块内分为 fixed 元素和长高度的空元素，长高度元素起高度撑开作用；由于 fixed 元素存在交互，需要将长高度元素的 z-index 放在最底层，所以无法自然滚动该元素，故采用控制滚动。fixed 元素在上下翻动的时候改为 absolute 布局。
2. 将 swiper 内的长模块的内容完全移出来，在 swiper 翻页的时候，单独控制其 transform，原本的 swiper 模块只做高度撑开作用，来配合控制滚动。

这两个方案分别用在了 pc 端和移动端，最后效果看来是第二种好，absolute 和 fixed 布局还是有差异，会导致页面抖动，需要不断调试。第二个方式这是需要自己修改 swiper 翻页模式，将 fixed 的元素和对应 swiper 页面的翻动结合在一起。

swiper 切换模式

初步尝试切换，采用在 fade 模式和 transform 修改，但在移动端的 progress 事件里修改 transform 时候，页面的动画无法生效，一直是 translate3d(0px, 0px, 0px)，除非采用 !important 增加 transform 的权重，并且要写在 css 样式中，无法做到动态修改，于是一开始移动端使用的切换效果是基于 top 的，调试的时候效果符合要求，但是用真机调试，发现 top 的效果还是差强人意。

后面立刻研究 swiper 的源码，从模式入手，发现其切换模式的添加，是采用 swiper.use 方法，该方法没有开放出来，有点类似 Vue 的模式。研究 effect-fade.js 文件可以发现下面代码：

// ... 省略部分代码
const Fade = {
  setTranslate() {
    $slideEl
      .css({
        opacity: slideOpacity,
      })
      .transform(`translate3d(${tx}px, ${ty}px, 0px)`);
  }
}

export default {
  name: 'effect-fade',
  on: {
    setTranslate() {
      const swiper = this;
      if (swiper.params.effect !== 'fade') return;
      swiper.fadeEffect.setTranslate();
    },
  }
}

移动端每次滑动的时候，其 transform 值都会被重新修改，导致 progress 里面的修改无效。于是我就自定义一种模式 slide-page，其在滑动的时候，读取当前 progress 来修改 transform，只是需要注意的是不能仅仅对当前页面修改，需要对全体页面都重新设置，避免切换的时带来的问题，并且需要同步到 fixed 的元素。这样的模式也适用于 pc 端。

总结

sticky 的优势是最明显的，功能完备，pc 端兼容良好。而 swiper 需要在长短模块之间切换，mac 下由于高度是不变，没有正常布局的格式，所以会触发橡皮胶效果，体验整体没有 sticky 好。另外上面的方案还有改进点：对于长模块内容，内部可以去掉长高度元素，每次长模块滑动滑动都触发一次状态修改就可以了，没有必要采用 z-index 为负的滚动。

在研究时间调度时就有 React 的异步渲染的迹象了，只是在实际应用中却不知道如何开启，如何跟踪，后来看了 react-fiber-resources 上面介绍的 Try React Fiber asynchronous rendering!。其实在 React 的博客 React v16.0 发布之际就已经说明了：

We think async rendering is a big deal, and represents the future of React. To make migration to v16.0 as smooth as possible, we’re not enabling any async features yet, but we’re excited to start rolling them out in the coming months. Stay tuned!

直到现在本文研究的版本 16.4.1，异步渲染 async rendering 仍然没有正式推出，其中日常开发中可以看到 ReactDOM.render(element, container) 模式采用的就是 legacyCreateRootFromDOMContainer 这类方式，在生成 root 的时候直接将 root.current 的 mode 赋值为 0，也就是常见的同步的方式。fiber 的模式 mode 有以下类型：

// ReactTypeOfMode.js
const NoContext = 0b000;
const AsyncMode = 0b001;
const StrictMode = 0b010;
const ProfileMode = 0b100;

StrictMode/ProfileMode 在源码中似乎是用于开发中的，于是看这里的 AsyncMode 模式，也就是异步模式。只是通过官网教程介绍的方式是无法开启异步模式，还没有大规模的推广，现在日常开发用的 React 基本上还是同步模式 sync，也就是上面的 NoContext。

那如何开始异步模式呢？在上文链接中有介绍到。可以通过以下方式：

// 较于之前的方式，将 container 与 element 分开。通过 unstable_createRoot 
// 创建异步的 fiber。
const root = ReactDOM.unstable_createRoot(container);
root.render(<App />);

unstable_createRoot 的方式和先前一样，创建根部 root，即是 ReactRoot 对象，当前 current fiber 为异步模式，mode 为 3 即 AsyncMode|StrictMode。再进行 rendering 渲染。

expirationTime

在早期的 React 版本里面采用了优先级的 Priority 模式，如下：

module.exports = {
  NoWork: 0,              // No work is pending.
  SynchronousPriority: 1, // For controlled text inputs. Synchronous side-effects.
  AnimationPriority: 2,   // Needs to complete before the next frame.
  HighPriority: 3,        // Interaction that needs to complete pretty soon to feel responsive.
  LowPriority: 4,         // Data fetching, or result from updating stores.
  OffscreenPriority: 5,   // Won't be visible but do the work in case it becomes visible.
};

到了该版本 React 16.4.1，采用的则是 fiber.mode 以及 expirationTime 相继结合来实现异步以及优先级的。已经没有上面这些标志的存在了。通过统一的参数 expirationTime 来表示优先级。分为两种情况：

1. expirationTime 为 1，就是同步模式，也就类似于 React 16 之前的 stack 情况，程序会按照顺序执行下去，直到结束；
2. expirationTime 不为 1 的时候，则其值越低，优先级越高。rootExpirationTime 不为 1 的时候会启动异步模式。

function computeExpirationForFiber(currentTime: ExpirationTime, fiber: Fiber) {
  let expirationTime;
  if (expirationContext !== NoWork) {
    expirationTime = expirationContext;
  } else if (isWorking) {
    if (isCommitting) {
      // 在 commit 阶段更新任务，需要给予同步优先级
      expirationTime = Sync;
    } else {
      // 渲染阶段则设置为渲染结束后的下次时间
      expirationTime = nextRenderExpirationTime;
    }
  } else {
    // 非执行阶段，根据 fiber.mode来设置 expirationTime。
    if (fiber.mode & AsyncMode) {
      // 异步模式下
      if (isBatchingInteractiveUpdates) {
        expirationTime = computeInteractiveExpiration(currentTime);
      } else {
        expirationTime = computeAsyncExpiration(currentTime);
      }
    } else {
      // 同步模式下
      expirationTime = Sync;
    }
  }
  // ...省略交互相关部分
  return expirationTime;
}

如果 fiber.mode === AsyncMode，则 expirationTime 为大于 1 的值，同步则为 1，当然同步是优先级最高的，异步具有 LowPriority。前面博客都是同步模式下研究的。对于异步时间的计算，按照 当前时间为基准，250ms 为一个单元。两个异步 fiber 计算 expirationTime 的时候，如果当前时间 currentTime/25 为相同整数，则这两个异步 fiber 具有相同的优先级。

render/reconciliation 阶段的从深调用栈返回处理交互事件，也和时间的计算有关系。在上文中提到，在 workLoop 中通过计算 deadline.timeRemaining() 来判断是否还剩余时间，这个也就是 requestIdleCallback 的用法。但是有一点不同，在 performWork 里面，也就是即将进入 performWorkOnRoot 之前有：

function performWork(minExpirationTime, dl) {
  //...省略部分
  if(dl !== null) {
    while (
      nextFlushedRoot !== null &&
      nextFlushedExpirationTime !== NoWork &&
      (minExpirationTime === NoWork ||
        minExpirationTime >= nextFlushedExpirationTime) &&
      (!deadlineDidExpire ||
        recalculateCurrentTime() >= nextFlushedExpirationTime)
    ) {
      recalculateCurrentTime();
      performWorkOnRoot(nextFlushedRoot, nextFlushedExpirationTime, true);
      findHighestPriorityRoot();
    }
  }
  // 省略部分
}

由前文可知当没有剩余时间的时候会终结 workLoop 循环，同时令 deadlineDidExpire = true，只是如果这样还是不足以使得 performWork 里面的循环为 false，必须要 recalculateCurrentTime() >= nextFlushedExpirationTime。recalculateCurrentTime 计算的是当前时间，nextFlushedExpirationTime 则是 root.expirationTime，初看的时候会自然的认为后者肯定是更小的，但是恰恰相反。异步的 expirationTime 是以 5000ms 为基数， 250ms 为单位计算的。所以只有当超出时间过长，比如五六秒，才会变为立刻执行的情况。在之前的小版本里面，基本是只要是剩余时间不足就立刻中断，没有和 nextFlushedExpirationTime 比较的过程。

前面的 expirationContext 涉及到 ReactDOM 的另一个异步更新的 API，如下：

ReactDOM.unstable_deferredUpdates(() => {
  ReactDOM.render(<App />. container);
  // or
  instance.setState(() => newState);
}); 

与 unstable_createRoot 一开始就创建异步模式的 fiber 不同，unstable_deferredUpdates 会修改 expirationContext 生成异步的 expirationTime 达到延迟更新的目的，

优先级

当 expirationTime !== SYNC 时候，fiber 就具有不同的优先级，有优先级的前提是异步。异步模式是通过时间调度方式实现的，具体看前文 react 时间调度。那优先级是定义好了，但是如何保证高优先级的先执行呢？

在 renderRoot 的时侯，会有 nextRenderExpirationTime = root.nextExpirationTimeToWorkOn，所以当初次构建 workInProgress Tree 的时候所有的 fiber 也就是 expirationTime 都是一致，哪怕是异步组件 React.unstable_AsyncMode。生产的 expriationTime 是一样的，但是若中途出现优先级更高的事件，导致基准的 expriationTime 改变又如何？

function beginWork(current, workInProgress, renderExpirationTime) {
  if (
    workInProgress.expirationTime === NoWork ||
    workInProgress.expirationTime > renderExpirationTime
  ) {
    return bailoutOnLowPriority(current, workInProgress);
  }
  // ...省略后面 switch (workInProgress.tag) 的情况
}

在 beginWork 就比较当前 fiber.expirationTime 和 renderExpirationTime 关系。renderExpirationTime 即是 nextRenderExpirationTime，是下次要渲染的时长，高于它，则该 fiber 将不会在该阶段中渲染。这种情况会发生在异步渲染里面，还在渲染阶段的时候，插入低优先级的的事件，这个时候将会产生更低优先级的 fiber，本轮 commit 结束后，会在下一次渲染阶段再做安排。

update 的优先级

在 fiber 里面有任务队列 updateQueue，该队列维护的是传参 element，是个链表结构，节点为 update。通过 update.nextEffect 来指向下一个节点。而这里的每个节点，则是需要更新的 element。update 结构如下：

export function createUpdate(expirationTime: ExpirationTime): Update<*> {
  return {
    expirationTime: expirationTime,
    tag: UpdateState,
    payload: null,
    callback: null,
    next: null,
    nextEffect: null,
  };
}

expirationTime 是对应该节点的优先级。fiber 有优先级，这个 update 也有优先级，这个在 ReactUpdateQueue.js 开头的注释有介绍到：

1. updates 的排序不是基于优先级的，而是基于插入顺序。
2. 渲染阶段的时候，只有高优先级的 update 才会被被用到。

以前版本里面，对 update 的处理是采用 insert 方式的，即是高优先级的会插入到低优先级 update 前面。而今则是通过 expirationTime 区分。

function processUpdateQueue(workInProgress, queue, props, instance, renderExpirationTime){
  // ...省略部分
  let update = queue.firstUpdate;
  let resultState = newBaseState;
  while (update !== null) {
    const updateExpirationTime = update.expirationTime;
    if (updateExpirationTime > renderExpirationTime) {
      // This update does not have sufficient priority. Skip it.
      if (newFirstUpdate === null) {
        newFirstUpdate = update;
        newBaseState = resultState;
      }
    } else {
      // This update does have sufficient priority. Process it and compute
      // a new result.
      // ..,省略
    }
  }
  // ..,省略
}

可以看出只有小于或者等于 renderExpirationTime 的才会被采用，你没有看错是小于或者等于，而不仅仅是小于。因为同优先级的 update 是会被采用的，这个 bug 已经在 Always batch updates of like priority within the same event 被修复了，well，同时也修改和很多地方，最大的是 requestCurrentTime 取代了 recalculateCurrentTime。
没有被采用的 update 最怎么样呢？通过 newFirstUpdate 保留到 updateQueue 里的 firstUpdate 了。下次渲染的时候，才会被用到。

总结

异步渲染里面，除了 ReactDOM.unstable_createRoot/ReactDOM.unstable_deferredUpdates 以外，还有 React.unstable_AsyncMode 的方式创建异步组件，React.Timeout 这样的 TimeoutComponent 组件。只是目前关于异步，优先级，React 本身还在一直更新中，指不定有不少的坑，当然都冠以 unstable 的名号了，谁用谁负责，就像 UNSAFE_componentWillReceiveProps 之类的。期待未来 React 异步渲染正式推出那天。期待下图：

参考

1. [翻譯] React Fiber 現狀確認
2. react-fiber-resources 里面的资源都灰常好！如这篇 Build your own React Fiber，还有视频系列。
3. coordinating-async-react

前言

前文《初识immutable》介绍 immutable 的一些基本操作和特色，但是其重点部分结构共享，即数据结构留在了这里。这不是平时接触到的简单的数组、对象亦或则字典的形式，而是 tree ！日常开发基本就遇不到树结构，再复杂一个字典表就可以搞定了，于是乎 immutable.js 提供了一次很好的学习数据结构，学习算法的体验。

共享结构

共享结构还是比较简单的。对于已有的数据结构，若需要更新其中的某个节点（中间节点或则子叶），并不会把整个数据结构都拷贝一份，再修改该节点并返回新的数据结构。immutable.js 里面会采用路径修改的方式来实现更新。

简单的来讲，对于数组或则对象的形式，更新的时候，仅仅会修改该节点，浅拷贝该层级所有节点，修改所有父节点，以及浅拷贝该父节点的所有同父级节点。这么说可能有点绕口，来看看大神 camsong 做的图：

如图所示，当更新黄色节点的时候，黄色节点所在的同一父节点的元素都会被浅拷贝，同时黄色节点的所有父节点也会被更新，以及浅拷贝父节点的同一级节点。于是就有了路径修改这一说，相当于其他节点也就是树结构左下角蓝色的四个节点，对于新旧结构就是处于共享状态的。所以这应该就很清晰了，通过这样的树结构减少拷贝数量，而对于其他节点而言，由于都是浅拷贝，是不影响旧结构指向的。只是在新的父节点处修改对子节点的指向，也就是上图中右边分支。

同样的对于 List 结构，也是树结构，也会浅拷贝，所以这里就不多谈了。

数据结构

看了上篇博客的，基本可以发现，列表 List 的数据结构就是一个 32 阶树。查找和更新都是根据 5 bit 为标准的，一个分支最多有 32 个子分支。所以通过对索引序号 index 进行位移操作，就是 index >>> level，再取 31 的模。从 index 的高位到低位来读取树结构从上到下的数据。而这里用到的是什么技巧呢？

Bitmapped Vector Trie

总所周知，对于普通的数组结构，其读取的时间复杂度为 O(1)，只是插入更新的时间复杂度为 O(n)，对于海量数据是不可取的。而二叉树 BST 呢，读取的速度为 1.39 O(lg n)，插入平均速度也为 1.39 O(lg n)。相较于线性的读写，还是要优秀不少的。**所以是不可能采用线性结构来存储数据的。**List 结构采用 32 阶的树结构，其读写的时间复杂度更加优秀，是 O(lg n)，其底数是 32，也就是说时间复杂度是二叉树的 1/5。

Bitmapped Vector Trie，位图数列前缀树，名字有点长，但是意思很明显。先看看维基中的 trie：

trie 前缀树，是树的一种，只是 trie 的键是由位置决定的。比如数字 3 ，其就是有 t 节点， e 节点和子叶 a 节点决定的，是由其路径决定的。通过 tea 这个键，就可以找到值 3，而对于键 inn，则可以找到 9 这个数值。这个就是 trie 的功能，多用由于字典查询~~

Bitmap 算法则是，将数据通过位移运算映射到位上，从而实现内存开销的减少。如果能用一个 bit 位来识别这样一个数字，就会很方便了。如数字 3，通过位运算 1 << 3 得到映射的二进制 1 000，从而当的映射数据的第四位为 1 的时候，则说明 3 这个数存在！为 0，则不存在，通过位图算法可以大大减少内存使用。对于 java，int 类型的长度为 32 位，所以也就是为原来 1/32 的样子。

在普通数组中要如何结合 trie/Bitmap 呢。trie 和 Bitmap 的结合可以加快树结构里面的查询。具体操作可以看下图，

在该图中，对于数组 zoo，当要取索引为 5 的数，要如何获取呢？可以看到存储的数据结构是 trie 的形式，只是每个节点上面的键名都不是之前介绍的字符串，而是 0/1 的形式。将索引 5 二进制化为：101。通过二进制数 101，从高位到低位依次读取 1 bit，来读取现有的 trie 结构上节点的数组的值，就能够确定路径，从而现实 Bitmap 位图的查询，都不用什么复杂的判断，只要每次取索引 5 的映射值，也就是二进制 101，就能够轻松读到数据。

对于 32 阶的数结构，则是每次都读取最高位的 5 bit，来实现 Trie 查询。对于长度为 65 的数组，如索引值为 60，则其第一次 60 >> 5 & 31 为 1，第二次为 28，所以第 60 个数据，在第一个 32 阶分支的第二个分支下面的第 28 个元素就是目标值。是不是很快，飞一般的速度。

32 阶的选择

选择 32 阶树结构是要远远快于二叉树的，理论上是二叉树时间复杂度的 1/5。使用 32 底数的时候，若层级超过 7，就已经有超过数十亿个数了，这个时候内存可能都不够了吧。所以在实际开发中可以把这个 32阶的 Bitmapped Vector Trie 的时间复杂度当作常数。

那为何不继续使用更大的底数呢，底数更大，其时间复杂度应该是更加优秀的吧？

事实上，选择 32 作为 m 阶的分叉，是有其特殊性的。可以看到下图：

可以看到上面是更新操作，下面接近 x 轴的是查询操作。而当底数为 32 的时候，在更新和查询操作上都有良好的平衡性。当然这么一看不是最好的选择，可能看客会觉得似乎 8 要远远优于 32。只是这个考虑是不周全，在日常使用持久化操作的时候，查询操作的比例是要远远高于更新操作的。所以很显然会选择 32 而不是 8，前者的查询耗时是后者的 66% 左右。

只是为什么选择 32，而不是 33/31/29 之类的呢？原因很简单，因为选择 32 的时候，对索引的取模操作，可以被优化为位运算，也就是上文中出现的 index >>> level。在现代计算机下，位运算可以大大的减少计算时间。

另外由于计算机的高速缓存行的问题，阶数少的时候，其缓存效果更加，导致了底数为 2 的查询速度只是 32 的 1/4 而已，而不是 1/5。

HAMT

上面介绍 Bitmapped Vector Trie 的时候，讲的是 List 结构。那对于 Map 结构又要如何处理，毕竟没有 List 结构的索引，好像就无从下手了。

Map 是没有索引，没有错，但是我们可以把键名的哈希值变为索引呀~~

HAMT：Hash Arrey Mapped Trie，就是这样一个结构，将 key 的哈希值存储在 Trie 节点上。如同索引一样，需要对哈希值取模，也就是 32 bit 的位操作。只是不同的是 List 结构上面是从高位往低位的索引读取的，而 Map 是从 key 哈希值的低位往高位顺序读取的。为什么这么设计呢？List 一开始就能够知道数组的容量 capacity 是多少，通过 capacity 和 index 索引可以知道数据的位置，而容量肯定是大于等于索引的，排在索引前面的是必然有数据内容的。而 Map 结构，如果从哈希值的高位往低位读取的话，那就有点恐怖的，小于该哈希值的字段，却不一定有呀，这样就导致在没有什么数据下，树的层级就可以很深了。这样就达到了压缩层级的效果。

为了更好的解释 HAMT 结构，这里举个例子，对于 key = Aa，其计算出来的哈希值为 2112，取模 2112 & 31 为 0，所以他将会在数组的下角标为 0 的对象里面，至于该对象是不就是这个 key 生成的对象呢？取决于还有没有其他低 5 位也是 0 的元素，如果有那还要取下一个高 5 位来查询，直到找到数组。这样就很明朗了，通过每次取 31 的模，从低位到高位，这样的 Bitmapped 的方式就可以确定元素的位置了。

每次取 31 的模，这样每个层最多都有 32 个元素。于是就形成了 32 分叉的结构。但是并不是每次都是 32 个数据的，这样看数量量的大小。当字段比较少，少于 8 个的时候，Map 结构只是个简单的数组结构，每次读取 key，通过循环判断就好了。

如果字段介于 8 和 16 个之间（普通情况下），则是采用 BitmapIndexedNode 的对象，通过 bitmap 方式：计算出每个键 key 的哈希值，再将哈希值做基于 1 的位移操作，如哈希值为 A，将会得到新的 bit = 1 << A，如下所示：

class BitmapIndexedNode {
  constructor(ownerID, bitmap, nodes) {
    this.ownerID = ownerID;
    this.bitmap = bitmap;
    this.nodes = nodes;
  }
  // 省略部分内容
}
// 省略部分内容
const newBitmap =  bitmap | bit;

上面的 BitmapIndexedNode 对象的 bitmap 则是通过将所有字段的 bit 做或操作得到的，从而实现 bitmap 算法。再加上 popCount 操作，毕竟数据是以数组的形式存储在 BitmapIndexedNode 里面，而 BitmapIndexedNode 里面数组的长度为 16，所以不是字段 key 的 bit 是第几位就在第几位数组上，而是要同通过 popCount 来获得当前 bit 前面有多少个 1，也就是有多少个字段，从而得到对应的位置。

BitmapIndexedNode 里面最大数是 16，也就是在 32 个哈希值中选取 16 个不同的哈希值，为什么是 16 不是 17/18 个之类的呢？BitmapIndexedNode 这里其实起到一个压缩的作用，因为哈希分布不可能是从小开始出现，而是随机的，若是给随机的哈希，配置到同样的位置，就会造成很多内存的浪费，比如，对于 key = '0'，其计算出来的 bit 因该是 28，若前面没有什么数据，不可能就让数据的第 28 位存储 key = 0 的数据的，这只是浪费，它理所应当排在第一个位置，这样就有效的压缩了树内存大小。

如果这个时候字段数持续增多，如果得到的新的 Bit 和存在的值是重复的，比如字段 Aa 和 11 的哈希值 31 （哈希函数在下方）的模都是 0，但是却有完全不同的哈希值，前者是 2112 后者是 1568，于是下角标为 0 的元素就升级为 BitmapIndexedNode 对象，这个 BitmapIndexedNode 对象的 bitmap 则由 Aa 和 11 的下一个高 5 位的哈希值，再位移，做或操作来得到。

当字段持续增加，而对应的低位哈希量已经超过 16 个的时候，就会升级为 HashArrayMapNode 对象，可以没有 16 位的限制，根据取模 31，则最多有 32 的长度。通过每次读 5 bit 的方式，来实现读写。

哈希计算如下：

function hashString(string) {
  let hashed = 0;
  for (let ii = 0; ii < string.length; ii++) {
    hashed = (31 * hashed + string.charCodeAt(ii)) | 0;
  }
  return smi(hashed);
}
function smi(i32) {
  return ((i32 >>> 1) & 0x40000000) | (i32 & 0xbfffffff);
}

上面的 hashString 和 jvm 里面的 string 类型的 hashCode 计算是一致的。都是乘以 31，看这里又有 31，这个必然是 31 可以被计算机转换为位移操作啦，当然也有统计结果下性能好的原因。

但是这样的哈希值，以及取 31 的模的方式会出现另外一个问题。hashString 确实可以计算出一个独立的哈希值，只是独立的哈希值，却不意味着不会发生重复碰撞的情况，比如 key = 'Aa' key = 'BB'，其哈希值是完全一样的，这个时候就会启动 HashCollisionNode 对象，将相同的哈希值的对象都放在同一个 HashCollisionNode 里面，而这里面就是简单的线性读写数组了，没有之前的 Bitmapped 操作，毕竟一次性不可能有太多相同哈希值的键名出现。

另外 immutable.js 里面认为 splice 操作是昂贵，基本上都写了自己的 api 来替换掉 splice

总结

难得有一次学习数据结构的机会，大学好像就没有学过相关知识吧，这个月才开始看《算法》一书，很是感动，第一次如此接触到二叉树，红黑树，觉得前端，原来不止有三大框架，不止有三大框架的 API，生态圈里的的组件，nodejs，更有数据结构的存在，希望还是能更多的接触。

参考

1. Anjana Vakil: Immutable data structures for functional JS | JSConf EU 2017，非常好的视频，通俗易懂；
2. RRB-Trees: Efficient Immutable Vectors，很无聊的论文，语法怪怪的，但是键 RRB-Trees 的都会说到这篇文章，翻译了一半不到。
3. Striving to Make Things Simple and Fast - Phil Bagwell，Clojure 的一个讲座，说的挺好的，就是没有怎么听懂，和上面的论文比较搭。
4. Immutable 结构共享是如何实现的，很优秀的讨论。
5. Use RRB-Tree in Vector，immutable.js 里面对 RRB-Tree 的讨论。

前言

相信大家都或多或少接触过Vue，先前就有人介绍学习Vue的源码，提到旧版本的源码行数只不过一千多行，可以一个一个commit学习下去。前段时间为了找下家，一直在用Vue做作品，效率也较以前原生JavaScript要快上许多，后来工作上手了，不禁想看看Vue源码长什么样子的，只是从第一个commit开始读起来较为费时，而Github上面Vue项目能够找到的最早branch是Vue 0.10，然而在发布版本里面，可以发现最早一版本是Vue 0.6.0版本。本文介绍也是从该本版开始，该版本较0.10的要上少40%左右代码。

目标

本文目的在于最短时间内，介绍Vue0.6.0的核心模块源码，数据双向绑定，computed计算属性等。
看完本文之后，能明白Vue框架到底做了些什么，并自行构建一个早期Vue框架的简化版本。

准备

在介绍Vue 源码之前，需要了解Object.defineProperty,通过这个方式，在获取对象字段值时，调用getter方法，而设置对象字段值时候，调用setter方法，来实现数据劫。Object.defineProperty是Vue的基础内容，至今不熟悉的请一定要看Object.defineProperty MDN

思路

对于

data: {
    a: 1,
    c: 2
}

如果你要设置data.a的值，并更新渲染DOM，会怎么做呢？
了解Object.defineProperty神奇的setter和getter数据劫持功能后，自然而然是有以下步骤：

1. data.a的访问器属性setter里，通知所有和data.a有关的instances；
2. instances在源码中指的是Directive构造函数生成的实例集合，其中每个实例的this.el是一个指向data.a有关联的node节点，如
   {{a}}
   里面的textNode节点。如果有多个这样的节点，data.a就对应多个directive实例。在进行data.a重新赋值的时候，setter被调用，执行data.a下每个directive实例的update函数，实现局部DOM更新;
3. directive实例和data.a数据的对应关系可以用Binding构造函数说明，每个Binding都含有instances数组，该数组存放的就是directive实例集合，而data.a只有一个Binding

实现

看了源码不难发现，创建的实例new Vue({}),指的是ViewModel构造函数，而ViewModel函数如下：

function ViewModel (options) {
    // just compile. options are passed directly to compiler
    new Compiler(this, options)
}

所以comilper.js才是生成Vue的核心所在，下面是简化了compiler构造函数

function Compiler(vm, options) {
    let compiler = this;

    options = compiler.options = options || makeHash()

    var el = compiler.setupElement(options)

    var scope = options.scope;
    if (scope) utils.extend(vm, scope, true)

    compiler.vm = vm

    var observables = compiler.observables = [],
        computed    = compiler.computed    = [];

    compiler.bindings = makeHash()

    compiler.setupObserver()

    let keyPrefix;
    for(let key in vm) {
        keyPrefix = key.charAt(0)
        if (keyPrefix !== '$' && keyPrefix !== '_') {
            compiler.createBinding(key)
        }
    }

    compiler.compile(el, true)

    while (i--) {
        binding = observables[i]
        Observer.observe(binding.value, binding.key, compiler.observer)
    }

    if (computed.length) DepsParser.parse(computed)
}

上面过程分为三个阶段：

准备设置

1. compiler.setupElement(options)通过querySelector返回Vue的el节点
2. 我们熟悉的data，computed和metheds，在该版本中都是options.scope里面，也就是说米有data，computed和methods之分，统一在scope里面，utils.extend(vm, scope, true)则是将scope的所有字段扩展到vm下面，方便后面处理；
3. compiler.bindings = makeHash()则是给compiler的bindings设置为{}；

observer实现

这里实现每个key的数据劫持和事件监听
4. compiler.setupObserver() 创建compiler.observer监听'get', 'set', 'mutate'动作
5. compiler.createBinding(key)，将所有的scope里面的字段key都创建Binding实例，而compiler.bindings[key]则指向创建的binding，同时若字段不含有'.'则会进行define方法，该方法先是将刚刚创建的Binding{key].value设置为vm[key]，实现每个key的Binding实例都保存下value值。如果该value是对象或则数组，如scope.a为对象，则push到compiler.observables里面；最后现实数据劫持Object.defineProperty
在define里面的Object.defineProperty，setter方法: 若新值不等于旧值，则重新对bindings[key].value设置为新值，同时进行Observer.unobserve旧值和Observer.observe新值，只有value是对象或则数组的时候，才会进入Oberver.oberver/unobserve方法，那对于普普通通的data.a等于字符串这种呢？前文说好的设置data.a的时候通知所有和data.a有关的instances，又发生在那里呢？
答案在在setter里面还通过compiler.observer触发了set事件,set事件里面就有bindings[key].update，而正如上文所说的bindings[key].instances就是directive实例，而directive实例又是什么时候添加进去的呢，且看下面

compiler.compile的实现

6. compiler.compile(el, true)解析DOM节点，通过遍历所有的节点，对不同的属性名字如v-text采用不同指令，如果是有效的字段就返回Directive实例，这个实例会通过CompilerProto.bindDirective方法处理Directive和Binding的关系。如
   {{a}}
   , 会先生成一个Directive实例，该实例包含textNode节点，v-text的更新指令，在bindDirective方法中，则会判断vm是否有bindings['a'],如果有的话，直接使用compiler.bindings['a']，并将directive实例push到bindings['a'].instances，接着执行directive.update(value),而这个value就是前文提到的binding['a'].value,至此完成DOM节点和scope的关系

那对于scope.a为对象，如scope.a = {b: 1},这里的scope.a.b是无法在步骤5中实现的，只有scope.a会出现在步骤5，那scope.a.b要如何创建binding呢？
在步骤5中，进入define方法后，若检测到scope.a是对象，则将binding['a'] push到compiler.observables里面，到了步骤6，遍历到{{a.b}}的时候，会创建bindings['a.b'],但是不会进入define方法里面，无法对bindings['a.b']赋值，和Object.defineProperty数据劫持，没有赋值没有数据劫持，那又要如何实现{{a.b}}以及后面的重新设置a.b的值呢？

7. 对observables遍历，通过Observer.observe方法对scope.a下的所有字段遍历，并在observer.js里面的bind方法，对所有的字段建立Object.defineProperty数据劫持，同时触发'set'事件，最后会传递到步骤4里面的事件监听'set'事件，执行bingdings['a.b'].update,现实DOM里面的数据首次展现

通过对于普通的socpe.a = 12,而言打印创建的Vue实例有如下图

compiler下创建了a:Binding构造函数，而这个实例的instances包含了一个Directive，里面存放的value 12，

computed原理

类似于observables，在compiler里面也会创建compiler.computed数组，在define方法里除了在compiler.observables.push(binding)外，若是对象，并且有$get方法，则是computed，这个版本里面，computed是有$get方法的，well...当然还有$set;

scope: {
    a: 1,
    c: {
        $get: function(){
            return this.a
        }
    }
}

8. DepsParser.parse(computed)，若computed存在元素，则调用DepsParser.parse，这个时候DOM里面的计算属性还没有赋值！只是创建了对应的binding，和observables的遭遇是一样的。。。。在 DepsParser.parse里面，当执行computed的$get函数的时候，如遇到依赖scope.a,则会调用步骤5里面为scope.a创建的数据劫持getter，这个方法里面触发'get'事件，在步骤4里面监听到'get'事件后，触发DepsParser.observer的'get'事件，而这个'get'事件作用则是将bindings['a']，bindings['c'].deps里面，同时bindings['a'].subs里面放入bindings['c'],为何要这样做呢？在初始化的时候是不必的毕竟$get已经可以获得正确的数值了，但是当重新设置scope.a的时候，就需要通知scope.c同步更新了，这个在bindings['a'].update里面实现

自此Compiler构造函数也就大体如此，具体细节还是要多看源码

监听数组

在compiler.observables里面，在Observer.observe里面，可以看到当处理对象的typeOf值是对象或则数组都会进行特别处理，若是对象上文已经提过处理方法，若是数组的话又会如何呢？
这里简要概述一下：通过ExpParser.parse方法，将bindings['a[0]'].value设{$get: newFunction('this.a; return this.a[0]')}的形式，后面就和computed类似了，这里有一点需要注意，在observer.js里面，重写了['push','pop','shift','unshift','splice','sort','reverse']等数组方法，当a.push(1)的时候，会触发mutate动作，执行bindings['a'].pub()，从而通知bindings['a[0]']的instances更新，具体内容可以自己去看源码

参考资料

1. 剖析Vue原理&实现双向绑定MVVM

前言

续网络请求后，学习 HTTP/2。HTTP/2 的主要协议 RFC 7540 出来已经三年多了，HTTP/2 的应用也越来越多。几年前还在为 HTTPS 响应速度慢，能不上 HTTPS 就不上，结果现在基本成为标配了。对于大型系统，HTTP/2 也会是这样，毕竟知乎都是 HTTP 2 了。

HTTP/1.1

从 HTTP/1.1 诞生至今，互联网已经走过了十几个年头，当初的 HTTP/1.1 协议出现了不少缺陷，其中管线化，就是其中一个突出问题。

上图中的绿色是数据量的增加，红色是资源数的增加。流行的网站其首页加载的资源越来越多，在 2015 年的时候已经达到 2.1M 的数据量了，同时更严重的是完成渲染需要 100 多个资源，与 HTTP/1.1 出来时候的互联网环境与其相比，非常吓人，。

在 HTTP 请求时候，一个 TCP 连接上只能同时有一个请求/响应，如果你一次要发送多个请求，那可以建立多个 TCP 连接来实现，但是 主流浏览器只能允许同域下 6~8 个连接。这意味着如果你想同时访问多个连接怎么办，只能等，等最快的那个 HTTP 响应返回，通过 Keep-Alive 的方式继续使用该 TCP socket，而不是再次进行断开，握手的操作。在日益复杂的资源数下，管线化问题就日益突出了。

管线化是什么？看看维基中的图：

这张图很清晰的指出了，管线化可以避免在一个 TCP 连接下需要等待服务端响应，才能继续发送请求的问题。这个技术 HTTP pipelining 将多个请求批量提交，其实在 HTTP/1.1 中已经实现了，但是由于线头阻塞（Head of line blocking）的问题，服务器对浏览器的响应是按照其请求顺序来的，如果前一个响应出现阻塞，后一个请求将不会被处理。这样一来 HTTP pipelining 并没有解决 Head of line blocking 的问题。大部分浏览器也关闭了这项管线化功能。

下图比较全面的概况 HTTP/1.1 中的缺陷：

对于多请求的问题，前端可以采用雪碧图、js 文件合并、图片资源内联 base64，接口合并等等的方式。而后端可以采用分片的形式，简而言之即使既然限制了 6~8 个连接，那就用更多的主机，散列域名，比如微博的：wx1.sinaimg.cn，wx2.sinaimg.cn，wx3.sinaimg.cnwx4.sinaimg.cn。这样简单暴力，可以提升载入速度。

只是对于下面提到的服务端问题，请求/响应头的问题，已经不在 HTTP/1.1 能够处理范围了。

HTTP/2

HTTP/2 相比与 HTTP/1.1 并不会破坏现有的工作，服务器和客户端都必须确定自己是否完整兼容http2或者彻底不兼容。HTTP/2标准于2015年5月以 RFC 7540 正式发表，主要基于 Google 的 SPDY 协议。

先总结一下 HTTP/2 的新特性

1. 二进制分帧
2. 多路复用的流
3. 优先级/依赖性
4. 服务器推送
5. 头部压缩

这样上面就是其主要特性，下面着重介绍一下

二进制分帧

HTTP/2 是二进制协议，而 HTTP/1.1 是文本/ascii的协议，这也是其根本性的不同，是 HTTP/2 性能增强的核心。

该图就很清晰说明了一切，对 HTTP 和 TCP 都没有改动，只是在中间添加了一个层 二进制分帧层。HTTP/1.1 采用换行符作为纯文本的分隔符，而在 HTTP/2 里面则是将所有信息分割为更小单元的消息和帧的形式。用二进制的方式传输，这也是 HTTP/1.1 和 HTTP/2 的根本区别。

在这个二进制分帧层下，我们看看数据的传输是什么样子的：

上面就是数据传输的过程，可以看到数据是由 流（stream） 形成的，在 stream 里面有一个个 消息（message），而 message 里面还有 帧（frame）。在第一条流里面，有两个消息，请求消息和响应消息。响应消息里面又有两帧，分别是 HEADERS 和 DATA 帧，是 HTTP/2 里面最常见的帧。

上文图里面的消息，由与逻辑请求或响应消息对应的完整的一系列帧组成的，但是这些帧却可以不用整整齐齐排在一起，可以和其他的消息的帧交叉分散在一个流里面，从而实现交错分散，交错的帧也不会产生相互的干扰影响。再在服务器/客户端里面组装好。二进制帧的交错发送实现了请求响应的并行，解决了线头阻塞的问题。

这是一个官方的示例，well，在相同的网速下，可以看到左侧 HTTP/1.1 的图片是接近于一排一排的刷出来的，而右侧 HTTP/2 则是 duang 一下就好了。HTTP/2 真是强无敌，还有什么理由不用 HTTP/2 呢。

二进制的帧

下图是 HTTP/2 帧的通用结构：

+-----------------------------------------------+
|                Length (24)                    |
+---------------+---------------+---------------+
|  Type (8)     |  Flags (8)    |
+-+-------------+---------------+-------------------------------+
|R|                Stream Identifier (31)                       |
+=+=============================================================+
|                  Frame Payload (0...)                       ...
+---------------------------------------------------------------+

可以看到一共有 9 个字节，变化的部分是帧负载（payload），其余的 9 个字节是固定的。从上到下分别是

1. 帧长度 Length：24位表示帧负债的长度，默认最大长度是 2^14，当超过此值的时候，将不允许发送，除非收到接收方的长度修改同通知。
2. 帧类型 Type：8位表示帧的类型，HTTP/2 规范定义了 10 种帧，包括：HEADER(0x1)，DATA（0x0），SETTINGS（0x4），CONTINUATION（0x9），PUSH_PROMISE（0x5），PING（0x8），PRIORITY（0x2），WINDOW_UPDATE（0x8），RST_STREAWM（0x3），GOAWAY（0x7）。这里有最常见的 HEADER 和 DATA 帧。
3. 帧标识 Flags：8位表示帧的标识，一个帧可以同时是有多个帧标识。也和发送的帧类型数据有关系。
4. 帧保留位 R：在 HTTP/2 下作为保留字段。
5. 流标识符 Stream Identifier

HTTP/2 允许帧扩展的，毕竟有 8 位长度。

双方可以在逐跳原则（hop-by-hop basis） 基础上协商使用新的帧，但这些帧的状态无法被改变，也不受流控制.

常见的包括 ALTSVC（Alternative Services）：替换服务，服务端建议客户端连接到另外一台服务器，实现负债均衡；BLOCKED：阻塞，用于通知接收方，因为流量控制无法发送数据。

多路复用的流

提到多路复用，有通信领域常见的时分复用，空分复用亦或则是频复用等等，HTTP/2 里面的多路复用，更像是时分复用。

一个 TCP 连接里面可以允许多个流的存在，而流本身是由自己的 31 位的标识符的。客户端创建的流是奇数，服务端创建的流是偶数，

流的多路复用意味着在同一连接中来自各个流的数据包会被混合在一起。就好像两个（或者更多） 独立的“数据列车”被拼凑到了一辆列车上，但它们最终会在终点站被分开。

多路复用的实现是二进制上的。

优先性与依赖性

流的优先级在于告诉对方哪个流更重要，分配多少资源。优先级取决于数据流的权重以及依赖关系。

流与流之间是存在依赖关系的，所有流默认依赖 “根数据流” 0x0，其权重值在 1 至 256 之间的整数。同父级流的同样权重的流具有相同的优先级，而不是由顺序决定。可以看看下图：

HTTP/2 内的数据流依赖关系通过将另一个数据流的唯一标识符作为父项引用进行声明；如果忽略标识符，相应数据流将依赖于“根数据流”

声明的数据流依赖下，首先向父节点分配资源，在向依赖项分配资源，比如先处理 D 的响应，在处理 C 的。而对于上图中右侧的两种情况，当具有相同父级的时候，自然是先处理父级，再处理依赖级，而依赖的的资源分配取决于其权重，如 C 下面的 A/B，其权重分别是 12 : 4，所以 A 将占有 3/4 的资源，而 B 占有剩下的 1/4 的资源。

通过优先级的处理，可以提高浏览器的性能。当然客户端也可以自己随时更新优先级，其可以 通过 HEADERS 帧里面的优先级 priority 属性，也可以通过 PRIORITY 帧来专门设立优先级。

优先级的设立不一定能保证对端的遵守，非强制性需求，well，这也是必要行为，不能阻止服务端处理优先级低的资源。

流控制

流控制可以阻止发送方向接收方发送大量的数据，以免超过后者的需求或者处理能力，而同样的发送方忙碌的时候，可能仅仅能分配出少量资源给到高优先级的请求。

多路复用引入了资源的竞争，流控制可以保证流之间不会严重影响到彼此。流控制通过使用WINDOW_UPDATE帧实现，可作用于单个流以及整个的连接。

流的控制也有自己的原则，这就不阐述了。流使用 WINDOW_UPDATE 帧来做流量控制。接收方有流控制窗口，当流控制窗口允许的时候，可以恢复之前的传输。

流量控制是为解决线头阻塞问题，同时在资源约束情况下保护一些操作顺利进行，针对单个连接，某个流可能被阻塞或处理缓慢，但同时不会影响到其它流上正在传输的数据。

服务器推送

HTTP/2 让服务器可以将响应主动得 “推送” 到客户端，而不是以前简单的 “请求-响应” 模式。一个典型的场景就是当许多个资源的时候，客户端要逐个逐个的检查文档，遇到了才请求，而这个过程是由时间差的，为什么不一开始就让服务端发送所有的数据呢？尤其是一些内联的元素，提前让服务器推送是极好的。

服务器推送可以提前发送常规的资源，当然客户端也可以选择拒绝了，

所有服务器推送数据流都由 PUSH_PROMISE 帧发起，表明了服务器向客户端推送所述资源的意图，并且需要先于请求推送资源的响应数据传输。
使用 HTTP/2，客户端仍然完全掌控服务器推送的使用方式。客户端可以限制并行推送的数据流数量；调整初始的流控制窗口以控制在数据流首次打开时推送的数据量；或完全停用服务器推送。这些优先级在 HTTP/2 连接开始时通过 SETTINGS 帧传输，可能随时更新。

标头压缩

在 HTTP 请求中，当你不断发送类似的请求，比如都是 GET 请求，只有请求地址是不一样的，但是其他的信息，包括 cookie 什么的都是一样的，这个时候客户端还是会重复发送类似的请求头，尤其是一些图片加载。当有数个资源的时候还好，如果数量很多，将会很占用开销，尤其是对 cookie 的反复传输，冗余数据浪费了非常多的宽带。

HTTP/2 使用 HPACK 压缩格式压缩请求和响应标头元数据。其采用了哈夫曼编码表，同时要求请求方和响应方维护同一张见过的标头的索引表。

HPACK 压缩上下文包含一个静态表和一个动态表。静态表指的是常见的 HTTP 标头的列表，包括 method、status 等等，而动态表初始是空的，根据值动态更新。通过采用哈夫曼编码将请求中的部分替换为静态表或动态表中已经存在的索引，从而实现标头压缩。

注：在 HTTP/2 中，请求和响应标头字段的定义保持不变，仅有一些微小的差异：所有标头字段名称均为小写，请求行现在拆分成各个 :method、:scheme、:authority 和 :path 伪标头字段。

协商部署

服务器和客户端如何识别 HTTP/2 ，如何让协议从之前的 HTTP/1.1 升级到 HTTP/2 呢， 难道要通过握手来通知客户端和服务端采用 HTTP/2 的方式？HTTP/2 的前身 SPDY 为了实现协议升级，在 TLS 上添加了 NPN(Next Protocol Negotiation)，就是一个在 TLS 上面的扩展，服务器会通知客户端其所支持的协议，让客户端来选择。

后来在标准化制定时候，NPN 就演变成为 ALPN(Application Layer Protocal Negotiation)。ALPN 中是让客户端提供其所支持的协议类型，让服务端来选择。

这就要求 HTTP/2 是基于 HTTPS 的，也就是 HTTP 2 over HTTPS。那有没有不建立在 HTTPS 的 HTTP 2 呢？有的，但是主流浏览器都不支持的，这里就不做介绍了，看下图就好了。

左图中基于 HTTPS 的 HTTP/2，客户端在和服务端请求之前会在 TLS 中的通信中协商具体用什么协议。看看 wireshark 捕获到的数据：

上图中可以看出本机在与 183.61.14.105 通信前的 TLS 里面，有个 APLN 的插件，插件里面提供了两种协议，第一个是 h2，也就是 HTTP/2 的版本标识符，后面一个是 http/1.1 也就是之前的版本，如果服务端不支持 h2，就采用 http/1.1。在服务度的 Server Hello 里面返回的 ALPN 就只有 h2，所以当前协议就采用 HTTP/2 了。

参考

1. HTTP2 is here, let's optimize! 大神的文章
2. HTTP/2：新的机遇与挑战 大神的总结
3. High Performance Browser Networking 书中自有黄金屋

中后台近几年的发展，已经不满足于简单的手脚架，比如 vue-cli 和 create-react-app，从 ant-design-pro 到 vue-element-admin，提供了各种开箱即用的体验。这些方案可以直接套用，自己需要做的只是写业务代码就可以了，其他的整体架构，包括菜单和权限都帮你搞定了，甚至还有很多很多可以选择的业务模板，一顿微调，一个中后台系统就有模有样了。全套下来比自己从头开始搭质量要高很多，而且至少可以节省一两天开发成本，后期的扩展维护也很方便。

到如今这些开箱即用的解决方案已经显得有些不够用了，中后台的前端，大部分都不需要和移动端一样有严格的 GUI，布局，更多的是日常业务，而这些业务写多了以后，就变成一个个表单，一个个列表，一个个图表，写来写去，给人一种搬砖的感觉，重复劳动，成就感低。

WYSIWYG 为 所见即所得，是 github 上面的一个分类。可以追溯到 dreamweaver，只是后面随着前端的发展没落了。一个可视化的页面搭建工具，毫无疑问是可以解放生产力的，只是为什么以前没有大热门的开源产品出来，实在原因实在太多，可以看看侯老师的 前端服务化——页面搭建工具的死与生。

只是现在不同于以前，前端越来越繁华，虽然还要持续的不断学习新的内容方向，但是前端的三大框架基本定下来，更多的是新特性新版本。于是在中后台基础设施完善下，做了一个中后台系统，再做下个，再做一个，这种重复的问题，不在是大厂才会面临，小厂的前端员工自然也会有同样的困扰，需要解决效率问题。well，大厂一般都有这样的工具，只是看大厂开不开源罢了，比如支付宝的 金蝉/凤蝶，代替传统前端开发模式的一站式研发系统，都可以让非前端人员开发了，只是是要收费的好像，虽然金禅说是今年会开源，只是没有排期都是骗人的。

自己在写业务的时候也有这样的困扰，重复的组件，能提用公共的逻辑都抽离出来了，但是组件上实在是每个组件都需要定制，需要自由度非常高。于是开始探索有没有可以提高生产力的工具。

飞冰 ice

飞冰从去年就开始开源了，结合 umi.js，ant-design 和 ant-design-pro，基本上 react 的中后台开发有这一套就很棒了，加上自己的设计，按照同事的说法，是一套闭环的生态。

飞冰最大的特点，在于其海量的物料，以及杀手锏般的桌面工具，开发体验是非常友好的，没有什么复杂的操作，想要什么物料，在 iceworks 上面点一点就能安装好了，自己只要修改一些字段，再增加对应的交互和接口调试，就差不多了。飞冰提供的物料是以区块来的，而不是组件级别，而且基本布局是从上到下，按照选择的区块顺序生成页面。对比传统的开发模式，可以归纳为飞冰给你提供了更多可以复制粘贴的代码，而且质量还不低。

使用一阵之后，觉得其离高度自由化，还是差了点，解决了部分开发效率问题，但是区块级别依旧有点粗糙，缺少组件以及拖拽布局，美中不足。可视化的编辑区域至今也是规划。

iceworks 这样客户端的体验还是非常友好的。

百度 AMis

百度的 AMis 其实很早前就有踪迹了，在 吴多益 的描述里面 前端服务化-通向零成本开发之路，就提到 AMis 作为中后台解决方案。然而时隔多年，终于开源了。大厂的好处还是显而易见的，至少这种基础建设的水平要领先外面一到两年。这次 QCON 大会上 AMis 又再次露脸。

AMis 采用的是特定格式的 JSON 配置，这个特定的格式，指的是其自身 baidu 的一套 JSON Schema，这一套 JSON Schema 用的不同于 社区 的 JSON Schema，估计是结合自身的业务定制的，毕竟 16年就有 AMis，那会社会可能都还没有成熟。其自身的 schema 为： "$schema": "https://houtai.baidu.com/v2/schemas/page.json#" 的格式；

看 QCON 上面的介绍的 ppt 是挺好的，只是一看仓库文档，好像资料有点少，关于这个特定的 JSON 配置，在 github 里面是有明细的文档的，只是感觉构建的文档站点有点不好用，示例看不了代码，下面的教程文档倒是挺充足，只是更多的是 api 和一些字段的定义，没有教人怎么去用，而且整体的组件风格偏 bootstrap，和 antd 的设计相比，觉得差了不少。

关键是这个 AMis 只是开源了其 JSON 配置部分，渲染器的部分，其他的可视化编辑器没有开源出来，这样前端写 JSON 开发真的好吗？诚然 AMis 设计理念是很棒的，抽象出 UI 组件的逻辑，形成 JSON 的形式，减少前端的冗余开发，提高生产力，只是前端居然要写 JSON，路走歪了。所以其 可视化编辑生成页面 开源就好了，可惜还没有排期的消息，而且开源的 AMis 总觉得有点赶工的嫌疑，还是先不用，免得进坑。

react page

这个所见即所得工具使用起来体验是很好的，只是其更多的是面向用户的产品，而不是面向工程师的产品，其支持的组件需要自己提供，也就是可以用 antd 的那一套加一个中间层就可以用上了。生成的 editorState 对象也可以实现根部注入的方式，实现后端数据动态渲染。只能给用户画画原型什么的而已，其对前端的生产帮助少之又少。

阿里 UForm

看了一圈其他开源产品页面搭建工具优秀的少之又少，最后看到这个 UForm 是表单解决方案，似乎和前面提到的都不是一个东西，前面是通过页面编辑可视化，来提高效率，而这只是个 react 的表单解决方案。

这个 UForm 和百度的 AMis 其实是有点类似的，都可以通过特定的 JSON 规范来配置生成代码，只是 UForm 是专门针对表单的，而 AMis 是通用。 UForm 采用的 JSON Schema 是和社区保持一致，同时和 Mozilla 的 react-jsonschema-form 有点类型，在社会的 JSON Schema 之上增加了 UI 组件相关的信息。另外其字段状态分布式管理和 React EVA 的方式很大程度的提高 form 表单的性能和可维护性。对于 JSON Schema，UForm 采用了自己的 JSchema 描述语言，不再是单纯的写 JSON，可以通过 Field 等组件来描述，避免前端写 JSON 的尴尬情况。可以看出其整体的设计理念很赞。

并且其可视化编辑工具，说是要在端午后开源，表示万分期待。如果真是如此，那就可以进一步实现动态化了，用可视化编辑工具生成想要的 JSON 数据，最后通过后端返回数据注入到根组件，直接回显就可以了。前端要专注的只是 form 表单的交互和接口的调试，以及测试部分。感兴趣可以看看其介绍 UForm表单解决方案

百度 RCRE

这个是最近出现的中台后系统的解决方案，结合了状态（mobox和reduce）、表单和接口请求，解决复杂的组件联动带来的问题。给的 文档里面，看起来挺香的，只是对应的使用说明和知乎上面写的实在有点看不出所以然，最后还是有 demo 什么的吧。或许这就是百度的风格？

总结

期待百度系列 AMis 和 RCRE 接下来的表现，尤其是前者，在百度内部应该是非常成熟的方案了，可惜不够开源。目前能看得着，能使用的上的，就是阿里的 UForm 了，期待其可视化编辑器。然而最后基于业务的原因还是用上了 react-page 先，等 UForm 完善了再看。

前言

前文分析了Vue-router，感觉后劲十足，于是开始分析Vuex。在项目上，Vuex也是常客。它可以很好的管理状态，尤其是跨组件的时候，Vue的单向数据流使得子组件无法修改prop，经常用$emit和$on的话组件是要多难看就多难看。当组件切换，数据需要缓存总不能一直依赖于向上级组件emit传递数据吧？如果要更好的管理状态，Vuex是个很好的选择。Vuex代码量较Vue-router少了很多，而且也没有flow的校验机制，看起来更加习惯了。这里介绍的Vuex版本号为2.4.1。

从示例开始

Vue.use(Vuex)
const state = {
  count: 0
}

const mutations = {
  increment (state) {
    state.count++
  },
  decrement (state) {
    state.count--
  }
}

const actions = {
  increment: ({ commit }) => commit('increment'),
  decrement: ({ commit }) => commit('decrement'),
}
// getters are functions
const getters = {
  evenOrOdd: state => state.count % 2 === 0 ? 'even' : 'odd'
}
export default new Vuex.Store({
  state,
  getters,
  actions,
  mutations,
})

上面示例基本上包含了最常用的mutations，getters和actions了。可以发现这一切从Vue.use(Vuex)开始的，对Vue.use不熟悉的可以看上一篇的Vuex-router中对Vue.use的介绍。
Vuex中用到了install方法来提供Vuex的使用环境。和Vue-router不同，Vuex的主要代码功能都在store.js文件里面(这对查阅代码友好度明显提到了不少)。install过程里面用到了Vue.mixin，并用到了beforeCreate钩子，使得Vue实例化和组件加载的时候都可以调用到钩子。设计如下：

const version = Number(Vue.version.split('.')[0])
if (version >= 2) {
  Vue.mixin({ beforeCreate: vuexInit })
} else {
  const _init = Vue.prototype._init
  Vue.prototype._init = function (options = {}) {
    options.init = options.init
      ? [vuexInit].concat(options.init)
      : vuexInit
    _init.call(this, options)
  }
}

function vuexInit () {
  const options = this.$options
  // store injection
  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
  }
}

可以看到这里对Vue的版本分别做了处理，本版是2.0.0及以上的都会采用Vue.mixin的方法，而低版本的，则将修改Vue的内部_init方法，来添加$store至根。高级别的版本则采用mixin的方法，同样也是添加this.$store。在Vue-router里面是采用数据劫持的方法，来通知更新，顺便提供this.$router，对于状态管理而言，数据劫持显然是不需要的，仅仅提供入口this.$store就够了，这样为全局提供了访问store对象的方法，可以轻松得使用this.$store.commit, this.$store.state之类的方法。

Store

Store.js里面最主要的就是Store类，这个也是之前提到的this.$store对象。先看看constructor方法：
在构造里面先判断有无使用install方法，没有则intall一下，接着是断言有无安装Vue，是否支持Promise和是否是通过new创建Store的实例。另外在install过程里面还有是否重复安装Vuex的断言，这个场景会发生在已经先使用Vuex了，但是没有用Vue.use(Vuex)来显式安装Vuex，如果再加上Vue.use(Vuex)就会有这样的提示，尤其是在开发环境和生产环境配置中。
Store初始化过程，有this._modules = new ModuleCollection(options)，这个_modules就是Store集合的意思了。Vuex有modules的概念，允许对store进行分割形成不同的模块，每个模块都可以有自己的state，getter，mutation和action，甚至还可以嵌套子模块。于是将这些模块包括根模块一起放入modules里面。this._modules的一个重要api就是注册添加一个模块：

register (path, rawModule, runtime = true) {
  if (process.env.NODE_ENV !== 'production') {
    assertRawModule(path, rawModule)
  }

  const newModule = new Module(rawModule, runtime)
  if (path.length === 0) {
    this.root = newModule
  } else {
    const parent = this.get(path.slice(0, -1))
    parent.addChild(path[path.length - 1], newModule)
  }

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

这里还可以看到this._modules.root就是根模块，并且对于子模块的，还会被添加到父模块parent的_children对象里面；到这里可以发现this.modules.root和原先的store很像，只是单独分离出state，并且将子模块改为了_children关系，并将_rawMoudule赋值为整个传过来模块，同时为this._modules和每个module都添加不少方法，这些方法自然是为后面做准备的。
在谈commit和dispatch方法之前，先看看后面的模块安装和StoreVM的设置

installModule(this, state, [], this._modules.root)
resetStoreVM(this, state)

function installModule (store, rootState, path, module, hot) {
  const isRoot = !path.length
  const namespace = store._modules.getNamespace(path)
  // 命名空间字典的添加
  if (module.namespaced) {
    store._modulesNamespaceMap[namespace] = module
  }
  // 设置state
  if (!isRoot && !hot) {
    const parentState = getNestedState(rootState, path.slice(0, -1))
    const moduleName = path[path.length - 1]
    store._withCommit(() => {
      Vue.set(parentState, moduleName, module.state)
    })
  }
  const local = module.context = makeLocalContext(store, namespace, path)
  module.forEachMutation((mutation, key) => {
    const namespacedType = namespace + key
    registerMutation(store, namespacedType, mutation, local)
  })
  // 下面省略部分是通过module提供的方法分别对action和getter进行registe
  // 以及对子模块modules的遍历式得注册mutation/action/getter

  // ...
}

对于modules而言，官方文档有介绍到，模块内部的 action，mutation和getter是注册在全局命名空间的，如果想要独立的空间，比如有命名重复的情况下，可以使用namespaced: true来注册单独的空间；同时访问的时候也也要加上模块的名字，否则否则无法定位到。
接着看state的设置，对于if条件语句，若是子模块并且非hot，会获取子模块的亲父级模块，并通过Vue.set方法将该子模块的state添加到亲父模块state里面，这是响应式的，会被Vue劫持到。后面部分就是对action/getter/mutation的注册添加了，这部分后面在讲。

后面是resetStoreVM：

function resetStoreVM (store, state, hot) {
  const oldVm = store._vm
  // bind store public getters
  store.getters = {}
  const wrappedGetters = store._wrappedGetters
  const computed = {}
  forEachValue(wrappedGetters, (fn, key) => {
    // use computed to leverage its lazy-caching mechanism
    computed[key] = () => fn(store)
    Object.defineProperty(store.getters, key, {
      get: () => store._vm[key],
      enumerable: true // for local getters
    })
  })
  const silent = Vue.config.silent
  Vue.config.silent = true
  store._vm = new Vue({
    data: {
      $$state: state
    },
    computed
  })
  Vue.config.silent = silent
  // enable strict mode for new vm
  if (store.strict) {
    enableStrictMode(store)
  }
  // 如果存在oldVM对其进行销毁
  // ... 
}

刚看到这里时候可能会惊奇何时来的_vm？事实上这个_vm正是这里的核心，_vm是个Vue实例，并将_vm.data.$$state指向的option中的state。细心的话还可以发现在Store类中，其中的Store.state：如下

get state () {
  return this._vm._data.$$state
}

state返回的正是_vm.data.$$state，这个也就是平时所用的this.$store.state。观察resetStoreVM还可以发现通过遍历wrappedGetters，来将wrappedGetters中的方法通过_vm.computed的形式添加到store.getters里面，这么复杂的办法有什么好处呢？而且为什么只是专门处理getter，没有对mutation和action进行这样的处理？getter的方法是对state进行处理提取过滤，而computed是依赖于data的，当data更新的时候computed就自动计算，同样这里也是的，当state更新的时候，通过computed的方法，getter不就自动计算更新了吗？只是这样就有点麻烦。。。。。要新建一个Vue实例，关于_vm，更多的可以点这里

commit和dispatch

在介绍之前先看看前面忽略的，在installModule方法里面对mutation/getter/action等方法的添加机制。
对于registerMutation：

function registerMutation (store, type, handler, local) {
  // 内部的_mutations[type]保存对应的mutattion方法
  const entry = store._mutations[type] || (store._mutations[type] = [])
  entry.push(function wrappedMutationHandler (payload) {
    // 在mutation方法里面传入local.state和payload，
    // wrappedMutationHandler只需要payload，符合commit时，仅需传入type和payload
    handler.call(store, local.state, payload)
  })
}

上面方法添加了store._mutations[type]，而handler传参里面的local.state又是什么呢？回头看可以发现这里调用了makeLocalContext，生产local变量，makeLocalContext代码这里就不贴出来了。local.state就是对应path的state变量，只是是通过数据劫持的方法获得的，代码中说明getters和state对象都必须要懒加载，因为可能被vm更新影响到，这里是不是指_vm重新创建的时候造成的影响呢？由于namespaced的问题，local里面的dispatch和commit都做了特别处理，但是还是使用store的dispatch和commit的方法，只是传参做了修改。
对于registerAction，类似与mutation，采用了store._actions[type]来保存handler数组，但由于action有用于异步的情况，所以若返回的action不是Promise类型，则进行Promise包装。同时action的传参不是local.state，而是传入local的本身的所有字段和store的getters以及state，这也符合action的基本应用。
对于registerGetter，这里比较简单直接采用store._wrappedGetters[type] = handler的形式，而registerMutation是采用数组的形式。所以对于重复名字的getter就会有告警``[vuex] duplicate getter key: ${type}`。

回到commit方法和dispatch，在Store类构造的时候，有如下:

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)
}

这里面定义commit方法和dispatch方法，这两个就是$store.commit和$store.dispatch，而commit这个方法处理起来也是比较简单，就是将_mutations里面对应方法名都执行一遍，并传递payload进去。同时还将_subscribers里面的函数都遍历执行。_subscribers是通过subscribe这个api添加进来:

subscribe (fn) {
  const subs = this._subscribers
  if (subs.indexOf(fn) < 0) {
    subs.push(fn)
  }
  return () => {
    const i = subs.indexOf(fn)
    if (i > -1) {
      subs.splice(i, 1)
    }
  }
}

该方法可以添加订阅函数，每当mutation执行的时候，所有订阅函数都会执行，值得一提的时候在devtool.js文件里面用到了:

store.subscribe((mutation, state) => {
  devtoolHook.emit('vuex:mutation', mutation, state)
})

当使用devtoolHook的时候(这个也涉及到Vue官方推荐的浏览器插件工具Vue devtools)能在每个mutation动作结束后，触发vuex:mutation事件，并在devtools插件内打印动作
还可以看出这个subscribe设计很巧妙，subscribe直接运行是添加订阅函数，而其返回函数就是disSubscribe，就是将订阅函数去除掉，由于不常用，所以就没有直接给出api了，厉害的很。

dispatch该动作类似的，也是调用之前存在_actions里的handlers，只是由于handles可能有多个，并且是异步的原因，若是多个的话需要用Promise.all来执行；

其他Api

日常用的比较多的是registerModule/unregisterModule，两个过程是类似的，注册新模块的时候需要重新installModule和resetStoreVM，这个时候就会将老的_vm delete掉，重新实例化Vue给到_vm。
mapState/mapMutations/mapGetters/mapActions等api结构类似。以mapState为例子:

export const mapState = normalizeNamespace((namespace, states) => {
  const res = {}
  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
      }
      return typeof val === 'function'
        ? val.call(this, state, getters)
        : state[val]
    }
    // mark vuex getter for devtools
    res[key].vuex = true
  })
  return res
})

normalizeNamespace来调整参数，再通过normalizeMap将传入的state调整为{ key, val: key }结构，并根据情况返回。这几个api还是很容易懂的。

结束

一周下来写了两篇源码分析，Vuex的代码和Vue-router相比还是很良心的，没有Vue-router里面那么多弯弯绕绕，Vuex简单明了多了。

void 0

最近在backbone的源码(两年前就研究过underscore的源码，现在才看backbone是不是有点那个)，发现里面用到了void 0，这是什么鬼？void居然出现在JavaScript里面，敢情以前用的ES是假的....这么基础的东西，瞟一眼MDN文档，还果然有:

void: 运算符 对给定的表达式进行求值，然后返回 undefined。

So, void 0就是返回undefined了，这不是多此一举？直接用undefined来判断，不就完事了，何必用上void 0，这种云里雾里的操作？
原来在早期的ECMAscript里面，undefined不是关键字，也就是说undefined是可以被修改的，如

var undefined = 1;

这样再用undefined判断某个变量，是不是就懵逼了？而void却是关键字，从这个角度出发void 0很有使用的必要，幸好从ES5开始(IE8+)就只把undefined当作一个全局只读的值，不能进行修改，修改了当然就报错咯。
在backbone的issue里面也有人提到了void 0的问题，里面提到了void 0的运算速度比undefined更优，只是我在IE9+以上还有chrome上面测得的值都是十分接近的，所以性能不是需要关注，后面还提到void 0的字符要比undefined少，这好处之一，也是为什么我们不用void 1000, void 'hellow world'而是用void 0 的原因，这对主流大型框架还是很有意义的。只是普通的工程就木有必要了

let，const和var

上周在chrome的控制台里面无意写了let a = sd，sd是没有声明的变量，所以回车后马上报错，而后面我再次声明let a的时候，又报错显示a已经声明了，于是我再直接在控制台敲 a 回车，结果报错显示a没有声明，这是在赤裸裸的耍我吗？问同事也是一脸懵逼+神奇的样子，后来也就没有管了，毕竟用没有声明过带的变量赋值给其他变量本来就是有问题的，更不要提后面的情况了。
故事应该到这里就截止了，可是昨天，同事给我发了个链接，这是何其相似，这个实用性不大的问题上，居然还有人花了了两个月的时间，蛋疼的很。于是打开方应杭的介绍(链接在上面自己找)，发现里面的重点在于 Rick Waldron的一段话：

In JavaScript, all binding declarations are instantiated when control flow enters the scope in which they appear. Legacy var and function declarations allow access to those bindings before the actual declaration, with a "value" of undefined. That legacy behavior is known as "hoisting". let and const binding declarations are also instantiated when control flow enters the scope in which they appear, with access prevented until the actual declaration is reached; this is called the Temporal Dead Zone. The TDZ exists to prevent the sort of bugs that legacy hoisting can create.

var的使用存在变量提升，而let/const是不存在变量提升的，控制语句到let/const时，声明会被实例化(instantiated )，但是在执行前禁止访问，不像var和function会先是被赋予undefined，后者称为变量提升，而前者变量提升却是不一样的，也由此生成了死区，就是变量必须在let声明语句后使用；这点其实在阮一峰老师的ECMAscript 6已经介绍到了，只是没有提及死区形成原因；
回顾前文提到的问题就很简单了，对于let a = sd a变量会在语句执行前实例化，而执行let a = sd的时候，自然报错，同时由于a已经实例化了，不能再次 let a(还得看是什么浏览器。。。。。。)，并且由于a 初始化失败，而在实例化后到初始化这段过程里面，a处于死区中，是无法访问的(acess prevented)，所以不能对a有其他操作。
下文在引用ECMAscript的一段话:

The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable's LexicalBinding is evaluated.
A variable defined by a LexicalBinding with an Initializer is assigned the value of its Initializer's AssignmentExpression when the LexicalBinding is evaluated, not when the variable is created

前言

一直想知道Node.js是如何作为一个用js语言写的后端平台。这个设定很是奇怪，前端开始涉足后端了？刚开始用api实现通信的时候，蛮简单的，框架都不用到，简单几句就能实现通信，于是借此机会研究一下Node.js的通信。

从net模块出发

看一个简单的例子

require('http').createServer((req, res) => {
    res.end('hello world');
}).listen(8181);

这里用的是http模块通信，也就是我们最常用的部分，看官方文档可以发知道其返回一个http.Server实例，而该实例又继承与net.Server，net.Server的描述是用于创建TCP或者本地服务器，这不正是我们想要的吗？
通过上面例子不难发现，我们主要用到的api的接口是createServer和listen，而首先的是net.Server实例。

// net.js中
function createServer(options, connectionListener) {
  return new Server(options, connectionListener);
}
function Server(options, connectionListener) {
  ...
  EventEmitter.call(this);
  ...
    if (typeof connectionListener === 'function') {
      this.on('connection', connectionListener);
    }
  this._connections = 0;
  ...
  this[async_id_symbol] = -1;
  this._handle = null;
  this._usingWorkers = false;
  this._workers = [];
  this._unref = false;

  this.allowHalfOpen = options.allowHalfOpen || false;
  this.pauseOnConnect = !!options.pauseOnConnect;
}
util.inherits(Server, EventEmitter);

这里可以发现Server实例继承EventEmitter，就像Backbone里面的model等继承Events一样，监听connection事件，并初始化this，net.createServer也是返回Server实例，看来Server很重要。再看看listen

Server.prototype.listen = function(...args) {
  ...
  if (hasCallback) {
    this.once('listening', cb);
  }
  ...
  var backlog;
  if (typeof options.port === 'number' || typeof options.port === 'string') {
    ...
      // 对于listen(port, cb)的情况
      listenInCluster(this, null, options.port | 0, 4,
                      backlog, undefined, options.exclusive);
    return this;
  }
  ...
};
function listenInCluster(server, address, port, addressType,
                         backlog, fd, exclusive) {
  ...
  if (cluster.isMaster || exclusive) {
    server._listen2(address, port, addressType, backlog, fd);
    return; 
  }

  const serverQuery = {
  ...
  };
  ...
  cluster._getServer(server, serverQuery, listenOnMasterHandle);
  function listenOnMasterHandle(err, handle) {
    ...
    server._handle = handle;
    server._listen2(address, port, addressType, backlog, fd);
  }
}
Server.prototype._listen2 = setupListenHandle;  // legacy alias

上面listen方法中有不同的场景判断，上面代码仅仅列出开发中常用的listen(port， cb)的方法。 结合Node.js的document里面的server.listen方法和这里的源码，发现document里面的介绍不就是源码里面的实现吗。。。。listenInCluster方法中通过cluster.isMaster来判断是否是主线程，如果是直接server._listen2，不是的话，还要进行cluster._getServer
而setupListenHandle方法

function setupListenHandle(address, port, addressType, backlog, fd) {
  ...
    var rval = null;
  ...
      rval = createServerHandle(address, port, addressType, fd);
  ...
    this._handle = rval;
  }
  this[async_id_symbol] = getNewAsyncId(this._handle);
  this._handle.onconnection = onconnection;
  this._handle.owner = this;
  var err = this._handle.listen(backlog || 511);
  ...
  nextTick(this[async_id_symbol], emitListeningNT, this);
}
function createServerHandle(address, port, addressType, fd) {
  ...
    handle = new TCP();
    isTCP = true;

  if (address || port || isTCP) {
    ...
    if (!address) {
      err = handle.bind6('::', port);
      ...
    } else if (addressType === 6) {
      err = handle.bind6(address, port);
    } else {
      err = handle.bind(address, port);
    }
  }
  ...
  return handle;
}

上面的setupListenHandle经过简化，不难发现最后落脚点在this._handle = new TCP()，而TCP：const TCP = process.binding('tcp_wrap').TCP，this._handle 正是server._handle，在初始化Server实例时候所建立的，process.binding是用来连接Node.js的内建模块，这里要看tcp_wrap.cc文件

tcp_wrap.cc文件开始的C++和C语言

tcp_wrap.cc文件里面有这里几个方法,

TCPWrap::TCPWrap(Environment* env, Local<Object> object)
    : ConnectionWrap(env,
                     object,
                     AsyncWrap::PROVIDER_TCPWRAP) {
  int r = uv_tcp_init(env->event_loop(), &handle_);
  CHECK_EQ(r, 0);  // How do we proxy this error up to javascript?
                   // Suggestion: uv_tcp_init() returns void.
  UpdateWriteQueueSize();
}
void TCPWrap::Listen(const FunctionCallbackInfo<Value>& args) {
  TCPWrap* wrap;
  ASSIGN_OR_RETURN_UNWRAP(&wrap,
                          args.Holder(),
                          args.GetReturnValue().Set(UV_EBADF));
  int backlog = args[0]->Int32Value();
  int err = uv_listen(reinterpret_cast<uv_stream_t*>(&wrap->handle_),
                      backlog,
                      OnConnection);
  args.GetReturnValue().Set(err);
}

TCPWrap方法里面调用了tcp.c里面的方法，建立TCP的句柄，函数形参包括uv_loop_t，uv_tcp_t和flags标识，接着对uv_tcp_t结构体中的各项进行初始设置，并调用uv__handle_init循环；
为什么要提及listen方法？在net.js的setupListenHandle方法里面明确用到了this._handle.listen(backlog || 511)，在stream.c里面的uv_listen方法来监听，根据uv_stream_t结构体的type来判断是否是TCP类型，在tcp.c，uv_tcp_listen中通过uv_tcp_t结构体的flags来判断执行；

在uv.h里面定义了上面的结构体，每个结构体都有自己的成员。刚开始接触的时候，看到这里么就有种越看越乱，越看越多的感觉，这个时候开始知道有libuv；

libuv为何物

简单来讲就是跨平台io库，整合了window下的iocp和Linux的epoll，官网上有下图

在node_maic.cc里面调用了start方法，加载bootstrap_node.js文件，并同时while循环调用uv_run()，uv_run就是libuv事件循环的入口，这个方法的执行如下图

其中每一个模块和uv_run中的语句是对应，其中在window里面用(*poll)(loop, timeout)，而unix采用uv__io_poll(loop, timeout)。
上文提到的结构体uv_xx_s/t正是libuv的观察者，其中对应的类型uv_TYPE_t中的type指定了handle的使用目的。 至于具体的机理还是看官方文档好。
看过了文档以及api之后，再去看Node.js里面代码，well， 还是一脸懵逼。。。。

只有硬啃下来，发现就是观察体太过长了，一遍一遍的嵌套宏定义，只是到最后还是没有完全读懂libuv如何实现通信，或许以后有下一篇来阐述libuv吧

参考资料

1. node源码详解（六） —— 从server.listen 到事件循环
2. uvbook 中文教程
3. 初步研究node中的网络通信模块
4. 《深入理解Node.js：核心**与源码分析》

前言

每次用Vue-cli的时候，都会觉得配置的nodejs服务器很是让人省心，几个项目下来，都只用关心工程前端部分，用久了便想探其究竟。后来才发现原理用了express框架，代码也挺简单的，但是里面用的一个中间件webpack-dev-middleware，刚开始看的时候却不知有何用处？既然是express框架，又用的是SPA，路由不需要express来分发，那webpack-dev-middleware有何用处？抱着这样的疑问，看源码去吧

思路

一般express中间件的结构如下：

App.use((req, res, next) => {
  if (nextNeeded) {
    // 根据不同的请求处理，并传递到下一个next()，形成处理流
    next();
  } else { 
    // 根据不同的请求处理
  }
});

而webpackDevMiddleware也大体如此，只是返回一个Promise对象
在webpackDevMiddleware中的返回Promise前，有这两句：

var filename = getFilenameFromUrl(context.options.publicPath, context.compiler, req.url);
if(filename === false) return goNext();

getFilenameFromUrl这个名字就可以知道这是个返回匹配url路径文件名字，若不存在这个filename则goNext，而goNext里面若在webpackDevMiddleware中没有配置serverSideRender这个选项，则next进入下一个中间件。getFilenameFromUrl这个看源码就知道了，那问题的关键在于返回的Promise如何才能满足webpage开发和express框架？
Promisel里面的try出现了下面一句：

res.statusCode = res.statusCode || 200;
if(res.send) res.send(content);
else res.end(content);
resolve();

咦？这不就是最普通不过的res.send/end方法吗？那为何要大费周章的写个Promise呢？
用的确实是send和end方法，但是里面的content，却大有文章，一般用response返回的时候，直接返回本地文件就好了，用webpack的时候，部分文件却是自动生成的内存文件如index.html, app.js之类的，这些文件是不能直接本地读取并获得的。在processRequest里面的try里面有如下:

var stat = context.fs.statSync(filename);

这个context.fs是在Share.js里面的生成的

fs = compiler.outputFileSystem = new MemoryFileSystem();

MemoryFileSystem用的是memory-fs npm模块，这个模块就是一个内存文件模块，而这里用到的statSync方法，则是返回一个是否是文件/目录的对象，若都不是就抛出MemoryFileSystemError，所以思路就清楚了，当不存在内存文件的时候，如直接在html里面引用到的文件js/css/picture，就直接抛出Error，进入goNext，从而进入下一个中间件。若不抛出Error，则在try外部通过 context.fs.readFileSync(filename) 读取内存文件，如webpack生成的内存文件app.js等，从而选择性发送content。
至于剩下的响应头设置和webpackDevMiddleware的其他方法，聪明的你，自己挖掘吧

疑问

在返回的Promise里面，先是进行了shared.handleRequest，这里面会有若filename是文件才进行processRequest，而在processRequest的try里面，若filename不是文件，是路径才进行里面的改写filename，这样的逻辑设计是为何？是文件，又不是文件的，如何进入里面呢？

前言

ESnext 里面提到的修饰器，在 redux 的推广下，几乎每个工程师都有或多或少的用过，最常见的就是 @connect 的形式，而在 Java 领域同样也存在 @ 这种符号的存在，被称之为注解，而巧的是修饰器同样能实现注解的功能。在看 Java 的注解的时候必然会看到反射这个概念。在阅读下面之前请先看阮老师的文档修饰器，再看下文。

Babel 开发环境须知

修饰器 Decorator 是 ES7 里面提出的，在 babel 6 里面需要引入 preset-stage-2，并在 .babelrc 中配置 "presets": ["env", "stage-2"]。到了 babel 7.0.0-beta.54 之前，则是需要 npm 包 @babel/preset-stage-2，配置 .babelrc 为 ["@babel/preset-stage-2", { "decoratorsLegacy": true }]，默认是关闭的。而 babel 7.0.0-beta.54 之后的版本里面，已经 弃用 Stage Preset ，所以后面需要安装的版本是 @babel/plugin-proposal-decorators 配置为 ["@babel/plugin-proposal-decorators", { "legacy": true }]，这样可以达到以前的效果，具体看官方介绍，以及@babel/plugin-proposal-decorators。目前 babel 7.1.0 已经发布了TC39 Standards Track Decorators in Babel。

java 中的注解和反射

在 Java 里面注解是元数据，相当于是提供元素的配置信息，也就是额外的数据，比如最常见的 @Override @RequestMapping 这些。而在 ES 里面修饰器则更强大的多，是对类进行处理封装的改变，也可以不使用 @ 符号进行描述，但是这样就失去其便捷性、直观性了。ESnext 中关于 Decorator 的提案中提到修饰器不仅仅是可以用来修饰类，更包括了字段、getter、setter 和 方法。

先来看看 Java 中的注解是什么用法：

public class MyClass {
  ...
  @Test public void getName()
}

通过 Test 注解，来添加额外的信息，本身是没有什么作用的，需要工具支持才可以用，而这个工具就是反射了。反射有什么作用呢？反射可以在运行时获得程序或程序集中每一个类型的成员和成员的信息 。如果结合上注解，那就是 可以在运行时通过反射的方式取出方法的注解 ，从而实现额外的功能。反射里面主要用到下面四个类：

1. java.lang.Class 类对象；
2. java.lang.reflect.Constructor 构造器对象 有 public Constructor[] getConstructors() 方式；
3. java.lang.reflect.Method 方法对象，有 public Method[] getMethods() 等；
4. java.lang.reflect.Field 属性对象，有 public Field[] getFields() 等；

可以看看下面示例了解一下反射：

for (Method m : obj.getClass().getMethods()) {
  Test t = m.getAnnotation(Test.class);
  if (t != null) {
    // 对符合要求的 m 做处理
  }
}

反射的存在使得注解变得灵动起来。注解除了是 JDK 或者 Spring 里面提供的外，还可以自己定义注解，形如下面的 @Override 注解：

@Target({ElementType.METHOD})
@Retention(RetentionPolicy.SOURCE)
public @interface Override {
}

ES 中的修饰器

ES 中对类的修饰器，更像是给类加个包装，对这个类进行操作。这里可以看看 react-redux 里面的 connect 的实现：

function connectAdvanced() {
  return function wrapWithConnect(WrappedComponent) {
    // ...
    class Connect extends Component {
      // ...
      render() {
        if (this.state.error) {
          throw this.state.error
        } else {
          return createElement(WrappedComponent, this.addExtraProps(this.state.props))
        }  
      }
    }
    // ...
    return hoistStatics(Connect, WrappedComponent)
  }
}

// 使用方式
@connect(state => ({
  global: state.global
}))
class WrappedComponent extends PureComponent {}

如上所示的，通过 @connect，对 WrappedComponent 修饰，在 Connect 中实现一套更新 store 的逻辑，最后通过 setState 来触发，使得传入 WrappedComponent 的 props 发生更新，并注入 dispath 等等方法，最后达到传递状态的作用。
而上面的这一切的功能只要用一个 @connect 就可以办到，和 Java 的注解不同，这里不需要反射来实现其功能。

对类/方法修饰还可以看看方正大神的(egg-blueprint)[https://github.com/Foveluy/egg-blueprint/blob/master/lib/index.js]，是一个 egg.js 为插件，采用修饰器的方式，实现了类似于 Spring 中 @RequestMapping 的方式。

对于一些 java 中常见的注解，如 @override @readonly 等等，在 ES 里面也有同样的实现！比如常用的 core-decorators 和 lodash-decorators 库。

比如 @readonly 的实现：

function readonly(target, name, descriptor){
  descriptor.writable = false;
  return descriptor;
}

如果说对类的修饰是外在包装一层，那么对方法的修饰，由于 descriptor 的存在，则更像是修饰器。方法的修饰里面传入的参数中，包含了 descriptor 描述对象。这个在 Object.defineProperty 中应该是再熟悉不过的了。通过 descriptor 可以实现非常多的功能。

对于类的属性同样也能采用修饰器的方式，类似于方法，但是其 descriptor 属性描述符里面只能用 initializer 来替代之前的 value。

另外 ESnext 里面也可以通过 # 来定义私有变量，就如同 java 的修饰符 private。

只是对于私有方法和私有变量而言，其 descriptor 属性描述符里面 writable enumerable configurable 均为 false，同样的私有变量的描述对象只能用 initializer 来替代的 value。其他静态方法/变量等可以看看文档。

总结

由于对 java 的理解尚浅，本文也是做个简单的对比。ES 中的修饰器随着新特性的出现，也会被更多人所使用。

前言

本来想着学习路径是从 react 周围生态开始的，比如之前的 preact，react-router，再到后面 immutable.js，读懂这些源码，接着可以看 dva，rematch，亦或则是 redux，甚至是 ant-design 都可以看看的，到了最后再吃大餐，react 源码。只是不知道为什么想要挑战一下自己，不想这么循循渐进。想要试试自己的实力。于是便有了这次的 react 源码的阅读。

刚开始读的时候觉得看 react 源码是一种享受，就像在读一本小说一样，惊险刺激，停不下来。只是后面到了 fiber 的阶段，就有点懵逼了，这绝对是烧脑侦探片，而我是里面的路人甲，看几行代码都觉得费劲。这个时候遇到了如何阅读大型前端开源项目的源码，文章写得极好，根据上面的内容开始去看 react 文档里面的 Contribution Guide 里面的指导，随后又读了读 Blog 部分，简直是 amazing，尤其是Beyond React 16 by Dan Abramov，以及A Cartoon Intro to Fiber 。看得内心澎湃，觉得为何自己不能早点入坑呢？随后有看了正妹，以及方大神的介绍，顿时有了不少底气。

学习方式

想要完整的学习，于是最简单的从 ReactDom.render 开始一步一步往下走，后面遇到看不懂的地方，则开始用 debug 的方式，打断点看代码。按照 Contribution 里面的意思，先安装包，然后构建项目，生成对应的 core、dome 文件。这里需要注意的是，构建 React 项目居然要安装 Java，而且只能用 yarn，嗯，还是自己家的东西好是吧。构建好文件后，复制并打开fixtures/packaging/babel-standalone/dev.htm 文件，就可以是愉快的调试了（后期看代码看的心烦都是靠 debug 走下来的）。由于还有很多地方没有去读或者没有读懂，这里只是作为学习的记录，记录的是上面 dev.htm 里面这个例子的加载而已。

ReactDOM.render(
  <h1>Hello World!</h1>,
  document.getElementById('container')
);

就是从上面的例子，一步一步走下去，直到没有下一步。就是本文介绍的内容。由于涉及到的步骤内容较多，所以采用思维导图的方式来介绍。

前部分

这里是初始化以及 Reconciler 和 Scheduler 的前部分。

从 ReactDom.render 里面过来时，会先创建 new ReactRoot()，该对象也就是下图左侧的 root。同时 root.current 为 fiber 对象。而 fiber.stateNode 指回 root。在 updateContainer 函数里面会计算出超时时间 expirationTime，这个时间常数在后面经常用上。

前面这部分主要功能是以建立 root 对象，并创建第一个 fiber，HostRoot，也就是 tag 为 3 的情况。这个 HostRoot 有点类似于上文中的 container，将会包含的子 fiber，并且以后的 dom 节点的操作都少不了 HostRoot。

fiber 就是一个普通的对象，对于这个对象而言，最重要的字段是下面这几个：

const fiber = {
  stateNode: root,
  return: null,
  child: null,
  sibling: null,
  tag: HostRoot,
  effectTag: Callback,
  expirationTime: 1,
  updateQueue: updateQueue,
  alternate: workInProgress,
}

stateNode 在本文中就是 dom 节点，或者是 root；return 和 child 分别指向 父 Fiber 以及子 fiber，sibling 则是兄弟 fiber 了，这四个字段构成了 fiber 间最直接的关系；

tag 代表当前 fiber 类型，目前有 17 个值；effectTag 有 14 个类型，按照 bitmap 的结构，表示的是 dom 操作类型。

上图中 performWork 之前会构建一个 updateQueue，正如其名一个更新队列。在图中可以看到，root.containerInfo 为 container 这个 dom 元素，而传入 ReactDOM.render 的第一个元素，则在 update 对象的 payload 上。这里有两个重要函数 scheduleWork 和 performWork，可以说是开始 react 工作的第一步，其简化大致如下：

function scheduleWork(fiber, expirationTime) {
  let node = fiber;
  while(node !== null) {
    if(node.return === null) {
      const root = node.stateNode;
      const rootExpirationTime = root.expirationTime;
      requestWork(root, rootExpirationTime);
    }
    node = node.return;
  }
}
function requestWork(root, expirationTime) {
  if (expirationTime === Sync) {
    performWork(Sync, null);
  }
}
function performWork(minExpirationTime, dl) {
  findHighestPriorityRoot();
  while(nextFlushedRoot !== null) {
    performWorkOnRoot(nextFlushedRoot, nextFlushedExpirationTime, false);
    findHighestPriorityRoot();
  }
}

代码中的 Sync = 1，也就是本文中 expirationTime 的值。这里面 scheduleWork 是更新的开始，通过循环找到，也就是 return 字段，沿着父 fiber 的路径一直到根节点。最后在根 root 开始工作啦。而 performWork ，这名字取得真好，先是 findHighestPriorityRoot，获取当前的最高优先的 root，再 nextFlushedRoot = root，执行 performWorkOnRoot 函数，再循环 findHighestPriorityRoot 函数会更新 nextFlushedRoot，但是本文中，只会发生一次循环，只有一个 root 呀。。至于其他情况，还不晓得，当然好像不重要。performWorkOnRoot 函数如下：

function performWorkOnRoot(root, expirationTime, isYieldy) {
  if (!isYieldy) {
    let finishedWork = root.finishedWork;
    if(finishedWork === null) {
      root.finishedWork = null;
      renderRoot(root, false);
      finishedWork = root.finishedWork;
      if (finishedWork !== null) {
        completeRoot(root, finishedWork, expirationTime);
      }
    }
  }
}

performWorkOnRoot 函数主要是通过是否异步 isYield，有的话就进入 commit 阶段，上面的代码自然是没有的部分，没有就进入 renderRoot，等 renderRoot 结束了再判断有没有完成，完成就进入 completeRoot 函数，也就是 commit 阶段咯。下文中的大部分步骤都是在 renderRoot 里面执行的。

workInProgress tree

上面的过程更多只是准备以及刚进入更新的过程，下面则是 reconciler 的核心部分。
fiber 是有两个阶段，Phase 1 render/reconcilation，在这个阶段是生成更新 fiber，更新虚拟 DOM 的过程，这个过程是可以被打断的。第二个阶段是 commit 阶段，这个阶段里面会把元素插入更新删除到 dom 树里面，无法被打断。本段落以及前面段落都是在 Phase 1 里面。

该阶段最重要的一个特征是会创建一个 workInProgress tree。在之前已经创建了一个父子兄关联的 fiber tree 了，而本次过程里面会再次创建一个类似的 tree。如下图所示：

可以看出来在上图的 root 下面，current fiber 下面有两个 fiber 构成父子关系。先看看进入 renderRoot 的大致写法：

function renderRoot(root, isYieldy) {
  nextUnitOfWork = createWorkInProgress(
    nextRoot.current,
    null,
    nextRenderExpirationTime,
  );
  do {
    workLoop(isYieldy);
    break;
  } while(true)
}
function workLoop(isYieldy) {
  if (!isYieldy) {
    while (nextUnitOfWork !== null) {
      nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
    }
  }
}
function performUnitOfWork(workInProgress) {
  const current = workInProgress.alternate;
  let next;
  next = beginWork(current, workInProgress, nextRenderExpirationTime);
  if(next == null) {
    next = completeUnitOfWork(workInProgress);
  }
  return next;
}

上面可以看到是由两个循环组成的，而在进入循环之前，会 创建一个 fiber，也就是 workInProgress tree 的 root fiber，即 HostRoot。这个 HostRoot 与 root.current 的关系更像是一个浅复制的关系，共享一个 stateNode，tag 都为 HostRoot。 workLoop 里面的 nextUnitOfWork 全局变量指的是下次要处理的 fiber 单元，自然首次是 workInProgress tree 的根元素，而下次则是该根 fiber 的子 fiber，也就是 child，不断下来从而实现 tree 的迭代。在工作单元 performUnitOfWork 函数里面，有个至关重要的函数 beginWork，顾名思义要开始工作了，前面函数更多的只是一个展开迭代，beginWork 才是阶段一里面最为重要的部分。

beginWork

function beginWork(current, workInProgress, renderExpirationTime) {
  switch (workInProgress.tag) {
    case HostRoot:
      return updateHostRoot(current, workInProgress, renderExpirationTime);
    case HostComponent:
      return updateHostComponent(current, workInProgress, renderExpirationTime);
  }
}
function updateHostRoot(current, workInProgress, renderExpirationTime) {
  let updateQueue = workInProgress.updateQueue;
  processUpdateQueue(
    workInProgress,
    updateQueue,
    nextProps,
    null,
    renderExpirationTime,
  );
  reconcileChildren(current, workInProgress, nextChildren);
  return workInProgress.child;
}
function reconcileChildren(current, workInProgress, nextChildren, renderExpirationTime) {
  workInProgress.child = reconcileChildFibers(
    workInProgress,
    current.child,
    nextChildren,
    renderExpirationTime,
  );
}

beginWork 里面根据不同的 fiber 类型来选定更新函数。updateHostRoot 则是更新 HostRoot，其先是浅复制了 current.updateQueue，再修改当前 workInProgress.effectTag = 32。更新队列的时候会把之前的 firstUpdate/lastUpdate 置为 null，同时 firstEffect/lastEffect 指向 update。

这里的 nextChildren 是就是 update 里面的 payload 的 element，也就是传入 ReactDom.render 的 element。通过 reconcileChildren，会直接的创建一个子 fiber，并返回到 workInProgress.child。由于 element 的 type 为 'h1'，所以该 child 的 tag 为 HostComponent，child.effectTag = Placement，是一个需要插入元素的 fiber。这个 effectTag 在后面也会用到。

生成 child 返回给到 workInProgress.child，也就是下一轮的 nextUnitOfWork。child 也就是下一个工作单元 fiber 了。updateHostComponent 函数同样也会进入 reconcileChildren 里面，只是并不会生成一个 fiber 传给 child.child，因为该 child fiber 没有任何的子元素，所以直接结束，

completeWork

上面结束后，会继续在 performUnitOfWork 执行 completeUnitOfWork，上一段的工作主要是建立 workInProgress tree，而这一段的工作将是生成 DOM。先看看 completeUnitOfWork：

function completeUnitOfWork(workInProgress) {
  while (true) {
    const returnFiber = workInProgress.return;
    const siblingFiber = workInProgress.sibling;
    if ((workInProgress.effectTag & Incomplete) === NoEffect) {
      // 这个fiber 已经完成
      let next = completeWork(
        current,
        workInProgress,
        nextRenderExpirationTime,
      );
      // 修改 firstEffect/lastEffect 为当前 workInProgress 也就是 child fiber
      if (siblingFiber !== null) {
        return siblingFiber;
      } else if (returnFiber !== null) {
        workInProgress = returnFiber;
        continue;
      } else {
        // 到达根部
        return null;
      }
    }
  }
}

这里 completeUnitOfWork 的传参是 child fiber，先是执行 completeWork 函数，随后开始循环，如果有兄弟 siblingFiber 则用，否之则为父 fiber，如果都没有则 return null。可想而知结束该循环的方式就是循环执行到 workInProgress tree 的根部。值得注意的是这里的 子 fiber 的 effects 会被添加到 父 fiber 的 effects list 上面：

if (returnFiber.firstEffect === null) {
  returnFiber.firstEffect = workInProgress.firstEffect;
}
if (workInProgress.lastEffect !== null) {
  if (returnFiber.lastEffect !== null) {
    returnFiber.lastEffect.nextEffect = workInProgress.firstEffect;
  }
  returnFiber.lastEffect = workInProgress.lastEffect;
}

传递方式如上面所示，returnFiber 就是父 fiber，如果有 returnFiber.lastEffect 以及 workInProgress.lastEffect，则通过 nextEffect 这个字段来传递，当然啦这里的 lastEffect/nextEffect 都是 fiber 元素哦。

接下来看看重点 completeWork

function completeWork(current, workInProgress, renderExpirationTime) {
  const newProps = workInProgress.pendingProps;
  const type = workInProgress.type;
  switch (workInProgress.tag) {
    case HostComponent: {
      if(current === null || workInProgress.stateNode === null) {
        let instance = createInstance(
          type,
          newProps,
          // div#container 元素
          rootContainerInstance,
          currentHostContext,
          workInProgress,
        );
        appendAllChildren(instance, workInProgress);
        workInProgress.stateNode = instance;
        return null;
      }
    }
  }
}

在 completeWork 里会通过 createInstance 创建 dom 元素，这里的 instance 就是 <h1></h1> 随后会进一步添加 Dom 属性，最后成为 <h1>Hello World!<h1>。传递到 workInProgress 也就是 child fiber 的 stateNode。如上图所示。返回 null， completeUnitOfWork 里面会继续 completeWork 循环，此时 workInProgress.tag = HostRoot，进入不一样的 case，但是好像没有什么执行的。。。继续返回 null，同时和第一轮一样也会清空 fiber.expirationTime。

到了这一步基本就完成 completeUnitOfWork 的工作，接着会退出 performUnitOfWork 循环回到上文的第一个图的 performWorkOnRoot 里面，执行后面 performWorkOnRoot 函数。也就是 commit 阶段。

commit

commit 阶段主要有三大循环，每个循环都有不同的作用，其简化如下所示

function commitRoot(root, finishedWork) {
  let firstEffect;
  finishedWork.lastEffect.nextEffect = finishedWork;
  firstEffect = finishedWork.firstEffect;

  nextEffect = firstEffect;
  while(nextEffect !== null) {
    commitBeforeMutationLifecycles()
  }

  nextEffect = firstEffect;
  while(nextEffect !== null) {
    commitAllHostEffects()
  }

  nextEffect = firstEffect;
  while(nextEffect !== null) {
    commitAllLifeCycles(root, currentTime, committedExpirationTime);
  }
}

第一个 commitBeforeMutationLifecycles 函数，主要是执行组件的 getSnapshotBeforeUpdate 方法，这也是 react 新增加的一个生命钩子，该函数的返回值 snapshot，将是 componentDidUpdate 的第三个传参，commitBeforeMutationLifecycles 的主要作用也就在于此。

第二个 commitAllHostEffects 函数。这里面会将之前的插入，更新，删除和 ref 卸载的操作都执行到真实 DOM 上面。

function commitAllHostEffects() {
  const effectTag = nextEffect.effectTag;
  if (effectTag & ContentReset) {
    // ...
  }
  if (effectTag & Ref) {
    // ...
  }
  let primaryEffectTag = effectTag & (Placement | Update | Deletion);
  switch (primaryEffectTag) {
      case Placement: {
        commitPlacement(nextEffect);
        nextEffect.effectTag &= ~Placement;
        break;
      }
  }
  nextEffect = nextEffect.nextEffect;
}
function commitPlacement(finishedWork) {
  const parentFiber = getHostParentFiber(finishedWork);
  switch (parentFiber.tag) {
    case HostRoot:
      parent = parentFiber.stateNode.containerInfo;
      isContainer = true;
      break;
  }
  let node = finishedWork;
  while(true) {
    if (node.tag === HostComponent || node.tag === HostText) {
      if (isContainer) {
        appendChildToContainer(parent, node.stateNode);
      }
    }
    if (node === finishedWork) {
      return;
    }
  }
}

可知当前的 nextEffect 是 child， 在 commitAllHostEffects 里面根据不同的场景处理，由于都是 bitmap，所以流程下来很简单。最终由于 child 的 effectTag 为 Placement，从而 找到 root 的 containerInfo，将 child 的 stateNode 添加到 containerInfo 里面，并随后清楚掉 child.effectTag 的 Placement 位置。这样就从肉眼上可以看到的真实的 DOM 结构被改变了。第二轮 commitAllHostEffects 循环的时候，由于父 fiber 的 effectTag 为 Callback，不存在任何进一步的操作，最后会退出本次循环。

第三个循环 commitAllLifeCycles 函数，如下

function commitAllLifeCycles(finishedRoot, currentTime, committedExpirationTime) {
  while (nextEffect !== null) {
    const effectTag = nextEffect.effectTag;
    if (effectTag & (Update | Callback)) {
      const current = nextEffect.alternate;
      commitLifeCycles(
        finishedRoot,
        current,
        nextEffect,
        currentTime,
        committedExpirationTime,
      );
    }
    if (effectTag & Ref) {
      // .. 处理 ref 相关
    }
    const next = nextEffect.nextEffect;
    nextEffect.nextEffect = null;
    nextEffect = next;
  }
}
function commitLifeCycles(
  finishedRoot, 
  current, 
  finishedWork, 
  currentTime, 
  committedExpirationTime
) {
  switch (finishedWork.tag) {
    case ClassComponent: {
      // 执行生命钩子，componentDidMount与componentDidUpdate
    }
    case HostRoot: {

    }
    case HostComponent: {

    }
  }
}

在上面的 commitAllLifeCycles 函数中，通过 commitLifeCycles 方法，执行生命钩子 componentDidMount 与 componentDidUpdate 的调用，同时会处理 updateQueue。这两点应该就是该循环的主要作用了。

通过上面的三个循环，而不是递归的方式实现了 commit 阶段。最后执行回归到 performWorkOnRoot，并结束前面两个循环。到此结束了。

总结

本文更多的只是从一个非常非常简单的例子来摸索 react 的首次渲染，能够清晰的看到其生成的 workInProgress tree，以及 reconciliation 与 commit 两个阶段的存在。一切的真实的 DOM 操作都发生在 commit 阶段，同时也会执行相关的生命钩子。但是对于 react 而言以上的探索是远远不够的。后面还会继续其他研究如：

1. 后台调度机制 requestIdleCallback 的 ployfill 实现，以及现场保护等等运用。
2. diff 机制，原则。
3. 组件更新过程。
4. 其他生命周期过程。

参考

开头文章列出的部分

1. 如何阅读大型前端开源项目的源码
2. Beyond React 16 by Dan Abramov
3. A Cartoon Intro to Fiber
4. React Fiber架构
5. 为 Luy 实现 React Fiber 架构

WEB 图像.pdf

盛夏到初秋，这次没有坐在窗边看不到磅礴的雨，只是这个夏天也少了烈日的暴晒，就这么过去了。去年台风天的黄昏，很好看，还拍了不少照片，到了今年，左等右等的，结果台风一刮，夏天就走了。2021好像也快要过去了。今年没有专门学习新的技术，中途换工作的，从2月拖到了6月，中间又忙了工作，梳理业务的，难得现在又空总结一下自己做的多语言。

多语言与 eslint

多语言为什么和 eslint 相关？通过 eslint 规则来限制业务开发，凡是涉及到中文的，都应该有多语言的约束，否则提示 error。这样就很强约束了，在多人协作的时候尤其重要，保持团队的统一风格。

这里说一下这个功能： 凡是涉及到中文的，都应该有多语言的约束。在 eslint 里面，这样的规则称之为 rule，比如我们经常看到的 no-debugger 禁止使用 debugger，就是这样的。最后实现效果是这样的：当输入中文变量包括 jsx 里面存在非法中文的时候，都会提示报红：

加上代码提交之前的 lint-staged 检查就可以统一规范了。

通用规则实现

在看多语言的 eslint 的规则实现之前可以看一下普通规则是如何的，我们就按上面的 no-debugger 来看看，这个是 eslint 内部的实现，用户只需要配置就好了，代码如下:

module.exports = {
    meta: {
        type: "problem",

        docs: {
            description: "disallow the use of `debugger`",
            recommended: true,
            url: "https://eslint.org/docs/rules/no-debugger"
        },

        fixable: null,
        schema: [],

        messages: {
            unexpected: "Unexpected 'debugger' statement."
        }
    },

    create(context) {

        return {
            DebuggerStatement(node) {
                context.report({
                    node,
                    messageId: "unexpected"
                });
            }
        };

    }
};

eslint/lib/rules/no-debugger.js 这个文件蛮简单的，可以看出下面有个 meta 和 create，前者不难猜出是配置信息，包括提示信息以及是否推荐这些；后面的则是出现 debugger 语句的时候就提示报错 context.report。是不是很简单？

回过头来可以看一下 eslint rule 官方教程，可以看到 recommended 就是是否在 eslint:recommended 扩展里面启用。最重要的 create 方法，eslint 会去遍历代码的抽象语法树 AST，调用 rule 里面注册的方法检测节点，上面则是 degugger 节点。

函数名是自己随便定义的？不是的，需要是对应的节点，可以通过 esprima 来解析来获得需要的函数名，比如下图，先有变量声明 VariableDeclaration 后有 DebuggerStatement。

如果你把 no-debugger 中的 DebuggerStatement 换成 VariableDeclaration，那每次声明变量都会异常。提到 AST 解析还是要说一下，espree 是 eslint 的官方解析器，基于 esprima，并且输出结构相似。

钩子实现上面的 no-debugger 比较简单，遇到 DebuggerStatement 直接 context.report，就完成了整个上报过程了。

其他需要主要的是规则代码的位置需要在 lib/rules/ 下面，同时要有 tests/lib/rules 以及对应的文档。

多语言规则实现

通过上文 create 提示的实现，先是梳理常见的中文都是哪些节点，比如最常见的 let a = '中文'，在 esprima 里面查询到的节点类型为 Literal；其他的还有两大块一个是 jsx 里面的文字，比如 <div>中文</div> 这样的，还有一个是字符串模版变量，比如 let a = 中${name}文。前者可以通 JSXText 获取，后则稍微麻烦点，下面重点介绍一下：

模版字符串

模版字符串解析的下图：

可以看到存在 quasis 和 expressions 两个数组，前者是字符串信息，后面是表达式。i18next 本身是支持变量传入的，比如 i18next.t('中{{value}}文', { value: name })，变量从第二个参数里面传入，生成文案替换。由于表达式不一定是变量，可以采用 value 名字自动生成名称。

字段名称是生成了，后续还要获取到字段名称对应的 value 也就是 name 这个字符串。存在变量名的可以直接获取，其他的比如 i18next.t('中{{value}}文', { value: 1 + 1 })，要如何获取到后面的 1 + 1 呢？可以有如下写法

const value = context.getSourceCode().getText().slice(expression.range[0], expression.range[1]);

在 eslint 规则里面会传入 context 上下文，通过上下文可以获取到非常多的信息，比如上面的获取全文字符串，再通过 range，定位到具体的内容。

忽略与修复

正常代码里面中文也是会有需要的地方，比如上报日志，埋点信息这些，甚至更加根本的如何识别 i18next.t('中文') 这样的表达式不报错呢？这样的表达式已经是正常写法了。所以这里需要 ignore 正常表达式。

进入节点通过匹配白名单的形式可以过滤掉，只是就上文的 i18next.t('中文') 匹配了函数，但是文案又是另外一个节点，如何做到两个关联到一起呢？这里就需要额外数组来记录当前关系，比如进入 i18next.t 函数的时候，标记为 true，后面进入函数形参的时候，检查标记，为 true 就忽略了。只是什么时候退出呢？这里有另外一个钩子 CallExpression:exit。由于存在多个嵌套的可能，所以用的是一个数组来维护，当 exit 的时候退出。

上面的例子，是遇到 debugger 的时候报错，那如何 fix 呢，eslint 有修复功能。context.report 里面的传参 fixer 函数，提供了不少方法。

context.report({
    node,
    message,
    fix(fixer) {
        return fixer.replaceText(
            node,
            `${useCallee}('${textReplacer(node.value)}')`
        );
    }
});

还用到了 fixer.replaceTextRange，来精准替换。

存量代码处理

对于老项目，直接用多语言的主要问题是，现有文案如何处理，要一个个替换显然不合理。最先的 i18next 提供了 i18next-scanner 工具，只是起更多的是将现有的 i18n._('Loading...') 这样的实现提出文案到 json 文件里面。还有其他思路比如通过 babel 的形式来解析，还有通过正则的形式来处理，两个方案都比较麻烦，容易出问题，于是我们这边有新的方案，本来也是通过 eslint 的规则来处理，那为什么不用 eslint 的解析器来提取词条呢？

require('eslint').CLIEngine(options).executeOnFiles 获取到 eslint 的分析结果，当然需要提前配置好规则，比如 i18next/no-literal-string 这个。后续获取到结果后，将其输出为转换为 json 文件输出就可以了，可以说这个规则一举两得。

单测

用的是 require("eslint").RuleTester 比如下面：

var ruleTester = new RuleTester({
  parser: require.resolve("babel-eslint"),
  parserOptions: {
    sourceType: "module",
    ecmaFeatures: {
      jsx: true
    }
  }
});
ruleTester.run("多语言规则测试", rule, {
    // 写 case valid 和 invalid
})

debug 的时候采用 create javascript debug terminal 的方式就可以了。

总结

这次算是深入的研究 eslint 了，从单个规则到引擎扫描，还有测试，打开了自己了新天地，尤其是 eslint 对团队规范的统一还是有很大帮助，后续的还可以添加 typescript 帮助，将 json 文件改为 ts，在文案里面缺少该词条就报错的，建立更加完整的机制。

在三亚的酒店的窗边，眺望着远处的海岸线，觉得写写博客，旅游，生活可好了，只是心中想的还是想要进击，想要不断的提升自己，偶得半天安宁，还是好好偷闲。

惭愧这边文章是 2021.10 就写好了，结果拖到今天才发表，不过说来也奇怪感觉时间好像没有过多少一样，好像去三亚还是昨天的事情。

前言

项目中经常用 Jenkins 构建项目，只要点击构建，服务端就会按照指令，重新拉取数据构建，这是很好的，只是久而久之发现一个问题：项目的构建时间从之前的飞快，到现在龟速。等待构建开发时间长是一个问题，更重要的是如果项目继续发展壮大呢？现在的 antd-pro 项目也就十来个页面，一点也不多，但是测试服构建起来，时间将近4分钟，特别吃内存。如果以后页面多很多呢？五六十个页面呢？那岂不是要二十来分钟的构建时间？内存呢，难道最后要溢出？这是难以置信的。

初探问题

春节期间前有空，上网查了一下方法，webpack.optimize.UglifyJsPlugin 几乎是千夫所指的，自带的代码丑化基本就是鸡肋，用上其他丑化插件，打包时间可以节省上30%，甚至更多，只是 antd-pro 用的是 roadhog.js，是一款接近于 create-react-app 的基础工具，能自己编写的配置参数少之又少，更不要提随意运用 webpack 的插件了。只是想要试探性的玩一下，于是在本地的 node_modules 里面修改了 roadhog 关于 webpack 的 UglifyJsPlugin 插件，结果一试，速度 duang 的一下就上来了。后来由于工作忙就没有怎么 care 构建问题。

春节期间看了几位大佬的博客，有感珠玉在前，webpack 构建问题，是要好好处理的了。

roadhog.js问题

roadhog.js 是类似可配置的 react-create-app，只是这个可配置，也只是部分可配置的，木有办法，只能从源码开始看 webpack 配置。

在进行 npm run build 的时候发现终端有提示 Creating an optimized production build... 的字样，而且出现的时间也挺晚的，以前其他项目上面从未见过，难道是 roadhog 自己的？这个时候 webpack 居然还没有开始构建？抱着疑惑，从 roadhog 的bin/roadhog.js就开始打印当前时间，再在到开始webpack构建的时候再打印一次时间。

结果这个过程要花上2931ms，还是可以接受的，只是明明第一次的时候记得等了很久的，为什么这次只要3s不到？后面又试了几次，耗时均3s左右，后来想起了Webpack 构建性能优化探索里面提到的初次构建和再次构建的问题，一般再次构建耗时都要比初次构建的要少。会不会第一次比较慢是初次构建，后面都是再次构建呢？初次构建和再次构建有什么区别？百度和谷歌都没有查询到答案，只有该博客提到比较多。为了再现问题，well，重启电脑，再次 npm run build 不就是初次构建吗？结果还正如此。

初次构建从进入 roadhog.js 到开始执行 webpack，居然花了30268ms，没有看错居然要30s的时间，这还没有算是 webpack 运行的时间，我的天呀。

时间都去哪儿了-roadhog.js

多次尝试初次加载，大概都在30s时间左右，而再次加载平均3s不到，十倍的差距，初次加载如此龟速，时间都去哪儿了？

粗看代码，并没有什么特别耗时间的计算，于是到处用console.log()打印时间，发现原来是几个requre的地方特别耗时间，分别如下：

var _webpack = require('webpack');

var _getConfig = require('./utils/getConfig');

return (0, _applyWebpackConfig2.default)(require('./config/webpack.config.prod')(argv, appBuild, c, paths), process.env.NODE_ENV);

这三行代码基本占用80%以上的时间，尤其是最后一句读取webpack配置，耗时将近14s，**原来时间都花在读取这些文件上面了。**这下瞬间明白了，roadhog.js 在初次加载上面表现很差劲，就是这个原因了。对比一下 Vue 的脚手架 Vue-cli，Vue-cli 里面从开始到进入 webpack 初次构建只要13s左右。这 roadhog.js 简直是慢慢慢。

再次加载由于node的缓存机制，之前require的内容都可以缓存下来，所以只是读取一个缓存的过程，时间可以缩短到3s不到。而正式服上面，一周构建一次基本就算频繁了，每次构建前期工作都要花30s，有必要这么复杂吗？看看新出的 parcel，秒杀。

数据报备

本机硬盘环境：

2.3 GHz Intel Core i5 / 4 核
4 GB DDR3

项目数据:

1526 个 node_modules 文件，package.json 中项目依赖 58 个

运行数据:

在 [email protected] npm5.5 下整个webpack初次构建耗时达 92229ms，再次构建 86422ms

走进webpack优化

按照Webpack 构建性能优化探索里面给出的思路，对于webpack的优化，可以从四个维度考量：

• 从环境着手，提升下载依赖速度；
• 从项目自身着手，代码组织是否合理，依赖使用是否合理，反面提升效率；
• 从 webpack 自身优化手段着手，优化配置，提升 webpack 效率；
• 从 webpack 可能存在的不足着手，优化不足，进一步提升效率。

从环境出发这一点，是因为不同的nodejs版本和npm版本，有着显著的性能差异来的。可以这么认为最新版本的nodejs/npm自然有更优秀的性能。由于项目本身用的就是最新版本的环境，所以这里也不加以分析了。

从项目中出发

首先用比较常规的方法，通过 webpack-bundle-analyzer 来查看 webpack 体积过大问题，结果如下图所示：

图挺好看的，乍一看没有什么特别的地方，好像每个打包文件都是由诸多细文件组成的。并从文件大小来看压缩过后都在1M以下，无可厚非。但是细心对比下，还是有不少发现。

案例1：为了实现小功能而引用大型 lib

这里用 webpack-bundle-analyzer 来查看打包过大问题，但是在引用的时候，却发现roadhog原本自身就用了 webpack-visualizer-plugin 插件，只是在analyze指令下才能进入分析，整理之后webpack配置如下：

var BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
var Visualizer = require('webpack-visualizer-plugin');

plugins: [
  new Visualizer({
    filename: './statistics.html'
  })],
  new BundleAnalyzerPlugin()
]

这里 webpack-bundle-analyzer 可以给予直观的整体感受，而 webpack-visualizer-plugin则细化到每个文件中，每个模块的百分比。

首先看到的是：最大的文件打包压缩后是815.9kb，相对于其他较大的文件大出了整整400kb，这里肯定是有什么问题，细看之后，发现用了支付宝的 G2，在代码中的体现是:

import G2 from 'g2';
// 将整个G2都引入进来了，导致文件过大

遗憾的是目前G2没有实现按需加载的功能，在issue里面也只是表示正在讨论而已(庆幸这里只是用了G2，没有用到Data-set)。

仔细看了每个js文件打包构造后，发现有个文件也用了 moment 模块，在印象中是基本没有用到的。moment 模块大小为53.2kb，而在总的打包文件中占 131.6kb。正同 Webpack 构建性能优化探索所说的，如果不想简单实现，就采用 fecha 库来代替 moment，fecha 要比 moment 小很多。只是替换后，发现 moment 体积并没有降低多少，由于出处是在 index.js 文件里面，可能的地方只有 dva 了。只是 dva 怎么可能用到moment？完全不可能的，他的package.json里面也同样没有用到。通过排除法最后定位到如下：

// @src/index.js
import 'moment/locale/zh-cn';

// @src/router.js
import { LocaleProvider } from 'antd';

第一个行代码是直接使用了 moment 模块，该代码看着作用不大，而且查阅Ant-Design-Pro的历史版本，均没有发现在index.js里面使用 moment/locale/zh-cn。细心观察，发现在 index.js里面使用了 moment/locale/zh-cn 之后，其他几处用到moment的地方，生成文件都没有明显 moment 包，这些文件的体积基本上要减少一个 moment 的大小。这个moment/locale/zh-cn，还能降低其他文件体积。
第二行代码，是在 router.js 文件里面，由于使用了 LocaleProvider 组件，这个组件通过源码可以发现直接引用了 moment 模块 import * as moment from 'moment'。当然同样也起到了 moment/locale/zh-cn 的效果，能降低其他原本含 moment 文件的体积。

案例2：废弃依赖没有及时删除

项目中用的是 Ant Design，import 的时候，组件是按需加载的，并不会整个引入 Ant Design，但是由于敏捷开发周期较短，新建页面不会从零开始写，基本都是移植相似的页面，由此导致了Ant Design组件的乱引用。

由于 G2 的不可按需加载，以及 moment 在 Ant-Design 中的作用，工程的打包体积和打包时间没有较大的减少。

从 webpack 自身优化点出发

webpack 本身也提供了许多优化的插件，但是由于经常接触不多，许久后容易遗漏，导致再次学习的成本高。一个好的脚手架，是相当重要的。

webpack 自带的优化

webpack 就有不少内置的插件。

• CommonsChunkPlugin

CommonsChunkPlugin 可以从 module 提取公共 chunk，实现降低模块大小，有利于整体工程打包后的瘦身。
CommonsChunkPlugin 这个插件在Vue-cli中也有用到，如下：

// split vendor js into its own file
new webpack.optimize.CommonsChunkPlugin({
  name: 'vendor',
  minChunks: function (module, count) {
    // any required modules inside node_modules are extracted to vendor
    return (
      module.resource &&
      /\.js$/.test(module.resource) &&
      module.resource.indexOf(
        path.join(__dirname, '../node_modules')
      ) === 0
    )
  }
}),
new webpack.optimize.CommonsChunkPlugin({
  name: 'manifest',
  chunks: ['vendor']
})

把相同的 chunk 提取出来，命名 vendor 与 manifest，前者是常说的公共 chunk 部分，后者是由于代码变动导致 chunk 的 hash 值变化，导致公共部分在每次打包时都会有不一样的 hash 值，使得客户端无法缓存 vendor。**由于代码变动导致 hash 变化，而生成的代码，自然而然的会落在最后配置的 commonschunk 上面，**所以这部分可以单独提取，命名为 manifest。

在roadhog里面，刚开始看以后没有CommonsChunkPlugin的配置，想着赶紧提个issue，但是后面发现，是通过common.js引入，只有在roadhog里面配置了multipage选项为true的时候，才执行CommonsChunkPlugin插件。其代码如下：

var name = config.hash ? 'common.[hash]' : 'common';
ret.push(new _webpack2.default.optimize.CommonsChunkPlugin({
  name: 'common',
  filename: name + '.js'
}));

通过 CommonsChunkPlugin 插件，node.js 在打包的时候，峰值内存增加了40M，就是约5.4%的内存，打包时间延长了大约6s，而构建后项目体积基本不变，what？有点震惊。只有负面效果。。。。看构建文件，只提取了一个公共文件，大小1kb，而且内容为一句普通的错误打印。为什么人与人之间没有相互的chunk可以提取呢？

通过反复查 roadhog/ant-design/ant-design-pro 的 issue 都没有类似的问题，似乎用了 babel-plugin-antd 对 antd 进行按需加载，没有办法将其提取到 vendor 里面了。如若不想不想按需加载，直接用 cdn 不就好了。但是现在想的是只要单独的提取antd里面几个涉及CRUD的重要组件：表格，form，日历这几个组件能否实现单独打包到vendor？难道是我打开方式不对吗？大神里面少 7s，我还多了 6s。。。。

在这个issue里面看到了这种写法，顿时觉得没错，就是她了。entry 里面设置多入口，CommonsChunkPlugin里面再提取。

entry: {
  //...
  antd: [ //build the mostly used components into a independent chunk,avoid of total package over size.
      'antd/lib/button',
      'antd/lib/icon',
      'antd/lib/breadcrumb',
      'antd/lib/form',
      'antd/lib/menu',
      'antd/lib/input',
      'antd/lib/input-number',
      'antd/lib/dropdown',
      'antd/lib/table',
      'antd/lib/tabs',
      'antd/lib/modal',
      'antd/lib/row',
      'antd/lib/col'
  ]
},
//...
new webpack.optimize.CommonsChunkPlugin({
    names: ['antd'],
    minChunks: Infinity
}),

咦？见证奇迹的时候到了，构建后的项目大小居然小了，整整3M，少了36.64%，厉害了。更惊讶的是，峰值内存减少了180M，减少了24.3%，打包时间减少了26s，直接下降到59196ms，减少25%；这牛逼了。

仔细对比一下，发现原来减少的部分并不是我以为的 antd 组件，antd 组件反而在每个打包文件里面的体积都要更大了，大概多了几kb，而减少的部分却是一些 _rc 开头的组件，这 CommonsChunkPlugin 也是厉害，按需加载部分没有单独打包起来，反而打包了这些组件背后的引用，如 rc-table。为什么这些组件最后还是没有完整的打包在antd里面呢？难道每次用的都不同？

import { DatePicker } from 'antd';
// / babel-plugin-import 会帮助你加载 JS 和 CSS 转变成下面内容
import DatePicker from 'antd/lib/date-picker';  // 加载 JS
import 'antd/lib/date-picker/style/css';        // 加载 CSS

这没看来，只是典型的引入组件，以及引入css模块而已。这是必然会被打包到公共模块的呀。看了未丑化的代码，发现用同一个组件的话，生成的不同文件 antd 的组件内容是一样的，不存在组件内部不一样导致没有打包在一起的情况。折腾许久后尚未解决，不晓得有没有大神知道。

而且 roadhog.js 的方式不允许添加新的入口，只能直接改源代码。。。这项目要怎么上线呢？难道每次都要自己改一遍？这就是约定和可配置的问题所在了，后面大神的博客也有讨论到，最后的**还是约定为若干模块，可自选配置，来适合不同的场景。

• DedupePlugin/OccurrenceOrderPlugin

这两个功能在webpack里面很常见，以至于已经被移除了，默认加载包含在 webpack 2 里面了。

CommonsChunkPlugin对项目的优化还是很实在的，能减少不必要的打包，不仅是体积，更多的是从内存和时间上。

webpack外引入的优化

前面提到的 webpack-bundle-analyzer 和 webpack-visualizer-plugin 插件就是从 webapck 外部引入的，可以很直观的看。

externals 的设置在 Vue 项目里面用的比较多，其中主要 externals 的是 axios, Vue, Vonic, Vue-router 这些。本身体积也不大，而且作为单页面应用还是很需要的。

但是到了 Ant Design Pro 项目，由于 Ant Desgin 项目本身 CSS + JS 就要1.5M，对于首屏的影响是显著的。虽然可以通过浏览器缓存/cdn缓存的方式来自然优化，但是首次体验还是不行，还是按照官网上的介绍来吧。

• DllPlugin 和 DLLReferencePlugin

按照官网上的介绍：DLLPlugin 和 DLLReferencePlugin 用某种方法实现了拆分 bundles，同时还大大提升了构建的速度。具体原理则是将特定的第三方 NPM 包模块提前构建再引入就好了。通过在 webpack 外进行配置，DllPlugin 负责配置输出引用文件 manifest.json，而 DLLReferencePlugin 在webpack的正常配置里面用 manifest.json 就好了。可以避免每次都对 npm 包打包，明明它们就不会改动，直接引用不是更好吗。

在 roadhog.js 里面实现就有点那个了，按照 sorrycc 作者的意思，在生产环境使用 DllPlugin 是不合适，打包大量的 npm 包后，会延长首屏时间，与按需加载矛盾。这点就和 CommonsChunkPlugin 是相同，都是提取第三方库，而且 DllPlugin 是一次打包即可，以后重复用引用，而 CommonsChunkPlugin 是每次打包都要重复提取公共部分，那这两个又有什么区别？

一般 DllPlugin 打的包会包含很多 npm 包，导致体积很大，首次加载自然不好，而且若以后更新某个包，会导致客户端重新下载整个 DllPlugin 的生成文件，对于产品迭代是不友善的。反观 CommonsChunkPlugin，一般提取的公共部分体积较小，例如antd主要组件提取，不到500kb，除非大版本升级，否则客户端是不会重新请求 vendor.js 文件的。

基于上面的观点 DllPlugin 一般用于提升本地开发的编译速度，就是启动项目开发的时候能够快点。只是一天能够启动多少次项目呢，基本都是热更新为主吧。。。。。这么看好像意义不大，就是开发人员的自 hight 而已。

发现原来roadhog自己也有 DllPlugin 的配置，只要在 config 里面添加 dllPlugin: true 就可以了，当然也是仅仅限于开发环境，肯定不是生产环境。很是方便，这里就不详细介绍了，感兴趣的可以自行看看这个issue。

从 webpack 不足出发

• HappyPack

使用 HappyPack，可以利用 node.js 的多进程能力，来提升构建速度。在 webpack 打包的时候，经常可以看到 CPU 和内存飚的非常高，内存可以理解，但是 CPU 为何会如此之高呢？只能说明有大量计算，而 node.js 的单进程在大量计算面前是单薄的。可以在 webpack 中定义 loader 规则来转换文件，让HappyPack来处理这些文件，实现多进程处理转换。

设置如下：

new HappyPack({
    threads: 4,
    loaders: [{
      loader: 'babel-loader',
      options: babelOptions
    }],
})
{
  test: /\.(js|jsx)$/,
  include: paths.appSrc,
  // loader: 'babel',
  loader: 'happypack/loader',
  options: babelOptions
}

只是运行结果却不让人满意，打包时间/内存什么都和原先的数据几乎相当。难道和 CommonsChunkPlugin 的时候一样，又是打开方式不正确？于是按照官网说的加个 id 试试，结果立马报错，提示AssertionError: HappyPack: plugin for the loader '1' could not be found! Did you forget to add it to the plugin list?，看到有 issue 提出将 loader 里面的 options 改为 query 就可以了，只是官方提示 webpack 2+ 需要使用 options 来代替query ，最后试了一下也是报错，报错的根由是 happyloader 没有获取到查询的识别 id。回头看了下源码，query = loaderUtils.getOptions(this) || {}这句话不就是获取 loader 的 option 配置吗，里面怎么可能有 id 呢？里面就是 babelOptions，不可能有 id 的。接着看 loader-utils 的源码，这个就是简单的获取查询到的 query，没有毛病，难道是 HappyPack 用错了？

折腾好久后，差不多都要放弃了，我定了定神，重新理一遍，看到了 rules 里面的配置：

loaders: [{
  loader: 'happypack/loader?id=js',
  options: babelOptions
}],

options 选项是 roadhog 原先就有的，而 laoder 原先是 babel，后面改为了 happypack 的设置。这个时候眼睛一亮 loader 设置里面有个问号 ?，这个不就是 query 吗？那 options 呢？loader-utils 里面获取的是这个 query 还是 option？注释掉试一试？完美成功了。。。。原来如此简单。

用了 happypack 之后，不能在 rules 里面的相关 loader 中配置 options，相反只能在 happypack 插件中配置 options！

well， 然而什么都没有变呀，设置了缓存也没有用，速度/内存什么的都和之前一摸一样。这个时候看到了(在 roadhog 中尝试支持happypack)[https://github.com/sorrycc/roadhog/issues/122]里面大神说了社区版本有问题。。。。。。虽然不知道具体的原因，但是实际效果是对 js 文件用 HappyPack 的配置，是没有起到想象中的多进程计算的优点的，原因或许出在 babel/HappyPack 身上了，最后还是落到了单线程计算上。具体就不分析了，有空可以在研究一下。

• uglifyPlugin

uglifyPlugin 是生产环境中必备的，毕竟压缩丑化代码，不仅可以降低客户端加载项目体积，降低打开时间，而且可以防止反向编译工程的可能性。在本文的开头就提到过，首次优化就是针对 uglifyPlugin 的，而且效果显著。

使用 webpack.optimize.UglifyJsPlugin 的时候，平均下来 webpack 的构建时间要达到 86s 左右。当不进行代码压缩丑化的话，构建时间下降了 68s 左右，并且构建时候，node.js 占用内存峰值下降了 380M 多，可以说不压缩丑化的话，效果是非常好的。但是项目体积却基本是原本的三倍之大，这是难以容忍的。webpack自带的uglifyPlugin，如此笨拙，要如何处理呢？

对 webpack.optimize.UglifyJsPlugin 在里面添加 cache: true 的配置也是没有什么效果，看了下官网介绍的另外一个 UglifyJsPlugin 插件，上面写着 webpack =< v3.0.0 已经包含 UglifyjsWebpackPlugin 的 0.4.6 版本了，如果想要安装最新版本才按照下面介绍的来。发现本地安装的 webpack 版本是 3.11.0，自然是内置 0.4.6 版本。1.0.0 版本是会在 webpack 4.0.0 里面安排的。那如果直接用 uglifyjs-webpack-plugin 最新版本呢？

安装 uglifyjs-webpack-plugin 1.2.2，设置配置如下：

new UglifyJsPlugin({
  cache: true,
  uglifyOptions: {
    compress: {
      warnings: false
    },
    output: {
      comments: false,
      ascii_only: true
    },
    ie8: true,
  }
})

初次构建的时候，构建时间较之前多40s，也就是多了46.5%，有点夸张的多，内存还好，峰值基本和用 0.4.6 版本的一样。但是 再次构建呢？构建时间居然下降了68s，而且内存峰值和未用代码压缩丑化的时候相似，也就是减少了 380M，实在厉害，牛逼哄哄。

还可以开启并行，也就是多进程工作，设置 parallel: true，设置之后测试，初次构建时间居然比普通的再次构建时间要少10s，但是问题也很明显 CPU 在平时的时候峰值基本在 45% 左右，而多进程后，CPU 的峰值居然很长一段时间都在 100%，内存也是达到了 1300+M，实在恐怖，如果正式服这么用不晓得会不会爆炸呢？hahaha。parallel 除了可以设置为 true 以外，还能设置成进程数，于是试了等于 2 的时候，CPU 运行峰值接近 95%，而内存峰值在 1100+M，也算是相对较好的数据，只是 CPU 还是接近于爆表。

对于再次构建 parallel 自然是起不到作用的，这里有不得不提另外一个插件 webpack-parallel-uglify-plugin （下载量比另外一款 webpack-uglify-parallel 多上一倍，肯定使用这个嘛）。试了一下，初次构建基本和 uglifyjs-webpack-plugin 1.2.2 一致，只有构建时间快 7s。

综上所诉，对于服务器 CPU 豪华的可以考虑平行压缩丑化，一般时候用 uglifyjs-webpack-plugin 1.2.2 多进程就不用设置，使能 cache 就好了，初次构建会慢点，再次构建的话，速度就上天了。

• UglifyJsPlugin 与 CommonsChunkPlugin

最后自然也是要让两者合并试一试，效果如何呢？和为优化之前相比，初次构建，内存减少 120+M，构建时间基本一样，构建项目大小自然还是少了 3M。咋一看好像不怎么样，但是要知道这是用上了UglifyJsPlugin，有缓存的！结果再次构建数据如所想的一样，速度和内存数据，和没有用代码压缩丑化基本一致！

这样 uglifyjs-webpack-plugin 与 CommonsChunkPlugin 在生产环境自然是很好的选择。

** 总结
本文主要是按照(Webpack 构建性能优化探索)[https://github.com/pigcan/blog/issues/1]介绍到的方法实践一遍，可谓收获颇多。但是还是遗留下两个问题：

1. CommonsChunkPlugin 对 Ant Design 提取问题；
2. HappyPack 没有效果的问题；

另外前几天 webpack 4 已经正式发布了，大佬们都迫不及待的想介绍一波。初看一下，从之前的配置化**更多转化为约定俗成，这确实是前端发展的趋势。尤其是这类工具，每次都学习一下，成本过高，看看create-react-app，基本都封装好webpack，上手用就可以了。而2017年的明星项目 parcel 更是夸张，直接跑，没有什么配置的。还是期待 webpack 4 的传说中的提升98%的速度吧。Twitter上面的数据基本在提升60%多。Twitter数据。

对 webpack 4 感兴趣的可以看这篇(翻译)[http://www.zcfy.cc/article/x1f3bc-webpack-4-released-today-webpack-medium]（国外大佬们都迫不及待要介绍了，国内还在过春节元宵节，哈哈哈哈）

参考

1. Webpack 构建性能优化探索

前言

项目中遇到的文件下载，上传基本上最常见的事情了。大概半年前，需要实现某表单的查询下载功能，查询还好，只要后端返回数据，我负责展示就好了，但是下载要如何实现呢？用axios的GET请求返回的数据，不忍直视，根本就下载不了。一顿百度谷歌之后，哦，原来这么简单，只要一个window.location.href=url就搞定了，是不是很简单~

文件下载

后来的文件下载我都统统用这种方式，只是下载提示不够明显，后来改为window.open打开个新的tag页，然后自动关闭，明显点下载。好像到这里就已经很完美，一切交给浏览器解决。

直到开始node.js中间层搭建。中间层的功能负责连接前后端，接口还是由后端提供的，具体可以参考淘宝前后端分离实践，以及天猪大神的egg - JSConf China 2016。node.js端用的是egg.js，小公司用它还是很顺心的。平常的API接口还好，只用转发到对应的后端接口就好了，但是文件下载怎么办？难不成我也要在node.js里面写个window.open？滑稽可笑。

这个时候又回到了请求上面，客户端自然还是用window.open，而nodejs端获得文件流再返回给客户端，这样window.open才能用。于是在本地测试了一下，用fs.readFile以及fs.createReadStream的方式都可以返回给客户端，但是下载文件类型却是没有的，几经波折后才发现没有设置Content-disposition，Content-Disposition消息头指示回复的内容该以何种形式展示，是以内联的形式（即网页或者页面的一部分），还是以附件的形式下载并保存到本地，用上koa2的attachment(fileName)方法更是简单，那这个不就迎刃而解了？
这里测试的只是本地的文件流，那后端接口上的文件流呢？这里还是用ctx.curl方法来请求获取数据，只是需要注意的是curl的设置响应数据格式，不是之前的RESTful的API接口-json交流方式了，而是文件流，所以默认不设置dataType就好了。代码如下：

async download() {
  const { ctx, app } = this;
  let data = {};
  try {
    data = await ctx.curl(url, {
      method: 'GET',
      headers: {},
      timeout: 8000,
    });
  } catch(e) {
    data = {
      status: 404,
      data: {msg:'服务访问出错'}
    }
  }    
  ctx.status = data.status || 404;
  ctx.set(data.headers || {});
  ctx.body = data.data;
}

客户端的文件下载

之前在客户端表格导出不是用window.location.href=url就是用window.open(url)，这个方法感觉很土，当然还有更土的就是用a标签，动态修改里面的href，<a href="url" target="_blank">导出</a>一般这种才是最常见的吧，可惜url需要一直修改。那有没有正常的用请求接口的方式来下载文件呢？
答案是有的，

fetch('/download').then((response) => { 
  return response.blob().then((blob) => {
    var a = document.createElement('a');
    var url = window.URL.createObjectURL(blob);
    var filename = response.headers.get('Content-Disposition');
    a.href = url;
    a.download = filename;
    a.click();
    window.URL.revokeObjectURL(url);       
  })
});

这个好像那里看到过，不就是创建了个a标签，再点击下载嘛。。。。还不如直接用a标签方便的多！！而且这里还用到了HTML5的download属性，还有blob对象，实在是麻烦。另外如果接口返回的不是文本流，而是json的话，就不用blob，直接用返回的url作为href，来click就好了。
这么看来用接口的形式来下载文件似乎很笨吧，当然从另外一个角度讲，请求/download接口后可以用js控制很多东西，比如客户端权限认证，而不是一股脑丢给浏览器。

文件上传

文件上传也是软肋，毕竟多年来一直没有接触过。。。。以前知道的范围领域也就是input标签可以设置type属性为file，这样就能上传文件了。后来在项目中还真的遇到文件上传的，但是这个时候已经有各种组件了，上来直接是饿了吗element的组件库，又或则是Ant Design的组件，样式又漂亮，根本不需要自己去开发嘛。。。。但是这样真的好吗，之前忙一直没有时间去看，直到了用上了node.js中间层，需要自己来做中转维护。

客户端实现

想想只是用<input type="file" />要如何实现上传呢，明明这都没有和后端联系上。。。。于是乎只能从饿了吗的代码里面找起来，其实饿了吗和ant design的实现大同小异，只是语言不同罢了。代码如下：

let upLoad = (ev) => {
  let files = Array.prototype.slice.call(ev.target.files);
  let rawFile = files[0];
  const formData = new FormData();
  const xhr = new XMLHttpRequest();

  formData.append('file', rawFile);
  if (xhr.upload) {
    xhr.upload.onprogress = function progress(e) {
      if (e.total > 0) {
        e.percent = e.loaded / e.total * 100;
      }
    };
  }
  xhr.onload = function onload() {
    if (xhr.status < 200 || xhr.status >= 300) {
      return console.log('wrong');
    }

    // onSuccess(getBody(xhr));
  }
  xhr.open('post', '/action?_csrf=VNPzCPKhQRs4eYhoCjFQgwQh', true);  
  xhr.send(formData);
}

上传的文件到哪里了？ev.target.files里面就是上传的文件数组，获取到上传文件的对象，再添加到FormData里面。FormData又是何物？带着一脸懵逼又去一顿百度谷歌，FormData是用XMLHttpRequest发送请求的键/值对，当然这也意味着是表单传输multipart/form-data的形式。如果你想要传入参数，只需要formData.append(key, value)就可以了。上面代码中自然是用formData.append('file', rawFile)，紧接着用了xhr.open和xhr.send方法，开眼界了，原来xhr.send里面可以带参数的。。。。文件的键名是file。
可以看出上面的处理方式直接用的是XMLHttpRequest 2.0，那为什么不用fetch呢？fetch不应该是未来趋势吗？想来这里有兼容问题，另外一点fetch上传文件好像没有进度条一说，只是Response.body有getReader方法用于读取原始字节流，如此来解决进度条问题Fetch进阶指南，以及XMLHttpRequestabort方法取消对象，也是fetch不能媲美的。

node.js端实现

node.js端的实现就曲折多了，为了获得上传的文件，用了官方的示例里面的方法ctx.getFileStream()，获得了文件流之后，再在官网介绍的httpclient里面有示例，用到了苏大神的formstream模块，生成可以被httpclient消费的stream对象，如下：

const fileStream = await ctx.getFileStream();
const form = new FormStream();
form.stream('file', fileStream, fileStream.filename);
data = await ctx.curl(url, {
  method: 'POST',
  headers: form.headers({
      Cookie: 'cookieHere',
  }),
  // contentType: 'multipart/form-data',
  stream: form,
  dataType: 'json',
}) 

看着简单，但是刚开始弄的时候却一脸懵逼，不知道如何是好，尤其是添加cookie的时候，由于没有用到form.headers，文件上传一直有问题，没有依据rfc1867, multipart/form-data是必须的，同时最重要的是分隔符！！boundary=这个在headers中是一定要加上的。
看了苏大神的FormStream里面，才发现原来这是模拟浏览器文件上传的动作，添加leading再添加stream/buffer，是个不错的npm模块，值得学习。
知道FormStream了，那ctx.getFileStream()又是如何获得stream对象呢，一开始以为是egg中ctx自带的方法，后来查了api指南才知道是egg-multipart模块引入的。但是egg-multipart核心部分其实是基于Busboy模块的。Busboy是个好东西，其安装量也是杠杠的。Busboy是用来解析node.js里接受到的form-data请求，这里egg-multipart用到的代码大致如下；

busboy.on('file', onFile)
function onFile(fieldname, file, filename, encoding, mimetype) {
  if (checkFile) {
    var err = checkFile(fieldname, file, filename, encoding, mimetype)
    if (err) {
      // make sure request stream's data has been read
      var blackHoleStream = new BlackHoleStream()
      file.pipe(blackHoleStream)
      return onError(err)
    }
  }

  // opinionated, but 5 arguments is ridiculous
  file.fieldname = fieldname
  file.filename = filename
  file.transferEncoding = file.encoding = encoding
  file.mimeType = file.mime = mimetype
  ch(file)
}
request.pipe(busboy)

通过pipe，busboy会触发file事件，同时传入file参数，也就是一个可读流ReadableStream.call(this, opts)。对于这个可读流，可以直接file.pipe(fs.createWriteStream(saveTo))将文件保存到本地磁盘，也可以再度转手如ctx.getFileStream()。关于busboy模块还是自己多玩玩比较好。

总结

文件下载上传对于大多数JSer可能都不陌生，但是于我却是刚刚开始，犹如打开了新技能，同时也知道了postman里面的文件上传key值是file，所以想梳理api，总结一下文件相关部分。

前言

前文提到了一个简单的 react 例子，结构如下所示

ReactDOM.render(
  <h1>Hello World!</h1>,
  document.getElementById('container')
);

只是实在简单呀，缺少 state，缺少状态的变化，于是用另外一个例子来继续研究：

class Hello extends React.Component {
  state = {
    hasWorld: true,
  }

  changeWorld = (e) => {
    console.log('isChanging：', this.state.hasWorld)
    this.setState({hasWorld: !this.state.hasWorld});
  }

  render() {
    return (
      <div onClick={this.changeWorld}>
        {this.state.hasWorld ? 'Hello World!' : 'Hello'}
      </div>
    )
  }
}
ReactDOM.render(
  <Hello />,
  document.getElementById('container')
);

本文将围绕这个简单的 class 展开研究。

Hello 的初始化

这里先介绍 Hello 组件的初始化过程，包括前面提到的 render/reconcilation 阶段，以及 commit 阶段。

render/reconcilation 阶段

这个阶段前面部分和之前博客介绍的很类似，创建 root，创建 current，创建 workInProgress 的 root。只是到了 beginWork 就开始不一样了。这个阶段可以看看下面的图片。

可以看到在 Step 11 也就是 updateHostRoot 之前都是一样的，只是在该函数的时候，由于 element 的 type 为函数，不是前一篇博客中的 'h1'，所以会在 reconcileChildFibers 函数阶段创建 tag 为 ClassComponent 的 fiber。可以从上图中看到，其 type 为 element 的 hello 函数。

第二轮 beginWordk 的时候，对象为上面生成的 child，执行的 case 对应的函数如下：

function updateClassComponent(current, workInProgress, renderExpirationTime) {
  if (current === null) {
    if (workInProgress.stateNode === null) {
      // 构建实例
      constructClassInstance(
        workInProgress,
        workInProgress.pendingProps,
        renderExpirationTime,
      );
      mountClassInstance(workInProgress, renderExpirationTime);

      shouldUpdate = true;
    }
  }
  return finishClassComponent(
    current,
    workInProgress,
    shouldUpdate,
    hasContext,
    renderExpirationTime,
  );
}
function constructClassInstance(workInProgress, props, renderExpirationTime){
  const ctor = workInProgress.type;
  const context = emptyObject;
  const instance = new ctor(props, context);
  const state = workInProgress.memoizedState = instance.state || null;
  instance.updater = classComponentUpdater;
  workInProgress.stateNode = instance;
  instance._reactInternalFiber = workInProgress;
  return instance;
}

在 constructClassInstance 时候会 new 一个 Hello class，将 child.stateNode 指向该实例。这里有三个特别操作

1. 同时给实例的 instance.updater = classComponentUpdater。这个方法在 setState 里面会用到。
2. 给 child.memoizedState 添加上 instance 的 state，也就是 { hasWorld: true }。为以后更新提供前值。
3. 给 instance 添加对应的 fiber

这上面的三条都在 setState 里面起到非常关键的作用。updateClassComponent 里面还有 shouldComponentUpdate 的判断，但是这里是首次加载，必然是 true 了。

mountClassInstance 里面则是从 child 里面往 instance 添加 props，ref，context 等属性，同时判断 instance 有无 componentDidMount 函数，有的话 child.effectTag |= Update;。从而在后面阶段可以执行 componentDidMount。

后面的 finishClassComponent，如下

function finishClassComponent(current, workInProgress, shouldUpdate, hasContext, renderExpirationTime) {
  const ctor = workInProgress.type;
  const instance = workInProgress.stateNode;
  const nextChildren = instance.render();
  workInProgress.effectTag |= PerformedWork;
  reconcileChildren(current, workInProgress, nextChildren);
  return workInProgress.child;
}