ahabhgk's blog

2021 年终总结

Sat, 01 Jan 2022 00:00:00 GMT

记一下 2021 年的流水账吧。

今年主要就是两个事吧，前半年实习然后顺利转正，拿到 offer；后半年入门了 Rust，尝试用 Rust 写一些和前端相关的东西，尝试接触前端深水区。

年初的时候去字节互娱前端架构工程化团队实习，其实去之前一直不知道团队叫什么，只知道是做前端轮子的，我也因为相比业务对轮子更感兴趣才决定去这里，去了之后看到组织结构才知道这样叫比较合适，不过我回学校之前大团队开始对外做一些技术宣传，现在统称”抖音技术团队”。

去的前几周都在看代码，熟悉工作，做一些很简单的 feature，周围同事都在忙抖音的春节红包活动（就是当时春晚的抖音红包），没时间管我，而我看了一遍代码就很着急的要需求做，现在看来太年轻了，明明是一段很好的摸鱼时间，根本不需要急年前的几天，后面有的是时间写需求。

然后就是过年了，女朋友回家了，我因为疫情没有回去，跟 bks、hzh 留京过年，也一起出来玩了一两天。年后就是断断续续实习回学校，因为报道和考试回了两次学校，之间也做了一些小需求，虽然比较小但是还是有点麻烦的那种，收获比较多的就是 prerender 和 webpack 插件相关的知识，不过自那之后我就再也不想写 webpack 插件了，相比之下 esbuild、rollup 的插件设计和文档真的好太多。后来 mentor 让我开始准备做个大一点的需求，答辩的时候用，当时在修跨端 bundle 的一个 bug，就打算参考 rax-miniapp 的构建配合 esbuild 来重写一下我们的跨端构建模块，以便更合理的解决一些问题，不过还没开始做就因为考试回学校了……

考完试回来之后发现隔壁组为跨端写了个新的编译器，虽然目的是语法方面而不是打包方面，但因为更轻量更合理所以顺带解决了打包的很多问题，同时他们也在开发的初期，于是我的答辩设计也就继续推迟了。这段时间开始跟着做跨端构建的一个管理平台，开始写熟悉的 React，现在回顾起来体验并不好，需求靠口述，前后端仓库分开，同时又用了 TS，经常一个接口写两遍，也没有在 build 的时候开 tsc 的 type check 导致类型混乱 any 乱飞，总之当时明明可以提出来改进的，却一直憋着没说，可能当时也不知道哪里出了问题，该怎么改进吧，希望以后可以勇敢提出问题并解决。

后来新编译器比较稳定了，我们开始做构建方面的支持，mentor 跟其他团队做 esbuild 版的新构建底层，我则是迭代 webpack 版接入新编译器为业务团队提供一个“尝鲜版”，这段时间还是比较轻松的，同时也接了很多 on-call，维护旧版 web 构建工具，可能学最多的就是这些 debug 技巧吧。最后 8 月初转正答辩，也顺利通过了，最后拿到了 offer，后来开奖比预期的低了点但也比较满意了，回顾下来实习期间还是成长很快的。

8 月初也面过了 shopee，听说那里钱多活少比较轻松，就有试试的想法，但最终开奖远低于预期就拒绝了。8 月中旬，回家待了两周，周围朋友都在考研也就没有打扰。然后开始重拾 Rust，到年底终于感觉自己对 Rust 有些开窍了，在家的两周看了 joehoo 的《crust of rust》，用 Rust 实现了《Ray Tracing in One Weekend》，可以说没有 joehoo 我就学不会 Rust，他的新书我也已经入手了准备后面看。

9 月回学校后就继续学 Rust，看了看 Deno 源码也帮忙修了一两个 issue，写了篇文章，也开通了自己的公众号并发布在上面，不过后面觉得 Deno 的路还太远，对我收益并不高，也可能是我不够坚持，就没怎么在看 Deno 了，不过这回看 Deno 了解了些 JS Runtime 相关的东西，我对此兴趣还是很大的，因为很久之前就想做一个自己的跨端轮子，而 JS Runtime 也算其中需要用到的一部分。

后来尝试使用 QuickJS 和 Tokio 写一个 JS Runtime，但逐渐深陷 QuickJS 的 Rust FFI Binding 的大坑中，经常花一两天在修 bug 上面，最后终于耗不住决定停一段时间，在深入了解 JS engine 和 QuickJS 之后再回来填坑。后来开始看 engine262 的源码，尝试用 Rust 抄一个，写完 lexer 大部分功能后开始接触 parser，哈哈，看完《es how to》和 v8 的《Understanding ECMAScript spec》后才知道这又是个大坑，决定直接用 SWC 的 AST，写完解释器后再回来填坑，不过写了一阵又发现解释器也有很多难点，engine262 因为用 JS 实现所以一些困难又不影响理解代码的部分直接调用原生 JS 来实现的，导致 Rust 写很麻烦，总之还是打算停一段时间。回顾这段时间做的就是不断给自己挖坑弃坑，但过程中写的代码学习的资料还是让我收获很多的，我对 Rust 开窍也多亏了这段时间的实践。

年底这几天开始看《crafting interpreters》的字节码部分，使用 Rust 实现，之前很多相关的盲区不懂现在明白了还是很开心的。

去年追了些综艺和动漫之后今年开始看韩剧了，很喜欢悬疑类的韩剧，这一类韩剧拍的真的好看，经常越看越怕但是越想看，今年综艺感觉没什么感兴趣的，动漫也只是追一些续集，美剧感觉越来越剧荒了。

今年除了认识了工作中的同事，也认识了优秀的学弟，技术上很厉害，平时也比较聊得来，年底也成功内推到了我们组实习。

今年国庆放假开通了公众号，准备发一些技术类的文章在上面，顺便能有些名气的积累，以后可以多点选择，但是一直比较懒，只发了一篇文章。去年一共写了 9 篇文章在博客上，可能只是看看一些库的原理所以并不太深入，内容比较好写，今年总是想写一些更加深入的文章，但又眼高手低，一些在挖坑弃坑的路上，也没时间把学到的一些写出来，还是功力不太够吧。希望明年可以别再眼太高，多写几篇文章，有的学习笔记也会整理下发出来。

2021 年还是很满意的。上半年实习期间和女朋友在一起是上大学以来过得最开心的一段时间，每天没有太多的烦恼，有足够的实习工资，有女朋友陪伴，还有生活中的小事，相比之下下半年寝室生活如同坐牢，每天去找女朋友写 Rust 是为数不多的快乐。希望 2022 过完年去实习和毕业工作后生活可以回到那种无忧无虑的开心状态……

Fetching in Deno

Fri, 01 Oct 2021 00:00:00 GMT

最近在学习 Rust，刚看完异步，想自己从零写点关于 Rust 异步的简单项目来练练手，最好还和前端有关，但是我并没有想到什么合适的项目，build your own x 上也没找到，所以我决定看一看 Deno，最好还能水个 contribute 😉

Bird's eye view of Deno

Deno 主要分为三个部分：

第一部分是 cli，它包括所有用户使用的 API，像 fmt、repl、run、compile、doc 等。一部分功能是调用的其他项目实现的，cli 这里集成到 deno 中，比如 fmt 底层使用的 dprint、typescript 使用了官方的一份 fock 实现了 transpile with type checking，只 transpile 的话使用了 swc。JS 执行环境相关的 cli 相当于是一个入口，用来对模块、runtime 进行初始化。除此之外大部分的单元测试、集成测试、benchmark 测试也放在这里。

第二部分是 core，主要依赖了 rusty_v8。rusty_v8 是使用 Rust 对 v8 引擎做的一层 binding，基本就是直接调用 v8 的 API，并没有过多的封装，提供好用的封装则是在 core 这里做的；然后著名的事件循环也是 core 这里实现的，但并没有完全实现，熟悉 Rust Async 的同学应该知道 Rust 中的异步 API 实现分为两部分：一部分是实现 Future trait 的 poll 方法，另一部分是实现 executor，core 这里相当于只实现了 poll 方法，executor 可以使用 tokio、smol 等库，core 这里并没有直接依赖 tokio，但其他调用 core 的地方都是用的 tokio 作为 executor 的；最后 core 实现了 Rust 侧和 JS 侧通信的方法：ops，Rust 这里将 JS 要用的 ops 注册上，JS 就可以通过 opSync 进行同步调用或 opAsync 进行异步调用，传递的数据通过 serde_v8 进行序列化与反序列化，可以理解为是一种 RPC。

第三部分是 runtime，这里依赖 core 实现 Deno 的 JS 执行环境和所有有关操作系统的 ops 和 JS 封装，比如 os、fs、http、process 等，其他的 ops 比如 fetch、timers、net、webgpu 等则单独放到了 ext 中，Rust 代码在 cli 中进行注册，通过 JS 进行调用。

fetch

Deno 中的很多 API 会根据 web 的标准进行实现，所以你的有些代码即可以跑在 Deno 上也可以跑在浏览器上，当然这只是美好的愿景，web 标准并不是那么好实现的，Github 上有专门的 web platform tests，简称 wpt，用来测试是否符合规范，Deno 也只通过了部分测试，Rust 编写的浏览器引擎 Servo 的 wpt 的 TODO 只完成三分之一。

同样 Deno 实现的有些 API 细节上也有些不符标准的，比如 fetch 中对于 http header value 的实现，我的 PR 也是这样来的。

先看一下 issue，简单来说就是 Rust 侧对 header value 进行解析时某些 value 会导致 panic，这个 panic 会导致整个 Deno 的 JsRuntime 挂掉，还是挺严重的，试想下你的 server 本来运行的好好的，结果发了某个 fetch 请求，然后你的 server 就挂了……

先看一下 fetch 规范中对于合法的 header value 的描述：

A value is a byte sequence that matches the following conditions:
Has no leading or trailing HTTP tab or space bytes.
Contains no 0x00 (NUL) or HTTP newline bytes.

大意就是你的 header value 开头结尾没有空格，范围在 0x20 (SP) 到 0x7E (~) 之间并且不包含 0x00、0x0A、0x0D 这三个 charCode 对应的字符就是合法的，而且在你添加 headers 时，根据 append header 的规范会对 header value 进行 normalize，也就是说

1const headers = new Headers()
2headers.append("val1", " hah")
3headers.append("val2", "hah ")
4fetch("xxx", {
5  headers: { val: " hha " },
6})

这样 header value 即使前后有空格也都会给你通过 normalize 去头去尾变成合法的 header value，那么问题的原因就锁定在第二条规则，不能包含非法字符。

hyperium/http

hyperium/http 是 Deno 中 fetch 下层 Rust 实现的 ops 所依赖的 http 库，header value 会通过这个库中的方法来进行解析，JS 侧会根据 fetch 规范对 header value 进行检测，不符合规范的 header value 会 throw error 阻止传给 Rust 侧来发请求。

而 panic 正是因为这个库解析 header value 后 unwrap 导致的，可预期是 JS 侧不会把不合法的 header value 传进来，所以这里 unwrap 应该是安全的。

但是翻开 hyperium/http 的文档发现：

If the argument contains invalid header value bytes, an error is returned. Only byte values between 32 and 255 (inclusive) are permitted, excluding byte 127 (DEL).

也就是说 charCode 在 32 到 255 之间，除了 127 都是合法的，这就导致有些字符虽然符合 fetch 规范但是却不符合 hyperium/http 解析 header value 的要求，导致后面 unwrap 造成了 panic。

我也在这个库中也发现了相关的 issue，原来 Servo 也是用的这个库也有同样的问题，哈哈。这个库虽然坑了 Deno 和 Servo，但是这个库的实现并没有错，因为它解析规则是按照 http rfc7230 来实现的，而 fetch 的 header value 是按照 http rfc2616 来定义的，而 rfc2616 也已经被 rfc7230 废弃了，所以是因为规范的差异导致的坑……

我也在知乎上提了一个问题，想了解更深的原因（两个 RFC 有差异的原因，为啥 fetch 规范不更新），有兴趣的大佬可以答一下～

最后我修了这个 issue 并提交了我给 Deno 的第一个 PR，PR 的内容很简单，就是去掉 unwrap 改为返回这个 Err，这样 ops 中返回的 Err 也会序列化传给 JS 侧，JS 侧则会 throw error 出来，这样用户就可以 catch 到这个 error 而不至于无法处理 panic 而导致整个 runtime 挂掉。后续再补充两个测试，更新下 wpt 的测试结果就成功被 Merge 了。

后记

修 issue 的这几天虽然一行 Rust 异步的代码都还没写，但是让我体会到了 Deno 的优良的工作流，对测试的重视，同时在 Discord 看大佬聊天也能学到很多，还有 v8 snapshot 的应用（deno compile），如何实现一个 JS 运行环境，甚至一窥未来的前端 toolchain。很多都是我在接触 Rust 后才有机会学到的，很喜欢 doodlewind 的一句话：

只要少量的 C / C++ 配合现代的 JavaScript，就能使传统的 Web 技术栈走出浏览器

同样的，只要少量的底层知识配合前端技术栈，就能使自己走出浏览器，前端工程师同样也是工程师，不能只局限于前端，前端是起点，但不能是终点。

2020 年终总结

Thu, 31 Dec 2020 00:00:00 GMT

其实本来不太想写年终总结的，因为成功的人才写年终总结，2020 我也不算特别成功，没太多可写的。但是看程序员社区里面全是年终总结，可能除了成功的人以外只有程序员会写吧。那我就随便写写流水账吧，记录一年发生的事，再说说想说的话吧，至少有个记录，证明我活过

年初的时候疫情，开不了学，跟女朋友分开，跟异地恋一样，只能每天晚上打电话，带我看看书，偶尔视频见一下，每天都会期待开学，期待见到彼此。后面开学后一起复习，暑假一起写项目，给我过生日，一起下山玩，一起面字节。这一年跟女朋友学到很多，希望以后继续陪伴，一起成长 🌹

疫情期间继续学习前端，想学会 RxJS，看了《深入浅出 RxJS》，后面就没怎么写过了，现在已经忘完了哈哈，果然还是要多动手。后面看了 Koa、Preact、Vue3 和 Immer 的源码，学了学 Nest 和 GraphQL，也算了解了下后端，开阔下视野

一直尝试看完一本工业出版社的书，但是一直没成功，一直在博客上挖坑。《SICP》疫情期间尝试了一次，开学又尝试了一次，还是卡在第二章最后。《CSAPP》在上学期想看完，但看了前几章感觉跟前端关系不太大，就也放弃了，还是太浮躁了。进度最好的是计网自顶向下，重点看了应用层和传输层，草草看了 IP 层，现在该看链路层了，但是后面几章讲 WIFI 蜂窝什么的打算先鸽了

在 2 月的时候写了第一版重邮帮小程序的 UI，由于见不到后端就没有管数据，到后面开学要跟后端对接发现写的太烂了，已经不想看了，这时换届要换小程序的 UI，就干脆答应，正好重写一遍，第二版在暑假写完了。重邮帮的后台管理疫情的时候写的差不多了，后来暑假又进行完善，改了很多 bug。终于在开学后上线，很多次活动表现的并不是很好，现在重邮帮已经交给学弟维护，重邮帮带给我的并不是很多，但是希望能带给网校和以后 Web 研发部的干事多一些吧，毕竟是 Web 研发部第一个长期维护并多人合作的项目，希望越来越好

4 月的时候面了美团，没过，但是有机会查漏补缺了。暑假参加了字节的训练营，有机会面抖音的，但是为了项目就没去。年底面腾讯，奇舞团和抖音架构就轻松多了，最后决定去抖音架构，和女朋友一起去北京字节，期待明年的实习生活

至于明年的 flags，就算了吧，立了也不会完成的，反而明年年底看着尴尬，就希望自己能多看些书吧，培养些兴趣，继续进步

Immer in 100 lines

Wed, 30 Dec 2020 00:00:00 GMT

序
原理
- ShallowCopy on write
- Proxies
实现

序

Immer - Create the next immutable state by mutating the current one

Immer 实现的就是通过 mutate 当前对象创建下一个 immutable 对象，比如我们在使用 React 时经常遇到 memo 中的浅比较判断失败导致的不更新或多余更新的问题，就可以通过 immer 解决

1const Profile = memo((props) => {
2  console.log("render <Profile />");
3  return (
4    <>
5      <div>Name: {props.user.name}</div>
6      <div>Age: {props.user.age}</div>
7    </>
8  );
9});
10
11const Blog = memo((props) => {
12  console.log("render <Blog />");
13  return <div>blog: {props.blog.content}</div>;
14});
15
16class User extends Component {
17  state = {
18    user: {
19      name: "Michel",
20      age: 33
21    },
22    blog: {
23      content: "hahah..."
24    }
25  };
26
27  render() {
28    return (
29      <div>
30        <Profile user={this.state.user} />
31        <Blog blog={this.state.blog} />
32        <button onClick={this.onUpdateAgeByManual0}>onUpdateAgeByManual0</button>
33        <button onClick={this.onUpdateAgeByManual1}>onUpdateAgeByManual1</button>
34        <button onClick={this.onUpdateAgeByManual2}>onUpdateAgeByManual2</button>
35        <button onClick={this.onUpdateAgeByImmer}>onUpdateAgeByImmer</button>
36      </div>
37    );
38  }
39
40  onUpdateAgeByManual0 = () => {
41    this.setState((prevState) => {
42      prevState.user.age++;
43      return {
44        user: { ...prevState.user },
45        blog: prevState.blog
46      };
47    });
48  };
49
50  onUpdateAgeByManual1 = () => {
51    this.setState((prevState) => {
52      prevState.user.age++;
53      return { ...prevState };
54    });
55  };
56
57  onUpdateAgeByManual2 = () => {
58    this.setState((prevState) => {
59      prevState.user.age++;
60      return {
61        user: { ...prevState.user },
62        blog: { ...prevState.blog }
63      };
64    });
65  };
66
67  onUpdateAgeByImmer = () => {
68    this.setState(
69      produce(this.state, (draft) => {
70        draft.user.age += 1;
71      })
72    );
73  };
74}

可以先猜猜以上三种 onUpdateAgeByManual 分别会怎样更新？

Click me to show the answer...

onUpdateAgeByManual0：理想的更新状态，只会更新 Profile 组件
onUpdateAgeByManual1：不会有组件更新，user 对象的引用没变，memo 浅比较后不会触发更新
onUpdateAgeByManual2：造成多余的组件更新，blog 对象的引用改变，memo 浅比较后会触发 Blog 组件更新
onUpdateAgeByImmer：同 onUpdateAgeByManual0

所以 immutable 对象所要保证的就是每次更新需要产生一个新对象。深拷贝就是可以满足的，但如果考虑性能问题的话，就需要保证对象只是发生改变的属性产生新的引用，其他没发生改变的属性仍然使用旧的引用，这就是 Immer 所实现的

原理

按照作者的话来说：

Copy on write
Proxies

produce 的工作分为三个阶段，分别为创建代理（createDraft）、修改代理（produceDraft）、定稿（finalize），创建代理所做的就是对传入的第一个参数 base 对象进行代理，实现后面修改代理时，也就是传入的回调函数执行时，可以进行 ShallowCopy on write 的操作，最终定稿就是把进行修改的对象的引用指向 ShallowCopy 的对象上面

所以关键原理就是如何实现 ShallowCopy on write 和如何去进行代理

ShallowCopy on write

ShallowCopy on write 的原理就如上图，接下来举个例子来理解过程

1const state = {
2  user: {
3    name: "Michel",
4    age: 33
5  },
6  blog: {
7    content: "hahah..."
8  }
9};
10const nextState = produce(state, (draft) => {
11  draft.user.age = draft.user.age + 1;
12});

对象的结构就像一棵树，基本类型的属性就相当于叶子结点

首先在读的时候，也就是触发对象的 get 操作的时候，会根据值的类型进行不同的返回，如果是基本类型，就说明访问到了叶子结点，直接返回即可；如果是引用类型，就继续为该值创建代理，实现“懒代理”。例子中的 draft.user.age + 1 就是进行的读，先读 draft 上的 user，返回是 user 的代理，再读 user 上的 age 属性，返回基本类型 33，再经过加一得到结果 34

第一次创建过代理之后会进行存储，这样再次读的时候，就可以直接返回存储的代理，减少创建代理的开销，同时也是对于代理上的操作进行的存储，不至于每次都创建新的代理导致之前代理上的操作无效。例子中 draft.user.age = set 操作之前部分就是相当于再次读取，得到之前的代理

之后在修改的时候就创建浅拷贝，父节点也进行浅拷贝，并在浅拷贝的对象上进行修改，同时 Object.assign(state.copy, state.drafts) 把之前的代理再存到浅拷贝对象上，同样是保证之前的操作不失效。例子中 draft.user.age = set 操作部分就触发了 user 代理的 set 操作，创建 user 的浅拷贝，再向上创建 draft 的浅拷贝，修改 user 浅拷贝对象的 age 属性

最后定稿（finalize）时就是对对象树进行遍历，如果发现修改了代理，就返回浅拷贝对象；如果没有修改，就仅返回原始的对象

Proxies

对于如何去进行代理，Immer 使用的是 Proxy API 代理的对象和数组，Map 和 Set 则是创建了 DraftMap 和 DraftSet 重写了 set、get、add、delete、has 等操作实现的，ES5 环境使用的是 defineProperty 进行对象和数组的代理，所以 Proxy API 并不是必须的，仅仅是方便代理对象的操作，我们也可以指定一些方法实现代理操作

实现

100 行左右的实现可以看 ahabhgk/simple-immer，对 Immer v1.0.0 做了一些简化，原理更加清晰，支持柯里化和异步，难点会有注释，也有比较完善的测试，很容易上手调试

另外由于 Immer 支持柯里化，很容易就能实现 useImmer，可以直接在 Github 上看

打算改一改写作风格，之前三篇讲 Vue3 的文章有大段大段的贴代码，又臭又长，只会催眠吧，以后写的会尽量讲清楚原理，写的精简，除了很精炼的会贴代码，其他时候源码就直接给链接了，有疑难点会通过注释和测试写清楚

记 2020-12 寒假实习面试

Sun, 20 Dec 2020 00:00:00 GMT

腾讯 PCG
- 一面
- 二面
360 奇舞团
- 一面
- 二面
字节跳动抖音
准备

腾讯 PCG

官网投的，真的太慢了

一面

一开始面试官来晚了，另一个人给我两道题让我选一个做，一个是 Promise retry，另一个是处理 CSV 格式字符串整理出里面的数字，我因为写了比较擅长异步，怕选 Promise 翻车，就选了 CSV 处理的，做了大概 20 多分钟（中间卡了一下，问了下问题）然后补上测试又花了大概 5 分钟，才算过。这时差不多半小时过去了，开始问问题，问了项目相关的比较多，有些记不清了

自我介绍
介绍项目（迎新网、重邮帮）
迎新网的优化（字体压缩、图片优化、PWA、动态路由）
迎新网中的 PWA 优化真的有必要吗（确实没必要，所以后面再问我项目就没说过 PWA 了）
重邮帮中的状态管理（小程序用 state 和 context，后台用的 Dva）
重邮帮后台 redux-saga 怎么用的（复杂度不够没用到太多，只用到了 redux-thunk 的程度）
项目中有做线上的性能监控错误监控吗（无……）
有什么想问我的（你们部门是做什么的）

二面

面了 20 多分钟，感觉回答得不是很好

自我介绍
问项目
迎新网的优化
项目中怎么调试，移动端怎么调试（F12……）
首屏时间怎么算的，怎么做的性能监控（线上的无，本地用的 lighthouse）
性能监控的原理
前端安全（XSS、CRSF）
计算机安全知道哪些（无……）
项目中有做错误监控吗（没，但是这回简单说了下错误监控的原理）
看过哪些源码，Vue3 对于 Vue2 的优化（只说了响应式，自我介绍的时候说了看过一些源码，但是说的很少而且很浅，肯定坑了）
有什么想问我的（怎么评价，他说”基础的知道，但是原理的不懂“，我感觉没了）

二面答的不是很好，现在官网流程是三面的，但是已经十几天了还没有约面试时间

360 奇舞团

直接在奇舞周刊公众号上发的招聘上投的

一面

聊的挺放松的

看过哪些源码，看完 Vue3 有什么收获（响应式，对比 react hooks 会自动收集依赖的实现；Block Tree，对比 react 静态模版的优化。懂了，这种就使劲往深入的说就行了，答得好就加分，答不好会坑）
判断字符串是不是回文（上周分享会学员正好讲到了，但是我一下没想起怎么做，只想到了栈，就先说了下用栈实现的思路，然后他说再换个别的方法，我想到双指针，然后又说有内置的方法，我说 reverse）
WebSocket
localStorage、sessionStorage、cookie、session
左固定宽度，右边自适应（flex 没写出来，让我写别的思路，我用的 calc，其他的因为挺久没写 CSS 了就想不起来了）
position 的几种属性（static、relative、absolute、fixed、sticky）
事件委托，事件委托的原理（事件冒泡）
技术规划
有什么想问我的（如果我能通过，会去写什么？你们平时在写什么？奇舞团除了已经开源的还有一些其他的未开源的吗？）

二面

面试官一上来就跟我说一面面试官对我评价很好，感觉对我比较认可了，所以每个问题都要想一会，问的时候也比较随意，面了一个小时

自我介绍
问重邮帮，遇到什么难点（介绍了一下，没什么难点，就是模块比较多）
Dva 的数据流（就是 Redux 那一套，答完我说有看过 Redux 的源码）
聊小程序，小程序的生命周期，用到哪些小程序提供的方法（生命周期只说了一个 onPageShow，解释说项目用的 Taro 写的，很多都在 React 生命周期中做了）
React 的生命周期（getDerivedStateFromProps、getSnapshotBeforeUpdate 和错误处理的没说出来，其他的说到了，提了下部分生命周期已经废弃了，想让他后面问我为什么废弃，就可以吹 React Concurrent，结果没问）
小程序生态的看法，如果去了有没有兴趣做小程序相关的（微信做了小程序还是比较多的人去做，但是微信做的很不好，小程序像是阉割版的 Vue；比较感兴趣去写一些小程序底层相关的）
问迎新网，遇到什么难点（介绍了下，然后说优化方面的）
优化的指标，开发者工具 Element 面板有什么作用（我说的是看 Network 面板和首屏时间，他应该想听 RAIL 相关的，最后也给了我 RAIL 的链接让我下去看看，他也说 Performance 面板可以看到很多性能相关的东西，学到了！）
说一下前端安全，怎么解决
Webpack 和项目中的工程化配置（px2vw、ESLint、CI\CD，只是配置过 Webpack，不太了解原理，然后他讲了讲 Webpack 的源码）
做一道变量提升的题（坑了）
做一道异步的题（就是网上出现最多的异步题，可以说一下 Chrome 团队的 PR，但是没说，因为之前的输出记不太清了怕坑）
括号匹配的思路（没让写，我说用栈）
说一下 form 表单提交时候 Content-Type 的作用（form 表单的请求我几乎没用过，但是记得以前写文件上传用过 multipart，就说了下 multipart 的作用）
常见的 HTTP 状态码以及作用
浏览器缓存
到后面基本上他想一道题要挺久的，感觉想不出来了就问我有什么想问的（我如果去了会做什么，他说哪里缺人就去哪个部门，所以现在还不能确定，他们部门是做小程序的）
平时怎么看源码（简单的 Github 上翻翻看下原理，比较大型的就 clone 下来看，遇到一些问题会回退 commit 看看怎么写过来的，或者查一些相关的 issue 和 PR）

面试官最后说给我过了，让我等 HR 面的电话，等了半个月，接到电话时已经确定去字节了

字节跳动抖音

找神三元大佬内推的，抖音架构部门

一面

问了半个小时就开始问我熟悉什么但是他还没问的，最后一共 40 分钟，聊的也比较放松

自我介绍
输入 URL 到渲染页面发生了什么
浏览器缓存
重排重绘
爬楼梯（递归、缓存加递归、迭代，然后问我递归的时间复杂度，有点尴尬没答上来，然后让我分析了下快排的时间复杂度）
防抖（问到 this 的指向）
MySQL、Redis 了解吗（只是使用过，不太了解）
小程序底层运行机制（记不太清了，说的渲染线程和逻辑线程，然后他说不算是线程，我说是进程？然后问我线程和进程的区别）
写过 Webpack 的 Plugin 和 Loader 吗（无）
看过哪些源码，Vue3 的 diff 机制（我说串了说成 Preact 的了，实际上我 Vue3 的 diff 偷懒一直没认真看过，然后问我 key 的作用，为什么单个节点不用加 key）
有什么想问我的

最后问我想不想去深圳，或者身边同学有没有想去深圳的，后面加个微信可以内推，之前本来聊的挺好的问我想不想去深圳，我突然感觉要凉，但是还好过了，那么想去深圳字节的同学可以给我份简历，我可以发给他内推

二面

面了一个小时，算是最难的一次，自己没发挥太好，面完感觉有点悬了

自我介绍
浏览器缓存
强缓存 from disk 和 from memory 区别
缓存策略；LRU（缓存策略我只说上来 LRU，然后问我 LRU 是什么，全称，怎么实现）
CDN 是什么，CDN 怎样实现就近访问（DNS 解析可以做，具体不太了解）
ES5、ES6 两种方式实现数组去重，ES5 实现的数组元素的数据类型有什么影响（数据类型坑了，引用类型要用 deepEqual 去判断，当时前三道问完有点懵了）
了解的设计模式（观察者、单例、享元）
观察者模式和发布订阅有什么区别（坑了）
实现发布订阅
实现并发控制器（已经有点懵了，差不多写出来了，写的不是很优雅）
Vue2 的更改数据后同步获取 dom 节点值是新的还是旧的，怎样获取新的（旧的，改变 dom 节点会在微任务里进行，怎样获取新的，不太熟悉 Vue2 就没说，说了下 React 的 setState 的做法。其实这里真的可以说起来的，前面都说了是微任务里进行的，用 $nextTick / Promise.resolve().then 就可以解决）
Vue2 熟悉那些（不太熟，看过 Vue3 响应式的源码，讲了下 Vue3 响应式）
对于新东西有哪些获取的渠道（GitHub、知乎）
Koa2 洋葱模型
Koa2 洋葱模型有哪些应用（路由、请求携带参数的检查、鉴权）
MySQL、Redis 有什么区别
我自己写过得项目对于 MySQL、Redis 有什么应用；Redis 也需要存到 MySQL 中，怎样保证数据的一致性（经常访问的比如热门用 Redis，个人信息、消息的存储用 MySQL；一致性没答上来）
设计百度搜索框有什么注意的（节流防抖、一个请求发送后取消前一个请求、请求结果的竞态问题）
你觉得你的优势是什么
有没有兴趣做后端或者其他方向的
有兴趣做架构方面的吗，工作时除了技术方面比如一些设计方面的会怎么做
有什么想问的（如果我能去会去做什么，需要接触哪些新的技术栈）

三面

面了 15 分钟，一开始做了一道题，后面就是聊天了

自我介绍
看过哪些源码，看过 Vue2 吗
两数之和，但是返回所有结果，时间复杂度
职业规划
平时怎么学前端
能实习多久
你觉得你的优点和缺点是什么
做项目中有什么交流的问题
有什么想问的（如果我能去会去做什么，你们会对我有什么期待、要求）

HR 面

自我介绍
之前的面试体验，自己发挥的怎样
怎样接触到的前端
怎样学习的前端
学习过程中遇到什么困难
怎么缓解自己的压力
了解字节的工作强度吗
印象深刻的项目，项目中遇到哪些困难，学到了什么
还面了哪些公司
对来字节实习有什么期待
有什么想问的

最后选择了字节的 Offer，期待之后的实习

准备

leetcode 刷的比较多，看了看浏览器相关的，其他的之前美团面试的时候就准备差不多了，美团那次虽然没过但是真的收获很多，后面也有机会查漏补缺

自我介绍

我叫 XXX，老家在 XXX，现在在重庆上大学，专业是软件工程，成绩在年级前 10%。在大一接触到前端，加入一个叫红岩网校的学校组织进行学习，然后大二跟着做了几个小项目。比较擅长 JS 基础，异步编程，了解浏览器和 HTTP 协议，平时有看过一些源码。这次面试不管能不能通过都希望有所收获，谢谢

diff 中 key 的作用，为什么不能用 index 代替

开发者通过 key 暗示同层多个节点之间的顺序，尽可能多的复用节点
保证 state 准确，防止旧的 state 留到新的节点上面

例子：Codesandebox demo、Understanding React's key prop

1// 没有 key 或者使用 index 的情况下
2// old.1 - new.2
3// old.2 - new 3
4// old.3 - null
5// 进行 diff
6// 1. props 进行修改
7//   - 受控 props 进行 diff，如果两个受控 props 相差比较大，性能消耗就比较大
8//   - 非受控 props 错乱，同 state
9// 2. state 错乱，old.1 的 state 到了 new.2 上面
10
11<ul>
12  <li>1</li> {/* state: 1 */}
13  <li>2</li> {/* state: 2 */}
14  <li>3</li> {/* state: 3 */}
15</ul>
16
17<ul>
18  <li>2</li> {/* state: 1 */}
19  <li>3</li> {/* state: 2 */}
20</ul>

diff 算法

当旧的是单节点时
- 新的也是单节点，进行递归的 diff
- 新的是 null，删掉旧的
- 新的是多节点，删掉旧的并一一添加新的
当旧的是 null 时
- 新的是单节点，添加新的
- 新的也是 null，什么都不做
- 新的是多节点，一一添加新的
当旧的是多节点时
- 新的是单节点，一一移除旧的并添加新的
- 新的是 null，一一移除旧的
- 新的也是多节点，通过 diffChildren 处理

diffChildren（2、3 偷懒了没准备）：

Preact 和 React15 使用的方式，遍历一遍新 children
- 移动：遍历时遍历旧 children 找到 type 和 key 都相同的旧节点，进行 diff，lastIndex 指之前遍历过的 newChild 对应的在最后面的 oldChild 的索引，也就是之前遍历过的 oldChild 的最大的索引，这样之后遍历的可以对比 index 是否小于 lastIndex 判断是否需要移动节点，如果小于，指这个 newChild 原来在 lastIndex 节点的前面，现在在后面，需要移动，就 insertBefore(oldVNode.dom, newChildren[i - 1].dom.nextSibling) 进行移动，如果大于，指两节点相对位置没变，不需要移动，只更新 lastIndex
- 添加：如果没有找到，就添加新节点
- 删除：找到的旧 VNode 会被打上标记，如果没有打上标记就说明是要移除的
Vue2 使用 snabbdom 的双端进行比较的方法，上一种由于从前往后进行遍历，在 1 2 3 -> 3 1 2 的情况下会发生两次移动，但使用双端遍历可以优化成只移动一次
Vue3 使用了 inferno 的算法，先把相同的前缀节点和后缀节点进行 diff，然后再处理剩余中间的节点，并通过求最长递增子序列判断出需要移动的节点，同 lastIndex，只不过加了一个表以空间换时间

VDOM runtime 源码入门

Mon, 23 Nov 2020 00:00:00 GMT

序
VNode
Diff
Component
State
Go deeper

序

1. 核心部分小于 200 行

去掉 key diff 后真的很简单

2. 框架原理入门的入门

Go deeper 部分就是框架原理入门

3. 学习框架原理的起点

Go deeper 链接中的链接中的链接……

VNode

1[Virtual Node]
2--------------
3[DOM Node]

用来找到两个帧之间不同的地方（diff），仅对不同的地方进行实际的 DOM 更新（patch），减少与 DOM 通信、回流重回等性能消耗

于是需要在真是的 DOM Node 上建立一层 VNode，用以描述帧的 DOM 结构

就是普通的 JS 对象，存在内存中，下一帧的 VNode 和当前帧的 VNode 进行比对，找到需要更新的地方，然后做相应处理

Vue 是一边 diff 一边 patch；React16 是先 diff 然后对要更新的地方做标记（render phase），之后在对标记过的地方进行 patch（commit phase）。实现的不同也决定了一些 feature 的不同

前两部分先不考虑组件，仅对应 DOM 结构的两种 VNode，标签（div、span……）和文本（#text）进行处理（对应 DOM 中 Element、Text、Comment 都继承于 Node 类型）

1{
2  type,
3  props,
4  key, // key diff 用的
5  node, // 宿主环境的元素（dom node……）
6  parent, // parent VNode
7  children, // VNode[]，建立内部 VNode 树结构
8}

Diff

1div                    diff
2    / \                diffChildren
3  div div           diff          diff
4   |   |        diffChildren  diffChildren
5hello  world        diff          diff

只对同级元素进行 diff（diffChildren）
两个不同类型的元素会产生出不同的树（isSameVNodeType）
开发者可以通过 key 来暗示哪些子元素在不同的渲染下能保持稳定（key diff）

key diff 位于 diffChildren 这里，是 diff 算法最难的地方，代码中我们简化了很多，详细的可以看 Go deeper 链接中的链接

Vue 使用的是递归式的 diff，React16 使用的是迭代式的 diff，区别在于递归式的不可打断，迭代式的可以打断，这也决定了两个框架 feature 的不同代码中因为参考的是 Vue3 的源码，边 diff 边 patch，所以命名是 patch，但实际上做的是 diff + patch

Component

现在我们加入 Component 的 diff

1const hooksComponent = {
2  patch(internals, { n1, n2, container }) {
3    if (n1 == null) {
4      const instance = n2.instance = {
5        subTree: null,
6        vnode: n2,
7        update: () => {
8          // this: extends hooksComponent
9          const renderResult = this.render(instance.vnode.props) // 获取 render 的结果
10
11          instance.vnode.children = [renderResult] // 不考虑 Fragment，组件的子节点只有一个
12          renderResult.parent = instance.vnode // 建立父子联系
13          internals.patch(instance.subTree, renderResult, container) // 跟上一次结果进行 diff
14          instance.subTree = renderResult // 存储这次结果，供下一次 patch 用
15        },
16      }
17    } else {
18      const instance = n2.instance = n1.instance
19      instance.vnode = n2
20    }
21    n2.instance.update()
22  },
23
24  unmount(internals, { vnode, doRemove }) {
25    vnode.children.forEach(c => unmount(c, doRemove))
26  },
27
28  getNode(internals, { vnode }) {
29    return vnode.instance.subTree.node
30  }
31}
32
33export const createHooksComponent = (render) => ({ ...hooksComponent, render }) // “继承“ patch、unmount 等方法

现在的组件的更新是同步的，就是说比如一个 input，输入多少次就触发了多少次 diff，可以通过异步进行优化

1enqueueRender(n2.instance.update)

State

组件的 State 我们通过 Hooks “钩”入

1const instance = n2.instance = {
2  // ...
3  hooks: {
4    list: [],
5    pendingEffects: [],
6  },
7  update: () => {
8    currentHooksComponent = instance
9    currentIndex = 0
10    // this: extends hooksComponent
11    const renderResult = this.render(instance.vnode.props)
12    currentHooksComponent = null
13    // ...
14    invokePendingEffects(instance)
15  },
16}
17
18function getHookState(index) {
19  const { hooks } = currentHooksComponent
20  if (index >= hooks.list.length) {
21    hooks.list.push({});
22  }
23  return hooks.list[index];
24}
25
26export function useEffect(effect, args) {
27  const hookState = getHookState(currentIndex++);
28  if (argsChanged(hookState.args, args)) {
29    hookState.effect = effect;
30    hookState.args = args;
31    currentHooksComponent.hooks.pendingEffects.push(hookState);
32  }
33}

两类 Reactivity 的处理方式：一种是以 Vue 为代表的 mutable + change tracking。即可变的数据结构，配合变更追踪，触发更新函数。另一种是以 React 为代表的 immutability + referential equality testing。即不可变的数据结构，配合反复执行的渲染函数，以及在函数执行过程中，通过数据的引用相等性判断，找出变更部分，只应用变化的部分到 UI 上。—— 工业聚：打破框架的范式之争

Go deeper

👉 源码在这里

Vue3 Compat

Wed, 30 Sep 2020 00:00:00 GMT

序
Fragment
Teleport
Inject / Provide
onErrorCaptured
Suspense
defineAsyncComponent
KeepAlive
Transition
Ref
Complier 优化
😃 ramble

序

Vue3 中内置组件和一些其他新特性的实现原理，作为上一篇的补充

Fragment

runtime-core/components/fragment.js

1export const Fragment = {
2  patch(
3    { mountChildren, patchChildren, renderOptions },
4    { n1, n2, container, isSVG, anchor }
5  ) {
6    if (n1 == null) {
7      const {
8        createText: hostCreateText,
9        insert: hostInsert,
10      } = renderOptions
11      const fragmentStartAnchor = n2.node = hostCreateText('')
12      const fragmentEndAnchor = n2.anchor = hostCreateText('')
13      hostInsert(fragmentStartAnchor, container, anchor)
14      hostInsert(fragmentEndAnchor, container, anchor)
15      mountChildren(n2, container, isSVG, fragmentEndAnchor)
16    } else {
17      n2.node = n1.node
18      n2.anchor = n1.anchor
19      patchChildren(n1, n2, container, isSVG)
20    }
21  },
22
23  getNode(internals, { vnode }) { // 插入到它的前面，需要从头部拿
24    return vnode.node
25  },
26
27  getNextSibling({ renderOptions }, { vnode }) { // nextSibling 需要从尾部拿
28    return renderOptions.nextSibling(vnode.anchor)
29  },
30
31  move({ move, renderOptions }, { vnode, container, anchor }) {
32    const { insert: hostInsert } = renderOptions
33    const fragmentStartAnchor = vnode.node
34    const fragmentEndAnchor = vnode.anchor
35    hostInsert(fragmentStartAnchor, container, anchor)
36    for (let child of vnode.children) {
37      move(child, container, anchor)
38    }
39    hostInsert(fragmentEndAnchor, container, anchor)
40  },
41
42  unmount({ unmount, renderOptions }, { vnode, doRemove }) {
43    const { remove: hostRemove } = renderOptions
44    hostRemove(vnode.node)
45    vnode.children.forEach(c => unmount(c, doRemove))
46    hostRemove(vnode.anchor)
47  },
48}

这五个方法会在哪里调用可以看上一篇，有具体的讲解和代码，Fragment 就是直接将子节点进行渲染，本身可以用两个 placeholder 来标记头部和尾部，因为 Fragment 的 nextSibling 是尾部 placehoder 的 nextSibling，而 getNode 用于插入到 Fragment 前面，所以返回的是 Fragment 的头部 placeholder

Teleport

Teleport 很像 Fragment，唯一的不同就是 Teleport 把子节点渲染到 target 节点上

runtime-core/components/teleport.js

1export const Teleport = {
2  patch(
3    { renderOptions, mountChildren, patchChildren, move },
4    { n1, n2, container, isSVG, anchor },
5  ) {
6    if (n1 == null) {
7      const teleportStartAnchor = n2.node = renderOptions.createText('')
8      const teleportEndAnchor = n2.anchor = renderOptions.createText('')
9      renderOptions.insert(teleportStartAnchor, container, anchor)
10      renderOptions.insert(teleportEndAnchor, container, anchor)
11      const target = renderOptions.querySelector(n2.props.to)
12      n2.target = target
13      mountChildren(n2, target, isSVG, null)
14    } else {
15      n2.node = n1.node
16      n2.anchor = n1.anchor
17      n2.target = n1.target
18      patchChildren(n1, n2, n2.target, isSVG)
19
20      if (n1.props.to !== n2.props.to) {
21        const target = renderOptions.querySelector(n2.props.to)
22        n2.target = target
23        for (let child of n2.children) {
24          move(child, container, null)
25        }
26      }
27    }
28  },
29
30  getNode(internals, { vnode }) {
31    return vnode.node
32  },
33
34  getNextSibling({ renderOptions }, { vnode }) {
35    return renderOptions.nextSibling(vnode.anchor)
36  },
37
38  move({ renderOptions, move }, { vnode, container, anchor }) {
39    const { insert: hostInsert } = renderOptions
40    const teleportStartAnchor = vnode.node
41    const teleportEndAnchor = vnode.anchor
42    hostInsert(teleportStartAnchor, container, anchor)
43    hostInsert(teleportEndAnchor, container, anchor)
44  },
45
46  unmount({ renderOptions, unmount }, { vnode }) {
47    const { remove: hostRemove } = renderOptions
48    hostRemove(vnode.node)
49    vnode.children.forEach(c => unmount(c))
50    hostRemove(vnode.anchor)
51  },
52}

不同于 ReactDOM.createProtal 由于 ReactDOM 有一个事件的合成层，可以在这里做一些 hack，使 Portal 的父组件可以捕捉到 Portal 中的事件，Vue3、Preact 由于没有实现事件合成层，所以父组件不能捕捉到 Teleport 中的事件，但相应的减少了很多的代码量，包的体积减小很多

Inject / Provide

直接看实现

runtime-core/inject.js

1import { isFunction } from '../shared'
2import { getCurrentInstance } from './component'
3
4export const provide = (key, value) => {
5  const currentInstance = getCurrentInstance()
6  if (!currentInstance) {
7    console.warn(`provide() can only be used inside setup().`)
8  } else {
9    let { provides } = currentInstance
10    const parentProvides = currentInstance.parent && currentInstance.parent.provides
11    if (parentProvides === provides) {
12      provides = currentInstance.provides = Object.create(parentProvides)
13    }
14    provides[key] = value
15  }
16}
17
18export const inject = (key, defaultValue) => {
19  const currentInstance = getCurrentInstance()
20  if (currentInstance) {
21    const { provides } = currentInstance
22    if (key in provides) {
23      return provides[key]
24    } else if (arguments.length > 1) { // defaultValue 可以传入 undefined
25      return isFunction(defaultValue)
26        ? defaultValue()
27        : defaultValue
28    } else {
29      console.warn(`injection "${String(key)}" not found.`)
30    }
31  } else {
32    console.warn(`inject() can only be used inside setup() or functional components.`)
33  }
34}

可以看出来 provides 是放在 instance 上的，每个 instance 的 provides 都是通过 Object.create 继承 parentInstance 的 provides

provide 调用时就是拿到 currentInstance，然后继承 currentInstance.parent 的 provides，再像上面通过 key 添加属性；inject 就是拿到 currentInstance 的 provides，再通过 key 取值即可，比较巧妙的就是 defaultValue 对于 undefined 的处理

之前我们的 runtime 并没有再 instance 上放 provides 属性，而且怎样去拿 parentInstance，接下来我们修改之前写的 runtime

runtime-core/renderer.js

1const processComponent = (n1, n2, container, isSVG, anchor) => {
2  if (n1 == null) {
3    const instance = n2.instance = {
4      // ...
5      parent: null,
6      provides: null,
7    }
8    const parentInstance = instance.parent = getParentInstance(n2)
9    instance.provides = parentInstance ? parentInstance.provides : Object.create(null) // 没有 parentInstance 说明是根组件，它的 provides 我们初始化成空对象
10  } // ...
11}

runtime/component.js

1export const getParentInstance = (vnode) => {
2  let parentVNode = vnode.parent
3  while (parentVNode != null) {
4    if (parentVNode.instance != null) return parentVNode.instance
5    parentVNode = parentVNode.parent
6  }
7  return null
8}

源码中 parentInstance 是类似于 anchor 作为一个参数一层一层传下来的，之后的 parentSuspense 也是，我们这里尽量简化，通过判断 .parent 链中是否有 instance 进行查找

onErrorCaptured

我们来实现我们唯一没有砍掉的钩子……

runtime-core/error-handling.js

1import { getCurrentInstance } from './component'
2
3export const onErrorCaptured = (errorHandler) => {
4  const instance = getCurrentInstance()
5  if (instance.errorCapturedHooks == null) { // 这样不用修改 renderer 中的代码了
6    instance.errorCapturedHooks = []
7  }
8  instance.errorCapturedHooks.push(errorHandler)
9}
10
11export const callWithErrorHandling = (fn, instance, args = []) => {
12  let res
13  try {
14    res = fn(...args)
15  } catch (e) {
16    handleError(e, instance)
17  }
18  return res
19}
20
21export const handleError = (error, instance) => {
22  if (instance) {
23    let cur = instance.parent
24    while (cur) {
25      const errorCapturedHooks = cur.errorCapturedHooks
26      if (errorCapturedHooks) {
27        for (let errorHandler of errorCapturedHooks) {
28          if (errorHandler(error)) {
29            return
30          }
31        }
32      }
33      cur = cur.parent
34    }
35  }
36  console.warn('Unhandled error', error)
37}

onErrorCaptured 就是添加错误处理的函数，通过 handleError 来从 instance.parent 中调用这些函数，知道返回 true 为止，而 callWithErrorHandling 是用来触发 handleError 的，我们对于用户可能出错的地方（可能有副作用的地方）调用时包裹一层 callWithErrorHandling 即可

runtime-core/api-watch.js

1export const watchEffect = (cb, { onTrack, onTrigger } = {}) => {
2  let cleanup
3  const onInvalidate = (fn) => {
4    cleanup = e.options.onStop = () => callWithErrorHandling(fn, instance)
5  }
6  const getter = () => {
7    if (cleanup) {
8      cleanup()
9    }
10    return callWithErrorHandling(cb, instance, [onInvalidate])
11  }
12  // ...
13}

Suspense

Vue3 在更新时遇到 Suspense 是在内存中创建一个 hiddenContianer，在内存中继续渲染 children，渲染 children 时如果遇到 async setup 会隐式的返回一个 Promise，Suspense 通过 register 接收这个 Promise，渲染完 children 后判断是否有接收 Promise，如果没有则把 hiddenContainer 中的 children 移动到 container 中，有则渲染 fallback 作为子节点，之后所有接收到的 Promise 在 resolve 之后再把 hiddenContainer 中的 children 移动到 container 中

在内存中创建 hiddenContainer 去渲染 children 是因为 Suspense 必须要根据是否有接收到 Promise 判断渲染 fallback 还是 children，而 Promise 只来自执行 children 中的 async setup

Suspense 的处理主要分为两部分，一部分是 Suspense 本身的处理，另一部分是对 async setup 子组件的处理，首先来看 Suspense 本身

runtime-core/components/suspense.js

1const createSuspense = (vnode, container, isSVG, anchor, internals, hiddenContainer) => {
2  const suspense = {
3    deps: [],
4    container,
5    anchor,
6    isSVG,
7    hiddenContainer,
8    resolve() {
9      internals.unmount(vnode.props.fallback)
10      internals.move(vnode.props.children, suspense.container, suspense.anchor)
11      vnode.node = internals.getNode(vnode.props.children)
12    },
13    register(instance, setupRenderEffect) {
14      // ...
15    },
16  }
17  return suspense
18}
19
20export const Suspense = {
21  patch(
22    internals,
23    { n1, n2, container, isSVG, anchor },
24  ) {
25    if (n1 == null) {
26      const hiddenContainer = internals.renderOptions.createElement('div')
27      const suspense = n2.suspense = createSuspense(n2, container, isSVG, anchor, internals, hiddenContainer)
28      internals.mountChildren(n2, hiddenContainer, isSVG, null)
29      internals.patch(null, n2.props.fallback, container, isSVG, anchor)
30      n2.node = internals.getNode(n2.props.fallback)
31      if (suspense.deps.length === 0) {
32        suspense.resolve()
33      }
34    } else {
35      // patchSuspense
36    }
37  },
38
39  getNode(internals, { vnode }) {
40    return vnode.node
41  },
42
43  getNextSibling({ renderOptions }, { vnode }) {
44    return renderOptions.nextSibling(vnode.node)
45  },
46
47  move({ move }, { vnode, container, anchor }) {
48    if (vnode.suspense.deps.length) {
49      move(vnode.props.fallback, container, anchor)
50    } else {
51      move(vnode.props.children, container, anchor)
52    }
53    vnode.suspense.container = container
54    vnode.suspense.anchor = anchor
55  },
56
57  unmount({ unmount }, { vnode, doRemove }) {
58    if (vnode.suspense.deps.length) {
59      unmount(vnode.props.fallback, doRemove)
60    } else {
61      unmount(vnode.props.children, doRemove)
62    }
63  },
64}
65
66export const getParentSuspense = (vnode) => {
67  vnode = vnode.parent
68  while (vnode) {
69    if (vnode.type === Suspense) return vnode.suspense
70    vnode = vnode.parent
71  }
72  return null
73}

我们实现的很简陋，可以看到核心逻辑就是创建一个 hiddenContainer，在这里面渲染 children，然后 createSuspense 创建实例，resolve 的时候就是把 fallback unmount 掉再把 hiddContainer 中的移动到 container 中，move 的时候 container 和 anchor 会改变，会影响 resolve，所以 suspense 实例的属性也要进行修改，这时还有很重要的一部分 patchSuspense，但是跟原理相关性较小，就不写了

runtime-core/renderer.js

1const processComponent = (n1, n2, container, isSVG, anchor) => {
2  if (n1 == null) {
3    // ...
4    if (isPromise(render)) {
5      const suspense = getParentSuspense(n2)
6      const placeholder = instance.subTree = h(TextType, { nodeValue: '' })
7      patch(null, placeholder, container, anchor)
8      suspense.register(
9        instance,
10        () => setupRenderEffect(
11          instance,
12          internals.renderOptions.parentNode(instance.subTree.node),
13          isSVG,
14          internals.renderOptions.nextSibling(instance.subTree.node),
15        ),
16      )
17    } else if (isFunction(render)) {
18      setupRenderEffect(instance, container, isSVG, anchor)
19    } else {
20      console.warn('setup component: ', n2.type, ' need to return a render function')
21    }
22
23    function setupRenderEffect(instance, container, isSVG, anchor) {
24      instance.update = effect(() => { // component update 的入口
25        const renderResult = instance.render()
26        const vnode = instance.vnode
27        vnode.children = [renderResult]
28        renderResult.parent = vnode
29        patch(instance.subTree, renderResult, container, isSVG, anchor)
30        instance.subTree = renderResult
31      }, {
32        scheduler: queueJob,
33      })
34    }
35  } // ...
36}

接下来对于 async setup 子组件的处理就要修改 runtime 了，我们对 setup 返回结果进行判断，如果是 Promise 就找到 parentSuspense 进行注册，这里我们抽离 setupRenderEffect，注册时传入一个回调函数，用于 suspense resolve 时继续渲染该子组件使用，同时创建一个 placeholder 给组件站位，用以 setupRenderEffect 中获取 container 和 anchor，因为 async setup 组件在没有 resolve 时可能有新的节点插入，如果 container、anchor 还是旧的值时可能会出错（anchor 为 null，但是之后插入了节点，resolve 时 anchor 还是 null 的话就导致节点顺序错误）

runtime-core/components/suspense.js

1const createSuspense = (vnode, container, isSVG, anchor, internals, hiddenContainer) => {
2  const suspense = {
3    deps: [],
4    // ...
5    register(instance, setupRenderEffect) {
6      suspense.deps.push(instance)
7      instance.render
8        .catch(e => {
9          handleError(e, instance)
10        })
11        .then(renderFn => {
12          instance.render = renderFn
13          setupRenderEffect()
14          const index = suspense.deps.indexOf(instance)
15          suspense.deps.splice(index, 1)
16          if (suspense.deps.length === 0) {
17            suspense.resolve()
18          }
19        })
20    },
21  }
22  return suspense
23}

然后 register 就是将 async setup 组件实例加入到 suspense.deps 中，然后等 render resolve 时调用 setupRenderEffect 渲染该组件，并判断是否可以 resolve 了，这里 catch 后 handleError 是因为 async setup 可以执行副作用，可能会出错

defineAsyncComponent

是一个高阶组件，相当于一个增强版的 lazy，当它的上层有 Suspense 时，就返回一个 Promise，否则返回相应状态的组件

runtime-core/api-define-component.js

1export const defineAsyncComponent = (options) => {
2  if (isFunction(options)) options = { loader: options }
3
4  const {
5    loader,
6    errorComponent,
7    suspensible = true,
8    onError,
9  } = options
10
11  let resolvedComponent = null
12
13  let retries = 0
14  const retry = () => {
15    retries++
16    return load()
17  }
18
19  const load = () => loader()
20    .catch(e => {
21      if (onError) {
22        return new Promise((resolve, reject) => {
23          onError(
24            e,
25            () => resolve(retry()),
26            () => reject(e),
27            retries,
28          )
29        })
30      } else {
31        throw e
32      }
33    })
34    .then((comp) => {
35      if (comp && (comp.__esModule || comp[Symbol.toStringTag] === 'Module')) {
36        comp = comp.default
37      }
38      resolvedComponent = comp
39      return comp
40    })
41
42  return defineComponent((props) => {
43    const instance = getCurrentInstance()
44    if (resolvedComponent) return () => h(resolvedComponent, props)
45    if (suspensible && getParentSuspense(instance.vnode)) {
46      return load()
47        .then(comp => {
48          return () => h(comp, props)
49        })
50        .catch(e => {
51          handleError(e, instance)
52          return () => errorComponent ? h(errorComponent, { error: e }) : null
53        })
54    }
55  })
56}

先来看有 Suspense 的情况，类似于 lazy 的实现，作为一个高阶组件返回 Promise，在出错的时候如果有 onError 就通过 onError 交给用户处理，没有就继续抛出 error，后面 catch 住渲染 errorComponent

再补上没有 Suspense 的情况

runtime-core/api-define-component.js

1export const defineAsyncComponent = (options) => {
2  if (isFunction(options)) options = { loader: options }
3
4  const {
5    loader,
6    loadingComponent,
7    errorComponent,
8    delay = 200,
9    timeout,
10    suspensible = true,
11    onError,
12  } = options
13  // ...
14
15  return defineComponent((props) => {
16    // ...
17
18    const error = ref()
19    const loading = ref(true)
20    const delaying = ref(!!delay) // 延后出现 LoadingComponent
21
22    if (delay) {
23      setTimeout(() => delaying.value = false, delay)
24    }
25    if (timeout) {
26      setTimeout(() => {
27        // 超时
28        if (loading.value && !error.value) {
29          const err = new Error(`Async component timed out after ${timeout}ms.`)
30          handleError(err, instance)
31          error.value = err
32        }
33      }, timeout)
34    }
35
36    load()
37      .then(() => loading.value = false)
38      .catch(e => {
39        handleError(e, instance)
40        error.value = e
41      })
42
43    return () => {
44      if (!loading.value && resolvedComponent) return h(resolvedComponent, props)
45      // loading.value === true
46      else if (error.value && errorComponent) return h(errorComponent, { error: error.value })
47      else if (loadingComponent && !delaying.value) return h(loadingComponent)
48      return null
49    }
50  })
51}

这里通过判断 suspensible 为 false 或者没有 parentSuspense 返回 render function，根据相应的状态渲染相应的组件，delay 这个参数的作用是为了 delay 出现 loadingComponent 的，如果加载比较快就不用展示 loading

我们目前写的不能实现的一种情况是 suspensible 为 false 但是有 parentSuspense

1const ProfileDetails = defineAsyncComponent({
2  loader: () => import('./async.jsx'),
3  loadingComponent: defineComponent(() => () => <h1>Loading...</h1>),
4  suspensible: false,
5});
6
7const App = {
8  setup(props) {
9    return () => (
10      <Suspense fallback={<h1>Loading by Suspense</h1>}>
11        <ProfileDetails />
12      </Suspense>
13    );
14  },
15};

这是因为 setupRenderEffect 传入的 container、anchor 是不变的，通过闭包存起来了，ProfileDetails 一开始渲染时是在 Suspense 中的，它的 container 是 hiddenContainer，之后渲染也是 hiddenContainer，所以导致页面空白，我们可以把 container、anchor 放到 instance 实例上，让这两个值可以改变，通过 instance 上的 container、anchor 进行渲染

KeepAlive

建立一个 Map 作为缓存，以子节点的 key 或 type 作为缓存的 key（const key = vnode.key == null ? vnode.type : vnode.key）；KeepAlive 的 render function 被调用时，也就是 KeepAlive 被渲染时，会根据 props 的 includes 和 excludes 规则判断 children 是否可以被缓存，不可以就直接渲染，可以就在缓存里找，如果缓存里有就用缓存中的进行渲染，children 的状态都是旧的在缓存中的，否则用新的 children 并进行缓存

1if (cachedVNode) {
2  // copy over mounted state
3  vnode.el = cachedVNode.el
4  vnode.component = cachedVNode.component
5  if (vnode.transition) {
6    // recursively update transition hooks on subTree
7    setTransitionHooks(vnode, vnode.transition!)
8  }
9  // avoid vnode being mounted as fresh
10  vnode.shapeFlag |= ShapeFlags.COMPONENT_KEPT_ALIVE
11  // make this key the freshest
12  keys.delete(key)
13  keys.add(key)
14} else {
15  keys.add(key)
16  // prune oldest entry
17  if (max && keys.size > parseInt(max as string, 10)) {
18    pruneCacheEntry(keys.values().next().value)
19  }
20}

源码中 KeepAlive 的缓存用到了 LRU 算法，keys 是一个 Set，可以看到每次使用缓存时会刷新一下缓存，变成新鲜的，如果再来新缓存时，缓存超过了 max，就删去最陈旧的缓存，利用 Set 对 LRU 进行了简易的实现

Transition

Transition 是通过给 DOM 节点在合适时机添加移除 CSS 类名实现的，对于不同平台有不同的实现方法，Transiton 是针对浏览器平台对 BaseTransition 的封装

1// DOM Transition is a higher-order-component based on the platform-agnostic
2// base Transition component, with DOM-specific logic.
3export const Transition: FunctionalComponent<TransitionProps> = (
4  props,
5  { slots }
6) => h(BaseTransition, resolveTransitionProps(props), slots)
7
8export function resolveTransitionProps(
9  rawProps: TransitionProps
10): BaseTransitionProps<Element> {
11  // 拿到对应的 CSS 类名
12  let {
13    name = 'v',
14    type,
15    css = true,
16    duration,
17    enterFromClass = `${name}-enter-from`,
18    enterActiveClass = `${name}-enter-active`,
19    enterToClass = `${name}-enter-to`,
20    appearFromClass = enterFromClass,
21    appearActiveClass = enterActiveClass,
22    appearToClass = enterToClass,
23    leaveFromClass = `${name}-leave-from`,
24    leaveActiveClass = `${name}-leave-active`,
25    leaveToClass = `${name}-leave-to`
26  } = rawProps
27  // ...
28  // 重写 hooks 回调函数，根据对应的添加或移除 CSS 类名
29  return extend(baseProps, {
30    onBeforeEnter(el) {
31      onBeforeEnter && onBeforeEnter(el)
32      addTransitionClass(el, enterActiveClass)
33      addTransitionClass(el, enterFromClass)
34    },
35    onBeforeAppear(el) {
36      onBeforeAppear && onBeforeAppear(el)
37      addTransitionClass(el, appearActiveClass)
38      addTransitionClass(el, appearFromClass)
39    },
40    // ...
41  } as BaseTransitionProps<Element>)
42}

BaseTransition 做的就是从 props 传入的 hooks 通过 resolveTransitionHooks 进一步进行封装，封装成针对 diff 阶段各个时机进行调用的 hooks（beforeEnter、enter、leave、afterLeave、delayLeave、clone），setTransitionHooks 就是把这些 hooks 放到 vnode 上，以便在 diff 过程中进行调用

1const BaseTransitionImpl = {
2  name: `BaseTransition`,
3
4  props: {
5    // ...
6  },
7
8  setup(props: BaseTransitionProps, { slots }: SetupContext) {
9    const instance = getCurrentInstance()!
10    const state = useTransitionState()
11    // ...
12
13    return () => {
14      const children =
15        slots.default && getTransitionRawChildren(slots.default(), true)
16      // ...
17
18      // at this point children has a guaranteed length of 1.
19      const child = children[0]
20      // ...
21
22      // in the case of <transition><keep-alive/></transition>, we need to
23      // compare the type of the kept-alive children.
24      const innerChild = getKeepAliveChild(child)
25      if (!innerChild) {
26        return emptyPlaceholder(child)
27      }
28
29      const enterHooks = resolveTransitionHooks(
30        innerChild,
31        rawProps,
32        state,
33        instance
34      )
35      setTransitionHooks(innerChild, enterHooks)
36
37      const oldChild = instance.subTree
38      const oldInnerChild = oldChild && getKeepAliveChild(oldChild)
39      // ...
40      if (
41        oldInnerChild &&
42        oldInnerChild.type !== Comment &&
43        (!isSameVNodeType(innerChild, oldInnerChild) || transitionKeyChanged)
44      ) {
45        const leavingHooks = resolveTransitionHooks(
46          oldInnerChild,
47          rawProps,
48          state,
49          instance
50        )
51        // update old tree's hooks in case of dynamic transition
52        setTransitionHooks(oldInnerChild, leavingHooks)
53        // ...
54      }
55
56      return child
57    }
58  }
59}

调用的时机就是有关 vnode 节点位置改变的时候，分别是 mount、move 和 unmount。mount 时就调用 BeforeEnter，并注册 enter 到 post 任务队列中；unmount 时就调用 leave 和 afterLeave，并注册 delayLeave 到 post 任务队列中；move 根据 moveType 的不同调用的也不同，比如 Suspense 中 resolve 时是把 children 从 hiddContainer 移到 container 中，相当于 mount，KeepAlive 的 activate 相当于 mount，deactivate 相当于 unmount

Ref

ref（指 runtime 的 ref）是用来拿到宿主环境的节点实例或者组件实例的

runtime-core/renderer.js

1const setRef = (ref, oldRef, vnode) => {
2  // unset old ref
3  if (oldRef != null && oldRef !== ref) {
4    if (isRef(oldRef)) oldRef.value = null
5  }
6  // set new ref
7  const value = getRefValue(vnode)
8  if (isRef(ref)) {
9    ref.value = value
10  } else if (isFunction(ref)) {
11    callWithErrorHandling(ref, getParentInstance(vnode), [value])
12  } else {
13    console.warn('Invalid ref type:', value, `(${typeof value})`)
14  }
15}
16
17const getRefValue = (vnode) => {
18  const { type } = vnode
19  if (isSetupComponent(type)) return vnode.instance
20  if (isString(type) || isTextType(type)) return vnode.node
21  return type.getRefValue(internals, { vnode })
22}

ref 的更新由于传入的 ref（指响应式 ref 用来接收实例）可能不同（<img ref={num % 2 ? imgRef1 : imgRef2} />），所以要先清空 oldRef，再赋值 newRef

runtime-core/renderer.js

1const patch = (n1, n2, container, isSVG, anchor = null) => {
2  // ...
3  if (n2.ref != null) {
4    setRef(n2.ref, n1?.ref ?? null, n2)
5  }
6}
7
8const unmount = (vnode, doRemove = true) => {
9  const { type, ref } = vnode
10  if (ref != null) {
11    setRef(ref, null, vnode)
12  }
13  // ...
14}

ref 的更新主要在两个地方，一个是在 patch 之后，也就是更新 DOM 节点或组件实例之后，保证拿到最新的值，另一个是在 unmount 移除节点之前

Complier 优化

没有比 Vue3 Compiler 优化细节，如何手写高性能渲染函数这篇写的更好的了

这里简单说一下原理

Block Tree 和 PatchFlags

编译时生成的代码会打上 patchFlags，用来标记动态部分的信息

1export const enum PatchFlags {
2  // Indicates an element with dynamic textContent (children fast path)
3  TEXT = 1,
4
5  // Indicates an element with dynamic class binding.
6  CLASS = 1 << 1,
7
8  // Indicates an element with dynamic style
9  STYLE = 1 << 2,
10
11  // Indicates an element that has non-class/style dynamic props.
12  // Can also be on a component that has any dynamic props (includes
13  // class/style). when this flag is present, the vnode also has a dynamicProps
14  // array that contains the keys of the props that may change so the runtime
15  // can diff them faster (without having to worry about removed props)
16  PROPS = 1 << 3,
17
18  // Indicates an element with props with dynamic keys. When keys change, a full
19  // diff is always needed to remove the old key. This flag is mutually
20  // exclusive with CLASS, STYLE and PROPS.
21  FULL_PROPS = 1 << 4,
22
23  // Indicates an element with event listeners (which need to be attached during hydration)
24  HYDRATE_EVENTS = 1 << 5,
25
26  // Indicates a fragment whose children order doesn't change.
27  STABLE_FRAGMENT = 1 << 6,
28
29  // Indicates a fragment with keyed or partially keyed children
30  KEYED_FRAGMENT = 1 << 7,
31
32  // Indicates a fragment with unkeyed children.
33  UNKEYED_FRAGMENT = 1 << 8,
34
35  // ...
36}

创建的 Block 也会有 dynamicProps、dynamicChildren 表示动态的部分，Block 也是一个 VNode，只不过它有这些动态部分的信息

dynamicChildren 中即包含 children 中动态的部分，也包含 children 中的 Block，这样 Block 层层连接形成 Block Tree，在更新的时候只更新动态的那一部分

1const patchElement = (
2  n1: VNode,
3  n2: VNode,
4  parentComponent: ComponentInternalInstance | null,
5  parentSuspense: SuspenseBoundary | null,
6  isSVG: boolean,
7  optimized: boolean
8) => {
9  const el = (n2.el = n1.el!)
10  let { patchFlag, dynamicChildren, dirs } = n2
11  // #1426 take the old vnode's patch flag into account since user may clone a
12  // compiler-generated vnode, which de-opts to FULL_PROPS
13  patchFlag |= n1.patchFlag & PatchFlags.FULL_PROPS
14  const oldProps = n1.props || EMPTY_OBJ
15  const newProps = n2.props || EMPTY_OBJ
16  // ...
17
18  if (patchFlag > 0) {
19    // the presence of a patchFlag means this element's render code was
20    // generated by the compiler and can take the fast path.
21    // in this path old node and new node are guaranteed to have the same shape
22    // (i.e. at the exact same position in the source template)
23    if (patchFlag & PatchFlags.FULL_PROPS) {
24      // element props contain dynamic keys, full diff needed
25      patchProps(el, n2, oldProps, newProps, parentComponent, parentSuspense, isSVG)
26    } else {
27      // class
28      // this flag is matched when the element has dynamic class bindings.
29      if (patchFlag & PatchFlags.CLASS) {
30        if (oldProps.class !== newProps.class) {
31          hostPatchProp(el, 'class', null, newProps.class, isSVG)
32        }
33      }
34
35      // style
36      // this flag is matched when the element has dynamic style bindings
37      if (patchFlag & PatchFlags.STYLE) {
38        hostPatchProp(el, 'style', oldProps.style, newProps.style, isSVG)
39      }
40
41      // props
42      // This flag is matched when the element has dynamic prop/attr bindings
43      // other than class and style. The keys of dynamic prop/attrs are saved for
44      // faster iteration.
45      // Note dynamic keys like :[foo]="bar" will cause this optimization to
46      // bail out and go through a full diff because we need to unset the old key
47      if (patchFlag & PatchFlags.PROPS) {
48        // if the flag is present then dynamicProps must be non-null
49        const propsToUpdate = n2.dynamicProps!
50        for (let i = 0; i < propsToUpdate.length; i++) {
51          const key = propsToUpdate[i]
52          const prev = oldProps[key]
53          const next = newProps[key]
54          if (next !== prev || (hostForcePatchProp && hostForcePatchProp(el, key))) {
55            hostPatchProp(el, key, prev, next, isSVG, n1.children as VNode[], parentComponent, parentSuspense, unmountChildren)
56          }
57        }
58      }
59    }
60
61    // text
62    // This flag is matched when the element has only dynamic text children.
63    if (patchFlag & PatchFlags.TEXT) {
64      if (n1.children !== n2.children) {
65        hostSetElementText(el, n2.children as string)
66      }
67    }
68  } else if (!optimized && dynamicChildren == null) {
69    // unoptimized, full diff
70    patchProps(el, n2, oldProps, newProps, parentComponent, parentSuspense, isSVG)
71  }
72
73  if (dynamicChildren) {
74    patchBlockChildren(n1.dynamicChildren!, dynamicChildren, el, parentComponent, parentSuspense)
75  } else if (!optimized) {
76    // full diff
77    patchChildren(n1, n2, el, null, parentComponent, parentSuspense)
78  }
79
80  // ...
81}

静态提升

以下是 Vue 3 Template Explorer 选上 hoistStatic 这个选项后编译出的代码

1<div>
2  <p>text</p>
3</div>

1import { createVNode as _createVNode, openBlock as _openBlock, createBlock as _createBlock } from "vue"
2
3const _hoisted_1 = /*#__PURE__*/_createVNode("p", null, "text", -1 /* HOISTED */)
4
5export function render(_ctx, _cache, $props, $setup, $data, $options) {
6  return (_openBlock(), _createBlock("div", null, [
7    _hoisted_1
8  ]))
9}

可以看到 <p>text</p> 生成的是 _hoisted_1 变量，在 render 作用域外面，这样每次 render 函数调用是就可以服用 _hoisted_1，减少 VNode 创建的性能消耗

预字符串化

1<div>
2  <p>text</p>
3  <p>text</p>
4  <p>text</p>
5  <p>text</p>
6  <p>text</p>
7  <p>text</p>
8  <p>text</p>
9  <p>text</p>
10  <p>text</p>
11  <p>text</p>
12</div>

1import { createVNode as _createVNode, createStaticVNode as _createStaticVNode, openBlock as _openBlock, createBlock as _createBlock } from "vue"
2
3const _hoisted_1 = /*#__PURE__*/_createStaticVNode("<p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p><p>text</p>", 10)
4
5export function render(_ctx, _cache, $props, $setup, $data, $options) {
6  return (_openBlock(), _createBlock("div", null, [
7    _hoisted_1
8  ]))
9}

当有大量连续的静态的节点时，相比静态提升，预字符串化会进一步进行优化，通过字符串创建 Static VNode

1const patch: PatchFn = (
2  n1,
3  n2,
4  container,
5  anchor = null,
6  parentComponent = null,
7  parentSuspense = null,
8  isSVG = false,
9  optimized = false
10) => {
11  // ...
12  const { type, ref, shapeFlag } = n2
13  switch (type) {
14    // ...
15    case Static:
16      if (n1 == null) {
17        mountStaticNode(n2, container, anchor, isSVG)
18      } else if (__DEV__) {
19        patchStaticNode(n1, n2, container, isSVG)
20      }
21      break
22    // ...
23  }
24  // ...
25}
26
27const mountStaticNode = (n2: VNode, container: RendererElement, anchor: RendererNode | null, isSVG: boolean) => {
28  // static nodes are only present when used with compiler-dom/runtime-dom
29  // which guarantees presence of hostInsertStaticContent.
30  ;[n2.el, n2.anchor] = hostInsertStaticContent!(n2.children as string, container, anchor, isSVG)
31}

Static VNode 会在 patch 是直接插入到 container 中，生产环节下不进行更新

预字符串化的好处有生成代码的体积减少、减少创建 VNode 的开销、减少内存占用

😃 ramble

Vue3 源码系列结束！

Vue3 目前写的只是它的响应式系统和运行时，还有很大的一个部分 complier，这一部分由于我对编译目前还没有太多的了解，而且对于理解 Vue3 核心原理影响并不大，所以就没有写，以后可能会写一写吧

之后就是 React 的源码了，至于我为什么热衷于看源码，不仅是因为自己的学习习惯，也是因为这些框架的源码相当于前端的“边界”，不仅代表着挑战也代表着我这一技术方向的深度

simple-vue 实现完整代码

Let's build a Vue3 runtime

Thu, 24 Sep 2020 00:00:00 GMT

序
👀 Vue3 Entry
🌟 VNode Design
☄️ patchElement & patchText
💥 patchComponent
💫 Scheduler
⚡️ key diff
🎨 Renderer
😃 ramble

序

我们会一起写一个简易的 runtime，对于 Vue 如何运行的有一个大致的了解，当然我们实现的会和源码本身有一些不同，会简化很多，主要学习思想

本篇文章并不是为了深入 Vue3 源码，而是对 Vue3 核心 VDOM 和新特性的简单了解，适合作为深入 Vue3 源码的入门文章

👀 Vue3 Entry

我们先看一下 Vue3 的 JSX 组件怎么写，因为我们只是造一个 runtime，所以不会涉及到 Vue 的模版编译，直接用 JSX 就很方便

1import { createApp, ref } from 'vue';
2
3const Displayer = {
4  props: { count: Number },
5  setup(props) {
6    return () => <div>{props.count}</div>;
7  },
8};
9
10const App = {
11  setup(props) {
12    const count = ref(0);
13    const inc = () => count.value++;
14
15    return () => (
16      <div>
17        <Displayer count={count.value} />
18        <button onClick={inc}> + </button>
19      </div>
20    );
21  },
22};
23
24createApp(App).mount('#app');

我们这里直接用的对象形式的组件，一般会使用 defineComponent，它做的只是多了处理传入一个函数的情况，返回一个有 setup 方法的对象，并没有更多其他的处理了，至于为什么设计出一个 defineComponent 方法而不直接写对象，大概是为了在 API 设计层面和 defineAsyncComponent 一致吧

先看入口 createApp，翻翻源码可以看出做的事是根据 rendererOptions 创建 renderer，然后创建 app 对象，最后调用 app.mount 进行渲染，mount 里也是调用的 render

我们写简单一点，去掉 app 的创建，因为创建 app 其实类似于一个作用域，app 的插件和指令等只对该 app 下的组件起作用

runtime-core/renderer.js

1export function createRenderer(renderOptions) {
2
3  return {
4    render(rootVNode, container) {
5
6    },
7  }
8}

通过 createRenderer(nodeOps).render(<App />, document.querySelector('root')) 调用，没错我就是抄 React 的，但是与 React 不同的在于 React 中调用 <App /> 返回的是一个 ReactElement，这里我们直接返回 VNode，ReactElement 其实就是 Partial<Fiber>，React 中是通过 ReactElement 对 Fiber（VNode）进行 diff，我们直接 VNode 对比 VNode 也是可以的（实际上 Vue 和 Preact 都是这么做的）

🌟 VNode Design

接下来我们来设计 VNode，因为 VNode 很大程度上决定了内部 runtime 如何去 diff

runtime-core/vnode.js

1export function h(type, props, ...children) {
2  props = props ?? {}
3
4  const key = props.key ?? null
5  delete props.key
6
7  // 注意 props.children 和 children 的不同
8  // props.children 因为子组件会使用所以是没有处理过的
9  // children 是为了维持内部的 VNode 树结构而创建的，类型是一个 VNode 数组
10  if (children.length === 1) {
11    props.children = children[0]
12  } else if (children.length > 1) {
13    props.children = children
14  }
15
16  return {
17    type,
18    props,
19    key, // key diff 用的
20    node: null, // 宿主环境的元素（dom node……），组件 VNode 为 null
21    instance: null, // 组件实例，只有组件 VNode 会有，其他 VNode 为 null
22    parent: null, // parent VNode
23    children: null, // VNode[]，建立内部 VNode 树结构
24  }
25}

Vue3 的 JSX 语法已经跟 React 很像了，除了 props.children 是通过 Slots 实现以外，基本都一样，这里我们并不打算实现 Slots，因为 Slots 实现的 children 也是一种 props，是一段 JSX 而已，并不算特殊，毕竟你随便写个 props 不叫 children 然后传 JSX 也是可以的。Vue 专门弄一个 Slots 是为了兼容它的 template 语法

☄️ patchElement & patchText

runtime-core/renderer.js

1export function createRenderer(renderOptions) {
2  return {
3    render(vnode, container) {
4      if (vnode == null) {
5        if (container.vnode) {
6          unmount(container.vnode)
7        }
8      } else {
9        patch(container.vnode ?? null, vnode, container)
10      }
11      container.vnode = vnode
12    },
13  }
14}

我们补全 render 方法的实现，这里不直接写 patch(null, vnode, container) 的原因是 render 有可能多次调用，并不一定每次调用都是 mount

shared/index.js

1export const isObject = (value) => typeof value === 'object' && value !== null
2export const isString = (value) => typeof value === 'string'
3export const isNumber = (value) => typeof value === 'number'
4export const isText = (v) => isString(v) || isNumber(v)
5export const isArray = Array.isArray

runtime-core/component.js

1import { isObject } from '../shared'
2
3export const TextType = Symbol('TextType')
4export const isTextType = (v) => v === TextType
5
6export const isSetupComponent = (c) => isObject(c) && 'setup' in c

runtime-core/vnode.js

1// ...
2export const isSameVNodeType = (n1, n2) => n1.type === n2.type && n1.key === n2.key

runtime-core/renderer.js

1import { isString, isArray, isText } from '../shared'
2import { TextType, isTextType, isSetupComponent } from './component'
3import { isSameVNodeType, h } from './vnode'
4
5export function createRenderer(renderOptions) {
6  const patch = (n1, n2, container) => {
7    if (n1 && !isSameVNodeType(n1, n2)) {
8      unmount(n1)
9      n1 = null
10    }
11
12    const { type } = n2
13    if (isSetupComponent(type)) {
14      processComponent(n1, n2, container)
15    } else if (isString(type)) {
16      processElement(n1, n2, container)
17    } else if (isTextType(type)) {
18      processText(n1, n2, container)
19    } else {
20      type.patch(/* ... */)
21    }
22  }
23
24  // ...
25}

patch（也就是 diff）在 type 判断最后加一个“后门”，我们可以用它来实现一些深度定制的组件，比如 setupComponent 就可以放到这里实现，或者还可以实现 Hooks（抄 Preact 的，Preact Compat 很多实现都是拿到组件实例 this 去 hack this 上的一些方法，或者再拿内部的一些方法去处理，比如 diff、diffChildren……），这里我们甚至可以实现一套 Preact Component……

diff 最主要的就是对于 Element 和 Text 的 diff，对应元素节点和文本节点，所以我们先实现这两个方法

runtime-core/renderer.js

1const processText = (n1, n2, container) => {
2  if (n1 == null) {
3    const node = n2.node = document.createTextNode(n2.props.nodeValue)
4    container.appendChild(node)
5  } else {
6    const node = n2.node = n1.node
7    if (node.nodeValue !== n2.props.nodeValue) {
8      node.nodeValue = n2.props.nodeValue
9    }
10  }
11}
12
13const processElement = (n1, n2, container) => {
14  if (n1 == null) {
15    const node = n2.node = document.createElement(n2.type)
16    mountChildren(n2, node)
17    patchProps(null, n2.props, node)
18    container.appendChild(node)
19  } else {
20    const node = n2.node = n1.node
21    patchChildren(n1, n2, node)
22    patchProps(n1.props, n2.props, node)
23  }
24}
25
26const mountChildren = (vnode, container) => {
27  let children = vnode.props.children
28  children = isArray(children) ? children : [children]
29  vnode.children = []
30  for (let i = 0; i < children.length; i++) {
31    let child = children[i]
32    if (child == null) continue
33    child = isText(child) ? h(TextType, { nodeValue: child }) : child
34    vnode.children[i] = child
35    patch(null, child, container)
36  }
37}

可以看到对于 DOM 平台的操作是直接写上去的，并没有通过 renderOptions 传入，我们先这样耦合起来，后面再分离到 renderOptions 中

processText 的逻辑很简单，processElement 与 processText 类似，只不过多了 patchChildren / mountChildren 和 patchProps

patchProps 一看就知道是用来更新 props 的

mountChildren 就是对子节点处理下 Text 然后一一 patch

patchChildren 就是对于两个 VNode 的子节点的 diff，它与 patch 的不同在于 patchChildren 可以处理子节点是 VNode 数组的情况，对于子节点如何 patch 做了处理（指 key diff），而 patch 就是简简单单对于两个 VNode 节点的 diff

所以对于 Element 的子节点会调用 patchChildren / mountChildren 处理，因为 Element 子节点可以是多个的，而对于 Component 的子节点会调用 patch 处理，因为 Component 子节点都仅有一个（Fragment 是有多个子节点的，对于它我们可以通过 compat 处理），当然 Component 的子节点也可以调用 patchChildren 处理，Preact 就是这样做的，这样 Preact 就不用对 Fragment 单独处理了（这里关键不在于怎样处理，而在于设计的 Component 子节点可不可以是多的，做对应处理即可）

接下来我们看一下 patchProps

runtime-core/renderer.js

1const patchProps = (oldProps, newProps, node) => {
2  oldProps = oldProps ?? {}
3  newProps = newProps ?? {}
4  // remove old props
5  Object.keys(oldProps).forEach((propName) => {
6    if (propName !== 'children' && propName !== 'key' && !(propName in newProps)) {
7      setProperty(node, propName, null, oldProps[propName]);
8    }
9  });
10  // update old props
11  Object.keys(newProps).forEach((propName) => {
12    if (propName !== 'children' && propName !== 'key' && oldProps[propName] !== newProps[propName]) {
13      setProperty(node, propName, newProps[propName], oldProps[propName]);
14    }
15  });
16}
17
18const setProperty = (node, propName, newValue, oldValue) => {
19  if (propName[0] === 'o' && propName[1] === 'n') {
20    const eventType = propName.toLowerCase().slice(2);
21
22    if (!node.listeners) node.listeners = {};
23    node.listeners[eventType] = newValue;
24
25    if (newValue) {
26      if (!oldValue) {
27        node.addEventListener(eventType, eventProxy);
28      }
29    } else {
30      node.removeEventListener(eventType, eventProxy);
31    }
32  } else if (newValue !== oldValue) {
33    if (propName in node) {
34      node[propName] = newValue == null ? '' : newValue
35    } else if (newValue == null || newValue === false) {
36      node.removeAttribute(propName)
37    } else {
38      node.setAttribute(propName, newValue)
39    }
40  }
41}
42
43function eventProxy(e) {
44  // this: dom node
45  this.listeners[e.type](e)
46}

值得注意的是第 35 行对于 newValue === false 的处理，是直接 removeAttribute 的，这是为了表单的一些属性。还有对于事件的监听，我们通过一个 eventProxy 代理，这样不仅方便移除事件监听，还减少了与 DOM 的通信，修改了事件监听方法直接修改代理即可，不至于与 DOM 通信移除旧的事件再添加新的事件

接下来看 diff 算法的核心：patchChildren，我们先实现一个简易版的 key diff，不考虑节点的移动，后面会有完整的 key diff

runtime-core/renderer.js

1const patchChildren = (n1, n2, container) => {
2  const oldChildren = n1.children // 拿到旧的 VNode[]
3  let newChildren = n2.props.children // 新的 children
4  newChildren = isArray(newChildren) ? newChildren : [newChildren]
5  n2.children = [] // 新的 VNode[]
6
7  for (let i = 0; i < newChildren.length; i++) {
8    if (newChildren[i] == null) continue
9    let newChild = newChildren[i]
10    // 处理 Text，Text 也会建立 VNode，Text 不直接暴露给开发者，而是在内部处理
11    newChild = isText(newChild) ? h(TextType, { nodeValue: newChild }) : newChild
12    n2.children[i] = newChild
13    newChild.parent = n2 // 与 n2.children 建立内部 VNode Tree
14
15    let oldChild = null
16    for (let j = 0; j < oldChildren.length; j++) { // key diff
17      if (oldChildren[j] == null) continue
18      if (isSameVNodeType(oldChildren[j], newChild)) { // 找到 key 和 type 一样的 VNode
19        oldChild = oldChildren[j]
20        oldChildren[j] = null // 找到的就变为 null，最后不是 null 的就是需要移除的，全部 unmount 即可
21        break
22      }
23    }
24    patch(oldChild, newChild, container)
25    if (newChild.node) container.appendChild(newChild.node) // 有 node 就添加到 DOM 中，因为 component 没有 node
26  }
27
28  for (let oldChild of oldChildren) {
29    if (oldChild != null) unmount(oldChild)
30  }
31}

我们并没有考虑移动节点的情况，而且是根据顺序 diff 的 newVNode，如果之前 node 在 container 中，appendChild 会先移除之前的 node，然后添加到末尾，所以是没问题的

runtime-core/renderer.js

1const unmount = (vnode) => {
2  const child = vnode.node
3  const parent = child.parentNode
4  parent && parent.removeChild(child)
5}

然后实现 unmount，因为目前只考虑 Element 和 Text 的 diff，unmount 就没有对 Component 的 unmount 进行处理，后面我们会加上，现在可以写个 demo 看看效果了

1/** @jsx h */
2import { createRenderer, h } from '../../packages/runtime-core'
3
4const renderer = createRenderer() // 这里我们还没有分离平台操作，可以先这样写
5const $root = document.querySelector('#root')
6const arr = [1, 2, 3]
7
8setInterval(() => {
9  arr.unshift(arr.pop())
10  renderer.render(
11    <div>
12      {arr.map(e => <li key={e}>{e}</li>)}
13    </div>,
14    $root,
15  )  
16}, 300)

💥 patchComponent

下面实现 Component 的 patch

runtime-core/renderer.js

1const processComponent = (n1, n2, container) => {
2  if (n1 == null) {
3    const instance = n2.instance = {
4      props: reactive(n2.props), // initProps
5      render: null,
6      update: null,
7      subTree: null,
8      vnode: n2,
9    }
10    const render = instance.render = n2.type.setup(instance.props)
11    instance.update = effect(() => { // component update 的入口，n2 是更新的根组件的 newVNode
12      const renderResult = render()
13      n2.children = [renderResult]
14      renderResult.parent = n2
15      patch(instance.subTree, renderResult, container)
16      instance.subTree = renderResult
17    })
18  } else {
19    // update...
20  }
21}

首先是 mount Component，需要在 VNode 上建立一个组件实例，用来存一些组件的东西，props 需要 reactive 一下，后面写 update Component 的时候就知道为什么了，然后获取 setup 返回的 render 函数，这里非常巧妙的就是组件的 update 方法是一个 effect 函数，这样对应他的状态和 props 改变时就可以自动去更新

我们来看组件的 update

runtime-core/renderer.js

1const processComponent = (n1, n2, container) => {
2  if (n1 == null) {
3    // mount...
4  } else {
5    const instance = n2.instance = n1.instance
6    instance.vnode = n2
7    // updateProps, 根据 vnode.props 修改 instance.props
8    Object.keys(n2.props).forEach(key => {
9      const newValue = n2.props[key]
10      const oldValue = instance.props[key]
11      if (newValue !== oldValue) {
12        instance.props[key] = newValue
13      }
14    })
15  }
16}

这里类似 const node = n2.node = n1.node 获取 instance，然后去 updateProps，这里就体现了之前 reactive(props) 的作用了，render 函数调用 JSX 得到的 props 每次都是新的，跟之前的 instance.props 并无关联，要是想 props 改变时也能使组件更新，就需要 JSX 的 props 和 instance.props 响应式的 props 进行关联，所以这里通过 updateProps 把 props 更新到 instance.props 上

我们再来看 updateProps，只涉及到了 instance.props 第一层的更新，相当于是做了层浅比较，内部实现了 React 的 PureComponent，阻断与更新无关子节点的更新，同时这里使用 shallowReactive 即可，得到更好一点的性能，但是之前我们没有实现 shallowReactive，这里就先用 reactive 替代

不要忘了我们的 unmount 还只能 unmount Element，我们来完善 Component 的 unmount

runtime-core/renderer.js

1const remove = (child) => {
2  const parent = child.parentNode
3  if (parent) parent.removeChild(child)
4}
5
6const unmount = (vnode, doRemove = true) => {
7  const { type } = vnode
8  if (isSetupComponent(type)) {
9    vnode.children.forEach(c => unmount(c, doRemove))
10  } else if (isString(type)) {
11    vnode.children.forEach(c => unmount(c, false))
12    if (doRemove) remove(vnode.node)
13  } else if (isTextType(type)) {
14    if (doRemove) remove(vnode.node)
15  } else {
16    type.unmount(/* ... */)
17  }
18}

类似于 patch，针对不同 type 进行 unmount，由于组件的 node 是 null，就直接将子节点进行 unmount

注意这里的 doRemove 参数的作用，Element 的子节点可以不直接从 DOM 上移除，直接将该 Element 移除即可，但是 Element 子节点中可能有 Component，所以还是需要递归调用 unmount，触发 Component 的清理副作用（后面讲）和生命周期，解决方案就是加一个 doRemove 参数，Element unmount 时 doRemove 为 true，之后子节点的 doRemove 为 false

最后还有清理副作用，生命周期就不提了，React 已经证明生命周期是可以不需要的，组件添加的 effect 在组件 unmount 后仍然存在，还没有清除，所以我们还需要在 unmount 中拿到组件所有的 effect，然后一一 stop，这时 stop 很简单，但如何拿到组件的 effect 就比较难

💫 Scheduler

其实 Vue 中并不会直接使用 Vue Reactivity 中的 API，从 Vue 中导出的 computed、watch、watchEffect 会把 effect 挂载到当前的组件实例上，用以之后清除 effect，我们只实现 computed 和简易的 watchEffect（不考虑 flush 为 post 和 pre 的情况）

update 的 effect 在 Vue 中通过 scheduler 实现了异步更新，watchEffect 的回调函数执行时机 flush 也是通过 scheduler 实现，简单来说就是 scheduler 创建了三个队列，分别存 pre Callbacks、sync Callbacks 和 post Callbacks，这三个队列中任务的执行都是通过 promise.then 放到微任务队列中，都是异步执行的，组件的 update 放在 sync 队列中，sync 指的是同步 DOM 更新（Vue 中 VNode 更新和 DOM 更新是同步的），pre 指的是在 DOM 更新之前，post 指的是在 DOM 更新之后，所以 pre 得不到更新后的 DOM 信息，而 post 可以得到

runtime-core/renderer.js

1const unmount = (vnode, doRemove = true) => {
2  const { type } = vnode
3  if (isSetupComponent(type)) {
4    const instance = { vnode }
5    instance.effects.forEach(stop)
6    stop(instance.update)
7    vnode.children.forEach(c => unmount(c, doRemove))
8  } // ...
9}

runtime-core/component.js

1let currentInstance
2export const getCurrentInstance = () => currentInstance
3export const setCurrentInstance = (instance) => currentInstance = instance
4
5export const recordInstanceBoundEffect = (effect) => {
6  if (currentInstance) currentInstance.effects.push(effect)
7}

reactivity/renderer.js

1const processComponent = (n1, n2, container) => {
2  if (n1 == null) {
3    const instance = n2.instance = {
4      props: reactive(n2.props), // initProps
5      render: null,
6      update: null,
7      subTree: null,
8      vnode: n2,
9      effects: [], // 用来存 setup 中调用 watchEffect 和 computed 的 effect
10    }
11    setCurrentInstance(instance)
12    const render = instance.render = n2.type.setup(instance.props)
13    setCurrentInstance(null)
14    // update effect...
15  } else {
16    // update...
17  }
18}

组件的 setup 只会调用一次，所以在这里调用 setCurrentInstance 即可，这是与 React.FC 的主要区别之一

reactivity/api-watch.js

1import { effect, stop } from '../reactivity'
2import { recordInstanceBoundEffect, getCurrentInstance } from './component'
3
4export const watchEffect = (cb, { onTrack, onTrigger } = {}) => {
5  let cleanup
6  const onInvalidate = (fn) => cleanup = e.options.onStop = fn
7  const getter = () => {
8    if (cleanup) {
9      cleanup()
10    }
11    return cb(onInvalidate)
12  }
13
14  const e = effect(getter, {
15    onTrack,
16    onTrigger,
17    // 这里我们写成 lazy 主要是为了 onInvalidate 正常运行
18    // 不 lazy 的话 onInvalidate 会在 e 定义好之前运行，onInvalidate 中有使用了 e，就会报错
19    lazy: true,
20  })
21  e()
22
23  recordInstanceBoundEffect(e)
24  const instance = getCurrentInstance()
25
26  return () => {
27    stop(e)
28    if (instance) {
29      const { effects } = instance
30      const i = effects.indexOf(e)
31      if (i > -1) effects.splice(i, 1) // 清除 effect 时也要把 instance 上的去掉
32    }
33  }
34}

watchEffect 的回调函数还可以传入一个 onInvalidate 方法用于注册失效时的回调，执行时机是副作用即将重新执行时和侦听器被停止（如果在 setup() 中使用了 watchEffect, 则在卸载组件时），相当于 React.useEffect 返回的 cleanup 函数，至于为什么不设计成与 React.useEffect 一样返回 cleanup，是因为 watchEffect 被设计成支持参数传入异步函数的

1const useLogger = () => {
2  let id
3  return {
4    logger: (v, time = 2000) => new Promise(resolve => {
5      id = setTimeout(() => {
6        console.log(v)
7        resolve()
8      }, time)
9    }),
10    cancel: () => {
11      clearTimeout(id)
12      id = null
13    },
14  }
15}
16
17const App = {
18  setup(props) {
19    const count = ref(0)
20    const { logger, cancel } = useLogger()
21
22    watchEffect(async (onInvalidate) => {
23      onInvalidate(cancel) // 异步调用之前就注册失效时的回调
24      await logger(count.value)
25    })
26
27    return () => <button onClick={() => count.value++}>log</button>
28  }
29}

继续看 computed 怎么绑定 effect

reactivity/api-computed.js

1import { stop, computed as _computed } from '../reactivity'
2import { recordInstanceBoundEffect } from './component'
3
4export const computed = (options) => {
5  const computedRef = _computed(options)
6  recordInstanceBoundEffect(computedRef.effect) // computed 内部实现也用到了 effect 哦
7  return computedRef
8}

就是通过在 setup 调用时设置 currentInstance，然后把 setup 中的 effect 放到 currentInstance.effects 上，最后 unmount 时一一 stop

最后我们再实现组件和 watchEffect 的异步调用

reactivity/scheduler.js

1const resolvedPromise = Promise.resolve()
2const queue = [] // 相对于 DOM 更新是同步的
3
4export const queueJob = (job) => {
5  queue.push(job)
6  resolvedPromise.then(() => { // syncQueue 中的 callbacks 还是会加入到微任务中执行
7    const deduped = [...new Set(queue)]
8    queue.length = 0
9    deduped.forEach(job => job())
10  })
11}

reactivity/renderer.js

1const processComponent = (n1, n2, container) => {
2  // createInstance, setup...
3    instance.update = effect(() => {
4      // patch...
5    }, { scheduler: queueJob }) // 没有 lazy，mount 时没必要通过异步调用
6  // ...
7}

reactivity/api-watch.js

1import { queueJob } from './scheduler'
2
3const afterPaint = requestAnimationFrame
4export const watchEffect = (cb, { onTrack, onTrigger } = {}) => {
5  // onInvalidate...
6  const scheduler = (job) => queueJob(() => afterPaint(job))
7  const e = effect(getter, {
8    lazy: true,
9    onTrack,
10    onTrigger,
11    scheduler,
12  })
13  scheduler(e) // init run, run by scheduler (effect 的 lazy 为 false 时，即使有 scheduler 它的 init run 也不会通过 schduler 运行)
14  // bind effect on instance, return cleanup...
15}

这里 watchEffect 进入微任务中又加到 afterPaint 是模仿了 React.useEffect 的调用时机，源码中并不是这样的，源码中实现了 flush: 'pre' | 'sync' | 'post' 这三种模式，我们这里为了简单做了一些修改

其实就是创建一个队列，然后把更新和 watchEffect 的回调函数放到队列中，之后队列中的函数会通过 promise.then 放到微任务队列中去执行，实现异步更新

现在终于完成了！写一个 demo 看看效果～

1/** @jsx h */
2import { ref } from '../../packages/reactivity'
3import { h, createRenderer, watchEffect } from '../../packages/runtime-core'
4
5const Displayer = {
6  setup(props) {
7    return () => (
8      <div>{props.children}</div>
9    )
10  }
11}
12
13const App = {
14  setup(props) {
15    const count = ref(0)
16    const inc = () => count.value++
17
18    watchEffect(() => console.log(count.value))
19
20    return () => (
21      <div>
22        <button onClick={inc}> + </button>
23        {count.value % 2 ? <Displayer>{count.value}</Displayer> : null}
24      </div>
25    )
26  }
27}
28
29createRenderer().render(<App />, document.querySelector('#root'))

⚡️ key diff

这里我们只给出简单版的实现（React 使用的 key diff，相比 Vue 使用的少了些优化，但是简单易懂），具体讲解可以看这篇渲染器的核心 Diff 算法，是一位 Vue Team Member 写的，应该没有文章讲的比这篇更清晰易懂了

runtime-core/renderer.js

1const patchChildren = (n1, n2, container) => {
2  const oldChildren = n1.children
3  let newChildren = n2.props.children
4  newChildren = isArray(newChildren) ? newChildren : [newChildren]
5  n2.children = []
6
7  let lastIndex = 0 // 存上一次 j 的值
8  for (let i = 0; i < newChildren.length; i++) {
9    if (newChildren[i] == null) continue
10    let newChild = newChildren[i]
11    newChild = isText(newChild) ? h(TextType, { nodeValue: newChild }) : newChild
12    n2.children[i] = newChild
13    newChild.parent = n2
14
15    let find = false
16    for (let j = 0; j < oldChildren.length; j++) {
17      if (oldChildren[j] == null) continue
18      if (isSameVNodeType(oldChildren[j], newChild)) { // update
19        const oldChild = oldChildren[j]
20        oldChildren[j] = null
21        find = true
22
23        patch(oldChild, newChild, container)
24
25        if (j < lastIndex) { // j 在上一次 j 之前，需要移动
26          // 1. 目前组件的 VNode.node 为 null，后面我们会 fix
27          // 2. newChildren[i - 1] 因为在上一轮已经 patch 过了，所以 node 不为 null
28          const refNode = getNextSibling(newChildren[i - 1])
29          move(oldChild, container, refNode)
30        } else { // no need to move
31          lastIndex = j
32        }
33        break
34      }
35    }
36    // mount
37    if (!find) {
38      const refNode = i - 1 < 0
39        ? getNode(oldChildren[0])
40        : getNextSibling(newChildren[i - 1])
41      patch(null, newChild, container, refNode)
42    }
43  }
44
45  for (let oldChild of oldChildren) {
46    if (oldChild != null) unmount(oldChild)
47  }
48}

之前是不涉及节点移动的，不管有没有节点一律 appendChild，现在需要加上节点移动的情况，就需要处理没有节点时新添加节点的 mount，对于移动的节点需要找到要移动到的位置（refNode 前面）

现在 mount 新节点时进行插入需要向 patch 传入 refNode，需要相应的更改之前的 patch，同时取 refNode 和 move 时会根据 type 不同操作也不同，我们这里将这几个操作进行封装

现在根据 type 不同封装出的操作有这些，patch 用来进入 VNode 更新，getNode 用于插入新 VNode 时取 oldChildren[0] 的 node，getNextSibling 用于取移动 VNode 时取 nextSibling，move 用来移动节点，unmount 用来移除 VNode，这些操作都是在该 diff 算法下会根据 type 不同有不同操作的一个封装，此外再算上 mountChildren、patchChildren 和 renderOptions，作为 internals 传入 type 的这五个方法中（剩余的方法可以通过以上方法调用到，所以不用暴露出去），用于深度定制组件，下一篇会详细讲 Vue3 Compat，表示 Vue3 中周边组件和一些其他新特性的实现原理，作为本篇的补充

runtime-core/renderer.js

1const patch = (n1, n2, container, anchor = null) => { // insertBefore(node, null) 就相当于 appendChild(node)
2  // unmount...
3
4  const { type } = n2
5  if (isSetupComponent(type)) {
6    processComponent(n1, n2, container, anchor)
7  } else if (isString(type)) {
8    processElement(n1, n2, container, anchor)
9  } else if (isTextType(type)) {
10    processText(n1, n2, container, anchor)
11  } else {
12    type.patch(/* ... */)
13  }
14}
15
16const getNode = (vnode) => { // patchChildren 在插入新 VNode 时调用 getNode(oldChildren[0])
17  if (!vnode) return null // oldChildren[0] 为 null 是返回 null 相当于 appendChild
18  const { type } = vnode
19  if (isSetupComponent(type)) return getNode(vnode.instance.subTree)
20  if (isString(type) || isTextType(type)) return vnode.node
21  return type.getNode(internals, { vnode })
22}
23
24const getNextSibling = (vnode) => { // patchChildren 在进行移动 VNode 前获得 refNode 调用
25  const { type } = vnode
26  if (isSetupComponent(type)) return getNextSibling(vnode.instance.subTree)
27  if (isString(type) || isTextType(type)) return hostNextSibling(vnode.node)
28  return type.getNextSibling(internals, { vnode })
29}
30
31const move = (vnode, container, anchor) => { // patchChildren 中用于移动 VNode
32  const { type } = vnode
33  if (isSetupComponent(type)) {
34    move(vnode.instance.subTree, container, anchor)
35  } else if (isString(type) || isTextType(type)) {
36    hostInsert(vnode.node, container, anchor)
37  } else {
38    type.move(internals, { vnode, container, anchor })
39  }
40}
41
42const processComponent = (n1, n2, container, anchor) => {
43  if (n1 == null) {
44    // ...
45      patch(instance.subTree, renderResult, container, anchor)
46    // ...
47  } else {
48    // ...
49  }
50}
51
52const processElement = (n1, n2, container, anchor) => {
53  if (n1 == null) {
54    // ...
55    container.insertBefore(node, anchor)
56  } else {
57    // ...
58  }
59}
60
61const processText = (n1, n2, container, anchor) => {
62  if (n1 == null) {
63    // ...
64    container.insertBefore(node, anchor)
65  } else {
66    // ...
67  }
68}
69
70const mountChildren = (vnode, container, isSVG, anchor) => {
71  // ...
72  for (/* ... */) {
73    // ...
74    patch(null, child, container, isSVG, anchor)
75  }
76}

🎨 Renderer

现在我们的 runtime 基本完成了，之前为了写起来方便并没有抽离出来平台操作，现在我们抽离出来，然后把原来的从传入的 renderOptions 引入即可

runtime-dom/index.js

1import { createRenderer, h } from '../runtime-core'
2
3const nodeOps = {
4  querySelector: (sel) => document.querySelector(sel),
5
6  insert: (child, parent, anchor) => {
7    parent.insertBefore(child, anchor ?? null)
8  },
9
10  remove: child => {
11    const parent = child.parentNode
12    if (parent) {
13      parent.removeChild(child)
14    }
15  },
16
17  createElement: (tag) => document.createElement(tag),
18
19  createText: text => document.createTextNode(text),
20
21  nextSibling: node => node.nextSibling,
22
23  setProperty: (node, propName, newValue, oldValue) => {
24    if (propName[0] === 'o' && propName[1] === 'n') {
25      const eventType = propName.toLowerCase().slice(2);
26  
27      if (!node.listeners) node.listeners = {};
28      node.listeners[eventType] = newValue;
29  
30      if (newValue) {
31        if (!oldValue) {
32          node.addEventListener(eventType, eventProxy);
33        }
34      } else {
35        node.removeEventListener(eventType, eventProxy);
36      }
37    } else if (newValue !== oldValue) {
38      if (propName in node) {
39        node[propName] = newValue == null ? '' : newValue
40      } else if (newValue == null || newValue === false) {
41        node.removeAttribute(propName)
42      } else {
43        node.setAttribute(propName, newValue)
44      }
45    }
46  },
47}
48
49function eventProxy(e) {
50  // this: node
51  this.listeners[e.type](e)
52}
53
54export const createApp = (rootComponent) => ({
55  mount: (rootSel) =>
56    createRenderer(nodeOps).render(h(rootComponent), nodeOps.querySelector(rootSel))
57})

runtime-core/renderer.js

1export function createRenderer(renderOptions) {
2  const {
3    createText: hostCreateText,
4    createElement: hostCreateElement,
5    insert: hostInsert,
6    nextSibling: hostNextSibling,
7    setProperty: hostSetProperty,
8    remove: hostRemove,
9  } = renderOptions
10  // ...
11}

😃 ramble

之前 Vue2 的时候一直对 Vue 不太感兴趣，觉得没 React 精简好用，而且那时候 React 已经有 Hooks 了，后来 Vue Reactivity 和 Composition API 出现后，同时越发觉得 Hooks 有很重的心智负担，才逐渐想去深入了解 Vue，从之前写 Reactivity 解析到现在写 runtime，发现 Vue3 的心智负担并没有想象中的那么少，但还是抵挡不住它的简单好用
对 Vue 的越来越深入也让我越发觉得 Vue 和 React 很多地方是一样的，也发现了它们核心部分的不同，Vue 就是 Proxy 实现的响应式 + VDOM runtime + 模版 complier，React 因为是一遍一遍的刷新，所以是偏向函数式的 Hooks + VDOM runtime (Fiber) + Scheduler，所以总结来说一个前端框架的核心就是数据层（reactivity、hooks、ng service）和视图连接层（VDOM、complier）
没有处理 svg，但是也很简单，这篇写的时候改了很多次，感觉已经写的很复杂了，所以在有的地方做了简化，更完整的可以看这个仓库

simple-vue/runtime-core 实现完整代码

Vue Reactivity in Depth

Fri, 28 Aug 2020 00:00:00 GMT

序
⭐️ reactive
🌥 baseHandlers
🚀 effect
☁️ collectionHandlers
💫 ref
☄️ computed
😃 ramble

序

首先一起实现一个简易的 reactivity 吧，穿插着会提到源码中的一些细节，建议先跟着写写，细节可以 clone 下来 vue-next 打开源码跟着看

⭐️ reactive

首先是 reactive，它的作用是把一个对象变成响应式对象，更准确的说是 Object, Array, Map, WeakMap, Set, weakSet 这几种对象变为响应式

类似于 reactive 也有 readonly，将一个对象变为不可变对象

reactivity/reactive.js

1export function reactive(target) {
2  return createReactiveObject(target, false, mutableHandlers, mutableCollectionHandlers)
3}
4
5export function readonly(target) {
6  return createReactiveObject(target, true, readonlyHandlers, readonlyCollectionHandlers)
7}

实际上是可以 readonly(reactive(obj)) 将一个 reactive 对象转换为 readonly 对象的，而 reactive(readonly(obj)) 仍然返回 readonly 对象，实现是在 reactive 入口判断 target 是不是 readonly，是就直接返回，而 readonly 入口不做判断，可以将 reactive 对象在做一层代理，转换为 readonly
1const original = reactive({ count: 0 })
2const copy = readonly(original)
3
4effect(() => {
5  // works for reactivity tracking
6  console.log(copy.count)
7})
8
9// mutating original will trigger watchers relying on the copy
10original.count++
11// mutating the copy will fail and result in a warning
12copy.count++ // warning!
对于这种情况是在 reactive 代理上在加了一层 readonly 代理，当 readonly 对象的 get 触发时会调用 reactive 对象的 get 以触发 track，之后原 reactive 对象修改后对于 readonly 对象的 effect 就也会触发

这两种对象实现是相似的，我们通过 createReactiveObject 创建这两种对象，但在这之前我们先定义一些常量和工具函数

shared/index.js

1export const isObject = (value) => typeof value === 'object' && value !== null

reactivity/reactive.js

1// proxy 实例上的标识
2export const ReactiveFlags = {
3  IS_REACTIVE: '__v_isReactive',
4  IS_READONLY: '__v_isReadonly',
5  RAW: '__v_raw', // 原对象
6}
7
8const TargetType = {
9  COMMON: 'COMMON', // 表示 Object 和 Array
10  COLLECTION: 'COLLECTION', // 表示 Map、Set、WeakMap、WeakSet
11  INVALID: 'INVALID', // 其他不处理的
12}
13
14// 判断类型
15const getTargetType = (target) => {
16  const getTypeString = (target) => {
17    return Object.prototype.toString.call(target).slice(8, -1)
18  }
19  const typeString = getTypeString(target)
20  switch (typeString) {
21    case 'Object':
22    case 'Array':
23      return TargetType.COMMON
24    case 'Map':
25    case 'Set':
26    case 'WeakMap':
27    case 'WeakSet':
28      return TargetType.COLLECTION
29    default:
30      return TargetType.INVALID
31  }
32}
33
34export function toRaw(ob) {
35  return (ob && toRaw(ob[ReactiveFlags.RAW])) || ob
36}

ReactiveFlags 是 proxy 上的一些常量的定义。对于 target 类型的判断，在 createReactiveObject 中对于 COMMON 和 COLLECTION 有不同的 handlers 来处理。toRaw 用来取一个 reactive 对象的原对象，通过递归实现，非常巧妙

下面来看 createReactiveObject 的实现

reactivity/reactive.js

1export const reactiveMap = new WeakMap()
2export const readonlyMap = new WeakMap()
3
4function createReactiveObject(target, isReadonly, baseHandlers, collectionHandlers) {
5  if (!isObject(target)) {
6    throw new Error(`value cannot be made reactive: ${String(target)}`)
7  }
8  if (
9    target[ReactiveFlags.RAW] && // 已经是 reactive 或 readonly 对象
10    !(isReadonly && target[ReactiveFlags.IS_REACTIVE]) // 排除 readonly(reactiveObj) 这种情况
11  ) {
12    return target
13  }
14  // 已经有了对应的 proxy
15  const proxyMap = isReadonly ? readonlyMap : reactiveMap
16  const existingProxy = proxyMap.get(target)
17  if (existingProxy) {
18    return existingProxy
19  }
20  // 获取 typeString 判断是不是 collectionType（Map、Set、WeakMap、WeakSet）
21  const targetType = getTargetType(target)
22  if (targetType === TargetType.INVALID) {
23    return target
24  }
25
26  const observed = new Proxy(
27    target,
28    // Map、Set、WeakMap、WeakSet 通过 collectionHandlers 代理，Object、Array 通过 baseHandlers 代理
29    targetType === TargetType.COLLECTION ? collectionHandlers : baseHandlers
30  )
31  proxyMap.set(target, observed) // 存对应 proxy
32  return observed
33}

可以看到通过两个 WeakMap 来存对象对应的 reactive 实例和 readonly 实例，再次调用时就可以直接返回

然后通过 Proxy 进行代理，我们先看对于 Object 和 Array 的代理 mutableHandlers 和 readonlyHandlers

🌥 baseHandlers

reactivity/baseHandlers.js

1const get = createGetter()
2const readonlyGet = createGetter(true)
3
4const set = createSetter()
5
6export const mutableHandlers = {
7  get,
8  set,
9  deleteProperty,
10  has,
11  ownKeys,
12}
13
14export const readonlyHandlers = {
15  get: readonlyGet,
16  set(target, key) {
17    console.warn(
18      `Set operation on key "${String(key)}" failed: target is readonly.`,
19      target
20    )
21    return true
22  },
23  deleteProperty(target, key) {
24    console.warn(
25      `Delete operation on key "${String(key)}" failed: target is readonly.`,
26      target
27    )
28    return true
29  },
30}

可以看到 readonly 与 reactive 的不同就在于 readonly 代理的修改操作，修改时不会真正去修改对象，并在开发模式下报警告；readonly 代理的 get、has、ownKeys 操作不会去 track 收集依赖，get 比较特殊，has、ownKeys 可以直接用原对象操作就不会 track，直接不加即可

呜呜呜～我的 PR 没被 merge：PR: readonly object should not track on 'has' and 'ownKeys'

对于 get、readonlyGet 和 set 则是通过 createGetter 和 createSetter 创建

reactivity/baseHandlers.js

1function createGetter(isReadonly = false) {
2  return function get(target, key, receiver) {
3    if (key === ReactiveFlags.IS_REACTIVE) return !isReadonly
4    if (key === ReactiveFlags.IS_READONLY) return isReadonly
5    if (
6      key === ReactiveFlags.RAW &&
7      receiver === (isReadonly ? readonlyMap : reactiveMap).get(target)
8    ) {
9      return target
10    }
11
12    const res = Reflect.get(target, key, receiver)
13    if (!isReadonly) track(target, TrackOpTypes.GET, key)
14    if (isObject(res)) {
15      return isReadonly ? readonly(res) : reactive(res)
16    }
17    return res
18  }
19}
20
21function createSetter() {
22  return function set(target, key, value, receiver) {
23    const oldValue = target[key]
24    const res = Reflect.set(target, key, value, receiver)
25    if (target === receiver[ReactiveFlags.RAW] && hasChanged(value, oldValue)) {
26      trigger(target, TriggerOpTypes.SET, key)
27    }
28    return res
29  }
30}

这两个函数通过 isReadonly 的不同创建不同的 getter 和 setter，形成闭包存 isReadonly 的值，返回的 getter 代理 reactive 对象和 readonly 对象的 get 操作，当 key 是 __v_isReactive、__v_raw、__v_isReadonly 这几个 ReactiveFlags 常量时，就直接通过参数返回对应的结果，所以这几个常量并没有挂载在 proxy 实例上，而是通过代理 get 操作实现，保证了 proxy 实例上没有多余的属性

setter 并没有传 isReadonly，这里实际上并不需要 createSetter 实现，但在源码中还有 shallowReactive 的情况，需要判断 isShallow，这里为了精简省略了 shallow 对应的实现

之后就是代理后主要的操作了，首先通过 Reflect.get 取得 value，然后进行 track，也就是依赖收集，track 其实是实现响应式的前半部分，后半部分就是 trigger 触发依赖

最后判断 value 是否是对象，如果是就进行对应的 reactive 或 readonly，这样在结果处进行响应式，lazy 的进行深度递归，实现深度响应式的同时，也防止了循环引用导致的无限递归

Proxy 的代理只能代理一层，是浅的，reactive 实现的是深度响应式
源码中 reactive Object get 取出来如果是 ref 会自动返回 value，reactive Array 则不会，详细可以看看 Issues: Stable mutation of reactive arrays containing refs
源码中 arrayInstrumentations 的原因可以看这个 commit 的 test case

setter 代理操作也类似，先通过 Reflect.set 得到 set 的结果，然后 trigger 触发依赖，最后返回结果，这里一定要先执行 set 后再 trigger，effect 中可能有操作依赖于 set 后的对象，先 set 能保证 effect 中的函数执行出正确的结果

其他的 deleteProperty、has、ownKeys 也类似，得到结果然后触发 track 或 trigger，最后返回结果。deleteProperty 类似 set 会触发依赖比较好理解，那 has、ownKeys 为什么会收集依赖呢？因为有时需要判断 proxy 是否有 key 属性，或者依赖于 proxy 的 keys 等情况，在新增和删除 key 时就需要触发对应的 effect

1effect(() => console.log(Object.keys(proxy)))
2effect(() => console.log(key in proxy))

代理 ownKeys 时只有一个 target 参数，ownKeys 的操作并不需要 key，但是 track 和 trigger 至少需要 target 和对应的 key 以找到依赖，这时可以定义一个 ITERATE_KEY 常量，专门处理这种遍历而不需要 key 的情况

reactivity/baseHandlers.js

1export const ITERATE_KEY = Symbol('iterate')
2
3function ownKeys(target) {
4  track(target, TrackOpTypes.ITERATE, ITERATE_KEY)
5  return Reflect.ownKeys(target)
6}

所以什么是响应式对象呢？个人理解响应式对象与普通对象的区别就在于响应式对象的操作可以通过 proxy 代理以调用 track 收集依赖或调用 trigger 触发依赖

🚀 effect

上面提到很多次依赖收集和触发依赖了，那到底什么是依赖呢？依赖其实就是 effect 函数，我们先看 track 的实现

reactivity/effect.js

1const targetMap = new WeakMap()
2
3let activeEffect
4
5export function track(target, type, key) {
6  if (activeEffect == null) return
7
8  let depsMap = targetMap.get(target)
9  if (!depsMap) {
10    targetMap.set(target, (depsMap = new Map()))
11  }
12
13  let dep = depsMap.get(key)
14  if (!dep) {
15    depsMap.set(key, (dep = new Set()))
16  }
17
18  if (!dep.has(activeEffect)) {
19    dep.add(activeEffect)
20    activeEffect.deps.push(dep)
21  }
22}

首先判断当前的 activeEffect 有没有，没有就直接返回，之后通过 targetMap 拿到 target 对应的 depsMap，再通过 depsMap 拿到 key 对应的 dep，dep 是一个 Set，存储 target.key 需要的 effect 依赖，而 effect 又通过 deps 数组存储依赖于 effect 的所有 dep，建立一个双向的收集，dep 到 effect 是为了 trigger 使用，而 effect 到 dep 是为了 effect 调用时找到依赖于这个 effect 所有 dep，从 dep 中删除这个调用过的 effect，用来清除上一轮的依赖，防止本轮触发多余的依赖

reactivity/effect.js

1export function effect(fn, options = {}) {
2  const effect = createReactiveEffect(fn, options)
3  if (!options.lazy) {
4    effect()
5  }
6  return effect
7}
8
9// 停止监听
10export function stop(effect) {
11  if (effect.active) {
12    cleanup(effect)
13    effect.active = false
14  }
15}
16
17function createReactiveEffect(fn, options) {
18  const effect = function reactiveEffect() {
19    if (!effect.active) return effect.options.scheduler ? undefined : fn()
20    if (!effectStack.includes(effect)) {
21      cleanup(effect) // effect 调用时会清除上一轮的依赖，防止本轮触发多余的依赖
22      try {
23        effectStack.push(effect) // 可能有 effect 中调用另一个 effect 的情况，模拟一个栈来处理
24        activeEffect = effect
25        return fn() // let value = effect() 将函数的结果返回，可以从外面去到结果
26      } finally {
27        effectStack.pop()
28        activeEffect = effectStack[effectStack.length - 1]
29      }
30    }
31  }
32  effect.active = true // active 判断 effect 是否还活着，stop(effect) 后 active 就是 false
33  effect.deps = [] // 收集对应的 dep，cleanup 时以找到 dep，从 dep 中清除 effect
34  effect.options = options // 存放 onTrack、onTrigger、onStop 等钩子函数，为了精简我们只实现 scheduler
35  return effect
36}
37
38function cleanup(effect) {
39  const { deps } = effect
40  deps.forEach(dep => dep.delete(effect)) // deps 中的 dep 清 effect
41  deps.length = 0 // 清空 effect 的 deps
42}

可以看到 effect API 传入一个函数，effect API 通过 createReactiveEffect 创建一个 effect 函数，并返回这个函数，这个函数的返回值就是传入 effect API 函数的结果，只不过在调用 effect 函数时会把 activeEffect 赋值为当前这个调用中的 effect，并在调用结束后把 activeEffect 改回去

effect 函数创建后如果不是 lazy 的会首先执行一次，这次执行是为了调用 fn，触发 get 等代理，以先收集一遍依赖，先 track 了之后再 trigger 才能有依赖来触发，如果 options 传入了 lazy 为 true，就需要保证先手动执行一遍 effect 函数来收集依赖

effect API 其实是一个比较底层的函数，我们平时使用都是用 watchEffect 和 watch，这两个都是基于 effect 实现的，比如调用这两个函数返回的是一个 stop 函数用来停止监听，其实就是对上面的一个封装，但为什么 effect API 不直接返回一个 stop 函数，而是返回一个 effect 函数？因为 effect 函数可以取传入函数的结果，其他一些 API 的实现需要这个结果，所以 effect API 和 stop 函数设计成了分开的

下面我们看 trigger 的实现

reactivity/effect.js

1export function trigger(target, type, key) {
2  const depsMap = targetMap.get(target)
3  if (!depsMap) return
4  // 需要新建一个 set，如果直接 const effect = depsMap.get(key)
5  // effect 函数执行时 track 的依赖就也会在这一轮 trigger 执行，导致无限循环
6  const effects = new Set()
7  const add = (effectsToAdd) => {
8    if (effectsToAdd) {
9      effectsToAdd.forEach(effect => {
10        // 不要添加自己当前的 effect，否则之后 run（mutate）的时候
11        // 遇到 effect(() => foo.value++) 会导致无限循环
12        if (effect !== activeEffect) effects.add(effect)
13      })
14    }
15  }
16  // SET | ADD | DELETE
17  if (key !== undefined) {
18    add(depsMap.get(key))
19  }
20  const shouldTriggerIteration =
21    (type === TriggerOpTypes.ADD) ||
22    (type === TriggerOpTypes.DELETE)
23  // iteration key on ADD | DELETE
24  if (shouldTriggerIteration) {
25    add(depsMap.get(isArray(target) ? 'length' : ITERATE_KEY))
26  }
27
28  effects.forEach((effect) => {
29    if (effect.options.scheduler) {
30      effect.options.scheduler(effect)
31    } else {
32      effect()
33    }
34  })
35}

也很好理解，就是新建一个 Set，存通过 targetMap 和 depsMap 拿到的依赖（effect 函数），要注意不能将当前的 activeEffect 添加进去，否则可能会无限循环，同时针对触发 trigger 的不同方式（type）也有不同的添加方式，比如在新增或删除 key 导致 trigger 时需要把 length 或 ITERATE_KEY 的依赖也添加进去，对应上面 track ITERATE_KEY，最后依次执行即可

为什么需要新建一个 Set，而不直接用 targetMap.get(target).get(key).forEach(run) 呢？因为 effect 函数在执行的过程中会继续 track 向 depsMap 的 dep 中添加依赖，导致这里一直 trigger effect，effect 中又一直 track，无限循环

为什么不能解构？由于是通过 Proxy 代理对象的 get 操作，相当于 proxy.key 每次都这样访问数据才能成功收集到依赖，解构的话是 let key = proxy.key 获取了 key 的值，之后通过 key 访问数据没有进入代理的 get 操作，所以不会收集到依赖

最后我们来看一个例子，走一遍整体的流程，以便更好的理解

1<!DOCTYPE html>
2<html lang="en">
3<head>
4  <title>Counter</title>
5</head>
6<body>
7  <div class="count"></div>
8  <button class="inc">+</button>
9  <button class="dec">-</button>
10<script type="module">
11  import { reactive, effect } from '../../packages/reactivity/index.js'
12
13  const $inc = document.querySelector('.inc')
14  const $dec = document.querySelector('.dec')
15  const $count = document.querySelector('.count')
16
17  const obj = { count: 0 }
18  const state = reactive(obj)
19
20  effect(() => {
21    $count.innerHTML = state.count
22  })
23
24  $inc.addEventListener('click', () => {
25    state.count++
26  })
27
28  $dec.addEventListener('click', () => {
29    state.count--
30  })
31</script>
32</body>
33</html>

这里首先用 reactive 定义 state，传入 effect，然后 effect 会先执行一遍，将 activeEffect 设置为它，然后 cleanup 一遍，因为本来就是空的所以也没什么用，之后执行到 $count.innerHTML = state.count 触发 state 的 get 代理，get 中调用 track(obj, TrackOpTypes.GET, 'count')，将 activeEffect 收集到 dep（targetMap.set(obj, depsMap.set('count', activeEffect))）中，最后赋值 activeEffect 为 undefined，到此 effect 首次执行完毕

然后绑定好事件，之后点击触发事件会触发 state 的 set 代理，调用 trigger(obj, TriggerOpTypes.SET, 'count')，依次执行刚刚收集好的 effects，触发依赖，也就是执行 effect(() => { $count.innerHTML = state.count) }，其中 effect 执行时更上面第一次执行一样，设置 activeEffect 然后 cleanup 上一次的依赖，再访问 state.count 触发 get 代理，再把 activeEffect track 起来，完成依赖收集，最后重新设置 activeEffect

所以流程基本上是这样的：(track effects) => (trigger effects, track effects) => (trigger effects, track effects) => ...

现在已经讲完了响应式的核心原理，剩下的来讲一下 collectionHandlers、ref、computed

☁️ collectionHandlers

为什么 Map、Set、WeakMap、WeakSet 需要另一种 handlers 来处理呢？因为这些类型的 key 都是固定的，比如调用 map.set、map.get、map.has、map.delete 都会触发代理的 get 操作，set、get、has、delete 这些就是他们 key，只有 map.get = ... 才能触发代理的 set 操作，所以就需要 collectionHandlers 代理 get，针对不同的 key 进行不同的代理