update

fix: typo

SQL/231.SQL 入门.md

@@ -0,0 +1,174 @@
+本系列是 SQL 系列的开篇，介绍一些宏观与基础的内容。
+
+## SQL 是什么？
+
+SQL 是一种结构化查询语言，用于管理关系型数据库，我们 90% 接触的都是查询语法，但其实它包含完整的增删改查和事物处理功能。
+
+## 声明式特性
+
+SQL 属于声明式编程语言，而现代通用编程语言一般都是命令式的。但是不要盲目崇拜声明式语言，比如说它未来会代替低级的命令式语言，因为声明式本身也有它的缺点，它与命令式语言也有相通的地方。
+
+为什么我们觉得声明式编程语言更高级？因为声明式语言抽象程度更高，比如 `select * from table1` 仅描述了要从 table1 查询数据，但查询的具体步骤的完全没提，这背后可能存在复杂的索引优化与锁机制，但我们都无需关心，这简直是编程的最高境界。
+
+那为什么现在所有通用业务代码都是命令式呢？因为 **命令式给了我们描述具体实现的机会** ，而通用领域的编程正需要建立在严谨的实现细节上。比如校验用户权限这件事，即便 AI 编程提供了将 “登陆用户仅能访问有权限的资源” 转化为代码的能力，我们也不清楚资源具体指哪些，以及在权限转移过程中的资源所有权属于谁。
+
+SQL 之所以能保留声明式特性，完全因为锁定了关系型数据管理这个特定领域，而恰恰对这个领域的需求是标准化且可枚举的，才使声明式成为可能。
+
+基于命令式语言也完全可拓展出声明式能力，比如许多 ORM 提供了类似 `select({}).from({}).where({})` 之类的语法，甚至一个 `login()` 函数也是声明式编程的体现，因为调用者无需关心是如何登陆的，总之调用一下就完成了登陆，这不就是声明式的全部精髓吗？
+
+## 语法分类
+
+作为关系型数据库管理工具，SQL 需要定义、操纵与控制数据。
+
+数据定义即修改数据库与表级别结构，这些是数据结构，或者是数据元信息，它不代表具体数据，但描述数据的属性。
+
+数据操纵即修改一行行具体数据，增删改查。
+
+数据控制即对事务、用户权限的管理与控制。
+
+### 数据定义
+
+DDL（Data Definition Language）数据定义，包括 `CREATE` `DROP` `ALTER` 方法。
+
+### 数据操纵
+
+DML（Data Manipulation Language）数据操纵，包括 `SELECT` `INSERT` `UPDATE` `DELETE` 方法。
+
+### 数据控制
+
+DCL（Data Control Language）数据控制，包括 `COMMIT`、`ROLLBACK` 等。
+
+所有 SQL 操作都围绕这三种类型，其中数据操纵几乎占了 90% 的代码量，毕竟数据查询的诉求远大于写，数据写入对应数据采集，而数据查询对应数据分析，数据分析领域能玩出的花样远比数据采集要多。
+
+PS：有些情况下，会把最重要的 `SELECT` 提到 DQL（Data Query Language）分类下，这样分类就变成了四个。
+
+## 集合运算
+
+SQL 世界的第一公民是集合，就像 JAVA 世界第一公民是对象。我们只有以集合的视角看待 SQL，才能更好的理解它。
+
+何为集合视角，即所有的查询、操作都是二维数据结构中进行的，而非小学算术里的单个数字间加减乘除关系。
+
+集合的运算一般有 `UNION` 并集、`EXCEPT` 差集、`INTERSECT` 交集，这些都是以行为单位的操作，而各种 JOIN 语句则是以列为单位的集合运算，也是后面提到的连接查询。
+
+只要站在二维数据结构中进行思考，运算无非是横向或纵向的操作。
+
+## 数据范式
+
+数据范式分为五层，每层要求都比上一层更严苛，因此是一个可以逐步遵循的范式。数据范式要求数据越来越解耦，减少冗余。
+
+比如第一范式要求每列都具有原子性，即都是不可分割的最小数据单元。如果数据采集时，某一列作为字符串存储，并且以 "|" 分割表示省市区，那么它就不具有原子性。
+
+当然实际生产过程往往不都遵循这种标准，因为表不是孤立的，在数据处理流中，可能在某个环节再把列原子化，而原始数据为了压缩体积，进行列合并处理。
+
+希望违反范式的还不仅是底层表，现在大数据处理场景下，越来越多的业务采用大宽表结构，甚至故意进行数据冗余以提升查询效率，列存储引擎就是针对这种场景设计的，所以数据范式在大数据场景下是可以变通的，但依然值得学习。
+
+## 聚合
+
+当采用 GROUP BY 分组聚合数据时，如希望针对聚合值筛选，就不能用 WHERE 限定条件了，因为 WHERE 是基于行的筛选，而不是针对组合的。（GROUP BY 对数据进行分组，我们称这些组为 “组合”），所以需要使用针对组合的筛选语句 HAVING：
+
+```sql
+SELECT SUM(pv) FROM table
+GROUP BY city
+HAVING AVG(uv) > 100
+```
+
+这个例子中，如果 HAVING 换成 WHERE 就没有意义，因为 WHERE 加聚合条件时，需要对所有数据进行合并，不符合当前视图的详细级别。（关于视图详细级别，在我之前写的 [精读《什么是 LOD 表达式》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/215.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BB%80%E4%B9%88%E6%98%AF%20LOD%20%E8%A1%A8%E8%BE%BE%E5%BC%8F%E3%80%8B.md) 有详细说明）。
+
+聚合如此重要，是因为我们分析数据必须在高 LEVEL 视角看，明细数据是看不出趋势的。而复杂的需求往往伴随着带有聚合的筛选条件，明白 SQL 是如何支持的非常重要。
+
+## CASE 表达式
+
+CASE 表达式分为简单与搜索 CASE 表达式，简单表达式：
+
+```sql
+SELECT CASE pv WHEN 1 THEN 'low' ELSE 'high' END AS quality
+```
+
+上面的例子利用 CASE 简单表达式形成了一个新字段，这种模式等于生成了业务自定义临时字段，在对当前表进行数据加工时非常有用。搜索 CASE 表达式能力完全覆盖简单 CASE 表达式：
+
+```sql
+SELECT CASE WHEN pv < 100 THEN 'low' ELSE 'high' END AS quality
+```
+
+可以看到，搜索 CASE 表达式可以用 “表达式” 描述条件，可以轻松完成更复杂的任务，甚至可以在表达式里使用子查询、聚合等手段，这些都是高手写 SQL 的惯用技巧，所以 CASE 表达式非常值得深入学习。
+
+## 复杂查询
+
+SELECT 是 SQL 最复杂的部分，其中就包含三种复杂查询模式，分别是连接查询与子查询。
+
+### 连接查询
+
+指 JOIN 查询，比如 LEFT JOIN、RIGHT JOIN、INNER JOIN。
+
+在介绍聚合时我们提到了，连接查询本质上就是对列进行拓展，而两个表之间不会无缘无故合成一个，所以必须有一个外键作为关系纽带：
+
+```sql
+SELECT A.pv, B.uv
+FROM table1 as t1 LEFT JOIN table2 AS P t2
+ON t1.productId = t2.productId
+```
+
+连接查询不仅拓展了列，还会随之拓展行，而拓展方式与连接的查询的类型有关。除了连接查询别的表，还可以连接查询自己，比如：
+
+```sql
+SELECT t1.pv AS pv1, P2.pv AS pv2
+FROM tt t1, tt t2
+```
+
+这种子连接查询结果就是自己对自己的笛卡尔积，可通过 WHERE 筛选去重，后面会有文章专门介绍。
+
+### 子查询与视图
+
+子查询就是 SELECT 里套 SELECT，一般来说 SELECT 会从内到外执行，只有在关联子查询模式下，才会从外到内执行。
+
+而如果把子查询保存下来，就是一个视图，这个视图并不是实体表，所以很灵活，且数据会随着原始表数据而变化：
+
+```sql
+CREATE VIEW countryGDP (country, gdp)
+AS
+SELECT country, SUM(gdp)
+FROM tt
+GROUP BY country
+```
+
+之后 `countryGDP` 这个视图就可以作为临时表来用了。
+
+这种模式其实有点违背 SQL 声明式的特点，因为定义视图类似于定义变量，如果继续写下去，势必会形成一定命令式思维逻辑，但这是无法避免的。
+
+## 事务
+
+当 SQL 执行一连串操作时，难免遇到不执行完就会出现脏数据的问题，所以事务可以保证操作的原子性。一般来说每个 DML 操作都是一个内置事务，而 SQL 提供的 START TRANSACTION 就是让我们可以自定义事务范围，使一连串业务操作都可以包装在一起，成为一个原子性操作。
+
+对 SQL 来说，原子性操作是非常安全的，即失败了不会留下任何痕迹，成功了会全部成功，不会存在中间态。
+
+## OLAP
+
+OLAP（OnLine Analytical Processing）即实时数据分析，是 BI 工具背后计算引擎实现的基础。
+
+现在越来越多的 SQL 数据库支持了窗口函数实现，用于实现业务上的 runningSum 或 runningAvg 等功能，这些都是数据分析中很常见的。
+
+以 runningSum 为例，比如双十一实时表的数据是以分钟为单位的实时 GMV，而我们要做一张累计到当前时间的 GMV 汇总折线图，Y 轴就需要支持 `running_sum(GMV)` 这样的表达式，而这背后可能就是通过窗口函数实现的。
+
+当然也不是所有业务函数都由 SQL 直接提供，业务层仍需实现大量内存函数，在 JAVA 层计算，这其中一部分是需要下推到 SQL 执行的，只有内存函数与下推函数结合在一起，才能形成我们在 BI 工具看到的复杂计算字段效果。
+
+## 总结
+
+SQL 是一种声明式语言，一个看似简单的查询语句，在引擎层往往对应着复杂的实现，这就是 SQL 为何如此重要却又如此普及的原因。
+
+虽然 SQL 容易上手，但要系统的理解它，还得从结构化数据与集合的概念开始进行思想转变。
+
+不要小看 CASE 语法，它不仅与容易与编程语言的 CASE 语法产生混淆，本身结合表达式进行条件分支判断，是许多数据分析师在日常工作中最长用的套路。
+
+现在使用简单 SQL 创建应用的场景越来越少了，但 BI 场景下，基于 SQL 的增强表达式场景越来越多了，本系列我就是以理解 BI 场景下查询表达式为目标创建的，希望能够学以致用。
+
+> 讨论地址是：[精读《SQL 入门》· Issue #398 · ascoders/weekly](https://github.com/ascoders/weekly/issues/398)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/232.SQL 聚合查询.md

@@ -0,0 +1,199 @@
+SQL 为什么要支持聚合查询呢？
+
+这看上去是个幼稚的问题，但我们还是一步步思考一下。数据以行为粒度存储，最简单的 SQL 语句是 `select * from test`，拿到的是整个二维表明细，但仅做到这一点远远不够，出于以下两个目的，需要 SQL 提供聚合函数：
+
+1. 明细数据没有统计意义，比如我想知道今天的营业额一共有多少，而不太关心某桌客人消费了多少。
+2. 虽然可以先把数据查到内存中再聚合，但在数据量非常大的情况下很容易把内存撑爆，可能一张表一天的数据量就有 10TB，而 10TB 数据就算能读到内存里，聚合计算可能也会慢到难以接受。
+
+另外聚合本身也有一定逻辑复杂度，而 SQL 提供了聚合函数与分组聚合能力，可以方便快速的统计出有业务价值的聚合数据，这奠定了 SQL 语言的分析价值，因此大部分分析软件直接采用 SQL 作为直接面向用户的表达式。
+
+## 聚合函数
+
+常见的聚合函数有：
+
+- COUNT：计数。
+- SUM：求和。
+- AVG：求平均值。
+- MAX：求最大值。
+- MIN：求最小值。
+
+### COUNT
+
+COUNT 用来计算有多少条数据，比如我们看 id 这一列有多少条：
+
+```sql
+SELECT COUNT(id) FROM test
+```
+
+但我们发现其实查任何一列的 COUNT 都是一样的，那传入 id 有什么意义呢？没必要特殊找一个具体列指代呀，所以也可以写成：
+
+```sql
+SELECT COUNT(*) FROM test
+```
+
+但这两者存在微妙差异。SQL 存在一种很特殊的值类型 `NULL`，如果 COUNT 指定了具体列，则统计时会跳过此列值为 `NULL` 的行，而 `COUNT(*)` 由于未指定具体列，所以就算包含了 `NULL`，甚至某一行所有列都为 `NULL`，也都会包含进来。所以 `COUNT(*)` 查出的结果一定大于等于 `COUNT(c1)`。
+
+当然任何聚合函数都可以跟随查询条件 WHERE，比如：
+
+```sql
+SELECT COUNT(*) FROM test
+WHERE is_gray = 1
+```
+
+### SUM
+
+SUM 求和所有项，因此必须作用于数值字段，而不能用于字符串。
+
+```sql
+SELECT SUM(cost) FROM test
+```
+
+SUM 遇到 NULL 值时当 0 处理，因为这等价于忽略。
+
+### AVG
+
+AVG 求所有项均值，因此必须作用于数值字段，而不能用于字符串。
+
+```sql
+SELECT AVG(cost) FROM test
+```
+
+AVG 遇到 NULL 值时采用了最彻底的忽略方式，即 NULL 完全不参与分子与分母的计算，就像这一行数据不存在一样。
+
+### MAX、MIN
+
+MAX、MIN 分别求最大与最小值，与上面不同的是，也可以作用于字符串上，因此可以根据字母判断大小，从大到小依次对应 `a-z`，但即便能算，也没有实际意义且不好理解，因此不建议对字符串求极值。
+
+```sql
+SELECT MAX(cost) FROM test
+```
+
+### 多个聚合字段
+
+虽然都是聚合函数，但 MAX、MIN 严格意义上不算是聚合函数，因为它们只是寻找了满足条件的行。可以看看下面两段查询结果的对比：
+
+```sql
+SELECT MAX(cost), id FROM test -- id: 100
+SELECT SUM(cost), id FROM test -- id: 1
+```
+
+第一条查询可以找到最大值那一行的 id，而第二条查询的 id 是无意义的，因为不知道归属在哪一行，所以只返回了第一条数据的 id。
+
+当然，如果同时计算 MAX、MIN，那么此时 id 也只返回第一条数据的值，因为这个查询结果对应了复数行：
+
+```sql
+SELECT MAX(cost), MIN(cost), id FROM test -- id: 1
+```
+
+基于这些特性，最好不要混用聚合与非聚合，也就是一条查询一旦有一个字段是聚合的，那么所有字段都要聚合。
+
+现在很多 BI 引擎的自定义字段都有这条限制，因为混用聚合与非聚合在自定义内存计算时处理起来边界情况很多，虽然 SQL 能支持，但业务自定义的函数可能不支持。
+
+## 分组聚合
+
+分组聚合就是 GROUP BY，其实可以把它当作一种高级的条件语句。
+
+举个例子，查询每个国家的 GDP 总量：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+GROUP BY country
+```
+
+返回的结果就会按照国家进行分组，这时，聚合函数就变成了在组内聚合。
+
+其实如果我们只想看中、美的 GDP，用非分组也可以查，只是要分成两条 SQL：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+WHERE country = '中国'
+
+SELECT SUM(GDP) FROM amazing_table
+WHERE country = '美国'
+```
+
+所以 GROUP BY 也可理解为，将某个字段的所有可枚举的情况都查了出来，并整合成一张表，每一行代表了一种枚举情况，不需要分解为一个个 WHERE 查询了。
+
+### 多字段分组聚合
+
+GROUP BY 可以对多个维度使用，含义等价于表格查询时行/列拖入多个维度。
+
+上面是 BI 查询工具视角，如果没有上下文，可以看下面这个递进描述：
+
+- 按照多个字段进行分组聚合。
+- 多字段组合起来成为唯一 Key，即 `GROUP BY a,b` 表示 a,b 合在一起描述一个组。
+- `GROUP BY a,b,c` 查询结果第一列可能看到许多重复的 a 行，第二列看到重复 b 行，但在同一个 a 值内不会重复，c 在 b 行中同理。
+
+下面是一个例子：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+GROUP BY province, city, area
+```
+
+查询结果为：
+
+```text
+浙江 杭州 余杭区
+浙江 杭州 西湖区
+浙江 宁波 海曙区
+浙江 宁波 江北区
+北京 .........
+```
+
+### GROUP BY + WHERE
+
+WHERE 是根据行进行条件筛选的。因此 GROUP BY + WHERE 并不是在组内做筛选，而是对整体做筛选。
+
+但由于按行筛选，其实组内或非组内结果都完全一样，所以我们几乎无法感知这种差异：
+
+```sql
+SELECT SUM(GDP) FROM amazing_table
+GROUP BY province, city, area
+WHERE industry = 'internet'
+```
+
+然而，忽略这个差异会导致我们在聚合筛选时碰壁。
+
+比如要筛选出平均分大于 60 学生的成绩总和，如果不使用子查询，是无法在普通查询中在 WHERE 加聚合函数实现的，比如下面就是一个语法错误的例子：
+
+```sql
+SELECT SUM(score) FROM amazing_table
+WHERE AVG(score) > 60
+```
+
+不要幻想上面的 SQL 可以执行成功，不要在 WHERE 里使用聚合函数。
+
+### GROUP BY + HAVING
+
+HAVING 是根据组进行条件筛选的。因此可以在 HAVING 使用聚合函数：
+
+```sql
+SELECT SUM(score) FROM amazing_table
+GROUP BY class_name
+HAVING AVG(score) > 60
+```
+
+上面的例子中可以正常查询，表示按照班级分组看总分，且仅筛选出平均分大于 60 的班级。
+
+所以为什么 HAVING 可以使用聚合条件呢？因为 HAVING 筛选的是组，所以可以对组聚合后过滤掉不满足条件的组，这样是有意义的。而 WHERE 是针对行粒度的，聚合后全表就只有一条数据，无论过滤与否都没有意义。
+
+但要注意的是，GROUP BY 生成派生表是无法利用索引筛选的，所以 WHERE 可以利用给字段建立索引优化性能，而 HAVING 针对索引字段不起作用。
+
+## 总结
+
+聚合函数 + 分组可以实现大部分简单 SQL 需求，在写 SQL 表达式时，需要思考这样的表达式是如何计算的，比如 `MAX(c1), c2` 是合理的，而 `SUM(c1), c2` 这个 `c2` 就是无意义的。
+
+最后记住 WHERE 是 GROUP BY 之前执行的，HAVING 针对组进行筛选。
+
+> 讨论地址是：[精读《SQL 聚合查询》· Issue #401 · ascoders/weekly](https://github.com/ascoders/weekly/issues/401)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/233.SQL 复杂查询.md

@@ -0,0 +1,176 @@
+SQL 复杂查询指的就是子查询。
+
+为什么子查询叫做复杂查询呢？因为子查询相当于查询嵌套查询，因为嵌套导致复杂度几乎可以被无限放大（无限嵌套），因此叫复杂查询。下面是一个最简单的子查询例子：
+
+```sql
+SELECT pv FROM (
+  SELECT pv FROM test
+)
+```
+
+上面的例子等价于 `SELECT pv FROM test`，但因为把表的位置替换成了一个新查询，所以摇身一变成为了复杂查询！所以复杂查询不一定真的复杂，甚至可能写出和普通查询等价的复杂查询，要避免这种无意义的行为。
+
+我们也要借此机会了解为什么子查询可以这么做。
+
+### 理解查询的本质
+
+当我们查一张表时，数据库认为我们在查什么？
+
+这点很重要，因为下面两个语句都是合法的：
+
+```sql
+SELECT pv FROM test
+
+SELECT pv FROM (
+  SELECT pv FROM test
+)
+```
+
+为什么数据库可以把子查询当作表呢？为了统一理解这些概念，我们有必要对查询内容进行抽象理解：**任意查询位置都是一条或多条记录**。
+
+比如 `test` 这张表，显然是多条记录（当然只有一行就是一条记录），而 `SELECT pv FROM test` 也是多条记录，然而因为 `FROM` 后面可以查询任意条数的记录，所以这两种语法都支持。
+
+不仅是 `FROM` 可以跟单条或多条记录，甚至 `SELECT`、`GROUP BY`、`WHERE`、`HAVING` 后都可以跟多条记录，这个后面再说。
+
+说到这，也就很好理解子查询的变种了，比如我们可以在子查询内使用 `WHERE` 或 `GROUP BY` 等等，因为无论如何，只要查询结果是多条记录就行了：
+
+```sql
+SELECT sum(people) as allPeople, sum(gdp), city FROM (
+  SELECT people, gdp, city FROM test
+  GROUP BY city
+  HAVING sum(gdp) > 10000
+)
+```
+
+这个例子就有点业务含义了。子查询是从内而外执行的，因此我们先看内部的逻辑：按照城市分组，筛选出总 GDP 超过一万的所有地区的人口数量明细。外层查询再把人口数加总，这样就能对比每个 GDP 超过一万的地区，总人口和总 GDP 分别是多少，方便对这些重点城市做对比。
+
+不过这个例子看起来还是不太自然，因为我们没必要写成复杂查询，其实简单查询也是等价的：
+
+```sql
+SELECT sum(people) as allPeople, sum(gdp), city FROM test
+GROUP BY city
+HAVING sum(gdp) > 10000
+```
+
+那为什么要多此一举呢？因为复杂查询的真正用法并不在这里。
+
+### 视图
+
+正因为子查询的存在，我们才可能以类似抽取变量的方式，抽取子查询，这个抽取出来的抽象就是视图：
+
+```sql
+CREATE VIEW my_table(people, gdp, city)
+AS
+SELECT sum(people) as allPeople, sum(gdp), city FROM test
+GROUP BY city
+HAVING sum(gdp) > 10000
+
+SELECT sum(people) as allPeople, sum(gdp), city FROM my_table
+```
+
+这样的好处是，这个视图可以被多条 SQL 语句复用，不仅可维护性变好了，执行时也仅需查询一次。
+
+要注意的是，SELECT 可以使用任何视图，但 INSERT、DELETE、UPDATE 用于视图时，需要视图满足一下条件：
+
+1. 未使用 DISTINCT 去重。
+2. FROM 单表。
+3. 未使用 GROUP BY 和 HAVING。
+
+因为上面几种模式都会导致视图成为聚合后的数据，不方便做除了查以外的操作。
+
+另外一个知识点就是物化视图，即使用 MATERIALIZED 描述视图：
+
+```sql
+CREATE MATERIALIZED VIEW my_table(people, gdp, city)
+AS ...
+```
+
+这种视图会落盘，为什么要支持这个特性呢？因为普通视图作为临时表，无法利用索引等优化手段，查询性能较低，所以物化视图是较为常见的性能优化手段。
+
+说到性能优化手段，还有一些比较常见的理念，即把读的复杂度分摊到写的时候，比如提前聚合新表落盘或者对 CASE 语句固化为字段等，这里先不展开。
+
+### 标量子查询
+
+上面说了，WHERE 也可以跟子查询，比如：
+
+```sql
+SELECT city FROM test
+WHERE gdp > (
+  SELECT avg(gdp) from test
+)
+```
+
+这样可以查询出 gdp 大于平均值的城市。
+
+那为什么不能直接这么写呢？
+
+```sql
+SELECT city FROM test
+WHERE gdp > avg(gdp) -- 报错，WHERE 无法使用聚合函数
+```
+
+看上去很美好，但其实第一篇我们就介绍了，WHERE 不能跟聚合查询，因为这样会把整个父查询都聚合起来。那为什么子查询可以？因为子查询聚合的是子查询啊，父查询并没有被聚合，所以这才符合我们的意图。
+
+所以上面例子不合适的地方在于，直接在当前查询使用 `avg(gdp)` 会导致聚合，而我们并不想聚合当前查询，但又要通过聚合拿到平均 GDP，所以就要使用子查询了！
+
+回过头来看，为什么这一节叫标量子查询？标量即单一值，因为 `avg(gdp)` 聚合出来的只有一个值，所以 WHERE 可以把它当做一个单一数值使用。反之，如果子查询没有使用聚合函数，或 GROUP BY 分组，那么就不能使用 `WHERE >` 这种语法，但可以使用 `WHERE IN`，这涉及到单条与多条记录的思考，我们接着看下一节。
+
+### 单条和多条记录
+
+介绍标量子查询时说到了，`WHERE >` 的值必须时单一值。但其实 WHERE 也可以跟返回多条记录的子查询结果，只要使用合理的条件语句，比如 IN：
+
+```sql
+SELECT area FROM test
+WHERE gdp IN (
+  SELECT max(gdp) from test
+  GROUP BY city
+)
+```
+
+上面的例子，子查询按照城市分组，并找到每一组 GDP 最大的那条记录，所以如果数据粒度是区域，那么我们就查到了每个城市 GDP 最大的那些记录，然后父查询通过 WHERE IN 找到 gdp 符合的复数结果，所以最后就把每个城市最大 gdp 的区域列了出来。
+
+但实际上 `WHERE >` 语句跟复数查询结果也不会报错，但没有任何意义，所以我们要理解查询结果是单条还是多条，在 WHERE 判断时选择合适的条件。WHERE 适合跟复数查询结果的语法有：`WHERE IN`、`WHERE SOME`、`WHERE ANY`。
+
+### 关联子查询
+
+所谓关联子查询，即父子查询间存在关联，既然如此，子查询肯定不能单独优先执行，毕竟和父查询存在关联嘛，所以关联子查询是先执行外层查询，再执行内层查询的。要注意的是，对每一行父查询，子查询都会执行一次，因此性能不高（当然 SQL 会对相同参数的子查询结果做缓存）。
+
+那这个关联是什么呢？关联的是每一行父查询时，对子查询执行的条件。这么说可能有点绕，举个例子：
+
+```sql
+SELECT * FROM test where gdp > (
+  select avg(gdp) from test
+  group by city
+)
+```
+
+对这个例子来说，想要查找 gdp 大于按城市分组的平均 gdp，比如北京地区按北京比较，上海地区按上海比较。但很可惜这样做是不行的，因为父子查询没有关联，SQL 并不知道要按照相同城市比较，因此只要加一个 WHERE 条件，就变成关联子查询了：
+
+```sql
+SELECT * FROM test as t1 where gdp > (
+  select avg(gdp) from test as t2 where t1.city = t2.city
+  group by city
+)
+```
+
+就是在每次判断 `WHERE gdp >` 条件时，重新计算子查询结果，将平均值限定在相同的城市，这样就符合需求了。
+
+## 总结
+
+学会灵活运用父子查询，就掌握了复杂查询了。
+
+SQL 第一公民是集合，所以所谓父子查询就是父子集合的灵活组合，这些集合可以出现在几乎任何位置，根据集合的数量、是否聚合、关联条件，就派生出了标量查询、关联子查询。
+
+更深入的了解就需要大量实战案例了，但万变不离其宗，掌握了复杂查询后，就可以理解大部分 SQL 案例了。
+
+> 讨论地址是：[精读《SQL 复杂查询》· Issue #403 · ascoders/weekly](https://github.com/ascoders/weekly/issues/403)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/234.SQL CASE 表达式.md

@@ -0,0 +1,154 @@
+CASE 表达式分为简单表达式与搜索表达式，其中搜索表达式可以覆盖简单表达式的全部能力，我也建议只写搜索表达式，而不要写简单表达式。
+
+简单表达式：
+
+```sql
+SELECT CASE city
+WHEN '北京' THEN 1
+WHEN '天津' THEN 2
+ELSE 0
+END AS abc
+FROM test
+```
+
+搜索表达式：
+
+```sql
+SELECT CASE
+WHEN city = '北京' THEN 1
+WHEN city = '天津' THEN 2
+ELSE 0
+END AS abc
+FROM test
+```
+
+明显可以看出，简单表达式只是搜索表达式 `a = b` 的特例，因为无法书写任何符号，只要条件换成 `a > b` 就无法胜任了，而搜索表达式不但可以轻松胜任，甚至可以写聚合函数。
+
+## CASE 表达式里的聚合函数
+
+为什么 CASE 表达式里可以写聚合函数？
+
+因为本身表达式就支持聚合函数，比如下面的语法，我们不会觉得奇怪：
+
+```sql
+SELECT sum(pv), avg(uv) from test
+```
+
+本身 SQL 就支持多种不同的聚合方式同时计算，所以将其用在 CASE 表达式里，也是顺其自然的：
+
+```sql
+SELECT CASE
+WHEN count(city) = 100 THEN 1
+WHEN sum(dau) > 200 THEN 2
+ELSE 0
+END AS abc
+FROM test
+```
+
+只要 SQL 表达式中存在聚合函数，那么整个表达式都聚合了，此时访问非聚合变量没有任何意义。所以上面的例子，即便在 CASE 表达式中使用了聚合，其实也不过是聚合了一次后，按照条件进行判断罢了。
+
+这个特性可以解决很多实际问题，比如将一些复杂聚合判断条件的结果用 SQL 结构输出，那么很可能是下面这种写法：
+
+```sql
+SELECT CASE
+WHEN 聚合函数(字段) 符合什么条件 THEN xxx
+... 可能有 N 个
+ELSE NULL
+END AS abc
+FROM test
+```
+
+这也可以认为是一种行转列的过程，即 **把行聚合后的结果通过一条条 CASE 表达式形成一个个新的列**。
+
+## 聚合与非聚合不能混用
+
+我们希望利用 CASE 表达式找出那些 pv 大于平均值的行，以下这种想当然的写法是错误的：
+
+```sql
+SELECT CASE
+WHEN pv > avg(pv) THEN 'yes'
+ELSE 'no'
+END AS abc
+FROM test
+```
+
+原因是，只要 SQL 中存在聚合表达式，那么整条 SQL 就都是聚合的，所以返回的结果只有一条，而我们期望查询结果不聚合，只是判断条件用到了聚合结果，那么就要使用子查询。
+
+为什么子查询可以解决问题？因为子查询的聚合发生在子查询，而不影响当前父查询，理解了这一点，就知道为什么下面的写法才是正确的了：
+
+```sql
+SELECT CASE
+WHEN pv > ( SELECT avg(pv) from test ) THEN 'yes'
+ELSE 'no'
+END AS abc
+FROM test
+```
+
+这个例子也说明了 CASE 表达式里可以使用子查询，因为子查询是先计算的，所以查询结果在哪儿都能用，CASE 表达式也不例外。
+
+## WHERE 中的 CASE
+
+WHERE 后面也可以跟 CASE 表达式的，用来做一些需要特殊枚举处理的筛选。
+
+比如下面的例子：
+
+```sql
+SELECT * FROM demo WHERE
+CASE
+WHEN city = '北京' THEN true
+ELSE ID > 5
+END
+```
+
+本来我们要查询 ID 大于 5 的数据，但我想对北京这个城市特别对待，那么就可以在判断条件中再进行 CASE 分支判断。
+
+这个场景在 BI 工具里等价于，创建一个 CASE 表达式字段，可以拖入筛选条件生效。
+
+## GROUP BY 中的 CASE
+
+想不到吧，GROUP BY 里都可以写 CASE 表达式：
+
+```sql
+SELECT isPower, sum(gdp) FROM test GROUP BY CASE
+WHEN isPower = 1 THEN city, area
+ELSE city
+END
+```
+
+上面例子表示，计算 GDP 时，对于非常发达的城市，按照每个区粒度查看聚合结果，也就是看的粒度更细一些，而对于欠发达地区，本身 gdp 也不高，直接按照城市粒度看聚合结果。
+
+这样，就按照不同的条件对数据进行了分组聚合。由于返回行结果是混在一起的，像这个例子，可以根据 isPower 字段是否为 1 判断，是否按照城市、区域进行了聚合，如果没有其他更显著的标识，可能导致无法区分不同行的聚合粒度，因此谨慎使用。
+
+## ORDER BY 中的 CASE
+
+同样，ORDER BY 使用 CASE 表达式，会将排序结果按照 CASE 分类进行分组，每组按照自己的规则排序，比如：
+
+```sql
+SELECT * FROM test ORDER BY CASE
+WHEN isPower = 1 THEN gdp
+ELSE people
+END
+```
+
+上面的例子，对发达地区采用 gdp 排序，否则采用人口数量排序。
+
+## 总结
+
+CASE 表达式总结一下有如下特点：
+
+1. 支持简单与搜索两种写法，推荐搜索写法。
+2. 支持聚合与子查询，需要注意不同情况的特点。
+3. 可以写在 SQL 查询的几乎任何地方，只要是可以写字段的地方，基本上就可以替换为 CASE 表达式。
+4. 除了 SELECT 外，CASE 表达式还广泛应用在 INSERT 与 UPDATE，其中 UPDATE 的妙用是不用将 SQL 拆分为多条，所以不用担心数据变更后对判断条件的二次影响。
+
+> 讨论地址是：[精读《SQL CASE 表达式》· Issue #404 · ascoders/weekly](https://github.com/ascoders/weekly/issues/404)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/235.SQL 窗口函数.md

@@ -0,0 +1,124 @@
+窗口函数形如：
+
+```sql
+表达式 OVER (PARTITION BY 分组字段 ORDER BY 排序字段)
+```
+
+有两个能力：
+
+1. 当表达式为 `rank()` `dense_rank()` `row_number()` 时，拥有分组排序能力。
+2. 当表达式为 `sum()` 等聚合函数时，拥有累计聚合能力。
+
+无论何种能力，**窗口函数都不会影响数据行数，而是将计算平摊在每一行**。
+
+这两种能力需要区分理解。
+
+## 底表
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdUL60.png">
+
+以上是示例底表，共有 8 条数据，城市1、城市2 两个城市，下面各有地区1～4，每条数据都有该数据的人口数。
+
+## 分组排序
+
+如果按照人口排序，`ORDER BY people` 就行了，但如果我们想在城市内排序怎么办？
+
+此时就要用到窗口函数的分组排序能力：
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qddfIg.png">
+
+```sql
+SELECT *, rank() over (PARTITION BY city ORDER BY people) FROM test
+```
+
+该 SQL 表示在 city 组内按照 people 进行排序。
+
+其实 PARTITION BY 也是可选的，如果我们忽略它：
+
+```sql
+SELECT *, rank() over (ORDER BY people) FROM test
+```
+
+也是生效的，但该语句与普通 ORDER BY 等价，因此利用窗口函数进行分组排序时，一般都会使用 PARTITION BY。
+
+### 各分组排序函数的差异
+
+我们将 `rank()` `dense_rank()` `row_number()` 的结果都打印出来：
+
+```sql
+SELECT *, 
+rank() over (PARTITION BY city ORDER BY people),
+dense_rank() over (PARTITION BY city ORDER BY people),
+row_number() over (PARTITION BY city ORDER BY people)
+FROM test
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qd0uh4.png">
+
+其实从结果就可以猜到，这三个函数在处理排序遇到相同值时，对排名统计逻辑有如下差异：
+
+1. `rank()`: 值相同时排名相同，但占用排名数字。
+2. `dense_rank()`: 值相同时排名相同，但不占用排名数字，整体排名更加紧凑。
+3. `row_number()`: 无论值是否相同，都强制按照行号展示排名。
+
+上面的例子可以优化一下，因为所有窗口逻辑都是相同的，我们可以利用 WINDOW AS 提取为一个变量：
+
+```sql
+SELECT *, 
+rank() over wd, dense_rank() over wd, row_number() over wd
+FROM test
+WINDOW wd as (PARTITION BY city ORDER BY people)
+```
+
+## 累计聚合
+
+我们之前说过，凡事使用了聚合函数，都会让查询变成聚合模式。如果不用 GROUP BY，聚合后返回行数会压缩为一行，即使用了 GROUP BY，返回的行数一般也会大大减少，因为分组聚合了。
+
+然而使用窗口函数的聚合却不会导致返回行数减少，那么这种聚合是怎么计算的呢？我们不如直接看下面的例子：
+
+```sql
+SELECT *, 
+sum(people) over (PARTITION BY city ORDER BY people)
+FROM test
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdsDJS.png">
+
+可以看到，在每个 city 分组内，按照 people 排序后进行了 **累加**（相同的值会合并在一起），这就是 BI 工具一般说的 RUNNGIN_SUM 的实现思路，当然一般我们排序规则使用绝对不会重复的日期，所以不会遇到第一个红框中合并计算的问题。
+
+累计函数还有 `avg()` `min()` 等等，这些都一样可以作用于窗口函数，其逻辑可以按照下图理解：
+
+<img width=400 src="https://s1.ax1x.com/2022/03/26/qd6or9.png">
+
+你可能有疑问，直接 `sum(上一行结果，下一行)` 不是更方便吗？为了验证猜想，我们试试 `avg()` 的结果：
+
+<img width=400 src="https://s1.ax1x.com/2022/03/26/qdciIP.png">
+
+可见，如果直接利用上一行结果的缓存，那么 avg 结果必然是不准确的，所以窗口累计聚合是每行重新计算的。当然也不排除对于 sum、max、min 做额外性能优化的可能性，但 avg 只能每行重头计算。
+
+### 与 GROUP BY 组合使用
+
+窗口函数是可以与 GROUP BY 组合使用的，遵循的规则是，窗口范围对后面的查询结果生效，所以其实并不关心是否进行了 GROUP BY。我们看下面的例子：
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdgMOH.png">
+
+按照地区分组后进行累加聚合，是对 GROUP BY 后的数据行粒度进行的，而不是之前的明细行。
+
+## 总结
+
+窗口函数在计算组内排序或累计 GVM 等场景非常有用，我们只要牢记两个知识点就行了：
+
+1. 分组排序要结合 PARTITION BY 才有意义。
+2. 累计聚合作用于查询结果行粒度，支持所有聚合函数。
+
+> 讨论地址是：[精读《SQL 窗口函数》· Issue #405 · ascoders/weekly](https://github.com/ascoders/weekly/issues/405)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

SQL/236.SQL grouping.md

@@ -0,0 +1,151 @@
+SQL grouping 解决 OLAP 场景总计与小计问题，其语法分为几类，但要解决的是同一个问题：
+
+ROLLUP 与 CUBE 是封装了规则的 GROUPING SETS，而 GROUPING SETS 则是最原始的规则。
+
+为了方便理解，让我们从一个问题入手，层层递进吧。
+
+## 底表
+
+<img width=500 src="https://s1.ax1x.com/2022/03/26/qdUL60.png">
+
+以上是示例底表，共有 8 条数据，城市1、城市2 两个城市，下面各有地区1～4，每条数据都有该数据的人口数。
+
+现在想计算人口总计，以及各城市人口小计。在没有掌握 grouping 语法前，我们只能通过两个 select 语句 union 后得到：
+
+```sql
+SELECT city, sum(people) FROM test GROUP BY city
+union
+SELECT '合计' as city, sum(people) FROM test
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbKPRs.png">
+
+但两条 select 语句聚合了两次，性能是一个不小的开销，因此 SQL 提供了 GROUPING SETS 语法解决这个问题。
+
+## GROUPING SETS
+
+GROUP BY GROUPING SETS 可以指定任意聚合项，比如我们要同时计算总计与分组合计，就要按照空内容进行 GROUP BY 进行一次 sum，再按照 city 进行 GROUP BY 再进行一次 sum，换成 GROUPING SETS 描述就是：
+
+```sql
+SELECT 
+city, area,
+sum(people)
+FROM test
+GROUP BY GROUPING SETS((), (city, area))
+```
+
+其中 `GROUPING SETS((), (city, area))` 表示分别按照 `()`、`(city, area)` 聚合计算总计。返回结果是：
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbRnWF.png">
+
+可以看到，值为 NULL 的行就是我们要的总计，其值是没有任何 GROUP BY 限制算出来的。
+
+类似的，我们还可以写 `GROUPING SETS((), (city), (city, area), (area))` 等任意数量、任意组合的 GROUP BY 条件。
+
+通过这种规则计算的数据我们称为 “超级分组记录”。我们发现 “超级分组记录” 产生的 NULL 值很容易和真正的 NULL 值弄混，所以 SQL 提供了 GROUPING 函数解决这个问题。
+
+## 函数 GROUPING
+
+对于超级分组记录产生的 NULL，是可以被 `GROUPING()` 函数识别为 1 的：
+
+```sql
+SELECT 
+GROUPING(city),
+GROUPING(area),
+sum(people)
+FROM test
+GROUP BY GROUPING SETS((), (city, area))
+```
+
+具体效果见下图：
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbRLpF.png">
+
+可以看到，但凡是超级分组计算出来的字段都会识别为 1，我们利用之前学习的 [SQL CASE 表达式](https://github.com/ascoders/weekly/blob/master/SQL/234.SQL%20CASE%20%E8%A1%A8%E8%BE%BE%E5%BC%8F.md) 将其转换为总计、小计字样，就可以得出一张数据分析表了：
+
+```sql
+SELECT 
+CASE WHEN GROUPING(city) = 1 THEN '总计' ELSE city END,
+CASE WHEN GROUPING(area) = 1 THEN '小计' ELSE area END,
+sum(people)
+FROM test
+GROUP BY GROUPING SETS((), (city, area))
+```
+
+<img width=500 src="https://s1.ax1x.com/2022/04/04/qbRz01.png">
+
+然后前端表格展示时，将第一行 “总计”、“小计” 单元格合并为 “总计”，就完成了总计这个 BI 可视化分析功能。
+
+## ROLLUP
+
+ROLLUP 是卷起的意思，是一种特定规则的 GROUPING SETS，以下两种写法是等价的：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY ROLLUP(city)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city))
+```
+
+再看一组等价描述：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY ROLLUP(city, area)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city), (city, area))
+```
+
+发现规律了吗？ROLLUP 会按顺序把 GROUP BY 内容 “一个个卷起来”。用 GROUPING 函数判断超级分组记录对 ROLLUP 同样适用。
+
+## CUBE
+
+CUBE 又有所不同，它对内容进行了所有可能性展开（所以叫 CUBE）。
+
+类比上面的例子，我们再写两组等价的展开：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY CUBE(city)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city))
+```
+
+上面的例子因为只有一项还看不出来，下面两项分组就能看出来了：
+
+```sql
+SELECT sum(people) FROM test
+GROUP BY CUBE(city, area)
+
+-- 等价于
+SELECT sum(people) FROM test
+GROUP BY GROUPING SETS((), (city), (area), (city, area))
+```
+
+所谓 CUBE，是一种多维形状的描述，二维时有 2^1 种展开，三维时有 2^2 种展开，四维、五维依此类推。可以想象，如果用 CUBE 描述了很多组合，复杂度会爆炸。
+
+## 总结
+
+学习了 GROUPING 语法，以后前端同学的你不会再纠结这个问题了吧：
+
+> 产品开启了总计、小计，我们是额外取一次数还是放到一起获取啊？
+
+这个问题的标准答案和原理都在这篇文章里了。PS：对于不支持 GROUPING 语法数据库，要想办法屏蔽，就像前端 polyfill 一样，是一种降级方案。至于如何屏蔽，参考文章开头提到的两个 SELECT + UNION。
+
+> 讨论地址是：[精读《SQL grouping》· Issue #406 · ascoders/weekly](https://github.com/ascoders/weekly/issues/406)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/ascoders/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

TS 类型体操/243.精读《type challenges - easy》.md

@@ -0,0 +1,364 @@
+TS 强类型非常好用，但在实际运用中，免不了遇到一些难以描述，反复看官方文档也解决不了的问题，至今为止也没有任何一篇文档，或者一套教材可以解决所有犄角旮旯的类型问题。为什么会这样呢？因为 TS 并不是简单的注释器，而是一门图灵完备的语言，所以很多问题的解决方法藏在基础能力里，但你学会了基础能力又不一定能想到这么用。
+
+解决该问题的最好办法就是多练，通过实际案例不断刺激你的大脑，让你养成 TS 思维习惯。所以话不多说，我们今天从 [type-challenges](https://github.com/type-challenges/type-challenges) 的 Easy 难度题目开始吧。
+
+## 精读
+
+### [Pick](https://github.com/type-challenges/type-challenges/blob/main/questions/00004-easy-pick/README.md)
+
+手动实现内置 `Pick<T, K>` 函数，返回一个新的类型，从对象 T 中抽取类型 K：
+
+```ts
+interface Todo {
+  title: string
+  description: string
+  completed: boolean
+}
+
+type TodoPreview = MyPick<Todo, 'title' | 'completed'>
+
+const todo: TodoPreview = {
+    title: 'Clean room',
+    completed: false,
+}
+```
+
+结合例子更容易看明白，也就是 `K` 是一个字符串，我们需要返回一个新类型，仅保留 `K` 定义的 Key。
+
+第一个难点在如何限制 `K` 的取值，比如传入 `T` 中不存在的值就要报错。这个考察的是硬知识，只要你知道 `A extends keyof B` 这个语法就能联想到。
+
+第二个难点在于如何生成一个仅包含 `K` 定义 Key 的类型，你首先要知道有 `{ [A in keyof B]: B[A] }` 这个硬知识，这样可以重新组合一个对象：
+
+```ts
+// 代码 1
+type Foo<T> = {
+  [P in keyof T]: T[P]
+}
+```
+
+只懂这个语法不一定能想出思路，原因是你要打破对 TS 的刻板理解，`[K in keyof T]` 不是一个固定模板，其中 `keyof T` 只是一个指代变量，它可以被换掉，如果你换掉成另一个范围的变量，那么这个对象的 Key 值范围就变了，这正好契合本题的 `K`：
+
+```ts
+// 代码 2（本题答案）
+type MyPick<T, K in keyof T> = {
+  [P in K]: T[P]
+}
+```
+
+这个题目别看知道答案后简单，回顾下还是有收获的。对比上面两个代码例子，你会发现，只不过是把代码 1 的 `keyof T` 从对象描述中提到了泛型定义里而已，所以功能上没有任何变化，但因为泛型可以由用户传入，所以代码 1 的 `P in keyof T` 因为没有泛型支撑，这里推导出来的就是 `T` 的所有 Keys，而代码 2 虽然把代码挪到了泛型，但因为用的是 `extends` 描述，所以表示 `P` 的类型被约束到了 `T` 的 Keys，至于具体是什么，得看用户代码怎么传。
+
+所以其实放到泛型里的 `K` 是没有默认值的，而写到对象里作为推导值就有了默认值。泛型里给默认值的方式如下：
+
+```ts
+// 代码 3
+type MyPick<T, K extends keyof T = keyof T> = {
+  [P in K]: T[P]
+}
+```
+
+也就是说，这样 `MyPick<Todo>` 就也可以正确工作并原封不动返回 `Todo` 类型，也就是说，代码 3 在不传第二个参数时，与代码 1 的功能完全一样。仔细琢磨一下共同点与区别，为什么代码 3 可以做到和代码 1 功能一样，又有更强的拓展性，你对 TS 泛型的实战理解就上了一个台阶。
+
+### [Readonly](https://github.com/type-challenges/type-challenges/blob/main/questions/00007-easy-readonly/README.md)
+
+手动实现内置 `Readonly<T>` 函数，将对象所有属性设置为只读：
+
+```ts
+interface Todo {
+  title: string
+  description: string
+}
+
+const todo: MyReadonly<Todo> = {
+  title: "Hey",
+  description: "foobar"
+}
+
+todo.title = "Hello" // Error: cannot reassign a readonly property
+todo.description = "barFoo" // Error: cannot reassign a readonly property
+```
+
+这道题反而比第一题简单，只要我们用 `{ [A in keyof B]: B[A] }` 重新声明对象，并在每个 Key 前面加上 `readonly` 修饰即可：
+
+```ts
+// 本题答案
+type MyReadonly<T> = {
+  readonly [K in keyof T]: T[K]
+}
+```
+
+根据这个特性我们可以做很多延伸改造，比如将对象所有 Key 都设定为可选：
+
+```ts
+type Optional<T> = {
+  [K in keyof T]?: T[K]
+}
+```
+
+`{ [A in keyof B]: B[A] }` 给了我们描述每一个 Key 属性细节的机会，限制我们发挥的只有想象力。
+
+### [First Of Array](https://github.com/type-challenges/type-challenges/blob/main/questions/00014-easy-first/README.md)
+
+实现类型 `First<T>`，取到数组第一项的类型：
+
+```ts
+type arr1 = ['a', 'b', 'c']
+type arr2 = [3, 2, 1]
+
+type head1 = First<arr1> // expected to be 'a'
+type head2 = First<arr2> // expected to be 3
+```
+
+这题比较简单，很容易想到的答案：
+
+```ts
+// 本题答案
+type First<T extends any[]> = T[0]
+```
+
+但在写这个答案时，有 10% 脑细胞提醒我没有判断边界情况，果然看了下答案，有空数组的情况要考虑，空数组时返回类型 `never` 而不是 `undefined` 会更好，下面几种写法都是答案：
+
+```ts
+type First<T extends any[]> = T extends [] ? never : T[0]
+type First<T extends any[]> = T['length'] extends 0 ? never : T[0]
+type First<T> = T extends [infer P, ...infer Rest] ? P : never
+```
+
+第一种写法通过 `extends []` 判断 `T` 是否为空数组，是的话返回 `never`。
+
+第二种写法通过长度为 0 判断空数组，此时需要理解两点：1. 可以通过 `T['length']` 让 TS 访问到值长度（类型的），2. `extends 0` 表示是否匹配 0，即 `extends` 除了匹配类型，还能直接匹配值。
+
+第三种写法是最省心的，但也使用了 `infer` 关键字，即使你充分知道 `infer` 怎么用（[精读《Typescript infer 关键字》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/207.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%20infer%20%E5%85%B3%E9%94%AE%E5%AD%97%E3%80%8B.md)），也很难想到它。用 `infer` 的理由是：该场景存在边界情况，最便于理解的写法是 “如果 T 形如 `<P, ...>`” 那我就返回类型 `P`，否则返回 `never`”，这句话用 TS 描述就是：`T extends [infer P, ...infer Rest] ? P : never`。
+
+### [Length of Tuple](https://github.com/type-challenges/type-challenges/blob/main/questions/00018-easy-tuple-length/README.md)
+
+实现类型 `Length<T>` 获取元组长度:
+
+```ts
+type tesla = ['tesla', 'model 3', 'model X', 'model Y']
+type spaceX = ['FALCON 9', 'FALCON HEAVY', 'DRAGON', 'STARSHIP', 'HUMAN SPACEFLIGHT']
+
+type teslaLength = Length<tesla>  // expected 4
+type spaceXLength = Length<spaceX> // expected 5
+```
+
+经过上一题的学习，很容易想到这个答案：
+
+```ts
+type Length<T extends any[]> = T['length']
+```
+
+对 TS 来说，元组和数组都是数组，但元组对 TS 来说可以观测其长度，`T['length']` 对元组来说返回的是具体值，而对数组来说返回的是 `number`。
+
+### [Exclude](https://github.com/type-challenges/type-challenges/blob/main/questions/00043-easy-exclude/README.md)
+
+实现类型 `Exclude<T, U>`，返回 `T` 中不存在于 `U` 的部分。该功能主要用在联合类型场景，所以我们直接用 `extends` 判断就行了：
+
+```ts
+// 本题答案
+type Exclude<T, U> = T extends U ? never : T
+```
+
+实际运行效果：
+
+```ts
+type C = Exclude<'a' | 'b', 'a' | 'c'> // 'b'
+```
+
+看上去有点不那么好理解，这是因为 TS 对联合类型的执行是分配率的，即：
+
+```ts
+Exclude<'a' | 'b', 'a' | 'c'>
+// 等价于
+Exclude<'a', 'a' | 'c'> | Exclude<'b', 'a' | 'c'>
+```
+
+### [Awaited](https://github.com/type-challenges/type-challenges/blob/main/questions/00189-easy-awaited/README.md)
+
+实现类型 `Awaited`，比如从 `Promise<ExampleType>` 拿到 `ExampleType`。
+
+首先 TS 永远不会执行代码，所以脑子里不要有 “await 得等一下才知道结果” 的念头。该题关键就是从 `Promise<T>` 中抽取类型 `T`，很适合用 `infer` 做：
+
+```ts
+type MyAwaited<T> = T extends Promise<infer U> ? U : never
+```
+
+然而这个答案还不够标准，标准答案考虑了嵌套 `Promise` 的场景：
+
+```ts
+// 该题答案
+type MyAwaited<T extends Promise<unknown>> = T extends Promise<infer P>
+  ? P extends Promise<unknown> ? MyAwaited<P> : P
+  : never
+```
+
+如果 `Promise<P>` 取到的 `P` 还形如 `Promise<unknown>`，就递归调用自己 `MyAwaited<P>`。这里提到了递归，也就是 TS 类型处理可以是递归的，所以才有了后面版本做尾递归优化。
+
+### [If](https://github.com/type-challenges/type-challenges/blob/main/questions/00268-easy-if/README.md)
+
+实现类型 `If<Condition, True, False>`，当 `C` 为 `true` 时返回 `T`，否则返回 `F`：
+
+```ts
+type A = If<true, 'a', 'b'>  // expected to be 'a'
+type B = If<false, 'a', 'b'> // expected to be 'b'
+```
+
+之前有提过，`extends` 还可以用来判定值，所以果断用 `extends true` 判断是否命中了 `true` 即可：
+
+```ts
+// 本题答案
+type If<C, T, F> = C extends true ? T : F
+```
+
+### [Concat](https://github.com/type-challenges/type-challenges/blob/main/questions/00533-easy-concat/README.md)
+
+用类型系统实现 `Concat<P, Q>`，将两个数组类型连起来：
+
+```ts
+type Result = Concat<[1], [2]> // expected to be [1, 2]
+```
+
+由于 TS 支持数组解构语法，所以可以大胆的尝试这么写：
+
+```ts
+type Concat<P extends any[], Q extends any[]> = [...P, ...Q]
+```
+
+考虑到 `Concat` 函数应该也能接收非数组类型，所以做一个判断，为了方便书写，把 `extends` 从泛型定义位置挪到 TS 类型推断的运行时：
+
+```ts
+// 本题答案
+type Concat<P, Q> = [
+  ...P extends any[] ? P : [P],
+  ...Q extends any[] ? Q : [Q],
+]
+```
+
+解决这题需要信念，相信 TS 可以像 JS 一样写逻辑。这些能力都是版本升级时渐进式提供的，所以需要不断阅读最新 TS 特性，快速将其理解为固化知识，其实还是有一定难度的。
+
+### [Includes](https://github.com/type-challenges/type-challenges/blob/main/questions/00898-easy-includes/README.md)
+
+用类型系统实现 `Includes<T, K>` 函数：
+
+```ts
+type isPillarMen = Includes<['Kars', 'Esidisi', 'Wamuu', 'Santana'], 'Dio'> // expected to be `false`
+```
+
+由于之前的经验，很容易做下面的联想：
+
+```ts
+// 如果题目要求是这样
+type isPillarMen = Includes<'Kars' | 'Esidisi' | 'Wamuu' | 'Santana', 'Dio'>
+// 那我就能用 extends 轻松解决了
+type Includes<T, K> = K extends T ? true : false
+```
+
+可惜第一个输入是数组类型，`extends` 可不支持判定 “数组包含” 逻辑，此时要了解一个新知识点，即 TS 判断中的 `[number]` 下标。不仅这道题，以后很多困难题都需要它作为基础知识。
+
+`[number]` 下标表示任意一项，而 `extends T[number]` 就可以实现数组包含的判定，因此下面的解法是有效的：
+
+```ts
+type Includes<T extends any[], K> = K extends T[number] ? true : false
+```
+
+但翻答案后发现这并不是标准答案，还真找到一个反例：
+
+```ts
+type Includes<T extends any[], K> = K extends T[number] ? true : false
+type isPillarMen = Includes<[boolean], false> // true
+```
+
+原因很简单，`true`、`false` 都继承自 `boolean`，所以 `extends` 判断的界限太宽了，题目要求的是精确值匹配，故上面的答案理论上是错的。
+
+标准答案是每次判断数组第一项，并递归（讲真觉得这不是 easy 题），分别有两个难点。
+
+第一如何写 Equal 函数？比较流行的方案是这个：
+
+```ts
+type Equal<X, Y> =
+  (<T>() => T extends X ? 1 : 2) extends
+  (<T>() => T extends Y ? 1 : 2) ? true : false
+```
+
+关于如何写 Equal 函数还引发了一次 [小讨论](https://github.com/microsoft/TypeScript/issues/27024#issuecomment-421529650)，上面的代码构造了两个函数，这两个函数内的 `T` 属于 deferred（延迟）判断的类型，该类型判断依赖于内部 `isTypeIdenticalTo` 函数完成判断。
+
+有了 `Equal` 后就简单了，我们用解构 + `infer` + 递归的方式做就可以了：
+
+```ts
+// 本题答案
+type Includes<T extends any[], K> =
+  T extends [infer F, ...infer Rest] ?
+    Equal<F, K> extends true ?
+      true
+      : Includes<Rest, K>
+    : false
+```
+
+每次取数组第一个值判断 `Equal`，如果不匹配则拿剩余项递归判断。这个函数组合了不少 TS 知识，比如：
+
+- 递归
+- 解构
+- `infer`
+- `extends true`
+
+可以发现，就为了解决 `true extends boolean` 为 `true` 的问题，我们绕了一大圈使用了更复杂的方式来实现，这在 TS 体操中也算是常态，解决问题需要耐心。
+
+
+### [Push](https://github.com/type-challenges/type-challenges/blob/main/questions/03057-easy-push/README.md)
+
+实现 `Push<T, K>` 函数：
+
+```ts
+type Result = Push<[1, 2], '3'> // [1, 2, '3']
+```
+
+这道题真的很简单，用解构就行了：
+
+```ts
+// 本题答案
+type Push<T extends any[], K> = [...T, K]
+```
+
+可见，想要轻松解决一个 TS 简单问题，首先你需要能解决一些困难问题 😁。
+
+### [Unshift](https://github.com/type-challenges/type-challenges/blob/main/questions/03060-easy-unshift/README.md)
+
+实现 `Unshift<T, K>` 函数：
+
+```ts
+type Result = Unshift<[1, 2], 0> // [0, 1, 2,]
+```
+
+在 `Push` 基础上改下顺序就行了：
+
+```ts
+// 本题答案
+type Unshift<T extends any[], K> = [K, ...T]
+```
+
+### [Parameters](https://github.com/type-challenges/type-challenges/blob/main/questions/03312-easy-parameters/README.md)
+
+实现内置函数 `Parameters`：
+
+`Parameters` 可以拿到函数的参数类型，直接用 `infer` 实现即可，也比较简单：
+
+```ts
+type Parameters<T> = T extends (...args: infer P) => any ? P : []
+```
+
+`infer` 可以很方便从任何具体的位置取值，属于典型难懂易用的语法。
+
+## 总结
+
+学会 TS 基础语法后，活用才是关键。
+
+> 讨论地址是：[精读《type challenges - easy》· Issue #422 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/422)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
+
+

helper.js

@@ -0,0 +1,36 @@
+/**
+ * 发布辅助脚本
+ * @author 黄子毅
+ */
+
+const fs = require("fs");
+
+const dirs = [
+  "前沿技术",
+  "TS 类型体操",
+  "设计模式",
+  "编译原理",
+  "源码解读",
+  "商业思考",
+  "算法",
+  "SQL"
+];
+
+dirs.forEach((dir) => {
+  const readDir = fs.readdirSync(`./${dir}`);
+
+  console.log(`### ${dir}\n`);
+
+  readDir
+    .sort((left, right) => left.split(".")[0] - right.split(".")[0])
+    .forEach((dirName) => {
+      console.log(
+        `- <a href="./${dir}/${encodeURIComponent(dirName)}">${dirName.replace(
+          ".md",
+          ""
+        )}</a>`
+      );
+    });
+
+  console.log("");
+});

package.json

@@ -17,6 +17,7 @@
   },
   "homepage": "https://github.com/dt-fe/weekly#readme",
   "dependencies": {
+    "esm": "^3.2.25",
     "husky": "^3.0.4",
     "lint-md-cli": "^0.1.1"
   },
@@ -25,4 +26,4 @@
       "pre-commit": "npx lint-md ./"
     }
   }
-}
+}

readme.md

@@ -1,27 +1,289 @@
 # 前端精读
 
-<a href="https://travis-ci.org/dt-fe/weekly">
-  <img src="https://travis-ci.org/dt-fe/weekly.svg?branch=v2" alt="CircleCI Status">
+<a href="https://travis-ci.org/ascoders/weekly">
+  <img src="https://travis-ci.org/ascoders/weekly.svg?branch=v2" alt="CircleCI Status">
 </a>
 
 前端界的好文精读，每周更新！
 
-- [周刊参考池](https://github.com/dt-fe/weekly/issues/2)
+最新精读：<a href="./TS 类型体操/243.%E7%B2%BE%E8%AF%BB%E3%80%8Atype%20challenges%20-%20easy%E3%80%8B.md">243.精读《type challenges - easy》</a>
+
+素材来源：[周刊参考池](https://github.com/ascoders/weekly/issues/2)
+
+现已涵盖：
+
+- 结合大厂工作经验解读的 [前沿技术](./前沿技术)，[源码解读](./源码解读)。
+- 逐渐加入一些后端技术解读。
+- 一些 [商业思考](./商业思考)。
+- 已完成 [编译原理](./编译原理)、[设计模式](./设计模式) 两大基础模块。
+
+### 前沿技术
+
+- <a href="./前沿技术/1.%E7%B2%BE%E8%AF%BB%E3%80%8Ajs%20%E6%A8%A1%E5%9D%97%E5%8C%96%E5%8F%91%E5%B1%95%E3%80%8B.md">1.精读《js 模块化发展》</a>
+- <a href="./前沿技术/2.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%A8%A1%E6%80%81%E6%A1%86%E7%9A%84%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5%E3%80%8B.md">2.精读《模态框的最佳实践》</a>
+- <a href="./前沿技术/3.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E5%90%8E%E7%AB%AF%E6%B8%B2%E6%9F%93%E4%B9%8B%E4%BA%89%E3%80%8B.md">3.精读《前后端渲染之争》</a>
+- <a href="./前沿技术/4.%E7%B2%BE%E8%AF%BB%E3%80%8AAsyncAwait%20%E4%BC%98%E8%B6%8A%E4%B9%8B%E5%A4%84%E3%80%8B.md">4.精读《AsyncAwait 优越之处》</a>
+- <a href="./前沿技术/5.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B0%91%E5%B7%A5%E5%8F%94%E5%8D%95%E9%A1%B5%E6%95%B0%E6%8D%AE%E6%B5%81%E6%96%B9%E6%A1%88%E3%80%8B.md">5.精读《民工叔单页数据流方案》</a>
+- <a href="./前沿技术/6.%E7%B2%BE%E8%AF%BB%E3%80%8AJavaScript%20%E9%94%99%E8%AF%AF%E5%A0%86%E6%A0%88%E5%A4%84%E7%90%86%E3%80%8B.md">6.精读《JavaScript 错误堆栈处理》</a>
+- <a href="./前沿技术/7.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AF%B7%E5%81%9C%E6%AD%A2%20css-in-js%20%E7%9A%84%E8%A1%8C%E4%B8%BA%E3%80%8B.md">7.精读《请停止 css-in-js 的行为》</a>
+- <a href="./前沿技术/8.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%85%A5%E5%9D%91%20React%20%E5%89%8D%E6%B2%A1%E6%9C%89%E4%BA%BA%E4%BC%9A%E5%91%8A%E8%AF%89%E4%BD%A0%E7%9A%84%E4%BA%8B%E3%80%8B.md">8.精读《入坑 React 前没有人会告诉你的事》</a>
+- <a href="./前沿技术/9.%E7%B2%BE%E8%AF%BB%E3%80%8AImmutable%20%E7%BB%93%E6%9E%84%E5%85%B1%E4%BA%AB%E3%80%8B.md">9.精读《Immutable 结构共享》</a>
+- <a href="./前沿技术/10.%E7%B2%BE%E8%AF%BB%E3%80%8AWeb%20Components%20%E7%9A%84%E5%9B%B0%E5%A2%83%E3%80%8B.md">10.精读《Web Components 的困境》</a>
+- <a href="./前沿技术/11.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E8%B0%83%E8%AF%95%E6%8A%80%E5%B7%A7%E3%80%8B.md">11.精读《前端调试技巧》</a>
+- <a href="./前沿技术/12.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20%E9%AB%98%E9%98%B6%E7%BB%84%E4%BB%B6%E3%80%8B.md">12.精读《React 高阶组件》</a>
+- <a href="./前沿技术/13.%E7%B2%BE%E8%AF%BB%E3%80%8AThis%20%E5%B8%A6%E6%9D%A5%E7%9A%84%E5%9B%B0%E6%83%91%E3%80%8B.md">13.精读《This 带来的困惑》</a>
+- <a href="./前沿技术/14.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1%E4%B9%8B%20DCI%E3%80%8B.md">14.精读《架构设计之 DCI》</a>
+- <a href="./前沿技术/15.%E7%B2%BE%E8%AF%BB%E3%80%8ATC39%20%E4%B8%8E%20ECMAScript%20%E6%8F%90%E6%A1%88%E3%80%8B.md">15.精读《TC39 与 ECMAScript 提案》</a>
+- <a href="./前沿技术/16.%E7%B2%BE%E8%AF%BB%E3%80%8ACSS%20Animations%20vs%20Web%20Animations%20API%E3%80%8B.md">16.精读《CSS Animations vs Web Animations API》</a>
+- <a href="./前沿技术/17.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A6%82%E4%BD%95%E5%AE%89%E5%85%A8%E5%9C%B0%E4%BD%BF%E7%94%A8%20React%20context%E3%80%8B.md">17.精读《如何安全地使用 React context》</a>
+- <a href="./前沿技术/18.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E5%AE%8C%E7%BE%8E%E7%9A%84%E6%97%A5%E6%9C%9F%E9%80%89%E6%8B%A9%E5%99%A8%E3%80%8B.md">18.精读《设计完美的日期选择器》</a>
+- <a href="./前沿技术/19.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%9C%80%E4%BD%B3%E5%89%8D%E7%AB%AF%E9%9D%A2%E8%AF%95%E9%A2%98%E3%80%8B%E5%8F%8A%E9%9D%A2%E8%AF%95%E5%AE%98%E6%8A%80%E5%B7%A7.md">19.精读《最佳前端面试题》及面试官技巧</a>
+- <a href="./前沿技术/20.%E7%B2%BE%E8%AF%BB%E3%80%8ANestjs%E3%80%8B%E6%96%87%E6%A1%A3.md">20.精读《Nestjs》文档</a>
+- <a href="./前沿技术/21.%E7%B2%BE%E8%AF%BB%E3%80%8AWeb%20fonts%3A%20when%20you%20need%20them%2C%20when%20you%20don%E2%80%99t%E3%80%8B.md">21.精读《Web fonts: when you need them, when you don’t》</a>
+- <a href="./前沿技术/22.%E7%B2%BE%E8%AF%BB%E3%80%8AV8%20%E5%BC%95%E6%93%8E%E7%89%B9%E6%80%A7%E5%B8%A6%E6%9D%A5%E7%9A%84%E7%9A%84%20JS%20%E6%80%A7%E8%83%BD%E5%8F%98%E5%8C%96%E3%80%8B.md">22.精读《V8 引擎特性带来的的 JS 性能变化》</a>
+- <a href="./前沿技术/23.%E7%B2%BE%E8%AF%BB%E3%80%8AAPI%20%E8%AE%BE%E8%AE%A1%E5%8E%9F%E5%88%99%E3%80%8B.md">23.精读《API 设计原则》</a>
+- <a href="./前沿技术/24.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%8E%B0%E4%BB%A3%20JavaScript%20%E6%A6%82%E8%A7%88%E3%80%8B.md">24.精读《现代 JavaScript 概览》</a>
+- <a href="./前沿技术/25.%E7%B2%BE%E8%AF%BB%E3%80%8Anull%20%3E%3D%200%3F%E3%80%8B.md">25.精读《null >= 0?》</a>
+- <a href="./前沿技术/26.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%8A%A0%E5%AF%86%E5%AA%92%E4%BD%93%E6%89%A9%E5%B1%95%E3%80%8B.md">26.精读《加密媒体扩展》</a>
+- <a href="./前沿技术/27.%E7%B2%BE%E8%AF%BB%E3%80%8Acss-in-js%20%E6%9D%80%E9%B8%A1%E7%94%A8%E7%89%9B%E5%88%80%E3%80%8B.md">27.精读《css-in-js 杀鸡用牛刀》</a>
+- <a href="./前沿技术/28.%E7%B2%BE%E8%AF%BB%E3%80%8A2017%20%E5%89%8D%E7%AB%AF%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E5%A4%87%E5%BF%98%E5%BD%95%E3%80%8B.md">28.精读《2017 前端性能优化备忘录》</a>
+- <a href="./前沿技术/29.%E7%B2%BE%E8%AF%BB%E3%80%8AJS%20%E4%B8%AD%E7%9A%84%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86%E3%80%8B.md">29.精读《JS 中的内存管理》</a>
+- <a href="./前沿技术/30.%E7%B2%BE%E8%AF%BB%E3%80%8AJavascript%20%E4%BA%8B%E4%BB%B6%E5%BE%AA%E7%8E%AF%E4%B8%8E%E5%BC%82%E6%AD%A5%E3%80%8B.md">30.精读《Javascript 事件循环与异步》</a>
+- <a href="./前沿技术/31.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%88%91%E4%B8%8D%E5%86%8D%E4%BD%BF%E7%94%A8%E9%AB%98%E9%98%B6%E7%BB%84%E4%BB%B6%E3%80%8B.md">31.精读《我不再使用高阶组件》</a>
+- <a href="./前沿技术/32.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Router4.0%20%E8%BF%9B%E9%98%B6%E6%A6%82%E5%BF%B5%E3%80%8B.md">32.精读《React Router4.0 进阶概念》</a>
+- <a href="./前沿技术/33.%E7%B2%BE%E8%AF%BB%E3%80%8A30%20%E8%A1%8C%20js%20%E4%BB%A3%E7%A0%81%E5%88%9B%E5%BB%BA%E7%A5%9E%E7%BB%8F%E7%BD%91%E7%BB%9C%E3%80%8B.md">33.精读《30 行 js 代码创建神经网络》</a>
+- <a href="./前沿技术/34.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20%E4%BB%A3%E7%A0%81%E6%95%B4%E6%B4%81%E4%B9%8B%E9%81%93%E3%80%8B.md">34.精读《React 代码整洁之道》</a>
+- <a href="./前沿技术/35.%E7%B2%BE%E8%AF%BB%E3%80%8Adob%20-%20%E6%A1%86%E6%9E%B6%E5%AE%9E%E7%8E%B0%E3%80%8B.md">35.精读《dob - 框架实现》</a>
+- <a href="./前沿技术/36.%E7%B2%BE%E8%AF%BB%E3%80%8AWhen%20You%20%E2%80%9CGit%E2%80%9D%20in%20Trouble-%20a%20Version%20Control%20Story%E3%80%8B.md">36.精读《When You “Git” in Trouble- a Version Control Story》</a>
+- <a href="./前沿技术/37.%E7%B2%BE%E8%AF%BB%E3%80%8Ahow%20we%20position%20and%20what%20we%20compare%E3%80%8B.md">37.精读《how we position and what we compare》</a>
+- <a href="./前沿技术/38.%E7%B2%BE%E8%AF%BB%E3%80%8Adob%20-%20%E6%A1%86%E6%9E%B6%E4%BD%BF%E7%94%A8%E3%80%8B.md">38.精读《dob - 框架使用》</a>
+- <a href="./前沿技术/39.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%85%A8%E9%93%BE%E8%B7%AF%E4%BD%93%E9%AA%8C%E6%B5%8F%E8%A7%88%E5%99%A8%E6%8C%96%E7%9F%BF%E3%80%8B.md">39.精读《全链路体验浏览器挖矿》</a>
+- <a href="./前沿技术/40.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%88%9D%E6%8E%A2%20Reason%20%E4%B8%8E%20GraphQL%E3%80%8B.md">40.精读《初探 Reason 与 GraphQL》</a>
+- <a href="./前沿技术/41.%E7%B2%BE%E8%AF%BB%E3%80%8AAnt%20Design%203.0%20%E8%83%8C%E5%90%8E%E7%9A%84%E6%95%85%E4%BA%8B%E3%80%8B.md">41.精读《Ant Design 3.0 背后的故事》</a>
+- <a href="./前沿技术/42.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E6%95%B0%E6%8D%AE%E6%B5%81%E5%93%B2%E5%AD%A6%E3%80%8B.md">42.精读《前端数据流哲学》</a>
+- <a href="./前沿技术/43.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A2%9E%E5%BC%BA%E7%8E%B0%E5%AE%9E%E4%B8%8E%E5%8F%AF%E8%A7%86%E5%8C%96%E3%80%8B.md">43.精读《增强现实与可视化》</a>
+- <a href="./前沿技术/44.%E7%B2%BE%E8%AF%BB%E3%80%8ARekit%20Studio%E3%80%8B.md">44.精读《Rekit Studio》</a>
+- <a href="./前沿技术/45.%E7%B2%BE%E8%AF%BB%E3%80%8AReact's%20new%20Context%20API%E3%80%8B.md">45.精读《React's new Context API》</a>
+- <a href="./前沿技术/46.%E7%B2%BE%E8%AF%BB%E3%80%8Areact-rxjs%E3%80%8B.md">46.精读《react-rxjs》</a>
+- <a href="./前沿技术/47.%E7%B2%BE%E8%AF%BB%E3%80%8Awebpack4.0%20%E5%8D%87%E7%BA%A7%E6%8C%87%E5%8D%97%E3%80%8B.md">47.精读《webpack4.0 升级指南》</a>
+- <a href="./前沿技术/49.%E7%B2%BE%E8%AF%BB%E3%80%8ACompilers%20are%20the%20New%20Frameworks%E3%80%8B.md">49.精读《Compilers are the New Frameworks》</a>
+- <a href="./前沿技术/50.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%BF%AB%E9%80%9F%E4%B8%8A%E6%89%8B%E6%9E%84%E5%BB%BA%20ARKit%20%E5%BA%94%E7%94%A8%E3%80%8B.md">50.精读《快速上手构建 ARKit 应用》</a>
+- <a href="./前沿技术/51.%E7%B2%BE%E8%AF%BB%E3%80%8AElements%20of%20Web%20Dev%E3%80%8B.md">51.精读《Elements of Web Dev》</a>
+- <a href="./前沿技术/52.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%9B%BE%E8%A7%A3%20ES%20%E6%A8%A1%E5%9D%97%E3%80%8B.md">52.精读《图解 ES 模块》</a>
+- <a href="./前沿技术/53.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%8F%92%E4%BB%B6%E5%8C%96%E6%80%9D%E7%BB%B4%E3%80%8B.md">53.精读《插件化思维》</a>
+- <a href="./前沿技术/54.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%9C%A8%E6%B5%8F%E8%A7%88%E5%99%A8%E8%BF%90%E8%A1%8C%20serverRender%E3%80%8B.md">54.精读《在浏览器运行 serverRender》</a>
+- <a href="./前沿技术/55.%E7%B2%BE%E8%AF%BB%E3%80%8Aasync%20await%20%E6%98%AF%E6%8A%8A%E5%8F%8C%E5%88%83%E5%89%91%E3%80%8B.md">55.精读《async await 是把双刃剑》</a>
+- <a href="./前沿技术/56.%E7%B2%BE%E8%AF%BB%E3%80%8A%E9%87%8D%E6%96%B0%E6%80%9D%E8%80%83%20Redux%E3%80%8B.md">56.精读《重新思考 Redux》</a>
+- <a href="./前沿技术/57.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%8E%B0%E4%BB%A3%20js%20%E6%A1%86%E6%9E%B6%E5%AD%98%E5%9C%A8%E7%9A%84%E6%A0%B9%E6%9C%AC%E5%8E%9F%E5%9B%A0%E3%80%8B.md">57.精读《现代 js 框架存在的根本原因》</a>
+- <a href="./前沿技术/58.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript2.0%20-%202.9%E3%80%8B.md">58.精读《Typescript2.0 - 2.9》</a>
+- <a href="./前沿技术/59.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A6%82%E4%BD%95%E5%88%A9%E7%94%A8%20Nodejs%20%E7%9B%91%E5%90%AC%E6%96%87%E4%BB%B6%E5%A4%B9%E3%80%8B.md">59.精读《如何利用 Nodejs 监听文件夹》</a>
+- <a href="./前沿技术/60.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A6%82%E4%BD%95%E5%9C%A8%20nodejs%20%E4%BD%BF%E7%94%A8%E7%8E%AF%E5%A2%83%E5%8F%98%E9%87%8F%E3%80%8B.md">60.精读《如何在 nodejs 使用环境变量》</a>
+- <a href="./前沿技术/61.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20%E5%85%AB%E7%A7%8D%E6%9D%A1%E4%BB%B6%E6%B8%B2%E6%9F%93%E3%80%8B.md">61.精读《React 八种条件渲染》</a>
+- <a href="./前沿技术/62.%E7%B2%BE%E8%AF%BB%E3%80%8AJS%20%E5%BC%95%E6%93%8E%E5%9F%BA%E7%A1%80%E4%B9%8B%20Shapes%20and%20Inline%20Caches%E3%80%8B.md">62.精读《JS 引擎基础之 Shapes and Inline Caches》</a>
+- <a href="./前沿技术/63.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20%E7%9A%84%E5%A4%9A%E6%80%81%E6%80%A7%E3%80%8B.md">63.精读《React 的多态性》</a>
+- <a href="./前沿技术/68.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%A1%A1%E9%87%8F%E7%94%A8%E6%88%B7%E4%BD%93%E9%AA%8C%E3%80%8B.md">68.精读《衡量用户体验》</a>
+- <a href="./前沿技术/69.%E7%B2%BE%E8%AF%BB%E3%80%8ASQL%20vs%20Flux%E3%80%8B.md">69.精读《SQL vs Flux》</a>
+- <a href="./前沿技术/72.%E7%B2%BE%E8%AF%BB%E3%80%8AREST%2C%20GraphQL%2C%20Webhooks%2C%20%26%20gRPC%20%E5%A6%82%E4%BD%95%E9%80%89%E5%9E%8B%E3%80%8B.md">72.精读《REST, GraphQL, Webhooks, & gRPC 如何选型》</a>
+- <a href="./前沿技术/74.%E7%B2%BE%E8%AF%BB%E3%80%8A12%20%E4%B8%AA%E8%AF%84%E4%BC%B0%20JS%20%E5%BA%93%E4%BD%A0%E9%9C%80%E8%A6%81%E5%85%B3%E5%BF%83%E7%9A%84%E4%BA%8B%E3%80%8B.md">74.精读《12 个评估 JS 库你需要关心的事》</a>
+- <a href="./前沿技术/76.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%B0%88%E8%B0%88%20Web%20Workers%E3%80%8B.md">76.精读《谈谈 Web Workers》</a>
+- <a href="./前沿技术/77.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%94%A8%20Reduce%20%E5%AE%9E%E7%8E%B0%20Promise%20%E4%B8%B2%E8%A1%8C%E6%89%A7%E8%A1%8C%E3%80%8B.md">77.精读《用 Reduce 实现 Promise 串行执行》</a>
+- <a href="./前沿技术/79.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Hooks%E3%80%8B.md">79.精读《React Hooks》</a>
+- <a href="./前沿技术/80.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%80%8E%E4%B9%88%E7%94%A8%20React%20Hooks%20%E9%80%A0%E8%BD%AE%E5%AD%90%E3%80%8B.md">80.精读《怎么用 React Hooks 造轮子》</a>
+- <a href="./前沿技术/81.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BD%BF%E7%94%A8%20CSS%20%E5%B1%9E%E6%80%A7%E9%80%89%E6%8B%A9%E5%99%A8%E3%80%8B.md">81.精读《使用 CSS 属性选择器》</a>
+- <a href="./前沿技术/83.%E7%B2%BE%E8%AF%BB%E3%80%8AReact16%20%E6%96%B0%E7%89%B9%E6%80%A7%E3%80%8B.md">83.精读《React16 新特性》</a>
+- <a href="./前沿技术/84.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%203.2%20%E6%96%B0%E7%89%B9%E6%80%A7%E3%80%8B.md">84.精读《Typescript 3.2 新特性》</a>
+- <a href="./前沿技术/86.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%9B%BD%E9%99%85%E5%8C%96%E5%B8%83%E5%B1%80%20-%20Logical%20Properties%E3%80%8B.md">86.精读《国际化布局 - Logical Properties》</a>
+- <a href="./前沿技术/87.%E7%B2%BE%E8%AF%BB%E3%80%8AsetState%20%E5%81%9A%E4%BA%86%E4%BB%80%E4%B9%88%E3%80%8B.md">87.精读《setState 做了什么》</a>
+- <a href="./前沿技术/88.%E7%B2%BE%E8%AF%BB%E3%80%8ACaches%20API%E3%80%8B.md">88.精读《Caches API》</a>
+- <a href="./前沿技术/89.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A6%82%E4%BD%95%E7%BC%96%E8%AF%91%E5%89%8D%E7%AB%AF%E9%A1%B9%E7%9B%AE%E4%B8%8E%E7%BB%84%E4%BB%B6%E3%80%8B.md">89.精读《如何编译前端项目与组件》</a>
+- <a href="./前沿技术/91.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%AD%A3%E5%88%99%20ES2018%E3%80%8B.md">91.精读《正则 ES2018》</a>
+- <a href="./前沿技术/94.%E7%B2%BE%E8%AF%BB%E3%80%8AServerless%20%E7%BB%99%E5%89%8D%E7%AB%AF%E5%B8%A6%E6%9D%A5%E4%BA%86%E4%BB%80%E4%B9%88%E3%80%8B.md">94.精读《Serverless 给前端带来了什么》</a>
+- <a href="./前沿技术/95.%E7%B2%BE%E8%AF%BB%E3%80%8AFunction%20VS%20Class%20%E7%BB%84%E4%BB%B6%E3%80%8B.md">95.精读《Function VS Class 组件》</a>
+- <a href="./前沿技术/96.%E7%B2%BE%E8%AF%BB%E3%80%8AuseEffect%20%E5%AE%8C%E5%85%A8%E6%8C%87%E5%8D%97%E3%80%8B.md">96.精读《useEffect 完全指南》</a>
+- <a href="./前沿技术/97.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%BC%96%E5%86%99%E6%9C%89%E5%BC%B9%E6%80%A7%E7%9A%84%E7%BB%84%E4%BB%B6%E3%80%8B.md">97.精读《编写有弹性的组件》</a>
+- <a href="./前沿技术/99.%E7%B2%BE%E8%AF%BB%E3%80%8AScheduling%20in%20React%E3%80%8B.md">99.精读《Scheduling in React》</a>
+- <a href="./前沿技术/100.%E7%B2%BE%E8%AF%BB%E3%80%8AV8%20%E5%BC%95%E6%93%8E%20Lazy%20Parsing%E3%80%8B.md">100.精读《V8 引擎 Lazy Parsing》</a>
+- <a href="./前沿技术/101.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90%20vs%20%E6%8C%81%E7%BB%AD%E4%BA%A4%E4%BB%98%20vs%20%E6%8C%81%E7%BB%AD%E9%83%A8%E7%BD%B2%E3%80%8B.md">101.精读《持续集成 vs 持续交付 vs 持续部署》</a>
+- <a href="./前沿技术/102.%E7%B2%BE%E8%AF%BB%E3%80%8AMonorepo%20%E7%9A%84%E4%BC%98%E5%8A%BF%E3%80%8B.md">102.精读《Monorepo 的优势》</a>
+- <a href="./前沿技术/104.%E7%B2%BE%E8%AF%BB%E3%80%8AFunction%20Component%20%E5%85%A5%E9%97%A8%E3%80%8B.md">104.精读《Function Component 入门》</a>
+- <a href="./前沿技术/105.%E7%B2%BE%E8%AF%BB%E3%80%8AWhat's%20new%20in%20javascript%E3%80%8B.md">105.精读《What's new in javascript》</a>
+- <a href="./前沿技术/107.%E7%B2%BE%E8%AF%BB%E3%80%8AOptional%20chaining%E3%80%8B.md">107.精读《Optional chaining》</a>
+- <a href="./前沿技术/109.%E7%B2%BE%E8%AF%BB%E3%80%8AVue3.0%20Function%20API%E3%80%8B.md">109.精读《Vue3.0 Function API》</a>
+- <a href="./前沿技术/111.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E6%9C%AA%E6%9D%A5%E5%B1%95%E6%9C%9B%E3%80%8B.md">111.精读《前端未来展望》</a>
+- <a href="./前沿技术/112.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%BA%90%E7%A0%81%E5%AD%A6%E4%B9%A0%E3%80%8B.md">112.精读《源码学习》</a>
+- <a href="./前沿技术/113.%E7%B2%BE%E8%AF%BB%E3%80%8ANodejs%20V12%E3%80%8B.md">113.精读《Nodejs V12》</a>
+- <a href="./前沿技术/117.%E7%B2%BE%E8%AF%BB%E3%80%8ATableau%20%E6%8E%A2%E7%B4%A2%E5%BC%8F%E6%A8%A1%E5%9E%8B%E3%80%8B.md">117.精读《Tableau 探索式模型》</a>
+- <a href="./前沿技术/118.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BD%BF%E7%94%A8%20css%20%E5%8F%98%E9%87%8F%E7%94%9F%E6%88%90%E9%A2%9C%E8%89%B2%E4%B8%BB%E9%A2%98%E3%80%8B.md">118.精读《使用 css 变量生成颜色主题》</a>
+- <a href="./前沿技术/119.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E6%B7%B1%E6%B0%B4%E5%8C%BA%E3%80%8B.md">119.精读《前端深水区》</a>
+- <a href="./前沿技术/120.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Hooks%20%E6%9C%80%E4%BD%B3%E5%AE%9E%E8%B7%B5%E3%80%8B.md">120.精读《React Hooks 最佳实践》</a>
+- <a href="./前沿技术/121.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E4%B8%8E%20BI%E3%80%8B.md">121.精读《前端与 BI》</a>
+- <a href="./前沿技术/123.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%94%A8%20Babel%20%E5%88%9B%E9%80%A0%E8%87%AA%E5%AE%9A%E4%B9%89%20JS%20%E8%AF%AD%E6%B3%95%E3%80%8B.md">123.精读《用 Babel 创造自定义 JS 语法》</a>
+- <a href="./前沿技术/124.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%94%A8%20css%20grid%20%E9%87%8D%E6%96%B0%E6%80%9D%E8%80%83%E5%B8%83%E5%B1%80%E3%80%8B.md">124.精读《用 css grid 重新思考布局》</a>
+- <a href="./前沿技术/125.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%BA%A6%E5%AD%A6%E4%B9%A0%20-%20%E5%87%BD%E6%95%B0%E5%BC%8F%E4%B9%8B%E7%BE%8E%E3%80%8B.md">125.精读《深度学习 - 函数式之美》</a>
+- <a href="./前沿技术/126.%E7%B2%BE%E8%AF%BB%E3%80%8ANuxtjs%E3%80%8B.md">126.精读《Nuxtjs》</a>
+- <a href="./前沿技术/127.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Conf%202019%20-%20Day1%E3%80%8B.md">127.精读《React Conf 2019 - Day1》</a>
+- <a href="./前沿技术/129.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Conf%202019%20-%20Day2%E3%80%8B.md">129.精读《React Conf 2019 - Day2》</a>
+- <a href="./前沿技术/132.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%AD%A3%E4%BA%A4%E7%9A%84%20React%20%E7%BB%84%E4%BB%B6%E3%80%8B.md">132.精读《正交的 React 组件》</a>
+- <a href="./前沿技术/133.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%AF%BB%E6%89%BE%E6%A1%86%E6%9E%B6%E8%AE%BE%E8%AE%A1%E7%9A%84%E5%B9%B3%E8%A1%A1%E7%82%B9%E3%80%8B.md">133.精读《寻找框架设计的平衡点》</a>
+- <a href="./前沿技术/134.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%88%91%E5%9C%A8%E9%98%BF%E9%87%8C%E6%95%B0%E6%8D%AE%E4%B8%AD%E5%8F%B0%E5%A4%A7%E5%89%8D%E7%AB%AF%E3%80%8B.md">134.精读《我在阿里数据中台大前端》</a>
+- <a href="./前沿技术/138.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%B2%BE%E9%80%9A%20console.log%E3%80%8B.md">138.精读《精通 console.log》</a>
+- <a href="./前沿技术/139.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20JSON%20Parser%E3%80%8B.md">139.精读《手写 JSON Parser》</a>
+- <a href="./前沿技术/140.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%BB%93%E5%90%88%20React%20%E4%BD%BF%E7%94%A8%E5%8E%9F%E7%94%9F%20Drag%20Drop%20API%E3%80%8B.md">140.精读《结合 React 使用原生 Drag Drop API》</a>
+- <a href="./前沿技术/141.%E7%B2%BE%E8%AF%BB%E3%80%8AuseRef%20%E4%B8%8E%20createRef%20%E7%9A%84%E5%8C%BA%E5%88%AB%E3%80%8B.md">141.精读《useRef 与 createRef 的区别》</a>
+- <a href="./前沿技术/142.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A6%82%E4%BD%95%E5%81%9A%E5%A5%BD%20CodeReview%E3%80%8B.md">142.精读《如何做好 CodeReview》</a>
+- <a href="./前沿技术/143.%E7%B2%BE%E8%AF%BB%E3%80%8ASuspense%20%E6%94%B9%E5%8F%98%E5%BC%80%E5%8F%91%E6%96%B9%E5%BC%8F%E3%80%8B.md">143.精读《Suspense 改变开发方式》</a>
+- <a href="./前沿技术/144.%E7%B2%BE%E8%AF%BB%E3%80%8AWebpack5%20%E6%96%B0%E7%89%B9%E6%80%A7%20-%20%E6%A8%A1%E5%9D%97%E8%81%94%E9%82%A6%E3%80%8B.md">144.精读《Webpack5 新特性 - 模块联邦》</a>
+- <a href="./前沿技术/145.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Router%20v6%E3%80%8B.md">145.精读《React Router v6》</a>
+- <a href="./前沿技术/146.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Hooks%20%E6%95%B0%E6%8D%AE%E6%B5%81%E3%80%8B.md">146.精读《React Hooks 数据流》</a>
+- <a href="./前沿技术/147.%20%E7%B2%BE%E8%AF%BB%E3%80%8A%40types%20react%20%E5%80%BC%E5%BE%97%E6%B3%A8%E6%84%8F%E7%9A%84%20TS%20%E6%8A%80%E5%B7%A7%E3%80%8B.md">147. 精读《@types react 值得注意的 TS 技巧》</a>
+- <a href="./前沿技术/148.%20%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Error%20Boundaries%E3%80%8B.md">148. 精读《React Error Boundaries》</a>
+- <a href="./前沿技术/149.%20%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20%E6%80%A7%E8%83%BD%E8%B0%83%E8%AF%95%E3%80%8B.md">149. 精读《React 性能调试》</a>
+- <a href="./前沿技术/150.%20%E7%B2%BE%E8%AF%BB%E3%80%8ADeno%201.0%20%E4%BD%A0%E9%9C%80%E8%A6%81%E4%BA%86%E8%A7%A3%E7%9A%84%E3%80%8B.md">150. 精读《Deno 1.0 你需要了解的》</a>
+- <a href="./前沿技术/152.%20%E7%B2%BE%E8%AF%BB%E3%80%8Arecoil%E3%80%8B.md">152. 精读《recoil》</a>
+- <a href="./前沿技术/153.%20%E7%B2%BE%E8%AF%BB%E3%80%8Asnowpack%E3%80%8B.md">153. 精读《snowpack》</a>
+- <a href="./前沿技术/154.%20%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%94%A8%20React%20%E5%81%9A%E6%8C%89%E9%9C%80%E6%B8%B2%E6%9F%93%E3%80%8B.md">154. 精读《用 React 做按需渲染》</a>
+- <a href="./前沿技术/157.%20%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%A6%82%E4%BD%95%E6%AF%94%E8%BE%83%20Object%20%E5%AF%B9%E8%B1%A1%E3%80%8B.md">157. 精读《如何比较 Object 对象》</a>
+- <a href="./前沿技术/158.%20%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%204%E3%80%8B.md">158. 精读《Typescript 4》</a>
+- <a href="./前沿技术/159.%20%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%AF%B9%E4%BD%8E%E4%BB%A3%E7%A0%81%E6%90%AD%E5%BB%BA%E7%9A%84%E7%90%86%E8%A7%A3%E3%80%8B.md">159. 精读《对低代码搭建的理解》</a>
+- <a href="./前沿技术/160.%20%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%87%BD%E6%95%B0%E7%BC%93%E5%AD%98%E3%80%8B.md">160. 精读《函数缓存》</a>
+- <a href="./前沿技术/161.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%8F%AF%E8%A7%86%E5%8C%96%E6%90%AD%E5%BB%BA%E6%80%9D%E8%80%83%20-%20%E5%AF%8C%E6%96%87%E6%9C%AC%E6%90%AD%E5%BB%BA%E3%80%8B.md">161.精读《可视化搭建思考 - 富文本搭建》</a>
+- <a href="./前沿技术/162.%E7%B2%BE%E8%AF%BB%E3%80%8ATasks%2C%20microtasks%2C%20queues%20and%20schedules%E3%80%8B.md">162.精读《Tasks, microtasks, queues and schedules》</a>
+- <a href="./前沿技术/163.%E7%B2%BE%E8%AF%BB%E3%80%8ASpring%20%E6%A6%82%E5%BF%B5%E3%80%8B.md">163.精读《Spring 概念》</a>
+- <a href="./前沿技术/164.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%95%B0%E6%8D%AE%E6%90%AD%E5%BB%BA%E5%BC%95%E6%93%8E%20bi-designer%20API-%E8%AE%BE%E8%AE%A1%E5%99%A8%E3%80%8B.md">164.精读《数据搭建引擎 bi-designer API-设计器》</a>
+- <a href="./前沿技术/165.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%95%B0%E6%8D%AE%E6%90%AD%E5%BB%BA%E5%BC%95%E6%93%8E%20bi-designer%20API-%E7%BB%84%E4%BB%B6%E3%80%8B.md">165.精读《数据搭建引擎 bi-designer API-组件》</a>
+- <a href="./前沿技术/166.%E7%B2%BE%E8%AF%BB%E3%80%8ABI%20%E6%90%AD%E5%BB%BA%20-%20%E7%AD%9B%E9%80%89%E6%9D%A1%E4%BB%B6%E3%80%8B.md">166.精读《BI 搭建 - 筛选条件》</a>
+- <a href="./前沿技术/190.%E7%B2%BE%E8%AF%BB%E3%80%8ADOM%20diff%20%E5%8E%9F%E7%90%86%E8%AF%A6%E8%A7%A3%E3%80%8B.md">190.精读《DOM diff 原理详解》</a>
+- <a href="./前沿技术/191.%E7%B2%BE%E8%AF%BB%E3%80%8A%E9%AB%98%E6%80%A7%E8%83%BD%E8%A1%A8%E6%A0%BC%E3%80%8B.md">191.精读《高性能表格》</a>
+- <a href="./前沿技术/192.%E7%B2%BE%E8%AF%BB%E3%80%8ADOM%20diff%20%E6%9C%80%E9%95%BF%E4%B8%8A%E5%8D%87%E5%AD%90%E5%BA%8F%E5%88%97%E3%80%8B.md">192.精读《DOM diff 最长上升子序列》</a>
+- <a href="./前沿技术/193.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Server%20Component%E3%80%8B.md">193.精读《React Server Component》</a>
+- <a href="./前沿技术/194.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%E5%9F%BA%E7%A1%80%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E3%80%8B.md">194.精读《算法基础数据结构》</a>
+- <a href="./前沿技术/195.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%96%B0%E4%B8%80%E4%BB%A3%E5%89%8D%E7%AB%AF%E6%9E%84%E5%BB%BA%E5%B7%A5%E5%85%B7%E5%AF%B9%E6%AF%94%E3%80%8B.md">195.精读《新一代前端构建工具对比》</a>
+- <a href="./前沿技术/196.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E8%81%8C%E4%B8%9A%E8%A7%84%E5%88%92%20-%202021%20%E5%B9%B4%E3%80%8B.md">196.精读《前端职业规划 - 2021 年》</a>
+- <a href="./前沿技术/197.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BD%8E%E4%BB%A3%E7%A0%81%E9%80%BB%E8%BE%91%E7%BC%96%E6%8E%92%E3%80%8B.md">197.精读《低代码逻辑编排》</a>
+- <a href="./前沿技术/202.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%2018%E3%80%8B.md">202.精读《React 18》</a>
+- <a href="./前沿技术/204.%E7%B2%BE%E8%AF%BB%E3%80%8A%E9%BB%98%E8%AE%A4%E3%80%81%E5%91%BD%E5%90%8D%E5%AF%BC%E5%87%BA%E7%9A%84%E5%8C%BA%E5%88%AB%E3%80%8B.md">204.精读《默认、命名导出的区别》</a>
+- <a href="./前沿技术/205.%E7%B2%BE%E8%AF%BB%E3%80%8AJS%20with%20%E8%AF%AD%E6%B3%95%E3%80%8B.md">205.精读《JS with 语法》</a>
+- <a href="./前沿技术/206.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%B8%80%E7%A7%8D%20Hooks%20%E6%95%B0%E6%8D%AE%E6%B5%81%E7%AE%A1%E7%90%86%E6%96%B9%E6%A1%88%E3%80%8B.md">206.精读《一种 Hooks 数据流管理方案》</a>
+- <a href="./前沿技术/207.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%20infer%20%E5%85%B3%E9%94%AE%E5%AD%97%E3%80%8B.md">207.精读《Typescript infer 关键字》</a>
+- <a href="./前沿技术/208.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%204.4%E3%80%8B.md">208.精读《Typescript 4.4》</a>
+- <a href="./前沿技术/209.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%8D%95%E8%8E%B7%E6%89%80%E6%9C%89%E5%BC%82%E6%AD%A5%20error%E3%80%8B.md">209.精读《捕获所有异步 error》</a>
+- <a href="./前沿技术/210.%E7%B2%BE%E8%AF%BB%E3%80%8Aclass%20static%20block%E3%80%8B.md">210.精读《class static block》</a>
+- <a href="./前沿技术/211.%E7%B2%BE%E8%AF%BB%E3%80%8AMicrosoft%20Power%20Fx%E3%80%8B.md">211.精读《Microsoft Power Fx》</a>
+- <a href="./前沿技术/212.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%8F%AF%E7%BB%B4%E6%8A%A4%E6%80%A7%E6%80%9D%E8%80%83%E3%80%8B.md">212.精读《可维护性思考》</a>
+- <a href="./前沿技术/213.%E7%B2%BE%E8%AF%BB%E3%80%8APrisma%20%E7%9A%84%E4%BD%BF%E7%94%A8%E3%80%8B.md">213.精读《Prisma 的使用》</a>
+- <a href="./前沿技术/214.%E7%B2%BE%E8%AF%BB%E3%80%8Aweb%20streams%E3%80%8B.md">214.精读《web streams》</a>
+- <a href="./前沿技术/215.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BB%80%E4%B9%88%E6%98%AF%20LOD%20%E8%A1%A8%E8%BE%BE%E5%BC%8F%E3%80%8B.md">215.精读《什么是 LOD 表达式》</a>
+- <a href="./前沿技术/216.%E7%B2%BE%E8%AF%BB%E3%80%8A15%20%E5%A4%A7%20LOD%20%E8%A1%A8%E8%BE%BE%E5%BC%8F%20-%20%E4%B8%8A%E3%80%8B.md">216.精读《15 大 LOD 表达式 - 上》</a>
+- <a href="./前沿技术/217.%E7%B2%BE%E8%AF%BB%E3%80%8A15%20%E5%A4%A7%20LOD%20%E8%A1%A8%E8%BE%BE%E5%BC%8F%20-%20%E4%B8%8B%E3%80%8B.md">217.精读《15 大 LOD 表达式 - 下》</a>
+- <a href="./前沿技术/218.%E7%B2%BE%E8%AF%BB%E3%80%8ARust%20%E6%98%AF%20JS%20%E5%9F%BA%E5%BB%BA%E7%9A%84%E6%9C%AA%E6%9D%A5%E3%80%8B.md">218.精读《Rust 是 JS 基建的未来》</a>
+- <a href="./前沿技术/219.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%80%E3%80%8B.md">219.精读《深入了解现代浏览器一》</a>
+- <a href="./前沿技术/220.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%BA%8C%E3%80%8B.md">220.精读《深入了解现代浏览器二》</a>
+- <a href="./前沿技术/221.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E4%B8%89%E3%80%8B.md">221.精读《深入了解现代浏览器三》</a>
+- <a href="./前沿技术/222.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%B7%B1%E5%85%A5%E4%BA%86%E8%A7%A3%E7%8E%B0%E4%BB%A3%E6%B5%8F%E8%A7%88%E5%99%A8%E5%9B%9B%E3%80%8B.md">222.精读《深入了解现代浏览器四》</a>
+- <a href="./前沿技术/223.%E7%B2%BE%E8%AF%BB%E3%80%8ARecords%20%26%20Tuples%20%E6%8F%90%E6%A1%88%E3%80%8B.md">223.精读《Records & Tuples 提案》</a>
+- <a href="./前沿技术/224.%E7%B2%BE%E8%AF%BB%E3%80%8ARecords%20%26%20Tuples%20for%20React%E3%80%8B.md">224.精读《Records & Tuples for React》</a>
+- <a href="./前沿技术/225.%E7%B2%BE%E8%AF%BB%E3%80%8AExcel%20JS%20API%E3%80%8B.md">225.精读《Excel JS API》</a>
+- <a href="./前沿技术/226.%E7%B2%BE%E8%AF%BB%E3%80%8A2021%20%E5%89%8D%E7%AB%AF%E6%96%B0%E7%A7%80%E5%9B%9E%E9%A1%BE%E3%80%8B.md">226.精读《2021 前端新秀回顾》</a>
+- <a href="./前沿技术/228.%E7%B2%BE%E8%AF%BB%E3%80%8Apipe%20operator%20for%20JavaScript%E3%80%8B.md">228.精读《pipe operator for JavaScript》</a>
+- <a href="./前沿技术/230.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%AF%B9%20Markdown%20%E7%9A%84%E6%80%9D%E8%80%83%E3%80%8B.md">230.精读《对 Markdown 的思考》</a>
+- <a href="./前沿技术/237.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript%204.5-4.6%20%E6%96%B0%E7%89%B9%E6%80%A7%E3%80%8B.md">237.精读《Typescript 4.5-4.6 新特性》</a>
+- <a href="./前沿技术/238.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%B8%8D%E5%86%8D%E9%9C%80%E8%A6%81%20JS%20%E5%81%9A%E7%9A%84%205%20%E4%BB%B6%E4%BA%8B%E3%80%8B.md">238.精读《不再需要 JS 做的 5 件事》</a>
+- <a href="./前沿技术/239.%E7%B2%BE%E8%AF%BB%E3%80%8AJS%20%E6%95%B0%E7%BB%84%E7%9A%84%E5%86%85%E9%83%A8%E5%AE%9E%E7%8E%B0%E3%80%8B.md">239.精读《JS 数组的内部实现》</a>
+- <a href="./前沿技术/240.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20useEvent%20RFC%E3%80%8B.md">240.精读《React useEvent RFC》</a>
+- <a href="./前沿技术/242.%E7%B2%BE%E8%AF%BB%E3%80%8Aweb%20reflow%E3%80%8B.md">242.精读《web reflow》</a>
+
+### TS 类型体操
+
+- <a href="./TS 类型体操/243.%E7%B2%BE%E8%AF%BB%E3%80%8Atype%20challenges%20-%20easy%E3%80%8B.md">243.精读《type challenges - easy》</a>
+
+### 设计模式
+
+- <a href="./设计模式/167.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Abstract%20Factory%20%E6%8A%BD%E8%B1%A1%E5%B7%A5%E5%8E%82%E3%80%8B.md">167.精读《设计模式 - Abstract Factory 抽象工厂》</a>
+- <a href="./设计模式/168.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Builder%20%E7%94%9F%E6%88%90%E5%99%A8%E3%80%8B.md">168.精读《设计模式 - Builder 生成器》</a>
+- <a href="./设计模式/169.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Factory%20Method%20%E5%B7%A5%E5%8E%82%E6%96%B9%E6%B3%95%E3%80%8B.md">169.精读《设计模式 - Factory Method 工厂方法》</a>
+- <a href="./设计模式/170.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Prototype%20%E5%8E%9F%E5%9E%8B%E6%A8%A1%E5%BC%8F%E3%80%8B.md">170.精读《设计模式 - Prototype 原型模式》</a>
+- <a href="./设计模式/171.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Singleton%20%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F%E3%80%8B.md">171.精读《设计模式 - Singleton 单例模式》</a>
+- <a href="./设计模式/172.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Adapter%20%E9%80%82%E9%85%8D%E5%99%A8%E6%A8%A1%E5%BC%8F%E3%80%8B.md">172.精读《设计模式 - Adapter 适配器模式》</a>
+- <a href="./设计模式/173.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Bridge%20%E6%A1%A5%E6%8E%A5%E6%A8%A1%E5%BC%8F%E3%80%8B.md">173.精读《设计模式 - Bridge 桥接模式》</a>
+- <a href="./设计模式/174.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Composite%20%E7%BB%84%E5%90%88%E6%A8%A1%E5%BC%8F%E3%80%8B.md">174.精读《设计模式 - Composite 组合模式》</a>
+- <a href="./设计模式/175.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Decorator%20%E8%A3%85%E9%A5%B0%E5%99%A8%E6%A8%A1%E5%BC%8F%E3%80%8B.md">175.精读《设计模式 - Decorator 装饰器模式》</a>
+- <a href="./设计模式/176.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Facade%20%E5%A4%96%E8%A7%82%E6%A8%A1%E5%BC%8F%E3%80%8B.md">176.精读《设计模式 - Facade 外观模式》</a>
+- <a href="./设计模式/177.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Flyweight%20%E4%BA%AB%E5%85%83%E6%A8%A1%E5%BC%8F%E3%80%8B.md">177.精读《设计模式 - Flyweight 享元模式》</a>
+- <a href="./设计模式/178.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Proxy%20%E4%BB%A3%E7%90%86%E6%A8%A1%E5%BC%8F%E3%80%8B.md">178.精读《设计模式 - Proxy 代理模式》</a>
+- <a href="./设计模式/179.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Chain%20of%20Responsibility%20%E8%81%8C%E8%B4%A3%E9%93%BE%E6%A8%A1%E5%BC%8F%E3%80%8B.md">179.精读《设计模式 - Chain of Responsibility 职责链模式》</a>
+- <a href="./设计模式/180.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Command%20%E5%91%BD%E4%BB%A4%E6%A8%A1%E5%BC%8F%E3%80%8B.md">180.精读《设计模式 - Command 命令模式》</a>
+- <a href="./设计模式/181.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Interpreter%20%E8%A7%A3%E9%87%8A%E5%99%A8%E6%A8%A1%E5%BC%8F%E3%80%8B.md">181.精读《设计模式 - Interpreter 解释器模式》</a>
+- <a href="./设计模式/182.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Iterator%20%E8%BF%AD%E4%BB%A3%E5%99%A8%E6%A8%A1%E5%BC%8F%E3%80%8B.md">182.精读《设计模式 - Iterator 迭代器模式》</a>
+- <a href="./设计模式/183.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Mediator%20%E4%B8%AD%E4%BB%8B%E8%80%85%E6%A8%A1%E5%BC%8F%E3%80%8B.md">183.精读《设计模式 - Mediator 中介者模式》</a>
+- <a href="./设计模式/184.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Memoto%20%E5%A4%87%E5%BF%98%E5%BD%95%E6%A8%A1%E5%BC%8F%E3%80%8B.md">184.精读《设计模式 - Memoto 备忘录模式》</a>
+- <a href="./设计模式/185.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Observer%20%E8%A7%82%E5%AF%9F%E8%80%85%E6%A8%A1%E5%BC%8F%E3%80%8B.md">185.精读《设计模式 - Observer 观察者模式》</a>
+- <a href="./设计模式/186.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20State%20%E7%8A%B6%E6%80%81%E6%A8%A1%E5%BC%8F%E3%80%8B.md">186.精读《设计模式 - State 状态模式》</a>
+- <a href="./设计模式/187.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Strategy%20%E7%AD%96%E7%95%A5%E6%A8%A1%E5%BC%8F%E3%80%8B.md">187.精读《设计模式 - Strategy 策略模式》</a>
+- <a href="./设计模式/188.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Template%20Method%20%E6%A8%A1%E7%89%88%E6%A8%A1%E5%BC%8F%E3%80%8B.md">188.精读《设计模式 - Template Method 模版模式》</a>
+- <a href="./设计模式/189.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F%20-%20Visitor%20%E8%AE%BF%E9%97%AE%E8%80%85%E6%A8%A1%E5%BC%8F%E3%80%8B.md">189.精读《设计模式 - Visitor 访问者模式》</a>
+
+### 编译原理
+
+- <a href="./编译原理/64.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%8D%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md">64.精读《手写 SQL 编译器 - 词法分析》</a>
+- <a href="./编译原理/65.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E6%96%87%E6%B3%95%E4%BB%8B%E7%BB%8D%E3%80%8B.md">65.精读《手写 SQL 编译器 - 文法介绍》</a>
+- <a href="./编译原理/66.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%AD%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md">66.精读《手写 SQL 编译器 - 语法分析》</a>
+- <a href="./编译原理/67.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E5%9B%9E%E6%BA%AF%E3%80%8B.md">67.精读《手写 SQL 编译器 - 回溯》</a>
+- <a href="./编译原理/70.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%AD%E6%B3%95%E6%A0%91%E3%80%8B.md">70.精读《手写 SQL 编译器 - 语法树》</a>
+- <a href="./编译原理/71.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E9%94%99%E8%AF%AF%E6%8F%90%E7%A4%BA%E3%80%8B.md">71.精读《手写 SQL 编译器 - 错误提示》</a>
+- <a href="./编译原理/78.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E4%B9%8B%E7%BC%93%E5%AD%98%E3%80%8B.md">78.精读《手写 SQL 编译器 - 性能优化之缓存》</a>
+- <a href="./编译原理/85.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E6%99%BA%E8%83%BD%E6%8F%90%E7%A4%BA%E3%80%8B.md">85.精读《手写 SQL 编译器 - 智能提示》</a>
+
+### 源码解读
+
+- <a href="./源码解读/48.%E7%B2%BE%E8%AF%BB%E3%80%8AImmer.js%E3%80%8B%E6%BA%90%E7%A0%81.md">48.精读《Immer.js》源码</a>
+- <a href="./源码解读/73.%E7%B2%BE%E8%AF%BB%E3%80%8Asqorn%20%E6%BA%90%E7%A0%81%E3%80%8B.md">73.精读《sqorn 源码》</a>
+- <a href="./源码解读/75.%E7%B2%BE%E8%AF%BB%E3%80%8AEpitath%20%E6%BA%90%E7%A0%81%20-%20renderProps%20%E6%96%B0%E7%94%A8%E6%B3%95%E3%80%8B.md">75.精读《Epitath 源码 - renderProps 新用法》</a>
+- <a href="./源码解读/82.%E7%B2%BE%E8%AF%BB%E3%80%8AHtm%20-%20Hyperscript%20%E6%BA%90%E7%A0%81%E3%80%8B.md">82.精读《Htm - Hyperscript 源码》</a>
+- <a href="./源码解读/92.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20PowerPlug%20%E6%BA%90%E7%A0%81%E3%80%8B.md">92.精读《React PowerPlug 源码》</a>
+- <a href="./源码解读/93.%E7%B2%BE%E8%AF%BB%E3%80%8Asyntax-parser%20%E6%BA%90%E7%A0%81%E3%80%8B.md">93.精读《syntax-parser 源码》</a>
+- <a href="./源码解读/98.%E7%B2%BE%E8%AF%BB%E3%80%8Areact-easy-state%20%E6%BA%90%E7%A0%81%E3%80%8B.md">98.精读《react-easy-state 源码》</a>
+- <a href="./源码解读/110.%E7%B2%BE%E8%AF%BB%E3%80%8AInject%20Instance%20%E6%BA%90%E7%A0%81%E3%80%8B.md">110.精读《Inject Instance 源码》</a>
+- <a href="./源码解读/122.%E7%B2%BE%E8%AF%BB%E3%80%8Arobot%20%E6%BA%90%E7%A0%81%20-%20%E6%9C%89%E9%99%90%E7%8A%B6%E6%80%81%E6%9C%BA%E3%80%8B.md">122.精读《robot 源码 - 有限状态机》</a>
+- <a href="./源码解读/128.%E7%B2%BE%E8%AF%BB%E3%80%8AHooks%20%E5%8F%96%E6%95%B0%20-%20swr%20%E6%BA%90%E7%A0%81%E3%80%8B.md">128.精读《Hooks 取数 - swr 源码》</a>
+- <a href="./源码解读/130.%E7%B2%BE%E8%AF%BB%E3%80%8Aunstated%20%E4%B8%8E%20unstated-next%20%E6%BA%90%E7%A0%81%E3%80%8B.md">130.精读《unstated 与 unstated-next 源码》</a>
+- <a href="./源码解读/151.%20%E7%B2%BE%E8%AF%BB%E3%80%8A%40umijs%20use-request%E3%80%8B%E6%BA%90%E7%A0%81.md">151. 精读《@umijs use-request》源码</a>
+- <a href="./源码解读/155.%20%E7%B2%BE%E8%AF%BB%E3%80%8Ause-what-changed%20%E6%BA%90%E7%A0%81%E3%80%8B.md">155. 精读《use-what-changed 源码》</a>
+- <a href="./源码解读/156.%20%E7%B2%BE%E8%AF%BB%E3%80%8Areact-intersection-observer%20%E6%BA%90%E7%A0%81%E3%80%8B.md">156. 精读《react-intersection-observer 源码》</a>
+- <a href="./源码解读/227.%20%E7%B2%BE%E8%AF%BB%E3%80%8Azustand%20%E6%BA%90%E7%A0%81%E3%80%8B.md">227. 精读《zustand 源码》</a>
+- <a href="./源码解读/229.%E7%B2%BE%E8%AF%BB%E3%80%8Avue-lit%20%E6%BA%90%E7%A0%81%E3%80%8B.md">229.精读《vue-lit 源码》</a>
+- <a href="./源码解读/241.%E7%B2%BE%E8%AF%BB%E3%80%8Areact-snippets%20-%20Router%20%E6%BA%90%E7%A0%81%E3%80%8B.md">241.精读《react-snippets - Router 源码》</a>
+
+### 商业思考
+
+- <a href="./商业思考/90.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%9E%81%E5%AE%A2%E5%85%AC%E5%9B%AD%202019%E3%80%8B.md">90.精读《极客公园 2019》</a>
+- <a href="./商业思考/103.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%B8%BA%E4%BB%80%E4%B9%88%E4%B8%93%E5%AE%B6%E4%B8%8D%E5%86%8D%E5%85%B3%E5%BF%83%E6%8A%80%E6%9C%AF%E7%BB%86%E8%8A%82%E3%80%8B.md">103.精读《为什么专家不再关心技术细节》</a>
+- <a href="./商业思考/106.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%95%B0%E6%8D%AE%E4%B9%8B%E4%B8%8A%C2%B7%E6%99%BA%E6%85%A7%E4%B9%8B%E5%85%89%20-%202018%E3%80%8B.md">106.精读《数据之上·智慧之光 - 2018》</a>
+- <a href="./商业思考/108.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%99%BA%E8%83%BD%E5%95%86%E4%B8%9A%E3%80%8B.md">108.精读《智能商业》</a>
+- <a href="./商业思考/114.%E7%B2%BE%E8%AF%BB%E3%80%8A%E8%B0%81%E5%9C%A8%E4%B8%96%E7%95%8C%E4%B8%AD%E5%BF%83%E3%80%8B.md">114.精读《谁在世界中心》</a>
+- <a href="./商业思考/115.%E7%B2%BE%E8%AF%BB%E3%80%8ATableau%20%E5%85%A5%E9%97%A8%E3%80%8B.md">115.精读《Tableau 入门》</a>
+- <a href="./商业思考/116.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%88%B7%E6%96%B0%E3%80%8B.md">116.精读《刷新》</a>
+- <a href="./商业思考/131.%E7%B2%BE%E8%AF%BB%E3%80%8A%E4%BB%8E%200%20%E5%88%B0%201%E3%80%8B.md">131.精读《从 0 到 1》</a>
+- <a href="./商业思考/135.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%9E%81%E5%AE%A2%E5%85%AC%E5%9B%AD%20IFX%20-%20%E4%B8%8A%E3%80%8B.md">135.精读《极客公园 IFX - 上》</a>
+- <a href="./商业思考/136.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%9E%81%E5%AE%A2%E5%85%AC%E5%9B%AD%20IFX%20-%20%E4%B8%8B%E3%80%8B.md">136.精读《极客公园 IFX - 下》</a>
+- <a href="./商业思考/137.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%BD%93%E6%88%91%E5%9C%A8%E5%88%86%E4%BA%AB%E7%9A%84%E6%97%B6%E5%80%99%EF%BC%8C%E6%88%91%E5%9C%A8%E5%81%9A%E4%BB%80%E4%B9%88%EF%BC%9F%E3%80%8B.md">137.精读《当我在分享的时候，我在做什么？》</a>
+
+### 算法
+
+- <a href="./算法/198.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%20-%20%E5%8A%A8%E6%80%81%E8%A7%84%E5%88%92%E3%80%8B.md">198.精读《算法 - 动态规划》</a>
+- <a href="./算法/199.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%20-%20%E6%BB%91%E5%8A%A8%E7%AA%97%E5%8F%A3%E3%80%8B.md">199.精读《算法 - 滑动窗口》</a>
+- <a href="./算法/200.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%20-%20%E5%9B%9E%E6%BA%AF%E3%80%8B.md">200.精读《算法 - 回溯》</a>
+- <a href="./算法/201.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%20-%20%E4%BA%8C%E5%8F%89%E6%A0%91%E3%80%8B.md">201.精读《算法 - 二叉树》</a>
+- <a href="./算法/203.%E7%B2%BE%E8%AF%BB%E3%80%8A%E7%AE%97%E6%B3%95%20-%20%E4%BA%8C%E5%8F%89%E6%90%9C%E7%B4%A2%E6%A0%91%E3%80%8B.md">203.精读《算法 - 二叉搜索树》</a>
+
+### SQL
+
+- <a href="./SQL/231.SQL%20%E5%85%A5%E9%97%A8.md">231.SQL 入门</a>
+- <a href="./SQL/232.SQL%20%E8%81%9A%E5%90%88%E6%9F%A5%E8%AF%A2.md">232.SQL 聚合查询</a>
+- <a href="./SQL/233.SQL%20%E5%A4%8D%E6%9D%82%E6%9F%A5%E8%AF%A2.md">233.SQL 复杂查询</a>
+- <a href="./SQL/234.SQL%20CASE%20%E8%A1%A8%E8%BE%BE%E5%BC%8F.md">234.SQL CASE 表达式</a>
+- <a href="./SQL/235.SQL%20%E7%AA%97%E5%8F%A3%E5%87%BD%E6%95%B0.md">235.SQL 窗口函数</a>
+- <a href="./SQL/236.SQL%20grouping.md">236.SQL grouping</a>
 
 ## 关注前端精读微信公众号
 
 <img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
-
-## Special Sponsors
-
-<table>
-      <tbody>
-        <tr>
-          <td align="center" valign="middle">
-            <a href="https://e.coding.net/?utm_source=weekly" target="_blank">
-              <img width="300" src="https://img.alicdn.com/tfs/TB107D.QbrpK1RjSZTEXXcWAVXa-1000-332.png">
-            </a>
-          </td>
-        </tr>
-      </tbody>
-</table>

前沿技术/1.精读《js 模块化发展》.md

@@ -8,7 +8,7 @@
 
 # 1 引言
 
-<img src="assets/1/cube.jpeg" alt="logo" width="500" />
+<img src="https://img.alicdn.com/imgextra/i4/O1CN01mvDKCM1owPSsLDBmI_!!6000000005289-2-tps-475-297.png" alt="logo" width="500" />
 
 > 如今，Javascript 模块化规范非常方便、自然，但这个新规范仅执行了 2 年，就在 4 年前，js 的模块化还停留在运行时支持，10 年前，通过后端模版定义、注释定义模块依赖。对经历过来的人来说，历史的模块化方式还停留在脑海中，反而新上手的同学会更快接受现代的模块化规范。
 
@@ -81,7 +81,7 @@ YUI3 的 sandbox 像极了差不多同时出现的 AMD 规范，但早期 yahoo
 
 对于 js 模块化，最近出现的 `<script type="module">` 方式，虽然还没有得到浏览器原生支持，但也是我比较看好的未来趋势，这样就连 webpack 的拆包都不需要了，直接把源代码传到服务器，配合 http2.0 完美抛开预编译的枷锁。
 
-上述三中方案都不依赖预编译，分别实现了 html、css、js 模块化，相信这就是未来。
+上述三种方案都不依赖预编译，分别实现了 html、css、js 模块化，相信这就是未来。
 
 ### 模块化标准推进速度仍然缓慢
 
@@ -103,7 +103,7 @@ YUI3 的 sandbox 像极了差不多同时出现的 AMD 规范，但早期 yahoo
 
 > 看到大家基本都提到了 HTTP/2，对这项技术解决前端模块化及资源打包等工程问题抱有非常大的期待。很多人也认为 HTTP/2 普及后，基本就没有 Webpack 什么事情了。
 
-不过 Webpack 作者 @sokra 在他的文章 [webpack & HTTP/2](https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.zdo4juvgo) 里提到了一个新的 Webpack 插件 `AggressiveSplittingPlugin`。简单的说，这款插件就是为了充分利用 HTTP/2 的文件缓存能力，将你的业务代码自动拆分成若干个数十 KB 的小文件。后续若其中任意一个文件发生变化，可以保证其他的小 chunck 不需要重新下载。
+不过 Webpack 作者 @sokra 在他的文章 [webpack & HTTP/2](https://medium.com/webpack/webpack-http-2-7083ec3f3ce6#.zdo4juvgo) 里提到了一个新的 Webpack 插件 `AggressiveSplittingPlugin`。简单的说，这款插件就是为了充分利用 HTTP/2 的文件缓存能力，将你的业务代码自动拆分成若干个数十 KB 的小文件。后续若其中任意一个文件发生变化，可以保证其他的小 chunk 不需要重新下载。
 
 可见，**即使不断的有新技术出现，也依然需要配套的工具来将前端工程问题解决方案推向极致。**
 

前沿技术/104.精读《Function Component 入门》.md

@@ -813,25 +813,30 @@ function Parent() {
 换一个例子就可以看得更清楚：
 
 ```js
-function Parent() {
+function Parent(props) {
   const [count, setCount] = useState(0);
   const [step, setStep] = useState(0);
   const [other, setOther] = useState(0);
-  const drag = useDraggable(count, step); // 封装了拖拽函数
+  const drag = useDraggable(props.dom, count, step); // 封装了拖拽函数
+
+  useEffect(() => {
+    // dom 变化时重新实例化
+    drag()
+  }, [drag])
 }
 ```
 
 假设我们使用 [Sortablejs](https://github.com/SortableJS/Sortable) 对某个区域进行拖拽监听，这个函数每次都重复执行的性能损耗非常大，**然而这个函数内部可能因为仅仅要上报一些日志，所以依赖了没有实际被使用的 `count` `step` 变量：**
 
 ```js
-function useDraggable(count, step) {
+function useDraggable(dom, count, step) {
   return useCallback(() => {
     // 上报日志
     report(count, step);
 
     // 对区域进行初始化，非常耗时
     // ... 省略耗时代码
-  }, [count, step]);
+  }, [dom, count, step]);
 }
 ```
 

前沿技术/11.精读《前端调试技巧》.md

@@ -4,7 +4,7 @@
 
 # 1 引言
 
-<img src="assets/11/coffee.jpg" width="500" alt="logo" />
+<img src="https://img.alicdn.com/imgextra/i2/O1CN01JC1TZ51Nxn24teojP_!!6000000001637-2-tps-1024-1296.png" width="500" alt="logo" />
 
 梵高这幅画远景漆黑一片，近景的咖啡店色彩却反差很大，他只是望着黑夜中温暖的咖啡馆，交织着矛盾与孤独。代码不可能没有 BUG，调试与开发也始终交织在一起，我们在这两种矛盾中不断成长。
 
@@ -105,7 +105,7 @@ Css 不像 Js 一样方便分析规则是否存在冗余，Chrome 帮我们做
 
 Chrome 会记录最后插入的 5 个元素，分别以 `$0` ~ `$4` 的方式在控制台直接输出。
 
-<img src="assets/11/last-item.png" width="500" alt="last-items" />
+<img src="https://img.alicdn.com/imgextra/i4/O1CN01xsKHb822gkXhDDcCA_!!6000000007150-2-tps-417-516.png" width="500" alt="last-items" />
 
 ### Console.table
 

前沿技术/117.精读《Tableau 探索式模型》.md

@@ -154,7 +154,7 @@ Table 主要配置分为行、列、标记与筛选。通过这四个配置区
 
 我们会发现，原本存在于列的 Category 被自动挪到了行，原本存在于行的 Sales 被挪到了 “标记” 区域。在正式介绍 “标记” 区域前，先理解一下为何会发生这种转变：
 
-**表格类组件是双维度组件，折线图是单维度组件。**也就是表格的行与列都是维度，而折线图横轴作为维度后，纵轴就要作为度量。上面的例子中，折线图维度有两个字段，虽然通过分面方式渲染出来了，但当切换为支持双维度的表格后， **可以将多余的一个维度挪到表格组件另一个维度区域中**。
+**表格类组件是双维度组件，折线图是单维度组件。** 也就是表格的行与列都是维度，而折线图横轴作为维度后，纵轴就要作为度量。上面的例子中，折线图维度有两个字段，虽然通过分面方式渲染出来了，但当切换为支持双维度的表格后， **可以将多余的一个维度挪到表格组件另一个维度区域中**。
 
 而表格行与列都是维度的情况下，单元格的值就需要用 “标记” 中文本来表示，因此原折线图的度量字段自动转移到了 “标记” 区域。
 
@@ -313,7 +313,7 @@ Tableau 内置的图表分为 N 大类 - **表格、地图、柱折面饼、散
 
 <img width=529 src="https://cdn.nlark.com/yuque/0/2019/png/201572/1566699040802-40a23a43-7a23-43d1-9d06-27a6413803e8.png#align=left&display=inline&height=314&name=image.png&originHeight=856&originWidth=1440&size=106220&status=done&width=529">
 
-**上图也可以理解为展示出 Order Date 与 Order ID 的明细数据，按照 Order Date 分组且列合并。**下钻就是一步步接近明细数据的过程，但目的不是为了看明细表，而是看某些维度下按其他维度拆分的详细信息。
+**上图也可以理解为展示出 Order Date 与 Order ID 的明细数据，按照 Order Date 分组且列合并。** 下钻就是一步步接近明细数据的过程，但目的不是为了看明细表，而是看某些维度下按其他维度拆分的详细信息。
 
 图表下钻和表格思路是一致的：
 
@@ -323,9 +323,9 @@ Tableau 内置的图表分为 N 大类 - **表格、地图、柱折面饼、散
 
 <img width=667 src="https://cdn.nlark.com/yuque/0/2019/png/201572/1566700041429-03bcb68a-dd00-4cab-a256-f37234bb2300.png#align=left&display=inline&height=423&name=image.png&originHeight=1350&originWidth=2128&size=155697&status=done&width=667">
 
-**可以认为，当行或列上最后一个字段为度量时，就会切换为图表展示，因为图表适合展示连续状态。**如果排除上图蓝色区域，剩下的区域就是个交叉表，交叉表只是行与列同时存在维度字段的场景，仅有行或列时就变成了普通表格；而图形的下钻和表格下钻机理相同，只是把 “单元格” 的文本换成了柱子或线。
+**可以认为，当行或列上最后一个字段为度量时，就会切换为图表展示，因为图表适合展示连续状态。** 如果排除上图蓝色区域，剩下的区域就是个交叉表，交叉表只是行与列同时存在维度字段的场景，仅有行或列时就变成了普通表格；而图形的下钻和表格下钻机理相同，只是把 “单元格” 的文本换成了柱子或线。
 
-**所以对任何图表的下钻，都是对轴的下钻，**相同的是单元格属性永远不会改变，表格的单元格是文本，图形单元格是图形，一个简单折线图可以理解为对整体行与列单元格进行 “连续打通”：
+**所以对任何图表的下钻，都是对轴的下钻，** 相同的是单元格属性永远不会改变，表格的单元格是文本，图形单元格是图形，一个简单折线图可以理解为对整体行与列单元格进行 “连续打通”：
 
 <img width=406 src="https://cdn.nlark.com/yuque/0/2019/png/201572/1566700448492-a7b96c99-b600-41b0-9159-e88412f4402b.png#align=left&display=inline&height=329&name=image.png&originHeight=1342&originWidth=1654&size=105794&status=done&width=406">
 

前沿技术/119.精读《前端深水区》.md

@@ -10,7 +10,7 @@
 ## 概述
 
 原文对于深水区的想法，讲的很清楚，还是建议读者去读一下原文。
-对比 2010 年，整个前端生态已经翻新了好几遍，直到近几年的 Node BFF、IDE Cloud，抑或是客户端 AI，还是 Serverless 的建设，，前端想要深度参与的话，单纯依靠原来的 HTML/CSS/JS 三件套技能也远远不够了。再抛开技术，整个互联网创业生态也重构了好几遍。无论是技术层面还是意识层面，如今的前端开发已经进入深水区。
+对比 2010 年，整个前端生态已经翻新了好几遍，直到近几年的 Node BFF、IDE Cloud，抑或是客户端 AI，还是 Serverless 的建设，前端想要深度参与的话，单纯依靠原来的 HTML/CSS/JS 三件套技能也远远不够了。再抛开技术，整个互联网创业生态也重构了好几遍。无论是技术层面还是意识层面，如今的前端开发已经进入深水区。
 
 - 深水区需要哪些技能
 ![image.png](https://img.alicdn.com/tfs/TB1oovQe8r0gK0jSZFnXXbRRXXa-1832-1032.png)

前沿技术/124.精读《用 css grid 重新思考布局》.md

@@ -0,0 +1,372 @@
+## 1 引言
+
+Flex 与 Grid 相比就像功能键盘和触摸屏。触摸屏的控制力相比功能键盘来说就像是降维打击，因为功能键盘只能上下左右控制（x、y 轴），而触摸屏打破了布局障碍，直接从（z 轴）触达，这样 **无论 UI 内部布局再复杂，都可以通过 touch 直接定位。**
+
+Flex 是一维布局方式，我们需要不断嵌套 Div 才能形成复杂结构，而一旦布局产生了变化，原有嵌套结构如果不能 “兼容变化” 到新结构，代码就需要重构。而 Grid 就像触摸屏一样，可以二维布局，即便布局方式做了翻天覆地的调整，也仅需少量修改就能适配。
+
+这就是这次精读 [用 css grid 重新思考布局](https://www.freecodecamp.org/news/css-grid-changes-how-we-can-think-about-structuring-our-content/) 的原因，理解这个革命性布局技术给布局，甚至代码逻辑组织带来的变化。
+
+## 2 概述
+
+作者首先抛出了 Flex 的问题，其实是 `block` `float` `flex` 这三种布局模式的通病：
+
+- 布局结构由 Div 层级结构描述，导致 Div 层级复杂且遇到结构变更时难以维护。
+- 定制能力弱。Flex 布局有一些不受控制的智能设定，比如宽度 50% 的子元素会被同级元素挤到 50% 以下，这种智能化在某些场景是需要的，但由于没有提供像 Grid 的 `minmax` 之类的 API，所以定制型不足。
+
+![](https://img.alicdn.com/tfs/TB1X8Wvi4D1gK0jSZFyXXciOVXa-608-324.png)
+
+举个例子，上图的结构用 Flex 描述可能是这样的：
+
+```html
+<div class="card">
+  <div class="profile-sidebar">
+    <img src="https://i.pravatar.cc/125?image=3" alt="" class="profile-img" />
+    <ul class="social-list">
+      <li>
+        <a href="#" class="social-link"
+          ><i class="fab fa-dribbble-square"></i
+        ></a>
+      </li>
+      <li>
+        <a href="#" class="social-link"
+          ><i class="fab fa-facebook-square"></i
+        ></a>
+      </li>
+      <li>
+        <a href="#" class="social-link"
+          ><i class="fab fa-twitter-square"></i
+        ></a>
+      </li>
+    </ul>
+  </div>
+  <div class="profile-body">
+    <h2 class="profile-name">Ramsey Harper</h2>
+    <p class="profile-position">Graphic Designer</p>
+    <p class="profile-info">
+      Lorem ipsum dolor sit amet consectetur adipisicing elit. Facere a tempore,
+      dignissimos odit accusantium repellat quidem, sit molestias dolorum
+      placeat quas debitis ipsum esse rerum?
+    </p>
+  </div>
+</div>
+```
+
+利用 HTML 嵌套结构，我们将图形纵向分成两大块，然后在每块内部继续嵌套划分布局，这是最经典的布局行为了。
+
+![](https://img.alicdn.com/tfs/TB17_Oqi2b2gK0jSZK9XXaEgFXa-608-324.jpg)
+
+样式文件里，我们需要对每层布局进行描述，同时支持多分辨率弹性布局，包括顶层 `card` 容器在内的一些样式需要做一定调整：
+
+```scss
+.card {
+  width: 80%;
+  margin: 0 auto;
+  display: flex;
+  flex-direction: column;
+  max-width: 600px;
+  background: #005e9b;
+  flex-basis: 250px;
+  color: white;
+  padding: 2em;
+  text-align: center;
+}
+
+.profile-info {
+  font-weight: 300;
+  opacity: 0.7;
+}
+
+.profile-sidebar {
+  margin-right: 2em;
+  text-align: center;
+}
+
+.profile-name {
+  letter-spacing: 1px;
+  font-size: 2rem;
+  margin: 0.75em 0 0;
+  line-height: 1;
+}
+
+.profile-name::after {
+  content: "";
+  display: block;
+  width: 2em;
+  height: 1px;
+  background: #5bcbf0;
+  margin: 0.5em auto 0.65em;
+  opacity: 0.25;
+}
+
+.profile-position {
+  text-transform: uppercase;
+  font-size: 0.875rem;
+  letter-spacing: 3px;
+  margin: 0 0 2em;
+  line-height: 1;
+  color: #5bcbf0;
+}
+
+.profile-img {
+  max-width: 100%;
+  border-radius: 50%;
+  border: 2px solid white;
+}
+
+.social-list {
+  list-style: none;
+  justify-content: space-evenly;
+  display: flex;
+  min-width: 125px;
+  max-width: 175px;
+  margin: 0 auto;
+  padding: 0;
+}
+
+.social-link {
+  color: #5bcbf0;
+  opacity: 0.5;
+}
+
+.social-link:hover,
+.social-link:focus {
+  opacity: 1;
+}
+
+.bio {
+  padding: 2em;
+  display: flex;
+  flex-direction: column;
+  justify-content: center;
+}
+
+@media (min-width: 450px) {
+  .bio {
+    text-align: left;
+    max-width: 350px;
+  }
+}
+
+.bio-title {
+  color: #0090d1;
+  font-size: 1.25rem;
+  letter-spacing: 1px;
+  text-transform: uppercase;
+  line-height: 1;
+  margin: 0;
+}
+
+.bio-body {
+  color: #555;
+}
+
+.profile {
+  display: flex;
+  align-items: flex-start;
+}
+
+@media (min-width: 450px) {
+  .card {
+    flex-direction: row;
+    text-align: left;
+  }
+
+  .profile-name::after {
+    margin-left: 0;
+  }
+}
+```
+
+让我们看看 Grid 是怎么做的吧！Grid 有许多 API，我们重点看 `grid-template-areas` 这个属性，利用它，我们可以不关心模块的 HTML 结构，直接平铺方式描述：
+
+```html
+<div class="card">
+  <img src="https://i.pravatar.cc/125?image=3" alt="" class="profile-img" />
+  <ul class="social-list">
+    <li>
+      <a href="#" class="social-link"><i class="fab fa-dribbble-square"></i></a>
+    </li>
+    <li>
+      <a href="#" class="social-link"><i class="fab fa-facebook-square"></i></a>
+    </li>
+    <li>
+      <a href="#" class="social-link"><i class="fab fa-twitter-square"></i></a>
+    </li>
+  </ul>
+  <h2 class="profile-name">Ramsey Harper</h2>
+  <p class="profile-position">Graphic Designer</p>
+  <p class="profile-info">
+    Lorem ipsum dolor sit amet consectetur adipisicing elit. Facere a tempore,
+    dignissimos odit accusantium repellat quidem, sit molestias dolorum placeat
+    quas debitis ipsum esse rerum?
+  </p>
+</div>
+```
+
+可以看到，使用 Grid 可以将 UI 结构与 HTML 结构分离，HTML 结构仅描述包含关系，我们只需在样式文件中描述具体 UI 结构。
+
+样式文件只截取 Grid 相关部分：
+
+```scss
+.card {
+  width: 80%;
+  margin: 0 auto;
+  display: flex;
+  flex-direction: column;
+  max-width: 600px;
+  background: #005e9b;
+  flex-basis: 250px;
+  color: white;
+  padding: 2em;
+  text-align: left;
+
+  display: grid;
+  grid-template-columns: 1fr 3fr;
+  grid-column-gap: 2em;
+  grid-template-areas:
+    "image name"
+    "image position"
+    "social description";
+}
+
+.profile-name {
+  grid-area: name;
+}
+.profile-position {
+  grid-area: position;
+}
+.profile-info {
+  grid-area: description;
+}
+.profile-img {
+  grid-area: image;
+}
+.social-list {
+  grid-area: social;
+}
+```
+
+可以看到，`grid-template-areas` 是进一步抽象的语法，将页面结构通过直观的文本描述，无论是理解还是修改都更为轻松。
+
+这种描述方式适配不同分辨率下也具有优势，只要重组 `grid-template-areas` 即可：
+
+```scss
+@media (min-width: 600px) {
+  .card {
+    text-align: left;
+    grid-template-columns: 1fr 3fr;
+    grid-template-areas:
+      "image name"
+      "image position"
+      "social description";
+  }
+}
+```
+
+归根结底，Grid 通过二维结构描述，将子元素布局控制收到了父级，使布局描述更加直观。
+
+最后作者也提到，Flex 依然有使用场景，即简单的一维结构，或者 `space-between` 等 Flex 独有语法的情况。因此推荐整体、复杂的二维布局采用 Grid，一维的简单布局采用 Flex。
+
+## 3 精读
+
+Grid 的布局思路给了我很多启发，HTML 结构与 UI 结构的分离有助于减少 DIV 的层级结构，使代码看上去更清晰。
+
+也许有人会疑惑，Grid 无非将 HTML 布局部分功能挪到了 CSS，整体复杂度应该不变。其实，从 `grid-template-areas` 这个 API 可以看到，Grid 不仅仅将布局功能抽到 CSS 中，更是将布局描述进行了一层抽象，使代码更易维护。
+
+### 抽象，再抽象
+
+为什么 Grid 可以对布局进行抽象？因为 Grid 将二维结构都掌握在手中，得到了更大的布局能力，才能进一步将结构化语法抽象为字符串的描述。
+
+抽象的好处是不言而喻的，你觉得一堆嵌套的 DIV 与下面的代码，哪个更易读呢？
+
+```scss
+.card {
+  grid-template-areas:
+    "image name"
+    "image position"
+    "social description";
+}
+```
+
+这就是抽象的好处，一般来说，代码抽象程度越高就越易读，越易维护。
+
+再看一个 Chrome Grid 插件，将 Grid 可视化显示出来，并可以以 UI 方式进行调整：
+
+![](https://img.alicdn.com/tfs/TB1cAmui2b2gK0jSZK9XXaEgFXa-640-400.jpg)
+
+UI 是对文本的再抽象，同时可以规避一些不可能存在的语法，比如：
+
+```scss
+.card {
+  grid-template-areas:
+    "image name"
+    "image position"
+    "social image";
+}
+```
+
+布局只能以凸多边形方式拓展，不可能分离，也不可能突然插入一个其他模块而变成凹多边形。因此 UI 可以将这个错误规避，并简化为横竖多条线的方式对 UI 进行划分，显然这种描述方式效率更高。
+
+不得不说，Grid 以及图形化插件的探索，是布局领域的一大进步，是不断抽象的尝试，要解决的问题只有一个：如何提供一种更直观的描述 UI 的方式。
+
+### 布局对模块化的影响
+
+Grid 将布局方式提高了一个维度，会直接影响到 JS 模块化方式。
+
+尤其是以 JSX 组织代码的情况下，一个模块等于 UI + JS，通过嵌套方式的布局会让我们更倾向于站在 UI 视角划分模块。
+
+![](https://img.alicdn.com/tfs/TB1WQCvi.Y1gK0jSZFMXXaWcVXa-1052-750.png)
+
+比如对于上图模块，如果用 Flex 方式布局，我们可能会首先创建模块 X 作为左侧容器，子元素是 A 和 B，创建模块 Y 作为右侧容器，子元素是 C 以及新容器 Z，Z 容器的子元素是 D 和 E。
+
+如果你的第一印象是这么组织代码，不得不承认模块化会受到布局方式的影响。虽然许多时候这样划分是正确的，但当这 5 个模块各自没有关联时，我们创建的容器 X、Y、Z 就失去了复用性，在新的组合场景我们又要重新组合一遍。
+
+但是在 Grid 语法中，我们不需要 X、Y、Z，只需要用 [css grid generator](https://cssgrid-generator.netlify.com/) 按照上图的方式拖拖拽拽即可自动生成如下布局代码：
+
+```scss
+.parent {
+  display: grid;
+  grid-template-columns: 3fr repeat(2, 1fr);
+  grid-template-rows: repeat(5, 1fr);
+  grid-column-gap: 0px;
+  grid-row-gap: 0px;
+}
+
+.div1 {
+  grid-area: 1 / 1 / 3 / 2;
+}
+.div2 {
+  grid-area: 3 / 1 / 6 / 2;
+}
+.div3 {
+  grid-area: 1 / 2 / 2 / 4;
+}
+.div4 {
+  grid-area: 2 / 2 / 6 / 3;
+}
+.div5 {
+  grid-area: 2 / 3 / 6 / 4;
+}
+```
+
+其实 `grid-template-columns` `grid-template-rows` 组合起来使用比 `grid-template-areas` 更强大，但是纯代码方式描述没有 `grid-template-areas` 直观，可是配合一些可视化系统就非常直观了：
+
+![](https://img.alicdn.com/tfs/TB1E.9AiYj1gK0jSZFuXXcrHpXa-2006-1470.png)
+
+将 A ～ E 这 5 个模块布局抽出来后，它们之间的关系就打平了，我们可以完全从逻辑视角审视如何做模块化了。
+
+## 4 总结
+
+CSS Grid 本质上是一种二维布局的语法，相比 [Block](https://www.w3schools.com/Css/css_inline-block.asp)、[Flex](https://www.w3schools.com/Css/css3_flexbox.asp) 等一维布局方案，多了一个维度可以同时从行与列角度定义布局，因此派生出 `grid-template-areas` 等语法，整体上更内聚更直观，抽象度也更高了。
+
+理解了这些也就理解了布局未来的发展方向，**让布局与 Dom 分离** 一直是前端的一个梦想，开发 UI 部分时，只需关心页面由哪些模块组成，去实现这些模块就行了，而不需要关心模块之间应该如何组合。在描述组合时，可以通过可视化或比较抽象的字符串描述布局的结构，并对应到写好的模块上，这样的代码维护性远高于用 DIV 描述结构的方案。
+
+> 讨论地址是：[精读《用 css grid 重新思考布局》 · Issue #211 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/211)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/125.精读《深度学习 - 函数式之美》.md

@@ -0,0 +1,136 @@
+## 1 引言
+
+函数式语言在深度学习领域应用很广泛，因为函数式与深度学习模型的契合度很高，[The Beauty of Functional Languages in Deep Learning — Clojure and Haskell](https://www.welcometothejungle.co/fr/articles/btc-deep-learning-clojure-haskell) 就很好的诠释了这个道理。
+
+通过这篇文章可以加深我们对深度学习与函数式编程的理解。
+
+## 2 概述与精读
+
+深度学习是机器学习中基于人工神经网络模型的一个分支，通过模拟多层神经元的自编码神经网络，将特征逐步抽象化，这需要多维度、大数据量的输入。[TensorFlow](https://www.tensorflow.org/) 和 [PyTorch](https://pytorch.org/) 是比较著名的 Python 深度学习框架，同样 [Keras](https://blog.rstudio.com/2017/09/05/keras-for-r/) 在 R 语言中也很著名。然而在生产环境中，基于 **性能和安全性** 的考虑，一般会使用函数式语言 [Clojure](https://www.clojure.org/) 或 [Haskell](https://www.haskell.org/)。
+
+在生产环境中，可能要并发出里几百万个参数，因此面临的挑战是：如何高效、安全的执行这些运算。
+
+**所以为什么函数式编程语言可以胜任深度学习的计算要求呢？** 深度学习的计算模型本质上是数学模型，而数学模型本质上和函数式编程思路是一致的：数据不可变且函数间可以任意组合。这意味着使用函数式编程语言可以更好的表达深度学习的计算过程，因此更容易理解与维护，同时函数式语言内置的 Immutable 数据结构也保障了并发的安全性。
+
+另外函数式语言的函数之间都是相互隔离的，即便在多线程环境下也不会发生竞争和死锁的情况，函数式编程语言会自动处理这些情况。
+
+比如说 [Clojure](https://www.clojure.org/)，**它甚至可在两个同时修改同一引用的程序并发运行时，自动重试其中之一，而不需要手动加锁**：
+
+```clojure
+(import ‘(java.util.concurrent Executors))
+(defn test-stm [nitems nthreads niters]
+ (let [refs (map ref (repeat nitems 0))
+   pool (Executors/newFixedThreadPool nthreads)
+   tasks (map (fn [t]
+               (fn []
+                (dotimes [n niters]
+                  (dosync
+                   (doseq [r refs]
+                    (alter r + 1 t))))))
+              (range nthreads))]
+   (doseq [future (.invokeAll pool tasks)]
+      (.get future))
+   (.shutdown pool)
+   (map deref refs)))
+(test-stm 10 10 10000) -> (550000 550000 550000 550000 550000 550000 550000 550000 550000 550000)
+```
+
+上面的代码创建了引用（refs），同时创建了多个线程自增这个引用对象，按理说每个线程都修改这个引用会导致竞争状态出现，但从结果来看是正常的，说明 Clojure 引擎在执行时会自动解决这个问题。实际上当两个线程出现竞争而失败时，Clojure 会自动重试其中之一。
+
+> [原文介绍](https://clojure.org/about/concurrent_programming)
+
+**Clojure 的另一个优势是并行效率高：**
+
+```clojure
+(defn calculate-pixels-2 []
+ (let [n (* *width* *height*)
+       work (partition (/ n 16) (range 0 n))
+       result (pmap (fn [x]
+                  (doall (map
+                   (fn [p]
+                     (let [row (rem p *width*) col (int (/ p *height*))]
+                       (get-color (process-pixel (/ row (double *width*)) (/ col (double *height*))))))
+                   x)))
+                  work)]
+   (doall (apply concat result))))
+```
+
+使用 `partition` 结合 `pmap` 可以使并发效率达到最大化，也就是 CPU 几乎都消耗在实际计算上，而不是并行的任务管理与上下文切换。Clojure 凭借 `partition` 对计算进行分区，采取分而治之并对分区计算结果进行合并的思路优化了并发性能。
+
+> [原文介绍](http://www.fatvat.co.uk/2009/05/jvisualvm-and-clojure.html)
+
+Clojure 另一个特性是函数链式调用：
+
+```clojure
+;; pipe arg to function
+(-> "x" f1) ; "x1"
+
+;; pipe. function chaining
+(-> "x" f1 f2) ; "x12"
+```
+
+其中 `(-> "x" f1 f2)` 等价于 `f2(f1("x"))`，这种描述不仅更简洁清晰，也更接近于实际数学模型。
+
+> [原文介绍](http://xahlee.info/clojure/clojure_function_chaining.html)
+
+最后，Clojure 还具备计算安全性，计算过程不会修改已有的数据，因此在神经网络的任何一层的原始值都会保留，每层计算都可以独立运行且函数永远幂等。
+
+[Haskell](https://www.haskell.org/) 也有独特的优势，**它具有类型推断、惰性求值等特性**，被认为更适合用于机器学习。
+
+类型推断即 Haskell 类型都是静态的，如果试图赋予错误的类型会报错。
+
+Haskell 的另一个优势是可以非常清晰的描述数学模型。
+
+想想一般数学模型是怎么描述函数的：
+
+```text
+fn =>
+ f1 = 1
+ f2 = 9
+ f3 = 16
+ n > 2, fn = 3fn-3 + 2fn-2 + fn-1
+```
+
+一般语言用 `if-else` 描述等价关系，但 Haskell 可以几乎原汁原味的还原函数定义过程：
+
+```haskell
+solve :: Int -> Interger
+solve 1 = 1
+solve 2 = 9
+solve 3 = 16
+solve n = 3 * solve (n - 3) + 2 * solve (n - 2) + solve (n - 1)
+```
+
+这使得阅读 Haskell 代码和阅读数学公式一样轻松。
+
+> [原文](https://blog.jle.im/entry/purely-functional-typed-models-1.html)
+
+Haskell 另一个优势是惰性求值，即计算会在真正用到时才进行，而不会在计算前提前消费掉，比如：
+
+```haskell
+let x = [1..]
+let y = [2,4 ..]
+head (tail tail( (zip x y)))
+```
+
+可以看到，`x` 与 `y` 分别是 `1,2,3,4,5,6...` 与 `2,4,6,8...` 的无限数组，而 `zip` 函数将其整合为一个新数组 `(1,2),(2,4),(3,6),(4,8)...` 这也是无限数组，如果将 `zip` 函数执行完那么程序就会永远执行下去。但 Haskell 却不会陷入死循环，而是直接输出第一位数字 `1`。这就是惰性计算的特性，无论数组有多长，只有真正用到某项时才对其进行计算，所以哪怕初始数据量或计算量很大，实际消耗的运算资源只取决于这次计算实际用到的部分。
+
+由于深度学习数据量巨大，惰性求值可以忽略海量数据输入，大大提升计算性能。
+
+## 3 总结
+
+本文介绍了为什么深度学习更适合使用函数式语言，以及介绍了 Clojure 与 Haskell 语言的共性：安全性、高性能，以及各自独有的特性，证明了为何这两种语言更适合用在深度学习中。
+
+在前端领域说到函数式或函数之美，大部分时候想到的是 Class Component 与 Function Component 的关系，这个理解是较为片面的。通过本文我们可以了解到，函数式的思想与数学表达式思想如出一辙，以写数学公式的思维方式写代码，就是一种较好的函数式编程思路。
+
+函数式应该只有表达式，没有语句，这是因为函数式是为了处理运算而诞生的，因此很适合用在深度学习领域。
+
+> 讨论地址是：[精读《深度学习 - 函数式之美》 · Issue #212 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/212)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/126.精读《Nuxtjs》.md

@@ -0,0 +1,309 @@
+## 1 引言
+
+[Nuxt](https://github.com/nuxt/nuxt.js) 是基于 Vue 的前端开发框架，这次我们通过 [Introduction toNuxtJS](https://www.youtube.com/watch?v=NS0io3Z75GI) 视频了解框架特色以及前端开发框架的基本要素。
+
+> nuxt 与 [next](https://github.com/zeit/next.js) 结构很像，可以结合在一起看
+
+视频介绍了 NuxtJs 的安装、目录结构、页面路由、导航模版、asyncData、meta、vueX。
+
+这是一个入门级视频，所以上面所列举的特征都是一个前端开发框架的最核心的基本要素。一个前端开发框架，安装、目录结构、页面路由、导航模版一定是最要下功夫认真设计的。
+
+asyncData 和 Vuex 都在解决数据问题，meta 则是通过约定语法控制网页 meta 属性，这部分值得与 React 体系做对比，在精读部分再展开。
+
+Nuxtjs 前端开发框架不仅提供了脚手架的基本功能，还对项目结构、代码做了约定，以减少代码量。从这点可以看出，脚手架永远围绕两个核心目标：**让每一行源码都在描述业务逻辑；让每个项目结构都相同且易读**。
+
+20 年前，几百行 HTML、Css、Js 代码就能完成一个完整的项目，只需要遵守 W3C 的基本规范就足够了，每一个项目代码都简单清晰，而且由于没有复杂的业务逻辑，导致代码结构也非常简单。但现在前端项目复杂度逐渐升高，一个大型项目源码数量可能达到几十万行、几百万行，这是 W3C 规范没有设想到的，因此出现了各种工程化与模块化方案解决这个复杂度问题，也引发了各个框架间约定的割裂，且设计合理程度各不相同。
+
+Nuxtjs 等框架要做的就是定义支持现代大型项目的前端研发标准，这个规范具有网络效应，即用的人越多，价值越大。
+
+接下来我们进入正题，看看 Nuxt 脚手架定义了怎样的开发规范。
+
+## 2 概述
+
+### 安装
+
+使用 `npx create-nuxt-app app-name` 创建新项目。这个命令与 `create-react-app` 一样，区别主要是模版以及配置不同。
+
+这个命令本质上是拉取一个模版到本地，并安装 `nuxt` 系列脚本作为项目依赖，并自动生成一系列 npmScripts：
+
+```json
+{
+  "scripts": {
+    "dev": "nuxt",
+    "build": "nuxt build",
+    "start": "nuxt start",
+    "generate": "nuxt generate",
+    "lint": "eslint --ext .js,.vue --ignore-path .gitignore .",
+    "test": "jest"
+  },
+  "dependencies": {
+    "nuxt": "^2.0.0"
+  }
+}
+```
+
+之后即可通过 `npm start` 等命令开发项目，对大部分项目来说，npmScripts 启动是最能达成共识的。
+
+这种安装方式另一个好处是，依赖都被安装在了本地，即开发环境 100% 内置在项目中。Nuxt 没有采用全局 cli 命令方式执行，第一是 npmScripts 更符合大家通用习惯，不需要记住不同脚手架繁琐的名称与不同约定的启动命令，第二是全局脚手架一旦进行不兼容升级，老项目就面临维护难题。
+
+### 目录结构
+
+```text
+├── .nuxt
+├── layouts
+├── pages
+├── store
+├── assets
+├── static
+├── middleware
+├── plugins
+├── nuxt.config.js
+```
+
+**pages**
+
+页面文件存放的目录，路径 + 文件名即路由名，关于更多约定路由的信息，在下一节页面路由详细说明。
+
+**layouts**
+
+模版文件存放的目录，文件名即模版名，页面可以通过定义模版在选择使用的模版。
+
+**store**
+
+全局数据流目录，在 vueX 章节介绍。
+
+**assets**、**static**
+
+分别存放不需被编译的资源文件与非 `.vue` 的静态文件，比如 scss 文件。
+
+由于 `.vue` 文件集成了 html、js、css，因此一般不会再额外定义样式文件在 static 文件夹中。
+
+当然，这是 Vue 生态的特别之处，在 React 生态中会存在大量 `.scss` 文件混杂在各个目录中，比较影响阅读。
+
+**middleware**、**plugins**
+
+中间件与插件，这两个目录是可选的，作为一种定制化拓展能力。
+
+**.nuxt**
+
+为实现约定路由等便捷功能，启动项目时需要自动生成一些文件作为真正项目入口，这些文件就存储在 `.nuxt` 目录下，gitingore 且无需手动修改。
+
+**nuxt.config.js**
+
+nuxt 使用 js 文件作为配置文件，比 json 配置文件拓展性更好一些，这个文件也是整个项目唯一的配置文件。
+
+基本上 **pages**、**layouts**、**store**、**assets**、以及唯一的配置文件基本成为现代前端开发框架的标配。
+
+### 页面路由
+
+nuxt 支持约定路由：
+
+```text
+├── pages
+│   ├── home.vue
+│   └── index.vue
+```
+
+上述目录结构描述了两个路由：`/` 与 `/home`。
+
+也支持参数路由，只要以下划线作为前缀命名文件，就定义了一个动态参数路由：
+
+```text
+├── pages
+│   ├── videos
+│   │   └── _id.vue
+```
+
+`/videos/*` 都会指向这个文件，且可以通过 `$route.params.id` 拿到这个 url 参数。
+
+另一个特性是嵌套路由：
+
+```text
+├── pages
+│   ├── videos
+│   │   └── index.vue
+│   └── videos.vue
+```
+
+`videos.vue` 与 `videos/index.vue` 都指向 `/videos` 这个路由，如果这两个文件同时存在，那么外层的 videos 就会作为外层拦截所有 `/videos` 文件夹下的路由，可以通过 `nuxt-child` 透出子元素：
+
+```html
+# pages/videos.vue
+<template>
+  <div>
+    videos
+    <nuxt-child />
+  </div>
+</template>
+```
+
+### 导航模版
+
+页面公共逻辑，比如导航条可以放在模版里，模版的目录在 `layouts` 文件夹下。
+
+默认 `layouts/default.vue` 对所有页面生效，但也可以创建例如 `layouts/videos.vue` 特殊导航文件，在 `pages/` 页面文件通过如下申明指定使用这个模版：
+
+```html
+<script>
+  export default {
+    layout: "videos"
+  };
+</script>
+```
+
+### asyncData
+
+`asyncData` 是 nuxt 支持的异步取数函数，可以替代 `data`。
+
+`data` 函数：
+
+```html
+<script>
+  export default {
+    data() {
+      return {};
+    }
+  };
+</script>
+```
+
+对于异步场景，可以用 `asyncData` 替代：
+
+```html
+<script>
+  export default {
+    async asyncData() {
+      return await fetch("/");
+    }
+  };
+</script>
+```
+
+### meta
+
+nuxt 允许在 `.vue` 页面文件自定义 head 标签信息：
+
+```html
+<script>
+  export default {
+    headr() {
+      return {
+        title: "",
+        meta: {
+          charset: "utf-8"
+        }
+      };
+    }
+  };
+</script>
+```
+
+这是开发框架提供的特性，不过在 React 体系下可以通过 `useTitle` 等自定义 Hooks 解决此问题，将框架功能降维到代码功能，会更容易理解些。
+
+### vueX
+
+nuxt 集成了 [vuex](https://github.com/vuejs/vuex)，在 `store/` 文件夹下创建数据模型：
+
+```js
+export const state = () => ({
+  videos: [],
+  currentVideo: {}
+})
+
+export const mutations = {
+  SET_VIDEOS (state, videos) {
+    state.videos = videos
+  }
+  SET_CURRENT_VIDEO (state, video) {
+    state.currentVideo = video
+  }
+}
+```
+
+接下来就能在 `pages` 文件夹下的页面组件使用了：
+
+```html
+<script>
+  import { mapState } from "vuex";
+
+  export default {
+    async fetch({ $axios, params, store }) {
+      const reponse = await $axios.get(`/videos/${params.id}`);
+      const video = response.data.data.arrtibutes;
+      store.commit("SET_CURRENT_VIDEO", video);
+    }
+  };
+</script>
+```
+
+将 `return` 替换为 `store.commit` 即可，更多语法可以参考 [vuex 文档](https://github.com/vuejs/vuex)。
+
+## 3 精读
+
+Nuxtjs 框架做了几件事情：
+
+1. 统一执行命令。
+2. 统一开发框架。
+3. 统一目录与代码规范。
+4. 内置公共 utils 函数。
+
+### 统一执行命令
+
+命令行是所有开发者每天都要用上十几次甚至几十次的场景，试想一下团队中项目分别有如下这么多不同的启动命令会怎么样？
+
+1. npm start.
+2. monkey dev.
+3. npm run ng.
+4. npm run bootstrap & banana start.
+5. ...
+
+我永远不知道下一个项目该如何启动，这大大降低了开发效率。更严重的是，有的项目可以通过 `npm run docs` 查看文档，有的项目不能；有的项目 `npm run build` 可以触发编译，有的项目却无需编译，等等，所谓的环境不一致或者说迁移成本，学习成本，都是由最开始负责搭建项目脚手架的同学对架构设计不一致导致的，**然而没有必须用 `monkey dev` 才能运行起来的项目，但项目却可能因为被设计为 `monkey dev` 启动而显得与其他项目格格不入，甚至难以统一维护。**
+
+Nuxtjs 等前端开发框架统一执行命令就是为了解决这个问题，统一开发者习惯需要很长的时间周期，但这个趋势不可挡。
+
+### 统一开发框架
+
+**虽然现在 React、Vue、Angular 框架各有利弊，但如果一个团队的项目同时使用了两个以上的框架，没有人会觉得这是一件好事。**
+
+诚然每个框架都有自己的特点，在不同维度都一些优势，但三大框架能并存，说明各自都没有绝对的杀手锏来消灭对方。
+
+对开源来说，多元化是活力的源动力，但对一家公司来说，多元化就是一场灾难，至今没有一个框架敢说自己的优势是 “与其他框架混合使用可以提升整体开发效率”。
+
+前端开发框架要解决的最重要问题也是这一点，无论如何只能选择一种开发框架，Nuxtjs 选择了 Vue，Nextjs 选择了 React。
+
+### 统一目录与代码规范
+
+目录和代码规范不会从根本上影响项目的通用性，因为不同的目录结构可以通过映射来兼容，不同的代码规范不会影响代码执行。所以目录与代码规范真正影响的是一个程序员对项目的 “解码成本”。
+
+所谓解码成本，就是程序员理解项目逻辑所需要的成本。如果你是一个销售主管，让团队周报统一用一种格式汇总绝对比 “用自己喜欢的方式汇总” 效率高，而对编程也一样，一个完全不同的目录结构和代码规范对程序员来说是巨大的阅读阻碍，甚至可能引发恶心反应。
+
+所以不同的目录结构和代码规范是没有必要的壁垒，除非你的团队已经对某种规范产生达成了牢固的共识，否则最好和其他团队共享相同的目录结构与代码规范。改变代码规范是一件很难得事情，但只要不同规范的团队间产生了长期合作关系，规范统一就势必会被提上议程，那么为何不能在公司层面早一点达成共识，提前消除这种痛苦呢？
+
+所以统一目录与代码规范是前端开发框架需要优先确定的，很多时候不要去质疑为什么目录叫 `layouts` 而不叫 `layout`，因为这个规范背后形成的协同网络规模越大，叫什么名字就越不重要。
+
+### 内置公共 utils 函数
+
+让业务开发更聚焦，还可以通过抽取通用的逻辑的方式解决，但需要解决两个问题：
+
+1. 虽然将公共函数抽成 npm 包可以解决代码复用问题，但关键是怎么保证你的代码能被别人复用？
+2. 如何让业务通用的 utils 代码有效沉淀并从项目中移除？
+
+脚手架内置公共 utils 函数就为了解决这个问题。上面几个小节解决了通用命令、框架、规范，但实际代码中，`router` `history` `fetch` `store` 等等概念也都是可以统一的，**没有一个项目必须用定制的 `fetch` 函数才能取数，但一开始就定制了 `fetch` 会导致耦合了不可预期的、没有必要的业务逻辑，成为理解与提效的阻碍。**
+
+所以统一这些能统一的包，是进一步提效的关键。也许有人会觉得断了自己造轮子的路，但就像我们如今都不会重写浏览器内核逻辑一样，稳定的逻辑不仅带来了全行业的提效，还催生了前端岗位带来大量的就业，同样的，统一底层通用函数，其实是断了无意义产出这条路，每个人都有追求更高价值事情的权利，不要把自己困在反复造 `fetch` 函数这个低水平的活里。
+
+## 4 总结
+
+如果一个项目没有使用类似 Nuxtjs 开发框架，它面临的不仅仅是技术选型不统一的问题，久而久之这种项目势必成为 **代码孤岛**，当尘封在代码仓库几年后，一系列文档工具链接都失效后，就成为谁也不想碰，不敢碰的高危代码。
+
+所以我们今天不仅要看到 Nuxtjs 提供的能力对项目开发有多么便捷，更要看到这类框架带来的协同效应有多么巨大，如果它不能成为整个前端的标准，至少要成为你们公司，或者你们团队的标准。
+
+> 讨论地址是：[精读《Nuxtjs》 · Issue #213 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/213)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/127.精读《React Conf 2019 - Day1》.md

@@ -0,0 +1,702 @@
+## 1 引言
+
+[React Conf 2019](https://www.youtube.com/watch?v=RCiccdQObpo) 在今年 10 月份举办，内容质量还是一如既往的高，如果想进一步学习前端或者 React，这个大会一定不能错过。
+
+希望前端精读成为你学习成长路上的布道者，所以本期精读就介绍 React Conf 2019 - Day1 的相关内容。
+
+总的来看，React Conf 今年的内容视野更广了，不仅仅有技术内容，还有宣扬公益、拓展到移动端、后端，最后还有对 web 发展的总结与展望。
+
+前端世界正变得越来越复杂，可以看到大家对未来都充满了希望，永不停歇的探索精神是这场大会的主旋律。
+
+## 2 概述 & 精读
+
+本期大会思想、设计上的内容较多，具体实现层内容较少，因为行业领导者需要引领规范，而真正技术价值在于思维模型与算法，理解了解题思路，实现它其实并不难。
+
+### 开发者体验与用户体验
+
+- 开发者体验：DX（develop experience）
+- 用户体验：UX（user experience）
+
+技术人解决的问题总是围绕 DX 与 UX，而一般来说，优化了 DX 往往会带来 UX 的提升，这是因为一个解决开发者体验的技术创新往往也会带来用户体验的升级，至少也能让开发者有更好的心情、更充足的时间做出好产品。
+
+如何优化开发者体验呢？
+
+**易上手**
+
+React 确实致力于解决这个问题，因为 React 实际上是一个开发者桥梁，无论你开发 web、ios 还是单片机，都可以通过一套统一的语法去实现。React 是一个协议标准（读到 reactReconciler 章节会更有体感），React 像 HTML，但 React 不止能构建 HTML 应用，React 希望构建一切。
+
+**高效开发**
+
+React 解决调试、工具问题，让开发者更高效的完成工作，这也是开发者体验重要组成部分。
+
+**弹性**
+
+React 编写的程序拥有良好可维护性，包括数据驱动、模块化等等特征都是为了更好服务于不同规模的团队。
+
+对于 UX 问题，React 也有 Concurrent mode、Suspense 等方案。
+
+虽然 React 还不完美，但 React 致力于解决 DX 与 UX 的目标和效果都是我们有目共睹的，更好的 DX、UX 一定是前端技术未来发展的大趋势。
+
+### 样式方案
+
+Facebook 使用 css-in-js，而今年的 React conf 给出了一种技术方案，将 413 kb 的样式文件体积降低到 74kb！
+
+一步步了解这个方案，从用法开始：
+
+```tsx
+const styles = stylex.create({
+  blue: { color: "blue" },
+  red: { color: "red" }
+});
+
+function MyComponent(props) {
+  return <span className={styles("blue", "red")}>I'm red now!</span>;
+}
+```
+
+如上是这个方案的写法，通过 `stylex.create` 创建样式，通过 `styles()` 使用样式。
+
+**主题方案**
+
+如果使用 CSS 变量定义主题，那么换肤就可以由最外层 `class` 轻松决定了：
+
+```scss
+.old-school-theme {
+  --link-text: blue;
+}
+
+.text-link {
+  color: var(--link-text);
+}
+```
+
+字体颜色具体的值由外层 `class` 决定，因此外层的 `class` 就可以控制所有子元素的样式：
+
+```html
+<div class="old-school-theme">
+  <a class="text-link" href="...">
+    I'm blue!
+  </a>
+</div>
+```
+
+将其封装成 React 组件，也不需要用 `context` 等 JS 能力，而是包裹一层 `class` 即可。
+
+```tsx
+function ThemeProvider({ children, theme }) {
+  return <div className={themes[theme]}>{children}</div>;
+}
+```
+
+**图标方案**
+
+下面是设计师给出的 svg 代码：
+
+```tsx
+<svg viewBox="0 0 100 100">
+  <path d="M9 25C8 25 8..." />
+</svg>
+```
+
+将其包装为 React 组件：
+
+```tsx
+function SettingsIcon(props) {
+  return (
+    <SVGIcon viewBox="0 0 100 100" {...props}>
+      <path d="M9 25C8 25 8..." />
+    </SVGIcon>
+  );
+}
+```
+
+结合上面提到的主题方案，就可以控制 svg 的主题颜色。
+
+```tsx
+const styles = stylex.create({
+  primary: { fill: "var(--primary-icon)" },
+  gighlight: { fill: "var(--highlight-icon)" }
+});
+
+function SVGIcon(color, ...props) {
+  return (
+    <svg>
+      {...props}
+      className={styles({
+        primary: color === "primary",
+        highlight: color === "highlight"
+      })}
+      {children}
+    </svg>
+  );
+}
+```
+
+**减少样式大小的秘密**
+
+```tsx
+const styles = stylex.create({
+  blue: { color: "blue" },
+  default: { color: "red", fontSize: 16 }
+});
+
+function MyComponent(props) {
+  return <span className={styles("default", props.isBlue && "blue")} />;
+}
+```
+
+对于上述样式文件代码，最终会编译成 `c1`、`c2`、`c3` 三个 `class`：
+
+```scss
+.c1 {
+  color: blue;
+}
+.c2 {
+  color: red;
+}
+.c3 {
+  font-size: 16px;
+}
+```
+
+出乎意料的是，并没有根据 `blue` 和 `default` 生成对应的 `class`，而是根据实际样式值生成 `class`，这样做有什么好处呢？
+
+首先是加载顺序，`class` 生效的顺序与加载顺序有关，而按照样式值生成的 `class` 可以精确控制样式加载顺序，使其与书写顺序对应：
+
+```tsx
+// 效果可能是 blue 而不是 red
+<div className="blue red" />
+
+// 效果一定是 red，因为 css-in-js 在最终编排 class 时，虽然两种样式都存在，但书写顺序导致最后一个优先级最高，
+// 合并的时候就会舍弃失效的那个 class
+<div className={styles('blue', 'red')} />
+```
+
+这么做永远不会出现头疼的样式覆盖问题。
+
+更重要的是，随着样式文件的增多，`class` 总量会减少。这是因为新增的 `class` 涵盖的属性可能已经被其他 `class` 写到并生成了，此时会直接复用对应属性生成的 `class` 而不会生成新的：
+
+```tsx
+<Component1 className=".class1"/>
+<Component2 className=".class2"/>
+```
+
+```scss
+.class1 {
+  background-color: mediumseagreen;
+  cursor: default;
+  margin-left: 0px;
+}
+.class2 {
+  background-color: thistle;
+  cursor: default;
+  justify-self: flex-start;
+  margin-left: 0px;
+}
+```
+
+正如这个 Demo 所示，正常情况的 `class1` 与 `class2` 存在许多重复定义的属性，但换成 css-in-js 的方案，编译后的效果等价于将 `class` 复用并拆解了：
+
+```tsx
+<Component1 classNames=".classA .classB .classD">
+
+<Component2 classNames=".classA .classC .classD .classE">
+```
+
+```scss
+.classA {
+  cursor: default;
+}
+.classB {
+  background-color: mediumseagreen;
+}
+.classC {
+  background-color: thistle;
+}
+.classD {
+  margin-left: 0px;
+}
+.classE {
+  justify-self: flex-start;
+}
+```
+
+这种方式不仅节省空间、还能自动计算样式优先级避免冲突，并将 413 kb 的样式文件体积降低到 74kb。
+
+### 字体大小方案
+
+`rem` 的好处是相对的字体大小，使用 `rem` 作为单位可以很方便实现网页字体大小的切换。
+
+但问题是现在工业设计都习惯了以 px 作为单位，所以一种全新的编译方案产生了：在编译阶段将 `px` 自动转换成 `rem`。
+
+这等于让以 `px` 为单位的字体大小可以跟随根节点字体大小随意缩放。
+
+### 代码检测
+
+静态检测类型错误、拼写错误、浏览器兼容问题。
+
+在线检测 dom 节点元素问题，比如是否有可访问性，比如替代文案 aria-label。
+
+### 提升加载速度
+
+普通网页的加载流程是这样的：
+
+![](https://img.alicdn.com/tfs/TB1gqmXlAY2gK0jSZFgXXc5OFXa-2102-1094.png)
+
+先加载代码，然后会渲染页面，在渲染的同时发取数请求，等取数完成后才能渲染出真实数据。
+
+那么如何改善这个情况呢？首先是预取数，提前解析出请求并在脚本加载的同时取数，可以节省大量时间：
+
+![](https://img.alicdn.com/tfs/TB1r8Sblrj1gK0jSZFuXXcrHpXa-1704-890.png)
+
+那么下载的代码可以再拆分吗？注意到并不是所有代码都作用于 UI 渲染，我们可以将模块分为 `ImportForDisplay` 与 `importForAfterDisplay` ：
+
+![](https://img.alicdn.com/tfs/TB1sGx.lxz1gK0jSZSgXXavwpXa-2662-1352.png)
+
+这样就可以优先加载与 UI 相关的代码，其余逻辑代码在页面展示出之后再加载：
+
+![](https://img.alicdn.com/tfs/TB1_9N.lCf2gK0jSZFPXXXsopXa-2762-1206.png)
+
+这样可以实现源码分段加载，并分段渲染：
+
+![](https://img.alicdn.com/tfs/TB1YJN.lED1gK0jSZFGXXbd3FXa-2620-1308.png)
+
+对取数来说也是如此，并不是所有取数都是初始化渲染阶段必须用上的。可以通过 `relay` 的特性 `@defer` 标记出可以延迟加载的数据：
+
+```relay
+fragment ProfileData on User {
+  classNameprofile_picture { ... }
+
+  ...AdditionalData @defer
+}
+```
+
+这下取数也可以分段了，首屏的数据会优先加载：
+
+![](https://img.alicdn.com/tfs/TB1SIydluH2gK0jSZJnXXaT1FXa-2638-1330.png)
+
+利用 `relay` 还可以以数据驱动方式结合代码拆分：
+
+```relay
+... on Post {
+  ... on PhotoPost {
+    @module('PhotoComponent.js')
+    photo_data
+  }
+
+  ... on VideoPost {
+    @module('VideoComponent.js')
+    video_data
+  }
+
+  ... on SongPost {
+    @module('SongComponent.js')
+    song_data
+  }
+}
+```
+
+这样首屏数据中也只会按需加载用到的部分，请求时间可以再次缩短：
+
+![](https://img.alicdn.com/tfs/TB1klKcly_1gK0jSZFqXXcpaXXa-2632-1426.png)
+
+可以看到，与 relay 结合可以进一步优化加载性能。
+
+### 加载体验
+
+可以 `React.Suspense` 与 `React.lazy` 动态加载组件。通过 `fallback` 指定元素的占位图可以提升加载体验：
+
+```tsx
+<React.Suspense fallback={<MyPlaceholder />}>
+  <Post>
+    <Header />
+    <Body />
+    <Reactions />
+    <Comments />
+  </Post>
+</React.Suspense>
+```
+
+`Suspense` 可以被嵌套，资源会按嵌套顺序加载，保证一个自然的视觉连贯性。
+
+### 智能文档
+
+通过解析 Markdown 自动生成文档大家已经很熟悉了，也有很多现成的工具可以用，但这次分享的文档系统有意思之处在于，可以动态修改源码并实时生效。
+
+![](https://img.alicdn.com/tfs/TB1p1jKluT2gK0jSZFvXXXnFXXa-1692-1430.png)
+
+不仅如此，还利用了 Typescript + MonacoEditor 在网页上做语法检测与 API 自动提示，这种文档体验上升了一个档次。
+
+虽然没有透露技术实现细节，但从热更新的操作来看像是把编译工作放在了浏览器 web worker 中，如果是这种实现方式，原理与 [CodeSandbox 实现原理](https://segmentfault.com/a/1190000019679430) 类似。
+
+### GraphQL and Stuff
+
+这一段在安利利用接口自动生成 Typescript 代码提升前后端联调效率的工具，比如 go2dts。
+
+我们团队也开源了基于 swagger 的 Typescript 接口自动生成工具 [pont](https://github.com/alibaba/pont)，欢迎使用。
+
+### React Reconciler
+
+这是知识密度最大的一节，介绍了如何使用 React Reconclier。
+
+React Reconclier 可以创建基于任何平台的 React 渲染器，也可以理解为通过 React Reconclier 可以创建自定义的 ReactDOM。
+
+比如下面的例子，我们尝试用自定义函数 `ReactDOMMini` 渲染 React 组件：
+
+```jsx
+import React from "react";
+import logo from "./logo.svg";
+import ReactDOMMini from "./react-dom-mini";
+import "./App.css";
+
+function App() {
+  const [showLogo, setShowLogo] = React.useState(true);
+
+  let [color, setColor] = React.useState("red");
+  React.useEffect(() => {
+    let colors = ["red", "green", "blue"];
+    let i = 0;
+    let interval = setInterval(() => {
+      i++;
+      setColor(colors[i % 3]);
+    }, 1000);
+
+    return () => clearInterval(interval);
+  });
+
+  return (
+    <div
+      className="App"
+      onClick={() => {
+        setShowLogo(show => !show);
+      }}
+    >
+      <header className="App-header">
+        {showLogo && <img src={logo} className="App-logo" alt="logo /" />}
+        // 自创语法
+        <p bgColor={color}>
+          Edit <code>src/App.js</code> and save to reload.
+        </p>
+        <a
+          className="App-link"
+          href="https://reactjs.org"
+          target="_blank"
+          rel="noopener noreferrer"
+        >
+          Learn React{" "}
+        </a>
+      </header>
+    </div>
+  );
+}
+
+ReactDOMMini.render(<App />, codument.getElementById("root"));
+```
+
+`ReactDOMMini` 是利用 `ReactReconciler` 生成的自定义组件渲染函数，下面是完整的代码：
+
+```typescript
+import ReactReconciler from "react-reconciler";
+
+const reconciler = ReactReconciler({
+  createInstance(
+    type,
+    props,
+    rootContainerInstance,
+    hostContext,
+    internalInstanceHandle
+  ) {
+    const el = document.createElement(type);
+
+    ["alt", "className", "href", "rel", "src", "target"].forEach(key => {
+      if (props[key]) {
+        el[key] = props[key];
+      }
+    });
+
+    // React 事件代理
+    if (props.onClick) {
+      el.addEventListener("click", props.onClick);
+    }
+
+    // 自创 api bgColor
+    if (props.bgColor) {
+      el.style.backgroundColor = props.bgColor;
+    }
+
+    return el;
+  },
+
+  createTextInstance(
+    text,
+    rootContainerInstance,
+    hostContext,
+    internalInstanceHandle
+  ) {
+    return document.createTextNode(text);
+  },
+
+  appendChildToContainer(container, child) {
+    container.appendChild(child);
+  },
+  appendChild(parent, child) {
+    parent.appendChild(child);
+  },
+  appendInitialChild(parent, child) {
+    parent.appendChild(child);
+  },
+
+  removeChildFromContainer(container, child) {
+    container.removeChild(child);
+  },
+  removeChild(parent, child) {
+    parent.removeChild(child);
+  },
+  insertInContainerBefore(container, child, before) {
+    container.insertBefore(child, before);
+  },
+  insertBefore(parent, child, before) {
+    parent.insertBefore(child, before);
+  },
+
+  prepareUpdate(
+    instance,
+    type,
+    oldProps,
+    newProps,
+    rootContainerInstance,
+    currentHostContext
+  ) {
+    let payload;
+    if (oldProps.bgColor !== newProps.bgColor) {
+      payload = { newBgCOlor: newProps.bgColor };
+    }
+    return payload;
+  },
+  commitUpdate(
+    instance,
+    updatePayload,
+    type,
+    oldProps,
+    newProps,
+    finishedWork
+  ) {
+    if (updatePayload.newBgColor) {
+      instance.style.backgroundColor = updatePayload.newBgColor;
+    }
+  }
+});
+
+const ReactDOMMini = {
+  render(wahtToRender, div) {
+    const container = reconciler.createContainer(div, false, false);
+    reconciler.updateContainer(whatToRender, container, null, null);
+  }
+};
+
+export default ReactDOMMini;
+```
+
+笔者拆解一下说明：
+
+React 之所以具备跨平台特性，是因为其渲染函数 `ReactReconciler` **只关心如何组织组件与组件间关系，而不关心具体实现**，所以会暴露出一系列回调函数。
+
+**创建实例**
+
+由于 React 组件本质是一个描述，即 `tag` + 属性，所以 `Reconciler` 不关心元素是如何创建的，需要通过 `createInstance` 拿到组件基本属性，在 Web 平台利用 DOM API 实现：
+
+```typescript
+createInstance(
+    type,
+    props,
+    rootContainerInstance,
+    hostContext,
+    internalInstanceHandle
+  ) {
+    const el = document.createElement(type);
+
+    ["alt", "className", "href", "rel", "src", "target"].forEach(key => {
+      if (props[key]) {
+        el[key] = props[key];
+      }
+    });
+
+    // React 事件代理
+    if (props.onClick) {
+      el.addEventListener("click", props.onClick);
+    }
+
+    // 自创 api bgColor
+    if (props.bgColor) {
+      el.style.backgroundColor = props.bgColor;
+    }
+
+    return el;
+  }
+```
+
+之所以说 React 对 DOM 事件都做了一层代理，是因为 JSX 的所有函数都没有真正透传给 DOM，而是通过类似 `el.addEventListener("click", props.onClick)` 的方式代理实现的。
+
+而自定义这个函数，我们甚至能创建例如 `bgColor` 这种特殊语法，只要解析引擎实现了这个语法的 Handler。
+
+除此之外，还有 **创建、删除实例** 的回调函数，我们都要利用 DOM 平台的 API 重新实现一遍，这样不仅可以实现对浏览器 API 的兼容，还可以对接到比如 react-native 等非 WEB 平台。
+
+**更新组件**
+
+实现了 `prepareUpdate` 与 `commitUpdate` 才能完成组件更新。
+
+`prepareUpdate` 返回的 `payload` 被 `commitUpdate` 函数接收到，并根据接收到的信息决定如何更新实例节点。这个实例节点就是 `createInstance` 回调函数返回的对象，所以如果在 WEB 环境返回的 instance 就是 DOMInstance，后续所有操作都使用 DOMAPI。
+
+总结一下：`react` 主要用平台无关的语法生成具有业务含义的 AST，而利用 `react-reconciler` 生成的渲染函数可以解析这个 AST，并提供了一系列回调函数实现完整的 UI 渲染功能，`react-dom` 现在也是基于 `react-reconciler` 写的。
+
+### 图标体积优化
+
+Facebook 团队通过优化，将图标大小从 4046.05KB 降低到了 132.95kb，体积减少了惊人的 96.7%，减少体积占总包体积的 19.6%！
+
+实现方式很简单，下面是原始图标使用的代码：
+
+```jsx
+<FontAwesomeIcon icon="coffee" />
+<Icon icon={["fab", "twitter"]} />
+<Button leftIcon="user" />
+<FeatureGroup.Item icon="info" />
+<FeatureGroup.Item icon={["fail", "info"]} />
+```
+
+在编译期间通过 AST 分析，将所有字符串引用换成了图标实例的引用，利用 webpack 的 tree-shaking 功能实现按需加载，从而删除了没有使用到的图标。
+
+```jsx
+import {faCoffee,faInfo,faUser} from "@fontawesome/free-solid-svg-icons"
+import {faTwitter} from '@fontawesome/free-brands-svg-icons'
+import {faInfo as faInfoFal} from '@fontawesome/pro-light-svg-icons'
+
+<FontAwesomeIcon icon={faCoffee} />
+<Icon icon={faTwitter} />
+<Button leftIcon={faUser} />
+<FeatureGroup.Item icon={faInfo} />
+<FeatureGroup.Item icon={faInfoFal} />
+```
+
+[替换工具](https://github.com/skovy/font-awesome-codemod) 的链接放出来了，感兴趣的同学可以点进去了解更多。
+
+这也从某种意义上说明了 iconFont 注定被淘汰，因为字体文件目前无法按需加载，只有全部使用 SVG 图标的项目才能使用这种优化。
+
+### Git & Github
+
+这一节介绍了基本 Git 知识以及 Github 用法，笔者略过比较水的部分，直接列出两个可能你不知道的点：
+
+**干预 Github 项目主要语言检测**
+
+如果你提交的代码包含许多自动生成的文件，可能你实际使用的语言不会被 Github 解析为主要语言，这时候可以通过 `.gitattributes` 文件忽略指定文件夹的检测：
+
+```text
+static/* linguist-vendored
+```
+
+这样语言文件占比统计就会忽略 `static/` 文件夹。
+
+**Git hooks 的技巧**
+
+以下是几个比较具有启发的点，我们可以利用 Git hooks 做点什么：
+
+- 阻止提交到 master。
+- 在 commit 之前执行 prettier/eslint/jest 检测。
+- 检测代码规范、合并冲突、检测是否有大文件。
+- commit 成功后给出提示或记录到日志。
+
+但 Git hooks 仍然有局限性：
+
+- 容易被绕过：--no-verifuy --no-merge --no-checkout ---force。
+- 本地 hooks 无法提交，导致项目开发规则可能不尽相同。
+- 无法替代 CI、服务端分支保护、Code Review。
+
+可以畅想一下，在 WebIDE 环境可以通过自定义 git 命令禁止检测绕过，自然解决第二条环境不一致的问题。
+
+### GraphQL + Typescript
+
+GraphQL 是没有类型支持的，如果要手动创建一遍类型文件是非常痛苦的：
+
+```typescript
+interface GetArticleData {
+  getArticle: {
+    id: number;
+    title: string;
+  };
+}
+
+const query = graphql(gql`
+  query getArticle {
+    article {
+      id
+      title
+    }
+  }
+`);
+
+apolloClient.query<GetArticleData>(query);
+```
+
+同样的代码分散在两处维护一定会带来问题，我们可以利用比如 `typed-graphqlify` 这种库解决类型问题：
+
+```typescript
+import { params, types, query } from "typed-graphqlify";
+
+const getArticleQuery = {
+  article: params({
+    id: types.number,
+    title: types.string
+  })
+};
+
+const gqlString = query("getUser", getUserQuery);
+```
+
+只要一遍定义就可以自动生成 GQLString，并且拿到 Typescript 类型。
+
+### React 文档国际化
+
+即便是谷歌翻译也不是很靠谱，国际化文档还是要靠人肉，[Nat Alison](https://github.com/tesseralis) 利用 Github 充分发动各国人民的力量，共同打造了一个个 reactjs group 下的国际化仓库。
+
+国际化仓库命名规则是 `reactjs/xx.reactjs.org`，比如简体中文的国际化仓库是：https://github.com/reactjs/zh-hans.reactjs.org
+
+从仓库的 readme 可以看到维护规则是这样的：
+
+- 请 fork 这个仓库。
+- 基于 fork 后的仓库中 master 分支拉取一个新的分支（名字自取）。
+- 翻译(校对)你所选择的文章，提交到新的分支。
+- 此时提交 Pull Request 到该仓库。
+- 会有专人 Review 该 Pull Request，当两人以上通过该 Pull Request 时，你的翻译将被合并到仓库中。
+- 删除你所创建的分支（如继续参与，参考同步流程）。
+
+之后定期从 React 官方文档项目拉取最新代码即可保持文档的同步更新。
+
+### 你需要 redux 吗？
+
+关于数据流的话题目前没有什么新意，但这次 React Conf 关于数据流总结的算是比较真诚的，总结了以下几个点：
+
+1. 全局数据流现在不是必须的，比如 Redux，但也不能说完全不能用，至少在全局状态较为复杂时有必要使用。
+2. 不要只使用一种数据流方案，根据状态的作用域确定方案比较好。
+3. 工程技术与科学不同，工程世界没有最好的方案，只有更好的方案。
+4. 就算有了完美方案也不要停止学习的步伐，总会有新知识产生。
+
+### web 历史
+
+很精彩的演讲，不过新鲜内容并不多，比较有感触一点是：以前的网页地址对应到的是服务器磁盘的某个具体文件，比如早期 php 应用，现在后端不再是文件化而是服务化了，这层抽象让服务端摆脱了对文件结构的依赖，可以构建更多复杂动态逻辑，也支持了前后端分离的技术方案。
+
+## 3 总结
+
+这届 React Conf 让我们看到前端更多的可能性，我们不仅要关注技术实现细节，更要关注行业标准以及团队愿景。
+
+React 团队的愿景是让 React 包罗万象，提升全球开发者的开发体验、提升全球产品的用户体验，基于这个目标，React Conf 自然不能只包含 DOM Diff、Reconciler 等等技术细节，更需要展示 React 如何帮助全球开发者，如何让这些开发者帮助到用户，如何推动行业标准的演进，如何让 React 打破国界、语言的壁垒。
+
+相比其他前端大会非常多的干货来说，React Conf 虽然显得主题比较杂，但这正是人文情怀的体现，我相信只有带着更高的使命愿景，真诚帮助他人的技术团队才可以走得更远。
+
+> 讨论地址是：[精读《React Conf 2019 - Day1》 · Issue #214 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/214)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/129.精读《React Conf 2019 - Day2》.md

@@ -0,0 +1,630 @@
+## 1 引言
+
+这是继 [精读《React Conf 2019 - Day1》](https://github.com/dt-fe/weekly/blob/v2/127.%E7%B2%BE%E8%AF%BB%E3%80%8AReact%20Conf%202019%20-%20Day1%E3%80%8B.md) 之后的第二篇，补充了 React Conf 2019 第二天的内容。
+
+## 2 概述 & 精读
+
+第二天的内容更为精彩，笔者会重点介绍比较干货的部分。
+
+### Fast refresh
+
+[Fast refresh](https://facebook.github.io/react-native/docs/fast-refresh) 是更好的 react-hot-loader 替代方案，目前仅支持 react-native 平台，很快就会支持 react-dom 平台。
+
+相比不支持 Function component、无法错误恢复、更新经常失灵的 hot reloading 来说，fast refresh 还拥有以下几个优点：
+
+- 状态保持。
+- 支持 Function Component Hooks。
+- 更快的更新速度。
+
+Fast refresh 更新速度更快，是基于 Function Component 生成了 “签名”，从而最大成都避免销毁重渲染，尽可能保持对组件的 rerender 刷新。下面介绍签名机制的工作原理。
+
+Fast refresh 对每个 Function component 都生成了一份专属签名，用以描述这个组件核心状态，当这个核心状态改变时，就只能销毁重渲染了，但对于不触及核心的修改就能进行代价非常小的 rerender。
+
+这个签名包含了 hooks 和参数名：
+
+```js
+// signature: "useState{isLoggedIn}"
+
+function ExampleComponent() {
+  const [isLoggedIn, setIsLoggedIn] = useState(true);
+}
+```
+
+比如当参数名变更时，这个组件的逻辑已发生改动，此时只能销毁并重渲染了。因此实际上通过对签名的对比来判断是否要销毁并重刷新组件：
+
+```js
+// signature: "useState{isLoggedOut}"
+
+function ExampleComponent() {
+  const [isLoggedOut, setIsLoggedOut] = useState(true);
+}
+```
+
+同理，当 hooks 从 `useState` 改成了 `useReducer`，签名也会发生变化从而导致彻底的重渲染。
+
+但除此之外，**比如对样式的修改、Dom 结构的修改都不会触发签名的变化**，从而保证了 “对不触及逻辑的改动进行高效的轻量 renreder”。
+
+然而 Fast refresh 也有如下局限性：
+
+- 还不能友好支持 Class component。
+- 混合导出 React 和非 React 组件时无法精确的 hot reload。
+- 更高的内存要求。
+
+可以看到，Fast Refresh 随着功能推广与内置，现在已经覆盖了 Facebook 95% 以上 hot reload 场景了：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1bjm1mYr1gK0jSZR0XXbP8XXa-1598-1018.png">
+
+这部分内容不仅揭开了 hot reload 技术内幕，还对其功能进行了进一步优化，2019 年的 React 开发体系已经进入精细化阶段。
+
+### 重写 React devtools
+
+React devtools 的更新终于被正式介绍了，本来笔者以为新的 devtools 只是支持了 hooks，但听完分享后发现还有更多有用的改进，包括：
+
+- 更高的性能。
+- 更多特性支持。
+- 更好用户体验。
+
+**找到节点渲染链路**
+
+并不是每个 React 节点都参与渲染，新版 React devtools 可以展示出 rendered by：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1OSWomV67gK0jSZPfXXahhFXa-2354-668.png">
+
+**调试 Suspense**
+
+在 Day1 中讲到的 Suspense 特性可以在 React devtools 调试了：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1W790m4D1gK0jSZFsXXbldVXa-1816-660.png">
+
+通过点击时钟 icon，可以模拟 Suspense 处于 pendding 或 ready 状态。
+
+**增强调试能力**
+
+可以通过点击直接跳转到组件源码：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1IBK1m4n1gK0jSZKPXXXvUXXa-1806-772.png">
+
+最新版已增强至点击按钮后直接通过 Source 打开源码位置，**这样可以快速通过 UI 寻找到代码**。同时还可以看到，通过点击 debugger 按钮将当前组件信息打到控制台调试。
+
+除此之外还可以动态修改组件的 props 与 hook state，大大增强了调试能力。
+
+**profiler**
+
+分析工具也得到了增强，现在可以看到每个组件被渲染了几次以及重新渲染的原因：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1cla1m7P2gK0jSZPxXXacQpXa-1824-690.png">
+
+比如上图组件被渲染了 4 次，主要有两个原因：Hooks 改变与 Props 改变。
+
+除此之外，还优化了更多细节体验，比如高亮搜索、HOC 的展示优化、嵌套层级过多时不会占用过多的横向宽度等等。
+
+### react codemod
+
+codemod 是一个代码重构的方式，通过 AST 方式精准触达代码，我们可以认为 codemod 是一个更聪明的“查找/替换”。
+
+codemod 主要有以下三种使用方式：
+
+- 重命名。
+- 代码排序。
+- 一定程度的代码替换。
+
+接下来就讲到 [react codemod](https://github.com/reactjs/react-codemod) 了，它是 react 场景的 codemod 解决方案，facebook 是这么使用 react codemod 的：
+
+- 迁移 facebook 代码。
+- 涉及几万个组件。
+- 修复了 3500 个文件的 React.PropTypes。
+- 修复了 8500 个文件的生命周期 unsafe。
+- 修复了 20000 个文件的 createClass 转 JSX。
+
+使用方式：
+
+```bash
+npx react-codemod React-PropTypes-to-prop-types
+```
+
+可以看到，通过 cli 对文件进行一次性重构处理。除此之外，再列举几种使用场景：
+
+- create-element-to-jsx 将 `React.createElement` 转换为 JSX。
+- error-boundaries 将 `unstable_handleError` 改为 `componentDidCatch`。
+- findDOMNode 将 `React.createClass` 中 `this.getDOMNode()` 改为 `React.findDOMNode`。
+- sort-comp 将 Class Component 生命周期按照规范排序，[eslint-plugin-react](https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/sort-comp.md) 插件也有相同能力。
+
+理论上来讲，所有 codemode 做的事情都可以替换为 eslint 的 autofix 来完成，比如 sort-comp 就同时被 codemode 和 eslint 支持。
+
+### Suspense
+
+要理解 Suspense，就要理解 Suspense 与普通 loading 有什么区别。
+
+从代码角度来说，Suspense 可以类比为 `try/catch` 的体验。为了简化代码复杂度，我们可以用 `try/catch` 包裹代码，从而简化 try 区块代码复杂度，并将兜底代码放在 catch 区块：
+
+```js
+try {
+  // 只要考虑正确情况
+} catch {
+  // 错误时 fallback
+}
+```
+
+Suspense 也一样，它在渲染 React 组件时如果遇到了 Promise 抛出的 Error，就会进入 `fallback`，所以 `fallback` 含义是 Loading 中状态：
+
+```jsx
+<Suspense fallback={<Spinner />}>
+  <ProfilePage />
+</Suspense>
+```
+
+与此同时，实际业务组件中的取数也不需要担心取数是否正在进行中，只要直接处理拿到数据的情况就好了：
+
+```jsx
+function ProfileDetails() {
+  // 直接使用 user，不用担心失败。
+  const user = resource.user.read();
+  return <h1>{user.name}</h1>;
+}
+```
+
+进一步的，如果要处理组件渲染的异常，再使用 `ErrorBoundary` 包裹即可，此时的 `fallback` 含义是组件加载异常的错误状态：
+
+```jsx
+function Home(props) {
+  return (
+    <ErrorBoundary fallback={<ErrorMessage />}>
+      <Suspense fallback={<Placeholder />}>
+        <Composer />
+      </Suspense>
+    </ErrorBoundary>
+  );
+}
+```
+
+Suspense 模式的取数好处是 “fetch on render”，即渲染与取数同时进行，而普通模式的取数是 “fetch after render”，即渲染完成后再通过 `useEffect` 取数，此时取数时机已晚。
+
+**队列加载**
+
+假设 `Composer` 与 `NewsFeed` 组件内部都通过 `useQuery` 取数，那么并行取数时加载机制如下：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1AonZm7L0gK0jSZFtXXXQCXXa-1770-778.png">
+
+这可能有两个问题：组件内部加载顺序不统一与组件间加载顺序不统一。
+
+如果组件内部有图片，可能图片与组件渲染实际不一致，此时可以利用 Suspense 统一 hold 所有子组件的特性，将图片加载改为 Suspense 模式：
+
+```jsx
+<div>
+  <YourImage src={uri} alt={...} />
+  <MoreComposer />
+</div>
+```
+
+同一个 Suspense 可以等待所有子元素都 Ready 后才会一把渲染出 UI，因此可以看到网页被一次性刷新而不是分部刷新。
+
+第二个问题是组件间加载顺序不统一，可能导致先渲染了文章内容，再渲染出文章头部，此时如果区块高度不固定，文章头部可能会撑开，导致文章内容下移，用户的阅读体验会遭到打断。可以通过 `suspense ordering` 解决这个问题：
+
+```jsx
+function Home(props) {
+  return (
+    <SuspenseList revealOrder="forwards">
+      <Suspense fallback={<ComposerFallback />}>
+        <Composer />
+      </Suspense>
+      <Suspense fallback={<FeedFallback />}>
+        <NewsFeed />
+      </Suspense>
+    </SuspenseList>
+  );
+}
+```
+
+比如 `forwards` 表示从上到下，那么一定会先渲染头部再渲染文章内容，这样文章内容就不会都抖动了。
+
+### Render as you fetch
+
+相比 “fetch on render”，更高级别的优化是 “Render as you fetch”，即取数在渲染时机之前。
+
+比如页面路由的跳转、Hover 到一个区块，此时如果取数由这个动作触发，就可以再次将取数时机提前，Facebook 为此创造了一个新的 Hook：`usePreloadedQuery`。
+
+用法是，在某个事件中取数，比如点击页面跳转按钮时，通过 `preloadQuery` 预取数，得到的结果并不是取数结果，而是一个标识，在渲染组件中，把这个标识传给 `usePreloadedQuery` 可以拿到真实取数结果：
+
+```js
+// 组件 A 的 onClick
+const reference = preloadQuery(query, variables);
+// 组件 B 的 render
+const data = usePreloadedQuery(query, reference);
+```
+
+可以看到，取数真正触发的时机在渲染函数执行之前，所以在 `usePreloadedQuery` 调用时取数肯定已经在路上，甚至已经完成。相比之下，普通的 `useQuery` 函数存在下面几个问题：
+
+- 由于取数过程存在状态变化，可能导致组件在 “取数无意义” 状态下重新渲染多次。
+- 可能取数还未完成就触发重渲染。
+  - 没有取消的机制，没有清除结果的机制。
+- 没有办法唯一标识组件。
+
+preloadQuery 的好处就是将取数时机与 UI 分离，这样可以更细粒度的控制逻辑：
+
+- 调用 preloadQuery 时：
+  - 在组件销毁时取消取数。
+  - 有新取数触发时取消取数。
+  - 销毁一些轮询机制。
+- 渲染组件调用 usePreloadedQuery 时：
+  - 不会再触发取数，不会触发意外的 re-render。
+  - 不需要清空，因为取数不在这里发起。
+  - 不需要清理轮询。
+
+可见 preloadQuery 相比 useQuery 的确有了一些体验提升，然而这个优化比较追求极致，对大部分国内项目来说可能还走不到 facebook 这么极致的性能优化，所以投入产出比显得不是那么高，而且这个开发方式对开发者不是太友好，因为它让请求的时机割裂到两个模块中。
+
+但毕竟用户体验是大于开发者体验的，React 尽量通过提高开发者体验来间接提高用户体验，使双方都满意，但像 preloadQuery 就无法两者兼顾了，为了用户体验可以适当的降低一些开发者体验。
+
+### 如何维护代码
+
+这个分享讲述了如何提升代码维护效率，毕竟一个月后可能连自己写的代码都看不懂了。[hydrosquall](http://github.com/hydrosquall) 通过类比地图的方式解释了程序员是如何维护代码的。
+
+首先看我们是如何认路的。认路分为三个层次：
+
+- 随意走走。
+  - 通过一些地标判断方向。
+- 有方向的寻路。
+  - 通过跟随同伴或者了解更多本地信息找到目的地。
+- 地图。
+  - 通过 GPS 定位。
+  - 通过模拟地图方式指出路线。
+
+可以看到这三种方式是逐层递进的，那么类比到代码就有意思了：
+
+- 随意走走（滚动查看源代码 + ctrl/f 查找代码 + grep 搜索）。
+  - 入口（找到入口节点，查看数据结构）。
+  - 标记（查看代码注释、查看 README）。
+  - 发信号弹（断点、console.log 等调试行为）
+- 找到方向。
+  - git blame 查看 owner，或直接根据文档找到 codeowners。
+- 地图。
+  - 幸运的话你可以找到一份架构流程图。
+
+可以看到，地图有几种抽象层次，比如忽略了细节的纽约地铁线路图：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB14k7pmYr1gK0jSZR0XXbP8XXa-1014-702.png">
+
+或者是包含丰富地面信息的地铁线路图：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1Sbwpm.T1gK0jSZFrXXcNCXXa-692-750.png">
+
+抽象到什么层次取决于用户使用的场景，那么代码抽象也是如此。[hydrosquall](http://github.com/hydrosquall) 做了一个工具自动分析出代码调用关系：[js-callgraph](https://github.com/persper/js-callgraph)
+
+![](https://img.alicdn.com/tfs/TB1HsRRmubviK0jSZFNXXaApXXa-2042-592.png)
+
+这就像路牌一样，可以更高效的看出代码结构，也包括了数据流结构，由于篇幅限制，感兴趣的同学可以看 [原视频](https://youtu.be/JDDxR1a15Yo?t=6579) 了解更多。
+
+### 写作与写代码
+
+本章讲了写作（小说）与写代码的关联，总结出如下几个重点：
+
+- 写小说和写代码都是创造行为。
+- 写代码需要抽象思维，写小说也要有抽象思维构造人物和情节。
+- Show, don't tell，写作天然就是申明式的，和数据驱动很相似。
+
+更多可以去看 [原视频](https://youtu.be/JDDxR1a15Yo?t=9135)。
+
+### 移动端动画最佳实践
+
+首先要使用一个真实的手机设备调试，否则可能出现 PC Chrome 一切正常，而手机上实际效果性能很差的情况！
+
+**手势下拉退出**
+
+利用 [react-spring](https://github.com/react-spring/react-spring) 和 [react-use-gesture](react-use-gesture) 做一个下滑消失的 Demo：
+
+```jsx
+import { animated, useSpring } from "react-spring";
+import { useDrag } from "react-use-gesture";
+
+const [{ y }, set] = useSpring(() => {
+  y: 0;
+});
+```
+
+首先定义一个 `y` 纵向位置，通过 `useDrag` 将拖拽操作与 UI 绑定，通过回调将其与 `y` 数据绑定：
+
+```js
+const bind = useDrag(({ last, movement: [, movementY], memo = y.value }) => {
+  if (last) {
+    // 拖拽结束时，如果偏移量超过 50 则效果和结束一样，直接将 y 设置为 100
+    const notificationClosed = movementY > 50;
+
+    return set({
+      y: notificationClosed ? 100 : 0,
+      onReset: notificationClosed && removeNotification
+    });
+  }
+
+  // y 的位置区间在 0～100
+  set([{ y: clamp(0, 100, memo + movementY) }]);
+
+  return memo;
+});
+```
+
+将 `useDrag` 与 `y` 绑定后，就可以用在 UI 组件上了：
+
+```jsx
+<StyledNotification
+  as={animated.div}
+  onTouchStart={bind().onTouchStart}
+  style={{
+    opacity: y.interpolate([0, 100], [1, 0]),
+    transform: y.interpolate(y => `translateY(${y}px)`)
+  }}
+/>
+```
+
+将 `opacity` 与 `transform` 与位置 `y` 绑定就可以做出下拉消失的效果。
+
+**滑动的洞见**
+
+接着讲到了滑动的三个洞见：
+
+1. 要立刻响应，任何延迟都会造成用户额外精神负担。
+2. 滚动速度衰减可以提升用户体验:
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1HocDm1H2gK0jSZJnXXaT1FXa-1348-878.gif">
+
+接着我们需要预测用户的意图，比如在一个类似微信消息列表页左右滑动时：
+
+- 是否想取消手势交互？
+- 是否想展示出更多交互按钮？
+- 是否想删除所有内容？
+
+这需要更多设计思考。
+
+1. 橡皮筋滚动，即列表页可以一直向下拉，上面部分像橡皮筋一样可以被拉出空白页的效果。
+
+在设计手势动画时要考虑三个要点：
+
+- 使用移动增量作为手势动画的基准点。
+- 动画和手势应该随时可以被中断，通过 springs 即可实现。
+- 完成手势后的动画速度应该与手势速度相当，这样视觉体验更自然。
+
+最后提到了动画兼容性与性能，比如尽量只使用 `transform` 与 `opacity` 可以保证移动端的流畅度，不同移动设备的默认手势效果不同，最好通过 `touch-action` 禁用默认行为以达到更好的兼容性与效果。
+
+### 唱片与 React
+
+J.Dash 拥有十年软件开发经验，同时也卖过很多唱片，他介绍了唱片行业与软件开发的共同点。
+
+唱片行业需要音乐编排能力，这与编码能力类似，都存在良好的设计模式，并且需要团队合作，开发过程中会遇到一些痛苦的经历，但最终完成音乐和项目时都会获得满足的喜悦。
+
+### 函数式编程
+
+> Declaratives UIs are the future, and the future is Comonadic. - Phil Freeman
+
+申明式 UI 是未来，未来则是 Comonadic。
+
+所谓申明式 UI 可以用下面的公式表达：
+
+```js
+type render = (state: State) => View;
+```
+
+然后用一段公式介绍了 Comonadic：
+
+```js
+class Functor w => Comonad w where
+  extract   :: w a -> a
+  duplicate :: w a -> w (w a)
+  extend    :: (w a -> a) -> w a -> w b
+```
+
+用 JS 版本做一个解释：
+
+```js
+const Store = ({ state, render }) => ({
+  extend: f => Store({ state, render: state => f(Store({ state, render })) }),
+  extract: () => render(state)
+});
+```
+
+`extract` 调用后会进行申明式渲染 UI，即 `render(state)`。
+
+`extend` 表示拓展，接收一个拓展函数作为参数，返回一个新的 Store 对象。这个拓展函数可以拿到 `state`、`render` 并返回新的 `state` 作为 `extract` 时 `render` 的输入。使用例子是这样的：
+
+```jsx
+const App = Store({
+  state: { msg: "World" },
+  render: ({ msg }) => <p>Hello {msg}</p>
+});
+
+App.extend(({ state }) =>
+  state.msg === "World" ? { msg: "ReactConf" } : state
+).extract(); // <p> Hello ReactConf </p>
+```
+
+然而尴尬的是，笔者看了很久也没看懂 `Store` 函数，最后运行了一下发现这个 Demo 抛出了异常 😂。
+
+下面是笔者稍微修改后的例子，至少能跑起来：
+
+```js
+const Store = ({ state, render }) => ({
+  extend: f => Store({ state, render: state => render(f({ state, render })) }),
+  extract: () => render(state)
+});
+
+const app = Store({
+  state: { msg: "Hello World" },
+  render: ({ msg }) => console.log("render " + msg)
+});
+
+app
+  .extend(({ state }) => {
+    return { msg: state.msg + " extend1" };
+  })
+  .extend(({ state }) => {
+    return { msg: state.msg + " extend2" };
+  })
+  .extract(); // render Hello World extend2 extend1
+```
+
+然而作者的意思仍是未解之谜，希望对函数式了解的同学可以在评论区指点一下。
+
+### wick editor
+
+[wick editor](https://www.wickeditor.com/) 是一个开源的动画、游戏制作软件。
+
+wick editor 是一个动画制作工具，但拓展了一些 js 编程能力，因此可以很好的将动画与游戏结合在一起：
+
+<img width=300 src="https://img.alicdn.com/tfs/TB1hLJpnbr1gK0jSZR0XXbP8XXa-1766-1002.png">
+
+演讲介绍了 wick editor 的演化过程：
+
+从很简陋的 MVP 版本开始（1 周）
+
+<img width=300 src="https://img.alicdn.com/tfs/TB11sdsneL2gK0jSZFmXXc7iXXa-1192-764.png">
+
+到 Pre-Alpha（4 月）
+
+<img width=300 src="https://img.alicdn.com/tfs/TB1TMJnnXY7gK0jSZKzXXaikpXa-1306-858.png">
+
+Alpha（5 月）
+
+<img width=300 src="https://img.alicdn.com/tfs/TB1608pnoD1gK0jSZFGXXbd3FXa-1794-1186.png">
+
+Beta（1.5 年）
+
+<img width=300 src="https://img.alicdn.com/tfs/TB1CKJpnoD1gK0jSZFGXXbd3FXa-1274-854.png">
+
+重点是 1.0 版本采用 React 重写了！继 Beta 之后又经历了 1 年：
+
+<img width=300 src="https://img.alicdn.com/tfs/TB1ZZhrneH2gK0jSZFEXXcqMpXa-906-596.png">
+
+这个团队最棒的地方是，将游戏与教育结合，针对不同场景做了很多用户调研并根据反馈持续改进。
+
+### React Select
+
+[react-select](https://github.com/JedWatson/react-select) 的作者 [Jed Watson](https://github.com/JedWatson) 被请来啦。作为一个看上去很简单组件（select）的开发者，却拥有如此大的关注量（1.8w star），那作者有着怎样的心路历程呢？
+
+react-select 看似简单的名字背后其实有挺多的功能，比如作者列举了一些功能层面的内容：
+
+- autocomplete - 输入时搜索。
+- 单、多选。
+- focus 管理。
+- 下拉框层级与位置，比如可以放在根 DOM 节点，也可以作为当前节点的子元素。
+- 异步下拉框内容。
+- 键盘、触控。
+- Createble，即在搜索时如果没有内容可以动态创建。
+- 等等。
+
+<img width=300 src="https://img.alicdn.com/tfs/TB1RYS1mubviK0jSZFNXXaApXXa-1166-226.png">
+
+在设计层面：
+
+- 申明式。
+- 可以被定制。
+- 性能要求。
+- 等等。
+
+随着 Star 逐渐上涨，越来越多的需求被提出，核心库代码量越来越大，甚至许多需求之间都是相互冲突的，而且作者每天都会被上百个 Issue 与 PR 吵醒。做一个业务 Select 可能只要 5 分钟，但做一个开源 Select 却要 5 年，原因是一个简单的 Select 如何满足所有不同业务场景？这绝对是个巨大的挑战。
+
+比如用户即需要受控也要非受控的组件，如何满足好这个需求同时又让代码更可维护呢？
+
+假设我们拥有一个受控的组件 `SelectComponent`，那么它的主要 props 是 `value` 与 `onChange`，如果要拓展成一个既支持 `defaultValue`（非受控）又支持 `value`（受控）的组件，我们可以创建一个 `manageState` 组件对 `SelectComponent` 进行封装：
+
+```jsx
+const manageState = SelectComponent => ({
+  value: valueProps,
+  onChange: onChangeProp,
+  defaultValue,
+  ...props
+}) => {
+  const [valueState, setValue] = useState(defaultValue);
+
+  const value = valueProps !== undefined ? valueProps : valueState;
+
+  const onChange = (newValue, actionMeta) => {
+    if (typeof onChangeProp === "function") {
+      onChangeProp(newValue, actionMeta);
+    }
+    setValue(newValue);
+  };
+
+  return <SelectComponent {...props} value={value} onChange={onChange}>
+};
+```
+
+这样就可以组合为一个受控/非受控的综合 Select 组件：
+
+```js
+import BaseSelect from "./Select";
+import manageState from "./manageState";
+
+export default manageState(Select);
+```
+
+同理对异步的封装也可以放在 `makeAsync` 函数中：
+
+```jsx
+const makeAsync = SelectComponent => ({
+  getOptions,
+  defaultOptions,
+  ...props
+}) => {
+  const [options, setOptions] = useState(defaultOptions);
+  const [isLoading, setIsLoading] = useState(false);
+
+  const onInputChange = async newValue => {
+    setIsLoading(true);
+    const newOptions = await getOptions(newValue);
+    setIsLoading(false);
+    setOptions(newOptions);
+  };
+
+  return (
+    <SelectComponent
+      {...props}
+      options={options}
+      isLoading={isLoading}
+      onInputChange={onInputChange}
+    />
+  );
+};
+```
+
+可以看到，`SelectComponent` 是一个完全受控的数据驱动的 UI，无论是 `manageState` 还是 `makeAsync` 都是对数据处理的拓展，所以这三者之间才可以融洽的组合：
+
+```js
+import BaseSelect from "./Select";
+import manageState from "./manageState";
+import makeAsync from "./async";
+
+export default manageState(Select);
+
+export const AsyncSelect = manageState(makeAsync(Select));
+```
+
+后面还有一些风格化、开源协作的思考，这里就不展开了，对这部分感兴趣的同学可以查看原视频了解更多。
+
+### React + 政府财政透明项目
+
+usaspending.gov 这个网站使用 React 建设，可以查看美国政府支持财政的明细，通过流畅的体验让更多用户可以了解国家财政支出，进一步推动财政支出的透明化。由于并不涉及前端技术的介绍，主要是产品介绍，因此精读就不详细展开了。
+
+顺便说一句，智能分析数据就用 [QuickBI](https://www.alibabacloud.com/zh/product/quickbi)，QuickBI 是我们团队研发的一款智能 BI 服务平台，如果你将美国政府的财政支持作为数据集输入，你会分析得更透彻。
+
+### React + 星舰模拟器
+
+最后介绍的是使用 React 制作的星舰模拟器，看上去像一个游戏：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1HrxAneL2gK0jSZPhXXahvXXa-1946-1104.png">
+
+有星系图、船体、驾驶员信息、武器装备、燃料、通信等等内容。甚至可以模拟太空驾驶，进行任务，可以实时多人协同。对太空迷们的吸引力很大，感兴趣的同学建议直接观看 [视频](https://youtu.be/JDDxR1a15Yo?t=28638)。
+
+## 3 总结
+
+第二天的内容非常全面，涉及了 React API、开发者周边、codemod 工具、代码维护、写作/音乐与代码、动画、函数式编程、看似简单的 React 组件、使用 React 制作的各种脑洞大开的项目，等等。
+
+React Conf 要展示的是一个完整的 React 世界，第一天提到了 React 是一个桥梁，正因为这个桥梁，连接了各行各业不同的人群以及不同的项目，大家都有一个共同的语言：React。
+
+"We not only react code, but react the world"。
+
+> 讨论地址是：[精读《React Conf 2019 - Day2》 · Issue #217 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/217)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/13.精读《This 带来的困惑》.md

@@ -1,6 +1,6 @@
 # 1 引言
 
-<img src="assets/13/logo.jpeg" width="500" alt="logo" />
+<img src="https://img.alicdn.com/imgextra/i2/O1CN014VGV7a1x3ILYqK9OD_!!6000000006387-2-tps-1024-732.png" width="500" alt="logo" />
 
 javascript 的 this 是个头痛的话题，本期精读的文章更是引出了一个观点，避免使用 this。我们来看看是否有道理。
 
@@ -53,7 +53,7 @@ getName(person3) // Name: Sarah Doe
 getGreetingCallback(person3)('Jeff') // Hello Jeff, I'm Sarah Doe
 ```
 
-<img src="assets/13/1.png" width="500" alt="demo1" />
+<img src="https://img.alicdn.com/imgextra/i3/O1CN017Kw37u1oOyYHXGlqC_!!6000000005216-2-tps-1338-338.png" width="500" alt="demo1" />
 
 这样 person 实例是个纯对象，没有将方法挂载到原型链上，简单易懂。
 

前沿技术/132.精读《正交的 React 组件》.md

@@ -0,0 +1,262 @@
+## 1 引言
+
+搭配了合适的设计模式的代码，才可拥有良好的可维护性，[The Benefits of Orthogonal React Components](https://dmitripavlutin.com/orthogonal-react-components/) 这篇文章就重点介绍了正交性原理。
+
+所谓正交，即模块之间不会相互影响。想象一个音响的音量与换台按钮间如果不是正交关系，控制音量同时可能影响换台，这样的设备很难维护：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1dczIpQL0gK0jSZFtXXXQCXXa-1000-993.png">
+
+前端代码也一样，UI 与数据处理逻辑分离就是一种符合正交原则的设计，这样有利于长期代码质量维护。
+
+## 2 概述
+
+一个拥有良好正交性的 React App 会按照如下模块分离设计：
+
+1. UI 元素(展示型组件)。
+2. 取数逻辑(fetch library, REST or GraphQL)。
+3. 全局状态管理(redux)。
+4. 持久化（local storage, cookies）。
+
+文中通过两个例子说明。
+
+### 让组件与取数逻辑正交
+
+比如一个展示雇员列表组件 `<EmployeesPage>`:
+
+```jsx
+import React, { useState } from "react";
+import axios from "axios";
+import EmployeesList from "./EmployeesList";
+
+function EmployeesPage() {
+  const [isFetching, setFetching] = useState(false);
+  const [employees, setEmployees] = useState([]);
+
+  useEffect(function fetch() {
+    (async function() {
+      setFetching(true);
+      const response = await axios.get("/employees");
+      setEmployees(response.data);
+      setFetching(false);
+    })();
+  }, []);
+
+  if (isFetching) {
+    return <div>Fetching employees....</div>;
+  }
+  return <EmployeesList employees={employees} />;
+}
+```
+
+这样设计看上去没问题，但其实违背了正交原则，因为 `EmployeesPage` 既负责渲染 UI 又关心取数逻辑。正交的写法如下：
+
+```jsx
+import React, { Suspense } from "react";
+import EmployeesList from "./EmployeesList";
+
+function EmployeesPage({ resource }) {
+  return (
+    <Suspense fallback={<h1>Fetching employees....</h1>}>
+      <EmployeesFetch resource={resource} />
+    </Suspense>
+  );
+}
+
+function EmployeesFetch({ resource }) {
+  const employees = resource.employees.read();
+  return <EmployeesList employees={employees} />;
+}
+```
+
+**`Suspense` 将 loading 状态剥离到父级组件，因此子组件只需要关心如何用数据，不需关心如何取数据（以及 loading 态）。**
+
+### 让组件与滚动监听正交
+
+比如一个滚动到一定距离就出现 "jump to top" 的组件 `<ScrollToTop>`，可能会这么实现：
+
+```jsx
+import React, { useState, useEffect } from "react";
+
+const DISTANCE = 500;
+
+function ScrollToTop() {
+  const [crossed, setCrossed] = useState(false);
+
+  useEffect(function() {
+    const handler = () => setCrossed(window.scrollY > DISTANCE);
+    handler();
+    window.addEventListener("scroll", handler);
+    return () => window.removeEventListener("scroll", handler);
+  }, []);
+
+  function onClick() {
+    window.scrollTo({
+      top: 0,
+      behavior: "smooth"
+    });
+  }
+
+  if (!crossed) {
+    return null;
+  }
+  return <button onClick={onClick}>Jump to top</button>;
+}
+```
+
+可以看到，在这个组件中，按钮与滚动状态判断逻辑混合在了一起。如果我们将 “滚动到一定距离就渲染 UI” 抽象成通用组件 `IfScrollCrossed` 呢？
+
+```jsx
+import { useState, useEffect } from "react";
+
+function useScrollDistance(distance) {
+  const [crossed, setCrossed] = useState(false);
+
+  useEffect(
+    function() {
+      const handler = () => setCrossed(window.scrollY > distance);
+      handler();
+      window.addEventListener("scroll", handler);
+      return () => window.removeEventListener("scroll", handler);
+    },
+    [distance]
+  );
+
+  return crossed;
+}
+
+function IfScrollCrossed({ children, distance }) {
+  const isBottom = useScrollDistance(distance);
+  return isBottom ? children : null;
+}
+```
+
+有了 `IfScrollCrossed`，我们就能专注写 “点击按钮跳转到顶部” 这个 UI 组件了：
+
+```jsx
+function onClick() {
+  window.scrollTo({
+    top: 0,
+    behavior: "smooth"
+  });
+}
+
+function JumpToTop() {
+  return <button onClick={onClick}>Jump to top</button>;
+}
+```
+
+最后将他们拼装在一起：
+
+```jsx
+import React from "react";
+
+// ...
+
+const DISTANCE = 500;
+
+function MyComponent() {
+  // ...
+  return (
+    <IfScrollCrossed distance={DISTANCE}>
+      <JumpToTop />
+    </IfScrollCrossed>
+  );
+}
+```
+
+这么做，我们的 `<JumpToTop>` 与 `<IfScrollCrossed>` 组件就是正交关系，而且逻辑更清晰。不仅如此，这样的抽象使 `<IfScrollCrossed>` 可以被其他场景复用：
+
+```jsx
+import React from "react";
+
+// ...
+
+const DISTANCE_NEWSLETTER = 300;
+
+function OtherComponent() {
+  // ...
+  return (
+    <IfScrollCrossed distance={DISTANCE_NEWSLETTER}>
+      <SubscribeToNewsletterForm />
+    </IfScrollCrossed>
+  );
+}
+```
+
+### Main 组件
+
+上面例子中，`<MyComponent>` 就是一个 Main 组件，Main 组件封装一些脏逻辑，即它要负责不同模块的组装，而这些模块之间不需要知道彼此的存在。
+
+一个应用会存在多个 Main 组件，它们负责拼装各种作用域下的脏逻辑。
+
+### 正交设计的好处
+
+- **容易维护：** 正交组件逻辑相互隔离，不用担心连带影响，因此可以放心大胆的维护单个组件。
+- **易读：** 由于逻辑分离导致了抽象，因此每个模块做的事情都相对单一，很容易猜测一个组件做的事情。
+- **可测试：** 由于逻辑分离，可以采取逐个击破的思路进行单测。
+
+### 权衡
+
+如果不采用正交设计，因为模块之间的关联导致应用最终变得难以维护。但如果将正交设计应用到极致，可能会多处许多不必要的抽象，这些抽象的复用仅此一次，造成过度设计。
+
+## 3 精读
+
+正交设计一定程度可以理解为合理抽象，完全不抽象与过度抽象都是不可取的，因此列举了四块需要抽象的要点：UI 元素、取数逻辑、全局状态管理、持久化。
+
+全局状态管理注入到组件，就是一种正交的抽象模式，即组件不用关心数据从哪来，而直接使用数据，而数据管理完全交由数据流层管理。
+
+取数逻辑往往是可能被忽略的一环，无论是像原文中直接关心到 `fetch` 方法的 UI 组件，还是利用取数工具库关心了 `loading` 状态：
+
+```jsx
+import useSWR from "swr";
+
+function Profile() {
+  const { data, error } = useSWR("/api/user", fetcher);
+
+  if (error) return <div>failed to load</div>;
+  if (!data) return <div>loading...</div>;
+  return <div>hello {data.name}!</div>;
+}
+```
+
+虽然将取数生命周期封装到自定义 hook `useSWR` 中，但 `error` 信息对 UI 组件来说就是一个脏数据：**这让这个 UI 组件不仅要渲染数据，还要担心取数是否会失败，或者是否在 loading 中。**
+
+好在 Suspense 模式解决了这个问题：
+
+```jsx
+import { Suspense } from "react";
+import useSWR from "swr";
+
+function Profile() {
+  const { data } = useSWR("/api/user", fetcher, { suspense: true });
+  return <div>hello, {data.name}</div>;
+}
+
+function App() {
+  return (
+    <Suspense fallback={<div>loading...</div>}>
+      <Profile />
+    </Suspense>
+  );
+}
+```
+
+这样 `<Profile>` 只要专注于做数据渲染，而不用担心 `useSWR('/api/user', fetcher, { suspense: true })` 这个取数过程发生了什么、是否取数失败、是否在 `loading` 中。因为取数状态由 `Suspense` 管理，而取数是否意外失败由 `ErrorBoundary` 管理。
+
+合理的抽象使组件逻辑变得更简单，从而组件嵌套使用使不用担心额外影响。尤其在大型项目中，不要担心正交抽象会使本来就很多的模块数量再次膨胀，因为相比于维护 100 个相互影响，内部逻辑复杂的模块，维护 200 个职责清晰，相互隔离的模块也许会更轻松。
+
+## 4 总结
+
+从正交设计角度来看，`Hooks` 解决了状态管理与 UI 分离的问题，`Suspense` 解决了取数状态与 UI 分离的问题，`ErrorBoundary` 解决了异常与 UI 分离的问题。
+
+在你看来，React 还有哪些逻辑需要与 UI 分离？分别使用哪些方法呢？欢迎留言。
+
+> 讨论地址是：[精读《正交的 React 组件》 · Issue #221 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/221)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/133.精读《寻找框架设计的平衡点》.md

@@ -0,0 +1,207 @@
+## 1 引言
+
+[尤雨溪](https://github.com/yyx990803) 在 2019 JSConf 的分享 [Seeking the Balance in Framework Design](https://www.youtube.com/watch?v=ANtSWq-zI0s) 十分精彩，道出了如何进行合理的前端框架设计与框架选型。
+
+正如所说，框架对比不能只停留在 Star 数量、Npm 下载量、Stackoverflow 问题量这些简单的数据对比，而要深入到技术细节进行比较。比较框架有多种不同维度，这次分享就从服务范围、渲染机制、状态机制这三个维度进行对比。
+
+## 2 概述
+
+这次分享的精彩之处在于不偏不倚的站在客观立场分析了框架各维度好的一面与坏的一面，从中我们不仅能学习到一些框架知识，还能培养思辨能力。
+
+### 服务范围
+
+服务范围是个比较难翻译的单词，在原 PPT 中用了 “Scope” 这个单词表示，可以理解为 “作用域、框架的承诺功能范围、服务配套齐全程度”。比如提供的是一个工具库还是整体框架，插件管理是集中式还是依赖生态。
+
+React 是典型的小服务范围框架，核心包只实现了基本功能，而其他生态基本靠社区拓展；Angular 是典型大服务范围框架，官方对所有业务场景都做了最佳实践能力覆盖；Vue 处在中间区域，通过功能分层，既拥有小服务范围的能力，又可以搭配官方插件实现更多场景化能力。
+
+#### 小服务范围优势
+
+**概念少，易上手**
+
+小的服务范围代表了小的学习成本，因为暴露的基本能力较少，概念也会比较少，对新人上手比较友好。
+
+**生态繁荣，百花齐放**
+
+由于很多功能没有被官方实现，社区就有机会填补这些空白，因此会冒出许多第三方库，而且一旦做得好，就有机会成为 “事实标准”，因此开发者会更加积极参与到社区开发，自己做的框架 “上升空间” 也非常大。
+
+同时，社区的力量会导致多元化，因此整体生态完整度与创新性都会非常亮眼，而且具有持续迭代的能力。
+
+**核心维护成本低**
+
+官方维护的核心代码较少，因此维护成本大大降低，而且官方可以将精力放在更多核心能力增强上，比如 Suspense 等，而不是将精力消耗在生态插件上。
+
+#### 小服务范围的劣势
+
+**复杂场景要引入新概念**
+
+复杂场景无法支持时，就要引入新的概念解决，这导致后续技术选型可能产生分歧，并带来持续的新概念理解成本。
+
+**非官方的开发模式逐渐产生**
+
+随着时间的流逝，会逐渐涌出一些新的设计模式，成为当下几乎是必不可少的方案，但却不会出现在官方文档中，造成选型时的疑惑。Redux 就是一个例子。
+
+**生态变化快，碎片化且持续流失**
+
+非官方的生态也意味着不稳定，而且缺乏统一的管理，碎片化的模块之间可能经常出现不兼容的问题。
+
+而且任何模块都可能被时代无情的淘汰，就像 Flux 到 Redux 再到 Hooks，带来额外的迁移成本和认知成本。谁也不希望自己的项目架构 “变得过时”，或者随时面临被新架构取代的风险，但第三方社区几乎一定代表未来会出现一种模式取代现有模式，只是时间早晚而已。
+
+#### 大服务范围的优势
+
+**大部分业务场景都被内置解决**
+
+减少不必要的技术方案调研与纷争，大服务范围的框架内置的方案就能解决几乎 100% 业务问题，团队再也不会为通用架构问题烦恼了。
+
+**生态稳定、连贯**
+
+稳定是指，官方维护作为背书，几乎不会存在一些生态包突然不维护、与已有版本不兼容、被植入恶意程序等等意外情况。
+
+连贯是指，官方会统一考虑一个改动在所有生态插件造成的影响，并以一个最合理的思路做整体改造，生态包无论是接口还是兼容性都不需要担心，设计思路也会一脉相承。
+
+#### 大服务范围的劣势
+
+**前期上手成本高**
+
+全家桶的概念导致上手难度偏高，因为必须理解所有内置概念后才能开始项目。
+
+**如果内置模块无法满足业务，会觉得有些死板**
+
+一旦发生内置功能无法满足业务的场景，就很难拓展了，因为 all in one 的思路本质上就是排斥自定义拓展的，这点从 [angular-cli](https://github.com/angular/angular-cli) 就能看出来。
+
+之所以觉得死板，是因为这种情况没办法用优雅的方式解决，只能在现有约束的框架内通过某些 “Hack” 方式解决，自然会有种死板的感觉。
+
+#### 中等服务范围的优势
+
+**分层设计，允许新特性渐进加入**
+
+Vue 通过分层设计做到了折中，即官方还是会维护生态，只不过生态不是必须的，可以按需使用。这样做的好处是兼顾了一些优势。
+
+**低学习门槛**
+
+与小服务范围框架一样，对于核心包来说学习成本都比较低。
+
+**依然有最佳实践解决所有业务问题**
+
+和大服务范围框架一样，拥有全套官方最佳实践，但不内置，不强求一定要使用，因此你可以按需使用。
+
+#### 中等服务范围的劣势
+
+**维护成本高**
+
+和大服务范围框架一样，虽然生态不强求，但毕竟官方还是要持续维护的，因此维护成本高的问题依然存在。
+
+**生态多样性不高**
+
+虽然生态是按需的，但毕竟中等服务范围的框架官方会实现一套标准生态插件，这会极大影响社区生态的发展空间，导致 “非官方插件没人愿意做”，因此生态多样性会差一些。
+
+### 渲染机制
+
+渲染机制区别主要在 JSX vs Template 之间，不同的表达方式之间还是存在一些很本质的区别，然而正如一开始所说，无法一言蔽之，必须从多个角度拆解的看。
+
+#### JSX 的优势
+
+**纯 JS 表达 UI**
+
+单这一点就非常重要了，满足了 All In Js 的幻想。毕竟 Html、Css 相比 Js 来说，模块化能力和灵活性都很弱，将其都收敛到 Js 不仅表达方式更统一，更重要的是都获得了与 Js 一样的模块化、灵活性、Typescript 支持等能力。
+
+**视图即数据**
+
+将视图看作一种数据，让针对视图的逻辑测试成为可能。
+
+同时也将视图概念泛化了，因为数据是平台无关的，一份描述视图的 DSL 可以运行在任何平台。
+
+#### JSX 的劣势
+
+**开销大**
+
+页面节点越多，Diff 开销就越大。
+
+**动态渲染很难性能优化**
+
+由于所有 DOM 节点都是动态生成，因此无法根据初始状态结构进行安全的优化。相比之下，Template 模式可以确定哪部分属于变量，哪部分是固定的，对固定部分的 Diff 检测都可以跳过。
+
+**动态调度虽然改善了性能，但依赖更重的运行时**
+
+React ConcurrentMode 是一个调度优化器，但实现的逻辑也比较复杂，加重了运行时负担。
+
+#### Template 的优势
+
+**原生性能**
+
+由于 Template 对节点进行直接渲染，因此与原生性能一致。
+
+**Runtime 更小**
+
+由于不需要额外优化，运行时代码会小很多。
+
+#### Template 的劣势
+
+**被 Template 语法约束，且无法拓展**
+
+对于 Template 不支持的，只能选择接受，因为除了框架自己，没有人能拓展 Template 的特性。当遇到一些非常动态场景，但 Template 不支持的情况，只能选择接受，并用比较 Hack 的方式绕过解决，除此之外别无他法。
+
+**模版冗长**
+
+JSX 可以利用循环语句或者变量赋值进行模版区块的复用，但 Template 模式每次新模版都要一行一行的打出来，这种冗长的开发体验不太友好。
+
+**运行时解析开销或者依赖编译期逻辑**
+
+要么通过编译器预先生成 AST，要么运行时动态将 Template 解析成 AST，无论哪种方案都有额外的开销，一种是工程依赖的开销，一种是运行时动态解析的性能开销。
+
+#### VDom + Template 的特色
+
+Vue 在 Template 基础上支持了虚拟 DOM，因此兼具两者特色。
+
+性能上，在编译时就进行 AST 解析，减少了运行时解析开销。
+
+功能上，支持模版与 JSX 两种语法。
+
+### 状态机制
+
+状态机制 [尤雨溪](https://github.com/yyx990803) 在 JSConf 提到要单独拆出来讲，因为内容较多，时间可能不够，本次精读也限于篇幅原因略过：
+
+- Mutable vs Immutable。
+- 依赖追踪 vs 脏检测。
+- 响应式 vs 模拟响应式。
+
+显然，状态机制方案更是仁者见仁智者见智的事情，同样得从多个维度进行独立分析，并根据实际业务场景具体选择。
+
+最后，意识到没有一个绝对均衡的框架设计方案，因为在工程领域，没有最好只有更好。
+
+## 3 精读
+
+我们再延伸谈一谈为什么框架设计要寻找平衡点。
+
+**框架设计没有银弹**
+
+与数学公式不同，框架设计甚至整个工程技术设计都没有所谓的真理，所谓条条大路通罗马，实现同一个技术目标的众多方案之间也许就是平行关系，可以根据不同维度列出一二三的对比，但无法得出一个总的结论，孰优孰劣。
+
+**使用场景不同**
+
+不同使用场景决定了对框架诉求的不同。
+
+比如开发非常定制、炫酷的可视化大屏，那么前端开发框架基本也用不上，因为关注点不会聚焦在项目路由、UI 描述、甚至是数据流，而是聚焦在性能、图形渲染等问题。解决这些领域的框架可能是 虚幻 4、Unity 等游戏引擎，但普通的前端开发框架绝不会涉足这种领域，框架一定要确定自己功能范围。
+
+即便仅局限在 Web 领域，也需要考虑是否要支持非 Web 场景，那么将 HTML 抽象成一个通用 DSL 就可能是一种选择，但非 Web 领域毕竟不是主打业务领域，在这种业务场景周边生态维护可能就比较少，这也是需要取舍的地方。
+
+**使用的人不同**
+
+不同团队对框架的要求也不同。
+
+刚起步的小团队可能更需要保姆式的框架，因为这样最节省人力成本。对于规模较大的团队，希望对框架拥有较大定制能力时，小服务范围的框架可能更受青睐。当然框架作者可以像 Vue 一样做出渐进式官方能力增强方案，以此满足不同需求的用户，但毕竟也不能将生态完全交给社区，还是要做取舍。
+
+所以当遇到更新更酷的框架时，需要冷静思考的不只是这个框架带来的收益与花费的迁移成本哪个更高，以及团队能否接受这套框架的开发习惯，更需要思考的是这个框架自身做了哪些权衡，如果这些权衡与 React、Vue、Angular 类似，那么仅仅变化了语法或者语言的改动其实意义不大，此时需要慎重考虑。
+
+## 4 总结
+
+这次没有提到的状态机制对比，你能分别列举出优缺点吗？欢迎留言。
+
+> 讨论地址是：[精读《寻找框架设计的平衡点》 · Issue #223 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/223)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/134.精读《我在阿里数据中台大前端》.md

@@ -0,0 +1,111 @@
+## 1 引言
+
+当下互联网行业里面最流行的就是 ABC:
+
+> A: AI 人工智能  B: BIG DATA   C: CLOUD
+
+而阿里经济体中的 ABC，其中的 BIG DATA，即是我们 DT https://dt.alibaba.com/  ，我们用大数据赋能商业，创造价值。
+
+而我们说数据中台，其实阿里提出的中台只有两个：业务中台与数据中台。业务中台的目的是让业务能够快速落地，数据中台的目的是完成数据的采集、建设、管理、使用这四个环节，让数据从生产到使用过程变得丝般顺滑，不仅不让数据资产成为累赘，还会最大限度发挥出数据潜藏的价值。
+
+笔者所在的就是数据中台的大前端团队，既为阿里经济体提供数据服务，又着力为上云企业打造属于自己的数据中台，处在前端技术、商业模式、产品设计的最前沿，且听我慢慢道来。
+
+## 2 精读
+
+### 全链路数据能力
+
+从能力上看，数据中台处理数据的方方面面，从数据产生开始就进行追踪，不仅打通了数据采集、存储、处理、查询、消费的全链路，还用以下几种方式赋能业务：研发数据管理平台并监控数据质量，研发生意参谋等数据分析产品直接服务大、中、小商家，提供统一数据服务标准化数据使用流程，将数据分析的算法能力服务化，将支撑内部的数据服务上云搭建客户自己的数据中台，研发 BI 平台完成数据决策的最后一环。
+
+### 全链路数据技术
+
+从技术架构上看，从底层的数据采集技术开始，逐步向上建设了数据计算与管理能力、数据服务、数据平台、数据应用与数据安全。
+
+从使用者角度来看，现在的公司对数据的诉求可以概括为以下几点：
+
+1. 数据从哪来，如何完全数字化：对应全链路数据采集服务。
+2. 如何得到想要的数据：数据计算、建模与管理服务。
+3. 如何使用数据：统一数据服务平台。
+4. 如何利用数据做商业决策：BI 平台。
+5. 如何保障数据安全：数据安全服务。
+
+对阿里而言，还会额外考虑下面几点：
+
+1. 如何让数据服务横向支撑所有业务线：数据服务平台化，数据智能化服务平台与 BI 平台。
+2. 如何让数据服务普惠到每一个企业：数据服务全面上云。
+3. 如何让数据服务更有价值：打通阿里经济体的数据体系，让数据相互产生化学反应。
+
+当然，挑战性也非常大，首先是数据壁垒的挑战，要说服其他团队将数据交给你管理绝非易事。其次是价值挑战，如何证明数据中台存在的价值，并做到肉眼可见的业务增值。最后是技术挑战，对前端来说，几十款数据产品的搭建、几十万张数据报表的搭建，需要一个足够好用的数据产品搭建平台来支持；数据分析产品的下一代探索式分析也对 BI 引擎提出了新的要求；数据可视化远比普通可视化复杂，不仅要考虑大数据下的性能与可读性，还要理解商业，做出能体现数据分析价值的图表。
+
+不论是数据搭建还是数据可视化，都是前端垂直领域的另一条好赛道，不仅有沉甸甸的业务价值，还有全新数据领域的的前端技术挑战，而且随着数据中台影响力的持续扩大，我们的前端技术也会带来业界越来越大的影响力。
+
+### 如何建设和管理数据
+
+想要数据用的好，首先要管的好，在大数据时代，企业必须建立一套自己的标准数仓系统对数据的采集、运维调度做全链路管理，让大数据变成好数据，让好数据可以发挥价值。
+
+![](https://img.alicdn.com/tfs/TB1Pz.ZrAL0gK0jSZFtXXXQCXXa-1903-929.png)
+
+> Dataphin 数仓建设平台。
+
+数仓的建设需要从物理空间与逻辑空间，也就是底层的表开始整理，通过对数据的采集、清洗、结构化，产出一套规范的数据定义。
+
+所谓规范的数据定义即口径、算法、命名均一致的数据规范，降低数据二义性，提升数据查找效率与准确性。之后对数据建模，建模即是对数据的进一步抽象，可能是抽象为一个 Cube 模型，这样在顶层认知上，所有数据都是不同维度的 Cube，方便统一理解。
+
+最后通过对数据进行在线的、离线的调度计算，产出数据资产。
+
+### 如何看数据
+
+或导出一个 Excel 文件仔细品味，或如双十一媒体大屏般夺目，或如股票操盘手般紧盯着屏幕，或随时随地的手机浏览。在哪看，怎么看，看什么，决定着同一份数据可带来不同的效果，产生不同的价值。
+
+稳：双十一大屏，零点起得来，24 点收得住，每个彩蛋的出现，每个数字的跳动，如丝般顺滑，这不是播放 VCR，每一帧画面都是真实的数据展现。容：即是生意参谋用户的浏览器兼容，又是多端用户的兼容，也是 BI 分析结果的数据大容量。有容乃大，方显前端功底。
+
+**“如何看数据” 这恰是做为数据前端人的使命和责任。** 不同的人，不同的端，不同的需求，这恰是给数据前端的挑战。而让用户透过数据创造价值，也正是数据前端人的价值。
+
+### 如何分析数据
+
+大数据浪潮之下，必然会诞生各式各样的数据产品，产品化的方式可以降低数据应用的门槛。我们希望人人都能成为数据分析师，于是 BI （商业智能）产品应运而生，作为大数据行业中的一个重要领域，BI 产品用大数据的方式解决了企业的业务分析需求，支撑企业进行数字化转型，从经验驱动决策转变为数据驱动决策，进而给企业带来超额收益。
+
+![](https://img.alicdn.com/tfs/TB1KJE0rpP7gK0jSZFjXXc5aXXa-2664-1060.png)
+
+> QuickBI 数据分析工具。
+
+**人人都是数据分析师的情况在不断增强。**
+
+根据 Gartner 对 2020 年 BI 产品发展趋势预测：
+
+1. 到 2020 年，为用户提供对内部和外部数据策划目录的访问权限的组织将从分析投资中获得两倍的业务价值。
+2. 到 2020 年，业务部门的数据和分析专家数量的增速将是 IT 部门专家的 3 倍，这会迫使企业重新考虑其组织模式和技能。
+3. 到 2021 年，自然语言处理和会话分析这两个功能，会在新用户、特别是一线工作人员中，将分析和商业智能产品的使用率从 35% 提升到 50% 以上。
+
+**快速增涨的市场规模。**
+
+根据中国电子信息产业发展研究院发布的《中国大数据产业发展水平评估报告》，预计 2019 年我国大数据核心产业规模突破 5700 亿元，未来 2-3 年的市场规模的增长率仍将保持 35% 左右。未来切入这部分应用环节，BI 商业智能的潜在市场规模将在数百亿的市场空间。
+
+**大数据与前端。**
+
+前端的职业发展除了提升自己的技能技术储备之外，选择合适行业方向和研究领域也尤为重要。如果用路和车的关系来比喻的话，把前端技能比作车的话，各个行业都是路，有的路是乡间小路，有的路是城乡公路，而大数据行业当之无愧是行业中的上高速公路，路况更好，路面更宽，如果你拥有一辆好车，为什么不来高速公路上飞驰呢？
+
+大数据下的前端面临哪些挑战？以 BI 为例，BI 领域的四大方向：数据集、渲染引擎、数据模型与可视化都有许多可以做深的技术点，每一块都需要深入沉淀几年技术经验才能做好，需要大量优秀人才通力协作才有可能做好。你也可以阅读 [精读《前端与 BI》](https://github.com/dt-fe/weekly/blob/v2/121.%E7%B2%BE%E8%AF%BB%E3%80%8A%E5%89%8D%E7%AB%AF%E4%B8%8E%20BI%E3%80%8B.md) 了解更多 BI 相关知识。
+
+### 我们是数据中台大前端
+
+> “ 前端不是因为我们用 JavaScript，而是因为我们站在业务最前端，解决业务端的问题，所以我们是前端 ”。
+
+BI 分析产品、做数据可视化、做产品搭建 .. 我们早已经跳出了“前端”的传统概念范畴。我们做大数据表格优化、 Web Excel、 SQL 编辑器、智能可视化。在数据中台，我们有着天然的复杂业务场景和海量数据优势，迫使你向自己提出更大的挑战来解决业务上的问题。如果你热爱挑战、热爱技术，请加入我们吧。
+
+**在这里，你可以愉快的使用 React、TypesScript 写业务代码，尝试最新、最炫酷的 React Hooks 新特性，我们团队一直走在前端技术路线的最前沿，渴求技术创新。** 你也不需要担心伙伴的代码风格问题，因为我们有着严格的代码规；你不必担心每个人的代码都是一座孤岛，因为我们会对每一行代码做严格的 review；你不必担心你的成长空间，我们有定期的技术分享、团队内小竞赛，还有足够复杂的业务场景支撑；你也不必担心你会因工作日渐消瘦，下午茶和海量小零食等你来！
+
+## 4 总结
+
+**大数据前端人才缺口在 100 人以上，由于业务增长非常非常迅猛，春节前条件放宽、特批急召！**
+
+如果你对我们感兴趣，请立刻把简历发送到邮箱 **ziyi.hzy@alibaba-inc.com** 吧！绝无仅有的好机会，响应速度绝对超乎你的想象！
+
+> 讨论地址是：[精读《我在阿里数据中台大前端》 · Issue #224 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/224)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/138.精读《精通 console.log》.md

@@ -0,0 +1,123 @@
+## 1 引言
+
+本周精读的文章是 [Mastering JS console.log like a Pro](https://medium.com/javascript-in-plain-english/mastering-js-console-log-like-a-pro-1c634e6393f9)，一起来更全面的认识 console 吧！
+
+## 2 概述 & 精读
+
+console 的功能主要在于控制台打印，它可以打印任何字符、对象、甚至 DOM 元素和系统信息，下面一一介绍。
+
+### console.log( ) | info( ) | debug( ) | warn( ) | error( )
+
+直接打印字符，区别在于展示形态的不同：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1xZ_WveH2gK0jSZFEXXcqMpXa-1492-566.png">
+
+新版 chrome 控制台可以将打印信息分类：
+
+<img width=200 src="https://img.alicdn.com/tfs/TB1fZ2Vvhn1gK0jSZKPXXXvUXXa-420-446.png">
+
+`log()` 与 `info()` 都对应 `info`，`warn()` 对应 `warnings`，`error()` 对应 `errors`，而 `debug()` 对应 `verbose`，因此建议在合适的场景使用合适的打印习惯，这样排查问题时也可以有针对性的筛选。
+
+比如调试信息可以用 `console.debug` 仅在调试环境下输出，调试者即便开启了调试参数也不会影响正常 `info` 的查看，因为调试信息都输出在 `verbose` 中。
+
+### 使用占位符
+
+- %o — 对象
+- %s — 字符串
+- %d — 数字
+
+如下所示，可通过占位符在一行中插入不同类型的值：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1GtL3vlr0gK0jSZFnXXbRRXXa-1840-504.png">
+
+### 添加 CSS 样式
+
+- %c - 样式
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1eK23vlr0gK0jSZFnXXbRRXXa-1832-978.png">
+
+可以总结出，**console 支持输出复杂的内容，其输出能力堪比 HTML，但输入能力太弱，仅为字符串，因此采用了占位符 + 多入参修饰的设计模式解决这个问题。**
+
+### console.dir( )
+
+按 JSON 模式输出。笔者在这里也补充一句：`console.log()` 会自动判断类型，如果内容是 DOM 属性，则输出 DOM 树，但 `console.dir` 会强制以 JSON 模式输出，用在 DOM 对象时可强制转换为 JSON 输出。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1KQY1vbj1gK0jSZFuXXcrHpXa-922-302.png">
+
+### 输出 HTML 元素
+
+按照 HTML ELements 结构输出：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1mZ61va61gK0jSZFlXXXDKFXa-920-255.png">
+
+这种输出结构和 Elements 打印形式是一致的，如果要看详细属性，可以使用 `console.dir()`。
+
+### console.table
+
+在控制台打印一个表格，属于功能增强。虽然仅文本也可以在控制台打印出漂亮的表格，但浏览器调试控制台的功能更强大，`console.table` 只是其富文本能力的一个体现。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1WldouKbviK0jSZFNXXaApXXa-928-742.png">
+
+### console.group( ) & console.groupEnd( )
+
+接下来是另一个富文本能力，按分组输出：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1UV6UvXY7gK0jSZKzXXaikpXa-919-377.png">
+
+这种带有副作用的 API 显然是为方便阅读而设计的，然而在需要输出大量动态结构化数据的场景下，还需要进行结构转换，是比较麻烦的地方。
+
+### console.count( )
+
+`count()` 用来打印调用次数，一般用在循环或递归函数中。接收一个 `label` 参数以定制输出，默认直接输出 `1 2 3` 数字。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1ELLVveL2gK0jSZPhXXahvXXa-917-500.png">
+
+### console.assert( )
+
+`console` 版断言工具，当且仅当第一个参数值为 `false` 时才打印第二个参数作为输出。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1HEDUvfb2gK0jSZK9XXaEgFXa-1842-548.png">
+
+这种输出结果为 error，所以也可被 `console.error` + 代码级别断言所取代。
+
+### console.trace( )
+
+打印此时的调用栈，在打印辅助调试信息时非常有用。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1Jh_YvkL0gK0jSZFAXXcA9pXa-1840-1096.png">
+
+### console.time( )
+
+打印代码执行时间，性能优化和监控场景比较常见。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1wAT2vbj1gK0jSZFuXXcrHpXa-1612-524.png">
+
+### console.memory
+
+打印内存使用情况。
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1tPHYvkL0gK0jSZFAXXcA9pXa-1842-440.png">
+
+### console.clear( )
+
+清空控制台输出。
+
+## 3 总结
+
+`console` 提供了如此多的输出规范，其实也是在变相制定开发规范，毕竟离开发者最近的就是调试控制台，如果你的项目打印规范与标准规范有差异，那么调试时信息看起来就会很别扭。
+
+可以看到，大部分开源库都良好的遵循了这套规范，比如三方库绝不会输出 `log()`，而且将错误、警告与调试信息正确分开，并尽量少的用 CSS 样式、分组、`table` 等功能，因为这些功能干扰性较强，不能保证所有用户都可接受。
+
+相对的，项目源码就比较适合使用一些醒目的自定义规范，只要这套规则能被很好的执行起来。
+
+最后留下一个讨论点：`console` 可以作为调试、招聘信息、隐藏菜单的投放点，你还看到过哪些有意思的 `console` 使用方式呢？欢迎留言。
+
+> 讨论地址是：[精读《精通 console.log》 · Issue #228 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/228)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/139.精读《手写 JSON Parser》.md

@@ -0,0 +1,279 @@
+## 1 引言
+
+`JSON.parse` 是浏览器内置的 API，但如果面试官让你实现一个怎么办？好在有人已经帮忙做了这件事，本周我们一起精读这篇 [JSON Parser with Javascript](https://lihautan.com/json-parser-with-javascript/) 文章吧，再温习一遍大学时编译原理相关知识。
+
+## 2 概述 & 精读
+
+要解析 JSON 首先要理解语法概念，之前的 [精读《手写 SQL 编译器 - 语法分析》](https://github.com/dt-fe/weekly/blob/v2/066.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%AD%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md) 系列也有介绍过，不过本文介绍的更形象，看下面这个语法图：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1EbjfvQL0gK0jSZFtXXXQCXXa-1837-857.png">
+
+这是关于 Object 类型的语法描述图，从左向右看，根据箭头指向只要能走出这个迷宫就属于正确语法。
+
+比如第一行 `{` → `whitespace` → `}` 表示 `{ }` 属于合法的 JSON 语法。
+
+再比如观察向下的一条最长路线：`{` → `whitespace` → `string` → `whitespace` → `:` → `value` → `}` 表示 `{ string : value }` 属于合法的 JSON 语法。
+
+你可能会问，双引号去哪儿了？这就是语法树最核心的概念了，这张图是关于 Object 类型的 **产生式**，同理还有 string、value 的产生式，产生式中可以嵌套其他产生式，甚至形成环路，以此拥有描述纷繁多变语法的能力。
+
+最后我们再看一个环路，即 `{` → `whitespace` → `string` ... `,` → `whitespace` → `string` ... `,` ... `}`，我们发现，只要不走回头路，这条路是可以一直 “绕圈” 下去的，因此 Object 类型拥有了任意数量子字段的能力，只是每形成一个子字段，必须经过 `,` 号分割。
+
+### 实现 Parser
+
+首先实现一个基本结构：
+
+```js
+function fakeParseJSON(str) {
+  let i = 0;
+  // TODO
+}
+```
+
+`i` 表示访问字符的下标，当 `i` 走到字符串结尾表示遍历结束。
+
+然后是下一步，用几个函数描述解析语法的过程：
+
+```js
+function fakeParseJSON(str) {
+  let i = 0;
+  function parseObject() {
+    if (str[i] === '{') {
+      i++;
+      skipWhitespace();
+
+      // if it is not '}',
+      // we take the path of string -> whitespace -> ':' -> value -> ...
+      while (str[i] !== '}') {
+        const key = parseString();
+        skipWhitespace();
+        eatColon();
+        const value = parseValue();
+      }
+    }
+  }
+}
+```
+
+其中 `skipWhitespace` 表示匹配并跳过空格，所谓匹配意味着匹配成功，此时 `i` 下标可以继续后移，否则匹配失败。下一步则判断如果 `i` 不是结束标志 `}`，则按照 `parseString` 匹配字符串 → `skipWhitespace` 跳过空格 → `eatColon` 吃掉冒号 → `parseValue` 匹配值，这个链路循环。其中吃掉冒号表示 “匹配冒号但不会产生任何结果，所以就像吃掉了一样”，吃这个动作还可以用在其他场景，比如吃掉尾分号。
+
+> 对于看到这儿的小伙伴，笔者要友情提示一下，原文的思路是一种定制语法解析思路，无论是 `eatColon` 还是 `parseValue` 都仅具备解析 JSON 的通用性，但不具备解析任意语法的通用性。如果你想做一个具备解析任何通用语法的解析器，读入的内容应该是语法描述，处理方式必须更加通用，如果感兴趣可以阅读 [精读《手写 SQL 编译器 - 语法分析》](https://github.com/dt-fe/weekly/blob/v2/066.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%AD%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md) 系列文章了解更多。
+
+由于 Object 第一个元素前面不允许加逗号，因此可以利用 `initial` 做一个初始化判定，在初始时机不会吃掉逗号：
+
+```js
+function fakeParseJSON(str) {
+  let i = 0;
+  function parseObject() {
+    if (str[i] === '{') {
+      i++;
+      skipWhitespace();
+
+      let initial = true;
+      // if it is not '}',
+      // we take the path of string -> whitespace -> ':' -> value -> ...
+      while (str[i] !== '}') {
+        if (!initial) {
+          eatComma();
+          skipWhitespace();
+        }
+        const key = parseString();
+        skipWhitespace();
+        eatColon();
+        const value = parseValue();
+        initial = false;
+      }
+      // move to the next character of '}'
+      i++;
+    }
+  }
+}
+```
+
+那么当第一个子元素前面存在逗号时，由于没有 “吃掉逗号” 这个功能，所以读到逗号会报错，语法解析提前结束。
+
+吃逗号和吃冒号的代码都非常简单，即判断当前字符串必须是 “要吃的那个元素”，并且在吃掉后将 `i` 下标自增 1：
+
+```js
+function fakeParseJSON(str) {
+  // ...
+  function eatComma() {
+    if (str[i] !== ',') {
+      throw new Error('Expected ",".');
+    }
+    i++;
+  }
+
+  function eatColon() {
+    if (str[i] !== ':') {
+      throw new Error('Expected ":".');
+    }
+    i++;
+  }
+}
+```
+
+在有了基本判定功能后，`fakeParseJSON` 需要返回 Object，因此我们只需在每个循环中对 Object 赋值，最后一并 return 即可：
+
+```js
+function fakeParseJSON(str) {
+  let i = 0;
+  function parseObject() {
+    if (str[i] === '{') {
+      i++;
+      skipWhitespace();
+
+      const result = {};
+
+      let initial = true;
+      // if it is not '}',
+      // we take the path of string -> whitespace -> ':' -> value -> ...
+      while (str[i] !== '}') {
+        if (!initial) {
+          eatComma();
+          skipWhitespace();
+        }
+        const key = parseString();
+        skipWhitespace();
+        eatColon();
+        const value = parseValue();
+        result[key] = value;
+        initial = false;
+      }
+      // move to the next character of '}'
+      i++;
+
+      return result;
+    }
+  }
+}
+```
+
+解析 Object 的代码就完成了。
+
+接着试着解析 Array，下面是 Array 的语法图：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1FvYjvKH2gK0jSZFEXXcqMpXa-1837-479.png">
+
+我们只需要吃逗号和 `parseValue` 即可：
+
+```js
+function fakeParseJSON(str) {
+  // ...
+  function parseArray() {
+    if (str[i] === '[') {
+      i++;
+      skipWhitespace();
+
+      const result = [];
+      let initial = true;
+      while (str[i] !== ']') {
+        if (!initial) {
+          eatComma();
+        }
+        const value = parseValue();
+        result.push(value);
+        initial = false;
+      }
+      // move to the next character of ']'
+      i++;
+      return result;
+    }
+  }
+}
+```
+
+接下来到了有趣的 `value` 语法图，可以看到 `value` 是许多种基础类型的 “或” 关系组成的：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB1uGrmvND1gK0jSZFyXXciOVXa-1836-1293.png">
+
+我们只需要继续拆解分析即可：
+
+```js
+function fakeParseJSON(str) {
+  // ...
+  function parseValue() {
+    skipWhitespace();
+    const value =
+      parseString() ??
+      parseNumber() ??
+      parseObject() ??
+      parseArray() ??
+      parseKeyword('true', true) ??
+      parseKeyword('false', false) ??
+      parseKeyword('null', null);
+    skipWhitespace();
+    return value;
+  }
+}
+```
+
+其中 `parseKeyword` 函数用来解析一些保留关键字，比如将 `"true"` 解析成布尔类型 `true`：
+
+```js
+function fakeParseJSON(str) {
+  // ...
+  function parseKeyword(name, value) {
+    if (str.slice(i, i + name.length) === name) {
+      i += name.length;
+      return value;
+    }
+  }
+}
+```
+
+如上所示，只要在 name 与对应字符相等时，返回第二个传入参数即可。
+
+### 处理异常输入
+
+一个完整的语法解析功能需要包含错误处理，错误的情况主要分两种：
+
+1. 非法字符。
+2. 非正常结尾。
+
+原文提到的 JSON 错误提示优化非常棒，想想你在开发中突然看到下面的提示，是不是很蒙圈：
+
+```text
+Unexpected token "a"
+```
+
+既然我们是自己写的 JSON 解析器，就可以进行更友好的异常提示，比如：
+
+```text
+// show
+{ "b"a
+      ^
+JSON_ERROR_001 Unexpected token "a".
+Expecting a ":" over here, eg:
+{ "b": "bar" }
+      ^
+You can learn more about valid JSON string in http://goo.gl/xxxxx
+```
+
+更多 Demo 可以查看 [原文](https://lihautan.com/json-parser-with-javascript/)。
+
+## 3 总结
+
+这篇文章通过一个具体的例子解释如何做语法分析，对于词法解析入门非常直观，如果你想更深入理解语法解析，或者写一个通用语法解析器，可以阅读语法解析系列入门文章，笔者通过实际例子带你一步一步做一个完备的词法解析工具！
+
+语法解析入门系列文章，建议阅读顺序：
+
+- [精读《手写 SQL 编译器 - 词法分析》](https://github.com/dt-fe/weekly/blob/v2/064.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%8D%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md)
+- [精读《手写 SQL 编译器 - 文法介绍》](https://github.com/dt-fe/weekly/blob/v2/065.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E6%96%87%E6%B3%95%E4%BB%8B%E7%BB%8D%E3%80%8B.md)
+- [精读《手写 SQL 编译器 - 语法分析》](https://github.com/dt-fe/weekly/blob/v2/066.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%AD%E6%B3%95%E5%88%86%E6%9E%90%E3%80%8B.md)
+- [精读《手写 SQL 编译器 - 回溯》](https://github.com/dt-fe/weekly/blob/v2/067.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E5%9B%9E%E6%BA%AF%E3%80%8B.md)
+- [精读《手写 SQL 编译器 - 语法树》](https://github.com/dt-fe/weekly/blob/v2/070.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E8%AF%AD%E6%B3%95%E6%A0%91%E3%80%8B.md)
+- [精读《手写 SQL 编译器 - 错误提示》](https://github.com/dt-fe/weekly/blob/v2/071.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E9%94%99%E8%AF%AF%E6%8F%90%E7%A4%BA%E3%80%8B.md)
+- [精读《手写 SQL 编译器 - 性能优化之缓存》](https://github.com/dt-fe/weekly/blob/v2/078.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E4%B9%8B%E7%BC%93%E5%AD%98%E3%80%8B.md)
+- [精读《手写 SQL 编译器 - 智能提示》](https://github.com/dt-fe/weekly/blob/v2/085.%E7%B2%BE%E8%AF%BB%E3%80%8A%E6%89%8B%E5%86%99%20SQL%20%E7%BC%96%E8%AF%91%E5%99%A8%20-%20%E6%99%BA%E8%83%BD%E6%8F%90%E7%A4%BA%E3%80%8B.md)
+
+[syntax-parser](https://github.com/ascoders/syntax-parser) 这个零依赖的通用语法解析库就是根据上述文章一步一步完成的，看完了上面文章，就彻底理解了这个库的源码。
+
+> 讨论地址是：[精读《手写 JSON Parser》 · Issue #233 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/233)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）

前沿技术/140.精读《结合 React 使用原生 Drag Drop API》.md

@@ -0,0 +1,233 @@
+## 1 引言
+
+拖拽是前端非常常见的交互操作，但显然拖拽是强 DOM 交互的，而 React 绕过了 DOM 这一层，那么基于 React 的拖拽方案就必定值得聊一聊。
+
+结合 [How To Use The HTML Drag-And-Drop API In React](https://www.smashingmagazine.com/2020/02/html-drag-drop-api-react/) 这篇文章，让我们谈谈 React 拖拽这些事。
+
+## 2 概述
+
+原文说的比较简单，笔者先快速介绍其中重点部分。
+
+首先拖拽主要的 API 有 4 个：`dragEnter` `dragLeave` `dragOver` `drop`，分别对应拖入、拖出、正在当前元素范围内拖拽、完成拖入动作。
+
+基于这些 API，我们可以利用 React 实现一个拖入区域：
+
+```jsx
+import React from "react";
+
+const DragAndDrop = props => {
+  const handleDragEnter = e => {
+    e.preventDefault();
+    e.stopPropagation();
+  };
+  const handleDragLeave = e => {
+    e.preventDefault();
+    e.stopPropagation();
+  };
+  const handleDragOver = e => {
+    e.preventDefault();
+    e.stopPropagation();
+  };
+  const handleDrop = e => {
+    e.preventDefault();
+    e.stopPropagation();
+  };
+  return (
+    <div
+      className={"drag-drop-zone"}
+      onDrop={e => handleDrop(e)}
+      onDragOver={e => handleDragOver(e)}
+      onDragEnter={e => handleDragEnter(e)}
+      onDragLeave={e => handleDragLeave(e)}
+    >
+      <p>Drag files here to upload</p>
+    </div>
+  );
+};
+export default DragAndDrop;
+```
+
+`preventDefault` 指的是阻止默认响应，这个响应可能是跳转页面之类的，`stopPropagation` 是阻止冒泡，这样同样监听了事件的父元素就不会收到响应，我们可以精准作用于嵌套的子元素。
+
+接下来是拖拽状态管理，提到了 `useReducer`，顺便复习一下用法：
+
+```jsx
+...
+const reducer = (state, action) => {
+  switch (action.type) {
+    case 'SET_DROP_DEPTH':
+      return { ...state, dropDepth: action.dropDepth }
+    case 'SET_IN_DROP_ZONE':
+      return { ...state, inDropZone: action.inDropZone };
+    case 'ADD_FILE_TO_LIST':
+      return { ...state, fileList: state.fileList.concat(action.files) };
+    default:
+      return state;
+  }
+};
+const [data, dispatch] = React.useReducer(
+  reducer, { dropDepth: 0, inDropZone: false, fileList: [] }
+)
+...
+```
+
+最后一个关键点在于拖入后的处理，利用 `dispatch` 增加拖入文件、设置拖入状态即可：
+
+```js
+const handleDrop = e => {
+  ...
+  let files = [...e.dataTransfer.files];
+
+  if (files && files.length > 0) {
+    const existingFiles = data.fileList.map(f => f.name)
+    files = files.filter(f => !existingFiles.includes(f.name))
+
+    dispatch({ type: 'ADD_FILE_TO_LIST', files });
+    e.dataTransfer.clearData();
+    dispatch({ type: 'SET_DROP_DEPTH', dropDepth: 0 });
+    dispatch({ type: 'SET_IN_DROP_ZONE', inDropZone: false });
+  }
+};
+```
+
+`e.dataTransfer.clearData` 函数用于清除拖拽过程中产生的临时变量，这些临时变量可以通过 `e.dataTransfer.xxx =` 的方式赋值，一般用于拖拽过程中值的传递。
+
+总结一下，利用 HTML5 的 API 将拖拽转化为状态，最终通过状态映射到 UI。
+
+原文内容还是比较简单的，笔者在精读部分再拓展一些更体系化的内容。
+
+## 3 精读
+
+现阶段拖拽主要分为两种，一种是 HTML5 原生规范的拖拽，这种方式在拖拽过程中不会影响 DOM 结构。另一种是完全所见即所得的拖拽方式，拖拽过程中 DOM 位置会随之变动，好处是可以立即反馈拖拽结果，当然缺点是华而不实，一旦用在生产环境，这种拖拽过程可能导致页面结构频繁跳动，反而看不清拖拽效果。
+
+由于本文也采用了第一种拖拽方案，因为笔者再重新整理一遍自己的封装思路。
+
+从使用角度反推，假设我们拥有一个拖拽库，那必定要拥有两个 API：
+
+```jsx
+import { DragContainer, DropContainer } from 'dnd'
+
+const DragItem = (
+  <DragContainer>
+    {({ dragProps }) => (
+      <div {...dragProps} />
+    )}
+  </DragContainer>
+)
+
+const DropItem = (
+  <DropContainer>
+    {({ dropProps }) => (
+      <div {...dropProps} />
+    )}
+  </DropContainer>
+)
+```
+
+`DragContainer` 包裹可以被拖拽的元素，`DropContainer` 包裹可以被拖入的元素，而至于 `dragProps` 与 `dropProps` 需要透传到子元素的 dom 节点，是为了利用 DOM API 控制拖拽效果，这也是拖拽唯一对 DOM 的要求，双方元素都需要有实体 DOM 承载。
+
+而上面例子中给出 `dragProps` 与 `dropProps` 的方式属于 RenderProps，我们可以将 `children` 当作函数执行以达到效果：
+
+```jsx
+const DragContainer = ({ children, componentId }) => {
+  const { dragProps } = useDnd(componentId)
+
+  return children({
+    dragProps
+  })
+}
+
+const DropContainer = ({ children, componentId }) => {
+  const { dropProps } = useDnd(componentId)
+
+  return children({
+    dropProps
+  })
+}
+```
+
+那么这里创建了一个自定义 Hook `useDnd` 接收 `dragProps` 与 `dropProps`，这个自定义 Hook 可以这么写：
+
+```jsx
+const useDnd = ({ componentId }) => {
+  const dragProps = {}
+  const dropProps = {}
+
+  return { dragProps, dropProps }
+}
+```
+
+接下来，我们就要分别实现 `drag` 与 `drop` 了。
+
+对 `drag` 来说，只要实现 `onDragStart` 与 `onDragEnd` 即可：
+
+```jsx
+const dragProps = {
+  onDragStart: ev => {
+    ev.stopPropagation()
+    ev.dataTransfer.setData('componentId', componentId)
+  },
+  onDragEnd: ev => {
+    // 做一些拖拽结束的清理工作
+  }
+}
+```
+
+`stopPropagation` 的作用在原文简介中已经介绍过了，`setData` 则是通知拖拽方，当前拖拽的组件 id 是什么，**这是由于拖拽由 `drag` 发起而由 `drop` 响应，因此必须有个数据传输过程，而 `dataTransfer` 就最适合做这件事。**
+
+对于 `drop` 来说，只要实现 `onDragOver` 与 `onDrop` 即可：
+
+```jsx
+const dropProps = {
+  onDragOver: ev => {
+    // 做一些样式处理，提示用户此时松手会将元素放置在何处
+  },
+  onDrop: ev => {
+    ev.stopPropagation()
+    const componentId = ev.dataTransfer.getData('componentId')
+    // 通过 componentId 修改数据，通过 React Rerender 刷新 UI
+  }
+}
+```
+
+重点在 `onDrop`，它是实现拖拽效果的 “真正执行处”，最终通过修改 UI 的方式更新数据。
+
+存在一种场景，一个容器既可以被拖动，也可以被拖入，这种情况一般这个组件是个容器，但这个容器可以被拖入到其他容器中，可以自由嵌套。
+
+实现这种场景的方式就是将 `DragContainer` 与 `DropContainer` 作用到一个组件上：
+
+```jsx
+const Box = (
+  <DragContainer>
+    {({ dragProps }) => (
+      <DropContainer>
+        {({ dropProps }) => {
+          <div {...dragProps} {...dropProps} />
+        }}
+      </DropContainer>
+    )}
+  </DragContainer>
+)
+```
+
+之所以能嵌套，在于 HTML5 的 API 允许一个元素同时拥有 `onDragStart`、`onDrop` 这两种属性，而上面的语法不过是同时将这两种属性传给组件 DOM。
+
+所以，动手实现一个拖拽库就是这么简单，只要活用 HTML5 的拖拽 API，结合 React 一些特殊语法便够了。
+
+## 4 总结
+
+最后留下一个思考题，许多具有拖拽功能的系统都具备 “拖拽 placeholder” 的功能，即拖拽元素的过程中，在其 “落点” 位置展示一条横线或竖线，引导出松手后元素位置落点，如图所示：
+
+<img width=400 src="https://img.alicdn.com/tfs/TB11H04wbY1gK0jSZTEXXXDQVXa-1434-384.png">
+
+那么这条辅助线是通过什么方式实现的呢？欢迎在评论区留言！如果你有辅助线实现方案解析的文章，欢迎分享，也可以期待笔者未来专门写一篇 “拖拽 placeholder” 实现剖析的精读。
+
+> 讨论地址是：[精读《手写 JSON Parser》 · Issue #233 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/233)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）