Merge branch 'master' of https://github.com/ascoders/weekly

fix: typo in 精读《请停止 css-in-js 的行为》.md

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 COUNT(GDP) FROM amazing_table
+GROUP BY country
+```
+
+返回的结果就会按照国家进行分组，这时，聚合函数就变成了在组内聚合。
+
+其实如果我们只想看中、美的 GDP，用非分组也可以查，只是要分成两条 SQL：
+
+```sql
+SELECT COUNT(GDP) FROM amazing_table
+WHERE country = '中国'
+
+SELECT COUNT(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)）
+
+

helper.js

@@ -12,6 +12,7 @@ const dirs = [
   "源码解读",
   "商业思考",
   "算法",
+  "SQL"
 ];
 
 dirs.forEach((dir) => {

readme.md

@@ -6,7 +6,7 @@
 
 前端界的好文精读，每周更新！
 
-最新精读：<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="./SQL/232.SQL%20%E8%81%9A%E5%90%88%E6%9F%A5%E8%AF%A2.md">232.SQL 聚合查询</a>
 
 素材来源：[周刊参考池](https://github.com/ascoders/weekly/issues/2)
 
@@ -181,6 +181,11 @@
 - <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>
 
 ### 设计模式
 
@@ -235,6 +240,8 @@
 - <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>
 
 ### 商业思考
 
@@ -258,6 +265,11 @@
 - <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>
+
 ## 关注前端精读微信公众号
 
 <img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">

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

@@ -81,7 +81,7 @@ YUI3 的 sandbox 像极了差不多同时出现的 AMD 规范，但早期 yahoo
 
 对于 js 模块化，最近出现的 `<script type="module">` 方式，虽然还没有得到浏览器原生支持，但也是我比较看好的未来趋势，这样就连 webpack 的拆包都不需要了，直接把源代码传到服务器，配合 http2.0 完美抛开预编译的枷锁。
 
-上述三中方案都不依赖预编译，分别实现了 html、css、js 模块化，相信这就是未来。
+上述三种方案都不依赖预编译，分别实现了 html、css、js 模块化，相信这就是未来。
 
 ### 模块化标准推进速度仍然缓慢
 

前沿技术/19.精读《最佳前端面试题》及面试官技巧.md

@@ -88,7 +88,7 @@
 
 通过了基础问题还远远不够。甚至当问一个复杂的问题的时候，如果候选人瞬间把答案完美流畅表达出来，说明这个问题基本上白问了。
 
-**技术面更应该考察候选人的思考过程和基于此来表达出的技术能力和项目经验。**如果候选人基础没有落下太多，思维足够灵活，在过往项目中主动学习，并主导解决过项目问题，说明已经比较优秀了，我们招的每一人都应当拥有激情与学习能力。
+**技术面更应该考察候选人的思考过程和基于此来表达出的技术能力和项目经验**。如果候选人基础没有落下太多，思维足够灵活，在过往项目中主动学习，并主导解决过项目问题，说明已经比较优秀了，我们招的每一人都应当拥有激情与学习能力。
 
 所以，当问到候选人不了解的知识点时，通过引导并挖掘出候选人拥有多少问题解决能力，才是最大的权重项，如果这个问题候选人也提前准备了，那说明准备对了。
 

前沿技术/202.精读《React 18》.md

@@ -103,7 +103,7 @@ const root = ReactDOM.hydrateRoot(container, <App tab="home" />);
 
 简单来说，Concurrent Mode 就是一种可中断渲染的设计架构。什么时候中断渲染呢？当一个更高优先级渲染到来时，通过放弃当前的渲染，立即执行更高优先级的渲染，换来视觉上更快的响应速度。
 
-有人可能会说，不对啊，中断渲染后，之前渲染的 CPU 执行不就浪费了吗，换句话说，整体执行时常增加了。这句话是对的，但实际上用户对页面交互及时性的感知是分为两种的，第一种是即时输入反馈，第二种是这个输入带来的副作用反馈，比如更新列表。其中，即使输入反馈只要能优先满足，即便副作用反馈更慢一些，也会带来更好的体验，更不用说副作用反馈大部分情况会因为即使输入反馈的变化而作废。
+有人可能会说，不对啊，中断渲染后，之前渲染的 CPU 执行不就浪费了吗，换句话说，整体执行时长增加了。这句话是对的，但实际上用户对页面交互及时性的感知是分为两种的，第一种是即时输入反馈，第二种是这个输入带来的副作用反馈，比如更新列表。其中，即使输入反馈只要能优先满足，即便副作用反馈更慢一些，也会带来更好的体验，更不用说副作用反馈大部分情况会因为即使输入反馈的变化而作废。
 
 由于 React 将渲染 DOM 树机制改为两个双向链表，并且渲染树指针只有一个，指向其中一个链表，因此可以在更新完全发生后再切换指针指向，而在指针切换之前，随时可以放弃对另一颗树的修改。
 

前沿技术/221.精读《深入了解现代浏览器三》.md

@@ -8,7 +8,7 @@
 
 ### 解析阶段
 
-首先 renderer process 主线程会解析 HTML 文本为 DOM（Document Object Model），只译为中文就是文档对象模型，所以首先要把文本结构化才能继续处理。不仅是浏览器，代码的解析也得首先经历 Parse 阶段。
+首先 renderer process 主线程会解析 HTML 文本为 DOM（Document Object Model），直译为中文就是文档对象模型，所以首先要把文本结构化才能继续处理。不仅是浏览器，代码的解析也得首先经历 Parse 阶段。
 
 对于 HTML 的 link、img、script 标签需要加载远程资源的，浏览器会调用 network thread 优先并行处理，但遇到 script 标签就必须停下来优先执行，因为 js 代码可能会改变任何 dom 对象，这可能导致浏览器要重新解析。所以如果你的代码没有修改 dom 的副作用，可以添加 async、defer 标签，或 JS 模块的方式使浏览器不必等待 js 的执行。
 

前沿技术/222.精读《深入了解现代浏览器四》.md

@@ -69,7 +69,7 @@ document.body.addEventListener('touchstart', event => {
 
 ```css
 #area {
-  touch-action: pan-x;
+  touch-action: none;
 }
 ```
 

前沿技术/223.精读《Records & Tuples 提案》.md

@@ -364,7 +364,7 @@ assert("a" in #{ a: 1, b: 2 });
 对 Record 与 Tuple 进行原生数组或对象操作后，返回值也是 immutable 类型的：
 
 ```js
-assert(Object.keys(#{ a: 1, b: 2 }) === #["a", "b"]);
+assert(Object.keys(#{ a: 1, b: 2 }) !== #["a", "b"]);
 assert(#[1, 2, 3].map(x => x * 2), #[2, 4, 6]);
 ```
 

前沿技术/224.精读《Records & Tuples for React》.md

@@ -0,0 +1,258 @@
+继前一篇 [精读《Records & Tuples 提案》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/223.%E7%B2%BE%E8%AF%BB%E3%80%8ARecords%20%26%20Tuples%20%E6%8F%90%E6%A1%88%E3%80%8B.md)，已经有人在思考这个提案可以帮助 React 解决哪些问题了，比如这篇 [Records & Tuples for React](https://sebastienlorber.com/records-and-tuples-for-react)，就提到了许多 React 痛点可以被解决。
+
+其实我比较担忧浏览器是否能将 Records & Tuples 性能优化得足够好，这将是它能否大规模应用，或者说我们是否放心把问题交给它解决的最关键因素。本文基于浏览器可以完美优化其性能的前提，一切看起来都挺美好，我们不妨基于这个假设，看看 Records & Tuples 提案能解决哪些问题吧！
+
+## 概述
+
+[Records & Tuples Proposal](https://github.com/tc39/proposal-record-tuple) 提案在上一篇精读已经介绍过了，不熟悉可以先去看一下提案语法。
+
+### 保证不可变性
+
+虽然现在 React 也能用 Immutable 思想开发，但大部分情况无法保证安全性，比如：
+
+```tsx
+const Hello = ({ profile }) => {
+  // prop mutation: throws TypeError
+  profile.name = 'Sebastien updated';
+  return <p>Hello {profile.name}</p>;
+};
+
+function App() {
+  const [profile, setProfile] = React.useState(#{
+    name: 'Sebastien',
+  });
+  // state mutation: throws TypeError
+  profile.name = 'Sebastien updated';
+  return <Hello profile={profile} />;
+}
+```
+
+归根结底，我们不会总使用 `freeze` 来冻结对象，大部分情况下需要人为保证引用不被修改，其中的潜在风险依然存在。但使用 Record 表示状态，无论 TS 还是 JS 都会报错，立刻阻止问题扩散。
+
+### 部分代替 useMemo
+
+比如下面的例子，为了保障 `apiFilters` 引用不变，需要对其 `useMemo`:
+
+```tsx
+const apiFilters = useMemo(
+  () => ({ userFilter, companyFilter }),
+  [userFilter, companyFilter],
+);
+const { apiData, loading } = useApiData(apiFilters);
+```
+
+但 Record 模式不需要 memo，因为 js 引擎会帮你做类似的事情：
+
+```tsx
+const {apiData,loading} = useApiData(#{ userFilter, companyFilter })
+```
+
+### 用在 useEffect
+
+这段写的很啰嗦，其实和代替 useMemo 差不多，即：
+
+```tsx
+const apiFilters = #{ userFilter, companyFilter };
+
+useEffect(() => {
+  fetchApiData(apiFilters).then(setApiDataInState);
+}, [apiFilters]);
+```
+
+你可以把 `apiFilters` 当做一个引用稳定的原始对象看待，如果它确实变化了，那一定是值改变了，所以才会引发取数。如果把上面的 `#` 号去掉，每次组件刷新都会取数，而实际上都是多余的。
+
+### 用在 props 属性
+
+可以更方便定义不可变 props 了，而不需要提前 useMemo：
+
+```tsx
+<ExpensiveChild someData={#{ attr1: 'abc', attr2: 'def' }} />;
+```
+
+### 将取数结果转化为 Record
+
+这个目前还真做不到，除非用性能非常差的 `JSON.stringify` 或 `deepEqual`，用法如下：
+
+```tsx
+const fetchUserAndCompany = async () => {
+  const response = await fetch(
+    `https://myBackend.com/userAndCompany`,
+  );
+  return JSON.parseImmutable(await response.text());
+};
+```
+
+即利用 Record 提案的 `JSON.parseImmutable` 将后端返回值也转化为 Record，这样即便重新查询，但如果返回结果完全不变，也不会导致重渲染，或者局部变化也只会导致局部重渲染，而目前我们只能放任这种情况下全量重渲染。
+
+然而这对浏览器实现 Record 的新能优化提出了非常严苛的要求，因为假设后端返回的数据有几十 MB，我们不知道这种内置 API 会导致多少的额外开销。
+
+假设浏览器使用非常 Magic 的办法做到了几乎零开销，那么我们应该在任何时候都用 `JSON.parseImmutable` 解析而不是 `JSON.parse`。
+
+### 生成查询参数
+
+也是利用了 `parseImmutable` 方法，让前端可以精确发送请求，而不是每次 `qs.parse` 生成一个新引用就发一次请求：
+
+```tsx
+// This is a non-performant, but working solution.
+// Lib authors should provide a method such as qs.parseRecord(search)
+const parseQueryStringAsRecord = (search) => {
+  const queryStringObject = qs.parse(search);
+  // Note: the Record(obj) conversion function is not recursive
+  // There's a recursive conversion method here:
+  // https://tc39.es/proposal-record-tuple/cookbook/index.html
+  return JSON.parseImmutable(
+    JSON.stringify(queryStringObject),
+  );
+};
+
+const useQueryStringRecord = () => {
+  const { search } = useLocation();
+  return useMemo(() => parseQueryStringAsRecord(search), [
+    search,
+  ]);
+};
+```
+
+还提到一个有趣的点，即到时候配套工具库可能提供类似 `qs.parseRecord(search)` 的方法把 `JSON.parseImmutable` 包装掉，也就是这些生态库想要 “无缝” 接入 Record 提案其实需要做一些 API 改造。
+
+### 避免循环产生的新引用
+
+即便原始对象引用不变，但我们写几行代码随便 `.filter` 一下引用就变了，而且无论返回结果是否变化，引用都一定会改变：
+
+```tsx
+const AllUsers = [
+  { id: 1, name: 'Sebastien' },
+  { id: 2, name: 'John' },
+];
+
+const Parent = () => {
+  const userIdsToHide = useUserIdsToHide();
+  const users = AllUsers.filter(
+    (user) => !userIdsToHide.includes(user.id),
+  );
+  return <UserList users={users} />;
+};
+
+const UserList = React.memo(({ users }) => (
+  <ul>
+    {users.map((user) => (
+      <li key={user.id}>{user.name}</li>
+    ))}
+  </ul>
+));
+```
+
+要避免这个问题就必须 `useMemo`，但在 Record 提案下不需要：
+
+```tsx
+const AllUsers = #[
+  #{ id: 1, name: 'Sebastien' },
+  #{ id: 2, name: 'John' },
+];
+
+const filteredUsers = AllUsers.filter(() => true);
+AllUsers === filteredUsers;
+// true
+```
+
+### 作为 React key
+
+这个想法更有趣，如果 Record 提案保证了引用严格不可变，那我们完全可以拿 `item` 本身作为 `key`，而不需要任何其他手段，这样维护成本会大大降低。
+
+```tsx
+const list = #[
+  #{ country: 'FR', localPhoneNumber: '111111' },
+  #{ country: 'FR', localPhoneNumber: '222222' },
+  #{ country: 'US', localPhoneNumber: '111111' },
+];
+<>
+  {list.map((item) => (
+    <Item key={item} item={item} />
+  ))}
+</>
+```
+
+当然这依然建立在浏览器非常高效实现 Record 的前提，假设浏览器采用 `deepEqual` 作为初稿实现这个规范，那么上面这坨代码可能导致本来不卡的页面直接崩溃退出。
+
+### TS 支持
+
+也许到时候 ts 会支持如下方式定义不可变变量：
+
+```tsx
+const UsersPageContent = ({
+  usersFilters,
+}: {
+  usersFilters: #{nameFilter: string, ageFilter: string}
+}) => {
+  const [users, setUsers] = useState([]);
+  // poor-man's fetch
+  useEffect(() => {
+    fetchUsers(usersFilters).then(setUsers);
+  }, [usersFilters]);
+  return <Users users={users} />;
+};
+```
+
+那我们就可以真的保证 `usersFilters` 是不可变的了。因为在目前阶段，编译时 ts 是完全无法保障变量引用是否会变化。
+
+### 优化 css-in-js
+
+采用 Record 与普通 object 作为 css 属性，对 css-in-js 的区别是什么？
+
+```tsx
+const Component = () => (
+  <div
+    css={#{
+      backgroundColor: 'hotpink',
+    }}
+  >
+    This has a hotpink background.
+  </div>
+);
+```
+
+由于 css-in-js 框架对新的引用会生成新 className，所以如果不主动保障引用不可变，会导致渲染时 className 一直变化，不仅影响调试也影响性能，而 Record 可以避免这个担忧。
+
+## 精读
+
+总结下来，其实 Record 提案并不是解决之前无法解决的问题，而是用更简洁的原生语法解决了复杂逻辑才能解决的问题。这带来的优势主要在于 “不容易写出问题代码了”，或者让 Immutable 在 js 语言的上手成本更低了。
+
+现在看下来这个规范有个严重担忧点就是性能，而 stage2 并没有对浏览器实现性能提出要求，而是给了一些建议，并在 stage4 之前给出具体性能优化建议方案。
+
+其中还是提到了一些具体做法，包括快速判断真假，即对数据结构操作时的优化。
+
+快速判真可以采用类似 hash-cons 快速判断结构相等，可能是将一些关键判断信息存在 hash 表中，进而不需要真的对结构进行递归判断。
+
+快速判假可以通过维护散列表快速判断，或者我觉得也可以用上数据结构一些经典算法，比如布隆过滤器，就是用在高效快速判否场景的。
+
+### Record 降低了哪些心智负担
+
+其实如果应用开发都是 hello world 复杂度，那其实 React 也可以很好的契合 immutable，比如我们给 React 组件传递的 props 都是 boolean、string 或 number：
+
+```tsx
+<ExpensiveChild userName="nick" age={18} isAdmin />;
+```
+
+比如上面的例子，完全不用关心引用会变化，因为我们用的原始类型本身引用就不可能变化，比如 `18` 不可能突变成 `19`，如果子组件真的想要 `19`，那一定只能创建一个新的，总之就是没办法改变我们传递的原始类型。
+
+如果我们永远在这种环境下开发，那 React 结合 immutable 会非常美妙。但好景不长，我们总是要面对对象、数组的场景，然而这些类型在 js 语法里不属于原始类型，我们了解到还有 “引用” 这样一种说法，两个值不一样对象可能是 `===` 全等的。
+
+可以认为，Record 就是把这个顾虑从语法层面消除了，即 `#{ a: 1 }` 也可以看作像 `18`，`19` 一样的数字，不可能有人改变它，所以从语法层面你就会像对 `19` 这个数字一样放心 `#{ a: 1 }` 不会被改变。
+
+当然这个提案面临的最大问题就是 “如何将拥有子结构的类型看作原始类型”，也许 JS 引擎将它看作一种特别的字符串更贴合其原理，但难点是这又违背了整个语言体系对子结构的默认认知，Box 装箱语法尤其别扭。
+
+## 总结
+
+看了这篇文章的畅想，React 与 Records & Tulpes 结合的一定会很好，但前提是浏览器对其性能优化必须与 “引用对比” 大致相同才可以，这也是较为少见，对性能要求如此苛刻的特性，因为如果没有性能的加持，其便捷性将毫无意义。
+
+> 讨论地址是：[精读《Records & Tuples for React》· Issue #385 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/385)
+
+**如果你想参与讨论，请 [点击这里](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)）
+
+

前沿技术/225.精读《Excel JS API》.md

@@ -0,0 +1,103 @@
+Excel 现在可利用 js 根据单元格数据生成图表、表格，或通过 js 拓展自定义函数拓展内置 Excel 表达式。
+
+我们来学习一下 Excel js API 开放是如何设计的，从中学习到一些开放 API 设计经验。
+
+API 文档：[Excel JavaScript API overview](https://docs.microsoft.com/en-us/office/dev/add-ins/reference/overview/excel-add-ins-reference-overview)
+
+## 精读
+
+Excel 将利用 JS API 开放了大量能力，包括用户能通过界面轻松做到的，也包括无法通过界面操作做到的。
+
+### 为什么需要开放 JS API
+
+Excel 已经具备了良好的易用性，以及 [formula](https://support.microsoft.com/en-us/office/overview-of-formulas-in-excel-ecfdc708-9162-49e8-b993-c311f47ca173) 这个强大的公式。在之前 [精读《Microsoft Power Fx》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/211.%E7%B2%BE%E8%AF%BB%E3%80%8AMicrosoft%20Power%20Fx%E3%80%8B.md) 提到过，formula 就是 Excel 里的 Power FX，属于画布低代码语言，不过在 Excel 里叫做 “公式” 更合适。
+
+已经具备这么多能力，为何还需要 JS API 呢？一句话概括就是，在 JS API 内可以使用 formula，即 JS API 是公式能力的超集，它包含了对 Excel 工作簿的增删改查、数据的限制、RangeAreas 操作、图表、透视表，甚至可以自定义 formula 函数。
+
+也就是说，JS API 让 Excel “可编程化”，即以开发者视角对 Excel 进行二次拓展，包括对公式进行二次拓展，使 Excel 覆盖更多场景。
+
+### JS API 可以用在哪些地方
+
+从 Excel 流程中最开始的工作薄、工作表环节，到最细节的单元格数据校验都可通过 JS API 支持，目前看来 Excel JS API 并没有设置能力边界，而且还会不断完善，将 Excel 全生命周期中一切可编程的地方开放出来。
+
+首先是对工作薄、工作表的操作，以及对工作表用户操作的监听，或者对工作表进行只读设置。这一类 API 的目的是对 Excel 这个整体进行编程操作。
+
+第二步就是对单元格级别进行操作，比如对单元格进行区域选中，获取选中区域，或者设置单元格属性、颜色，或者对单元格数据进行校验。自定义公式也在这个环节，因为单元格的值可以是公式，而公式可以利用 JS API 拓展。
+
+最后一步是拓展行为，即在单元格基础上引入图表、透视表拓展。虽然这些功能在 UI 按钮上也可以操作出来，但 JS API 可以实现 UI 界面配置不出来的逻辑，对于非常复杂的逻辑行为，即便 UI 可以配置出来，可读性也远没有代码高。除了表格透视表外、还可以创建一些自定义形状，基本的几何图形、图片和 SVG 都支持。
+
+### JS API 设计
+
+比较有趣的是，Excel 并没有抽象 “单元格” 对象，即便我们所有人都认为单元格就是 Excel 的代表。
+
+这么做是出于 API 设计的合理性，因为 Excel 使用 Range 概念表示连续单元格。比如：
+
+```js
+Excel.run(function (context) {
+    var sheet = context.workbook.worksheets.getActiveWorksheet();
+
+    var headers = [
+      ["Product", "Quantity", "Unit Price", "Totals"]
+    ];
+    var headerRange = sheet.getRange("B2:E2");
+    headerRange.values = headers;
+    headerRange.format.fill.color = "#4472C4";
+    headerRange.format.font.color = "white";
+
+    return context.sync();
+});
+```
+
+可以发现，Range 让 Excel 聚焦在批量单元格 API，即把单元格看做一个范围，整体 API 都可以围绕一个范围去设计。这种设计理念的好处是，把范围局限在单格单元格，就可以覆盖 Cell 概念，而聚焦在多个单元格时，可以很方便的基于二维数据结构创建表格、折线图等分析图形，因为二维结构的数据才是结构化数据。
+
+或者可以说，结构化数据是 Excel 最核心的概念，而单元格无法体现结构化。结构化数据的好处是，一张工作表就是一个可以用来分析的数据集，在其之上无论是基于单元格的条件格式，还是创建分析图表，都是一种数据二次分析行为，这都得益于结构化数据，所以 Excel JS API 必然围绕结构化数据进行抽象。
+
+再从 API 语法来看，除了工作薄这个级别的 API 采用了 `Excel.createWorkbook();` 之外，其他大部分 API 都是以下形式：
+
+```js
+Excel.run(function (context) {
+    // var sheet = context.workbook.worksheets.getItem("Sample");
+    // 对 sheet 操作 ..
+    return context.sync();
+});
+```
+
+最外层的函数 `Excel.run` 是注入 `context` 用的，而且也可以保证执行的时候 Excel context 已经准备好了。而 `context.sync()` 是同步操作，即使当前对 context 的操作生效。所以 Excel JS API 是命令式的，也不会做类似 MVVM 的双向绑定，所以在操作过程中数据和 Excel 状态不会发生变化，直到执行 `context.sync()`。
+
+注意到这点后，就可以理解为什么要把某些代码写在 `context.sync().then` 里了，比如：
+
+```js
+Excel.run(function (ctx) {
+  var pivotTable = context.workbook.worksheets.getActiveWorksheet().pivotTables.getItem("Farm Sales");
+
+  // Get the totals for each data hierarchy from the layout.
+  var range = pivotTable.layout.getDataBodyRange();
+  var grandTotalRange = range.getLastRow();
+  grandTotalRange.load("address");
+  return context.sync().then(function () {
+    // Sum the totals from the PivotTable data hierarchies and place them in a new range, outside of the PivotTable.
+    var masterTotalRange = context.workbook.worksheets.getActiveWorksheet().getRange("E30");
+    masterTotalRange.formulas = [["=SUM(" + grandTotalRange.address + ")"]];
+  });
+}).catch(errorHandlerFunction);
+```
+
+这个从透视表获取数据的例子，只有执行 `context.sync()` 后才能拿到 `grandTotalRange.address`。
+
+## 总结
+
+微软还在 Office 套件 Excel、Outlook、Word 中推出了 [ScriptLab](https://docs.microsoft.com/zh-cn/office/dev/add-ins/overview/explore-with-script-lab) 功能，就可以在 Excel 的 ScriptLab 里编写 Excel JS API。
+
+在 Excel JS API 之上，还有一个 [通用 API](https://docs.microsoft.com/zh-cn/javascript/api/office?view=common-js-preview)，定义为跨应用的通用 API，这样 Excel JS API 就可以把精力聚焦在 Excel 产品本身能力上。
+
+> 讨论地址是：[精读《Excel JS API》· Issue #387 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/387)
+
+**如果你想参与讨论，请 [点击这里](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)）
+
+

前沿技术/226.精读《2021 前端新秀回顾》.md

@@ -0,0 +1,166 @@
+[2021 JavaScript Rising Stars](https://risingstars.js.org/2021/en) 每年都会对前端开源项目进行点评，其依据是去年 Star 的增幅。Star 虽然只是一个维度，但至少反应了流行度，根据这个排行榜可以大体分析出前端社区的趋势。
+
+## 精读
+
+该榜单包含整体榜单、前端框架、Node 框架、构建工具、Vue 生态、React 生态、CSS-In-JS、测试、移动端、桌面、静态建站、状态管理、GraphQL 共 13 个子榜单，都是前端开源最活跃的几个领域，下面分别介绍。
+
+### 整体榜单
+
+第一名 [zx](https://github.com/google/zx) 是一个命令行工具，它基于 Node 语法拓展了 Bash 支持，可以非常方便的进行 Node 与 Bash 之间的输入输出，就像 Node 原生就支持 Bash 一样。它解决了离不开 Bash，但 Bash 写起大段逻辑不如 Node 自然的痛点。
+
+第二名 [vite](https://github.com/vitejs/vite) 是去年最闪耀的星，它是一个 bundless 概念的前端构建工具，最初服务于 vue，后来进行框架无关升级后，在 react、angular 生态都大受欢迎。它解决了 webpack 编译太慢，其他 bundless 方案不够开箱即用且存在大量兼容问题的痛点。
+
+第三名 [next.js](https://github.com/vercel/next.js) 2016 年开始的项目，是一个大而全的 React 全家桶，定位就是各大厂都会自己做一套的前端一体化框架，但它更时髦，不断加入许多流行功能比如 Server Component。这和 next.js 所在的明星公司 Vercel 有关，这家公司挖了大量开源知名人物，包括 Svelte 作者与 React 团队核心成员，所以也许未来社区的新玩具会先用在 next.js 再独立开源。它给出了前端最佳实践，并解决了没有精力持续给项目进行全方位优化，或追逐不上潮流的问题，因为 next.js 本身正在成为前端潮流的发源地。
+
+第四名 [react](https://github.com/facebook/react) 不用多说了，数据驱动、响应式编程、函数式的领军框架，它改变了前端开发效率。
+
+第五名 [tauri](https://github.com/tauri-apps/tauri) 比 electron 更轻量的桌面应用开发框架，基于任何前端框架。它解决了前端开发者遇到桌面应用开发场景时各平台巨大的原生开发学习成本的痛点。
+
+第六名 [Tailwind CSS](https://github.com/tailwindlabs/tailwindcss) 是 css 框架，它提供了大量语义化 className，提供了许多最佳实践，让你有机会把 css 打理的井然有序。它解决了前端项目 css 杂乱无章又没有人真的在意的痛点。
+
+第七名 [vscode](https://github.com/microsoft/vscode) 宇宙级 IDE，它解决了程序员没有真正趁手软件写代码的痛点。
+
+第八名 [Slidev](https://github.com/slidevjs/slidev) 是一个把 markdown 渲染成 PPT 的框架，基于 vite + vue 等技术栈开发。用它开发的 PPT 非常简洁美观，非常适合在公开场合分享时使用，不仅看起来赏心悦目，还可以不经意间切换到 Markdown 源码 hotfix 一下小错误，展示出你的极客精神。它解决了你真的只想展示几句话，但又要以 PPT 方式 show 出来的痛点。
+
+第九名 [NocoDB](https://github.com/nocodb/nocodb) 是一个支持多种数据源的数据库 UI 管理工具。但其实它有更大的格局，即对标 [airtable](https://www.airtable.com/)，即用 NocoDB 连接数据库后，一切数据可视化的操作与功能都成为了可能，且提供了大量工作常用的甘特图、电子表格等视图，并可互相转换，最终其实数据存储到连接的数据库，但你无需关心细节。它解决了基于二维表格数据开发各类生产工具需投入大量研发资源的痛点。
+
+第十名 [Vue](https://github.com/vuejs/vue) 和 React 一样不多说了。
+
+### 前端框架
+
+第一名 [react](https://github.com/facebook/react) 在整体榜单里了。
+
+第二名 [Vue](https://github.com/vuejs/vue) 也在整体榜单里了。
+
+第三名 [svelte](https://github.com/sveltejs/svelte) 是一个类似 vue 的框架，但特色是极度重视编译时，而忽略运行时，即运行时除了必要逻辑外是完全不引入任何 runtime 框架的。说实话我觉得和 vue、react 相比在正儿八经项目中并没有核心优势，因为它并没有那种魔法能力，可以极大的减少大型项目体积与提升性能，反而会受制于其语法与编译时的特性产生副作用。但唯一一个好处是框架无关，即利用 svelte 编译的组件几乎没有额外运行时框架代码，可以最低成本，最大隔离性的与其他项目结合。
+
+第四名 [angular](https://github.com/angular/angular) 笔者已经很久没有关注 angular 框架了，无法给出什么点评。但从 svelte 新增热度超过 angular 来看，可能大部分开发者对 angular 的态度和我一样。
+
+第五名 [solid](https://github.com/solidjs/solid) 类似 svelte，提前编译，按需打包，重要的是，其类似 React `useEffect` 的 API `createEffect` 在依赖变化后，仅该函数会重新执行，而不会导致整个组件重新执行，在点对点更新上做得更极致。
+
+前端框架的亮点是 svelte 与 solid 的概念，即重编译时，轻运行时，更加原子化的更新粒度，与更直接的调用原生浏览器方法带来性能提升。很难不让人觉得这是一个前端框架新趋势，但我翻了不少资料发现，这种创新带来的收益在正常项目里微乎其微，所以实际上 2021 年前端框架还是没能跳出三巨头创造新的概念，而以 svelte 与 solid 为代表的 “静态化” 框架只能算微创新。
+
+### Node 框架
+
+第一名 [next.js](https://github.com/vercel/next.js) 在整体榜单里了，在 Node 框架一骑绝尘。
+
+第二名 [nest](https://github.com/nestjs/nest) 和 next.js 很像，据我当时的了解，是因为 next.js 起步较慢，源码还不支持 ts，所以就有了这个更时髦的新框架。但实际上 next.js 早就全部改为 ts 了，而且正如整体榜单所说，现在已经开始引领潮流了，所以不怪 nest 定位重合，只能怪 next.js 后续发力太猛了。nest 的唯一特点就是没有绑定 UI 库。
+
+第三名 [Strapi](https://github.com/strapi/strapi) 专门为 API 场景服务，提供了一个 API 管理后台，解决了只需要一个便捷 API 管理，而不希望了解一个大而全的后端框架的痛点。
+
+第四名 [remix](https://github.com/remix-run/remix) 其实和 next.js 定位差不多，由 react-router 作者开发，才开源不久，需要进一步观察。
+
+第五名 [nuxt.js](https://github.com/nuxt/nuxt.js) 是 vue 领域的 next.js。
+
+值得一提的是，svelte 也有自己的专属框架 [sveltekit](https://kit.svelte.dev/)，所以 Node 后端框架之争大部分其实在打全栈的牌，毕竟 Node 的优势就是支持 js 语言，而当前端应用基于某个框架编写时，如果有一个 Node 框架可以无缝集成这个前端框架，它就比非 Node 框架更优。
+
+不过大厂几乎都是前后端分离的，所以这种全栈优势框架在国内没有太多出场机会，如果你是一个个人博主，还是首推使用全栈框架建站。
+
+### 构建工具
+
+第一名 [vite](https://github.com/vitejs/vite) 在整体榜单里了，在构建工具里也是一骑绝尘。
+
+第二名 [esbuild](https://github.com/evanw/esbuild) 是用 go 编写的构建工具，适用使用范围更广，其压缩模块在 bundless 还未成熟时就被各大构建全家桶提前集成了，而 vite 也是基于 esbuild 进行编译的，但 vite 的火热度更高，说明了整体 bundless 方案已在 2021 年成熟了。
+
+第三名 [swc](https://github.com/swc-project/swc) 因采用 rust 编写而知名，类似 esbuild，但因为依托 rust 编译到 wasm 的特性，支持了在线编译器，非常方便。swc 还被大量新生代构建工具作为基建，这在 [精读《Rust 是 JS 基建的未来》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/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) 时提到过。
+
+第四名 [turborepo](https://github.com/vercel/turborepo) 是用 go 写的 monorepo 项目管理工具，是 lerna 的替代品。
+
+第五名 [nx](https://github.com/nrwl/nx) 也是一个 monorepo 管理工具。
+
+与框架不同，构建工具往往呈现套娃结构，不是你中有我，就是我中有你，每个热门库都重点解决某一块关键问题，不断套娃套娃，最后套成一个很棒的全家桶。
+
+### Vue 生态
+
+第一名 [Slidev](https://github.com/slidevjs/slidev) 在整体榜单里了。
+
+第二名 [Vue Element Admin](https://github.com/PanJiaChen/vue-element-admin) 基于 vue 的管理后台，在权限验证有一些最佳实践，使用 vuex 管理状态。
+
+第三名 [Headless UI](https://github.com/tailwindlabs/headlessui) 是一个完全无样式的基础组件库，支持 React 与 Vue，官网的例子都是利用 [Tailwind CSS](https://github.com/tailwindlabs/tailwindcss) 内置样式组合而成的。它解决了 UI 组件库绑定样式后，自定义样式 “实际上非常恶心” 的痛点。
+
+第四名 [Naive UI](https://github.com/TuSimple/naive-ui) 是一个 Vue 组件库，没有太多特别之处，但竟然上了排行榜。看了一下 star 趋势，在 2021.6 月份 star 涨幅是之后的十倍，估计刚开源推广了一波，后续涨幅很慢了，不出意外明年会跌出这个榜单。
+
+第五名 [vue-next](https://github.com/vuejs/vue-next) 即 vue3，star 数量只有 vue2 的 13%，但今年 star 增幅有 vue2 的一半。
+
+vue3 还自带了状态管理库 [pinia](https://github.com/vuejs/pinia)，其生态已经非常完备。
+
+### React 生态
+
+第一名 [next.js](https://github.com/vercel/next.js) 在整体榜单里了。
+
+第二名 [Ant Design](https://github.com/ant-design/ant-design) 虽然立志成为西湖区最好的 React 组件库，但事实上已经成为了全球最好的 React 组件库。
+
+第三名 [MUI](https://github.com/mui-org/material-ui) 就是大名鼎鼎的 material design UI 组件库，我对它影响最深的是按钮点击后出现的水波纹，这是 material design 的一大特色。早在 2014 年就创建了，在 Ant Design 没火的时候，是开源组件库首选。
+
+第四名 [remix](https://github.com/remix-run/remix) 在 Node 框架榜单里了，和 next.js 一样，是绑定了 React 生态的 Node 框架，所以也出现在 React 生态中。
+
+第五名 [react-use](https://github.com/streamich/react-use) 是很小巧的 React Hook 库，提供了如 `usePrevious`、`useDebounce` 等常用的 Hook。
+
+看完整个 React 生态榜单，无论是优质生态库数量，还是去年增长的 Star 数，都比 Vue 生态更胜一筹。这背后是无副作用的纯函数与自动依赖收集的响应式视图之争，甚至在 React 生态里也有比如 mobx-react 等优质 MVVM 库，这两种编程范式都会长期并存。
+
+### CSS-In-JS
+
+第一名 [vanilla-extract](https://github.com/seek-oss/vanilla-extract) 作为 2021 年的黑马，主打零运行时与 TS 支持。零运行时是通过 @vanilla-extract/webpack-plugin 插件在编译时就完成内容输出。
+
+第二名 [styled-components](https://github.com/styled-components/styled-components) 是推出最早，也最成熟的一个 CSS-In-JS 框架，虽然版本间出现过运行时不兼容让我放弃过，但不得不说是这个方向的鼻祖。
+
+第三名 [stitches](https://github.com/modulz/stitches) 和第一名很像，也主打零运行时，不过没有提对 TS 是否友好。
+
+第四名 [Twin](https://github.com/ben-rogerson/twin.macro) 基于 [Tailwind CSS](https://github.com/tailwindlabs/tailwindcss) 实现了 CSS-In-JS 版的语法，可以认为是内置了一套最佳实践的 CSS-In-JS 库，也没解决太大的痛点，只是如果你同时喜欢 Tailwind CSS 与 CSS-In-JS，可能会爱屋及乌的选择 Twin。
+
+第五名 [Emotion](https://github.com/emotion-js/emotion) 也是一个相对完备的库，基本上 CSS-In-JS 各类语法都能支持。
+
+相比传统 CSS-In-JS 库，第一名 vanilla-extract 的零运行时是一大亮点，是这个方向的新趋势。
+
+### 测试
+
+第一名 [Playwright](https://github.com/microsoft/playwright) 是一个跨浏览器跨平台的测试框架，可以利用 js 代码打开任意 url 地址截图或者对比，解决了搭建自动化测试平台需要从零开始编写底层框架的痛点。
+
+第二名 [Storybook](https://github.com/storybookjs/storybook) 是非常有名的文档工具，很多开源组件、项目的文档都基于 Storybook 创建。神奇的是它还支持[单元测试](https://storybook.js.org/docs/react/writing-tests/introduction)，在你访问 UI 组件时进行测试并打印出测试结果。Storybook 已经变成了一个 all-in-one 的组件开发工具。
+
+第三名 [Cypress](https://github.com/cypress-io/cypress) 与 Playwright 且诞生比较早，但由于不支持多 tab 页面，且仅支持 js，所以仅在前端流行，在测试工程师角度却不如支持多语言的 Playwright 好用。
+
+第四名 [Puppeteer](https://github.com/puppeteer/puppeteer) 是 2017 年谷歌推出基于 Chrome 无头浏览器的测试工具，但 2020 年微软的 Playwright 具有跨浏览器特性还是更胜一筹。
+
+第五名 [Jest](https://github.com/facebook/jest) 是代码级别单测工具的佼佼者，覆盖了全框架，只要你想对代码进行单元测试，选 Jest 是不会错的。
+
+测试框架围绕单测与浏览器测试这两个子领域，2021 年在浏览器测试领域出现了跨浏览器这个特色方向，在单测领域没有太大变化，顶多出了一个 [Vitest](https://github.com/vitest-dev/vitest) 让单测跑得更快，这个库在 2022 年稳定后可能会大放异彩，甚至可能因为 Vite 流行的原因取代 Jest。
+
+### 移动端
+
+第一名 [ReactNative](https://github.com/facebook/react-native) 是基于 React 的 Mobile Native 开发框架，笔者用过一段时间，只能说不能抱有太大期待，因为极大的局限了 web 语法，如果你觉得仅掌握前端知识就可以轻松使用，那么一定会让你失望，不要一开始就抱着这种期待。另外跨端真是非常痛，比如 `SwitchAndroid`、`SwitchIOS` 让你感受不到 Write Once, Run everywhere（虽然官方也没这么说）。
+
+第二名 [Ionic](https://github.com/ionic-team/ionic-framework) 是一个跨前端框架的跨平台构建工具，解决了 ReactNative 无法 Run everywhere 的痛点，但也带来了不够灵活的问题，即无法使用平台特定特性。
+
+第三名 [Expo](https://github.com/expo/expo) 是基于 ReactNative 的一站式跨端开发工具，它的 App 使用非常傻瓜化，并且内置了调试能力，可以说是把 ReactNative 要踩的坑帮你踩完了。
+
+第四名 [Quasar](https://github.com/quasarframework/quasar) 可以认为是 Vue 版的 ReactNative。
+
+第五名 [Flipper](https://github.com/facebook/flipper) 是一个 Native 应用调试工具，可以认为是手机应用版本的 Chrome DevTools，支持连接远程终端，解决了手机应用难以用电脑调试的痛点。
+
+其实还少了 [Flutter](https://github.com/flutter/flutter) 这个优秀框架，虽然不属于前端方向，但就像前端脚手架越来越多用 Rust、Go 写一样，Native 用 Dart 也是可以接受的。
+
+从前端角度看移动端，唯一需求就是 Write Once，Run Anywhere，然后再把调试体验做好一些，Native 的兼容性、拓展性做强一些，就是一个完美方案了。
+
+说到跨端，基于 Flutter 的 [kraken](https://github.com/openkraken/kraken) 也绝对值得一提，它利用 Flutter 高一执行渲染层能力，并解决了 Dart 生态对前端不友好的问题，做了一个 html+css+js 到 dart 的桥接层，如果明年可以在手淘稳定覆盖大量场景，那一定是个值得考虑的方案。
+
+## 总结
+
+还有更多榜单就不一一总结了，如果觉得不过瘾，可以去 [2021 JavaScript Rising Stars](https://risingstars.js.org/2021/en) 翻翻这些 top star 项目的介绍和源码深入了解一下。
+
+最后总结一下 2021 前端领域的几个关键特征：
+
+- 编程语言全面开花。以后 JS 开发者不等于前端开发者了，因为 Go、Rust、Dart、C++ 语言都可以为前端服务，并且 2021 年是真的有不少场景做到了生产环境可用，不论我们接不接受，前端不止有 JS 一种语言了。
+- 前端开发全家桶逐渐产生技术壁垒。在前几年，抄一个前端全家桶很容易，在过程中还可以学到很多底层知识，但现在前端全家桶的积累越来越多，涉及的领域越来越广，甚至 next.js 引入的特性会超越你自己调制的全家桶，这说明全家桶的知识量已经逐渐达到个人知识广度的极限，如果你没有足够精力持续学习，跟进时代步伐的最好方式是使用一个成熟的全家桶。
+
+> 讨论地址是：[精读《2021 前端新秀回顾》· Issue #390 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/390)
+
+**如果你想参与讨论，请 [点击这里](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)）
+
+

前沿技术/228.精读《pipe operator for JavaScript》.md

@@ -0,0 +1,306 @@
+[Pipe Operator (|>) for JavaScript](https://github.com/tc39/proposal-pipeline-operator#tacit-unary-function-application-syntax) 提案给 js 增加了 Pipe 语法，这次结合 [A pipe operator for JavaScript: introduction and use cases](https://2ality.com/2022/01/pipe-operator.html) 文章一起深入了解这个提案。
+
+## 概述
+
+Pipe 语法可以将函数调用按顺序打平。如下方函数，存在三层嵌套，但我们解读时需要由内而外阅读，因为调用顺序是由内而外的：
+
+```js
+const y = h(g(f(x)))
+```
+
+Pipe 可以将其转化为正常顺序：
+
+```js
+const y = x |> f(%) |> g(%) |> h(%)
+```
+
+Pipe 语法有两种风格，分别来自 Microsoft 的 [F#](https://en.wikipedia.org/wiki/F_Sharp_(programming_language)) 与 Facebook 的 [Hack](https://en.wikipedia.org/wiki/Hack_(programming_language))。
+
+之所以介绍这两个，是因为 js 提案首先要决定 “借鉴” 哪种风格。js 提案最终采用了 Hack 风格，因此我们最好把 F# 与 Hack 的风格都了解一下，并对其优劣做一个对比，才能知其所以然。
+
+### Hack Pipe 语法
+
+Hack 语法相对冗余，在 Pipe 时使用 `%` 传递结果：
+
+```js
+'123.45' |> Number(%)
+```
+
+这个 `%` 可以用在任何地方，基本上原生 js 语法都支持：
+
+```js
+value |> someFunction(1, %, 3) // function calls
+value |> %.someMethod() // method call
+value |> % + 1 // operator
+value |> [%, 'b', 'c'] // Array literal
+value |> {someProp: %} // object literal
+value |> await % // awaiting a Promise
+value |> (yield %) // yielding a generator value
+```
+
+### F# Pipe 语法
+
+F# 语法相对精简，默认不使用额外符号：
+
+```js
+'123.45' |> Number
+```
+
+但在需要显式声明参数时，为了解决上一个 Pipe 结果符号从哪来的问题，写起来反而更为复杂：
+
+```js
+2 |> $ => add2(1, $)
+```
+
+### await 关键字 - Hack 优
+
+F# 在 `await` `yield` 时需要特殊语法支持，而 Hack 可以自然的使用 js 内置关键字。
+
+```js
+// Hack
+value |> await %
+// F#
+value |> await
+```
+
+F# 代码看上去很精简，但实际上付出了高昂的代价 - `await` 是一个仅在 Pipe 语法存在的关键字，而非普通 `await` 关键字。如果不作为关键字处理，执行逻辑就变成了 `await(value)` 而不是 `await value`。
+
+### 解构 - F# 优
+
+正因为 F# 繁琐的变量声明，反而使得在应对解构场景时得心应手：
+
+```js
+// F#
+value |> ({ a, b }) => someFunction(a, b)
+// Hack
+value |> someFunction(%.a, %.b)
+```
+
+Hack 也不是没有解构手段，只是比较繁琐。要么使用立即调用函数表达式 IIFE：
+
+```js
+value |> (({ a, b }) => someFunction(a, b))(%)
+```
+
+要么使用 `do` 关键字：
+
+```js
+value |> do { const { a, b } = %; someFunction(a, b) }
+```
+
+但 Hack 虽败犹荣，因为解决方法都使用了 js 原生提供的语法，所以反而体现出与 js 已有生态亲和性更强，而 F# 之所以能优雅解决，全都归功于自创的语法，这些语法虽然甜，但割裂了 js 生态，这是 F# like 提案被放弃的重要原因之一。
+
+### 潜在改进方案
+
+虽然选择了 Hack 风格，但 F# 与 Hack 各有优劣，所以列了几点优化方案。
+
+#### 利用 Partial Application Syntax 提案降低 F# 传参复杂度
+
+F# 被诟病的一个原因是传参不如 Hack 简单：
+
+```js
+// Hack
+2 |> add2(1, %)
+// F#
+2 |> $ => add2(1, $)
+```
+
+但如果利用处于 stage1 的提案 [Partial Application Syntax](https://github.com/tc39/proposal-partial-application) 可以很好的解决问题。
+
+这里就要做一个小插曲了。js 对柯里化没有原生支持，但 [Partial Application Syntax](https://github.com/tc39/proposal-partial-application) 提案解决了这个问题，语法如下：
+
+```js
+const add = (x, y) => x + y;
+const addOne = add~(1, ?);
+addOne(2); // 3
+```
+
+即利用 `fn~(?, arg)` 的语法，将任意函数柯里化。这个特性解决 F# 传参复杂问题简直绝配，因为 F# 的每一个 Pipe 都要求是一个函数，我们可以将要传参的地方记为 `?`,这样返回值还是一个函数，完美符合 F# 的语法：
+
+```js
+// F#
+2 |> add~(1, ?)
+```
+
+上面的例子拆开看就是：
+
+```js
+const addOne = add~(1, ?)
+2 |> addOne
+```
+
+想法很美好，但 [Partial Application Syntax](https://github.com/tc39/proposal-partial-application) 得先落地。
+
+#### 融合 F# 与 Hack 语法
+
+在简单情况下使用 F#，需要利用 `%` 传参时使用 Hack 语法，两者混合在一起写就是：
+
+```js
+const resultArray = inputArray
+  |> filter(%, str => str.length >= 0) // Hack
+  |> map(%, str => '['+str+']') // Hack
+  |> console.log // F#
+```
+
+不过这个 [提案](https://github.com/tc39/proposal-smart-pipelines) 被废弃了。
+
+#### 创造一个新的操作符
+
+如果用 `|>` 表示 Hack 语法，用 `|>>` 表示 F# 语法呢？
+
+```js
+const resultArray = inputArray
+  |> filter(%, str => str.length >= 0) // Hack
+  |> map(%, str => '['+str+']') // Hack
+  |>> console.log // F#
+```
+
+也是看上去很美好，但这个特性连提案都还没有。
+
+### 如何用现有语法模拟 Pipe
+
+即便没有 [Pipe Operator (|>) for JavaScript](https://github.com/tc39/proposal-pipeline-operator#tacit-unary-function-application-syntax) 提案，也可以利用 js 现有语法模拟 Pipe 效果，以下是几种方案。
+
+#### Function.pipe()
+
+利用自定义函数构造 pipe 方法，该语法与 F# 比较像：
+
+```js
+const resultSet = Function.pipe(
+  inputSet,
+  $ => filter($, x => x >= 0)
+  $ => map($, x => x * 2)
+  $ => new Set($)
+)
+```
+
+缺点是不支持 `await`，且存在额外函数调用。
+
+#### 使用中间变量
+
+说白了就是把 Pipe 过程拆开，一步步来写：
+
+```js
+const filtered = filter(inputSet, x => x >= 0)
+const mapped = map(filtered, x => x * 2)
+const resultSet = new Set(mapped)
+```
+
+没什么大问题，就是比较冗余，本来可能一行能解决的问题变成了三行，而且还声明了三个中间变量。
+
+#### 复用变量
+
+改造一下，将中间变量变成复用的：
+
+```js
+let $ = inputSet
+$ = filter($, x => x >= 0)
+$ = map($, x => x * 2)
+const resultSet = new Set($)
+```
+
+这样做可能存在变量污染，可使用 IIFE 解决。
+
+## 精读
+
+Pipe Operator 语义价值非常明显，甚至可以改变编程的思维方式，在串行处理数据时非常重要，因此命令行场景非常常见，如：
+
+```bash
+cat "somefile.txt" | echo
+```
+
+因为命令行就是典型的输入输出场景，而且大部分都是单输入、单输出。
+
+在普通代码场景，特别是处理数据时也需要这个特性，大部分具有抽象思维的代码都进行了各种类型的管道抽象，比如：
+
+```js
+const newValue = pipe(
+  value,
+  doSomething1,
+  doSomething2,
+  doSomething3
+)
+```
+
+如果 [Pipe Operator (|>) for JavaScript](https://github.com/tc39/proposal-pipeline-operator#tacit-unary-function-application-syntax) 提案通过，我们就不需要任何库实现 pipe 动作，可以直接写成：
+
+```js
+const newValue = value |> doSomething1(%) |> doSomething2(%) |> doSomething3(%)
+```
+
+这等价于：
+
+```js
+const newValue = doSomething3(doSomething2(doSomething1(value)))
+```
+
+显然，利用 pipe 特性书写处理流程更为直观，执行逻辑与阅读逻辑是一致的。
+
+### 实现 pipe 函数
+
+即便没有 [Pipe Operator (|>) for JavaScript](https://github.com/tc39/proposal-pipeline-operator#tacit-unary-function-application-syntax) 提案，我们也可以一行实现 pipe 函数：
+
+```js
+const pipe = (...args) => args.reduce((acc, el) => el(acc))
+```
+
+但要实现 Hack 参数风格是不可能的，顶多实现 F# 参数风格。
+
+### js 实现 pipe 语法的考虑
+
+从 [提案](https://github.com/tc39/proposal-pipeline-operator#tc39-has-rejected-f-pipes-multiple-times) 记录来看，F# 失败有三个原因：
+
+- 内存性能问题。
+- `await` 特殊语法。
+- 割裂 js 生态。
+
+其中割裂 js 生态是指因 F# 语法的特殊性，如果有太多库按照其语法实现功能，可能导致无法被非 Pipe 语法场景所复用。
+
+甚至还有部分成员反对 [隐性编程(Tacit programming)](https://en.wikipedia.org/wiki/Tacit_programming)，以及柯里化提案 [Partial Application Syntax](https://github.com/tc39/proposal-partial-application)，这些会使 js 支持的编程风格与现在差异过大。
+
+看来处于鄙视链顶端的编程风格在 js 是否支持不是能不能的问题，而是想不想的问题。
+
+### pipe 语法的弊端
+
+下面是普通 `setState` 语法：
+
+```ts
+setState(state => ({
+  ...state,
+  value: 123
+}))
+```
+
+如果改为 `immer` 写法如下：
+
+```ts
+setState(produce(draft => draft.value = 123))
+```
+
+得益于 ts 类型自动推导，在内层 `produce` 里就已经知道 `value` 是数值类型，此时如果输入字符串会报错，而如果其在另一个上下文的 `setState` 内，类型也会随着上下文的变化而变化。
+
+但如果写成 pipe 模式：
+
+```ts
+produce(draft => draft.value = 123) |> setState
+```
+
+因为先考虑的是如何修改数据，此时还不知道后面的 pipe 流程是什么，所以 `draft` 的类型无法确定。所以 pipe 语法仅适用于固定类型的数据处理流程。
+
+## 总结
+
+pipe 直译为管道，潜在含义是 “数据像流水线一样被处理”，也可以形象理解为每个函数就是一个不同的管道，显然下一个管道要处理上一个管道的数据，并将结果输出到下一个管道作为输入。
+
+合适的管道数量与体积决定了一条生产线是否高效，过多的管道类型反而会使流水线零散而杂乱，过少的管道会让流水线笨重不易拓展，这是工作中最大的考验。
+
+> 讨论地址是：[精读《pipe operator for JavaScript》· Issue #395 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/395)
+
+**如果你想参与讨论，请 [点击这里](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)）
+
+

前沿技术/230.精读《对 Markdown 的思考》.md

@@ -0,0 +1,143 @@
+Markdown 即便在 2022 年也非常常用，比如这篇文章依然采用 Markdown 编写。
+
+但 Markdown 是否应该成为文本编辑领域的默认技术选型呢？答案是否定的。我找到了一篇批判无脑使用 Markdown 作为技术选型的好文 [Thoughts On Markdown](https://www.smashingmagazine.com/2022/02/thoughts-on-markdown/)，它提到 Markdown 在标准化、结构化、组件化都存在硬伤，如果你真的想做一个现代化的文本结构编辑器，不要采用 Markdown。
+
+## 概述
+
+Markdown 流传甚广，甚至已成为我们的第二语言。Markdown 最早的解析器由 John Gruber 在 2004 年基于 Perl 编写发布，那时候 Markdown 只有一个目的，即为了方便网络写作。
+
+网络写作必须基于 HTML 规范，而 HTML 规范对大部分人上手成本太高，因此 Markdown 就是基于文本创建的更易理解，或者说上手成本更低，甚至傻瓜化的一种语法，而要解析这个语法需要配套一个解析器，将这种语法文本最终转化为 HTML。
+
+而数字化发展到今天，Markdown 已不再适合当下的写作场景了，主要原因有二：
+
+1. Markdown 不再适合当下富交互、内容形态的编写。
+2. Markdown 纯文本的开发体验不再满足当代开发者日益提高的体验需求。
+
+首先还是从 Markdown 思想开始介绍。
+
+### Markdown 的核心思想
+
+Markdown 最大优势就是好上手，不需要接触 HTML 这种复杂的嵌套语句（虽然对程序员来说 HTML 也简单到处于鄙视链底端）。原文抽象了三个优势：
+
+1. 基于文本的合适抽象。虽然 HTML 甚至代码都是文本，但 “合适” 这个词很重要，即任何文本都可以是 Markdown，只要加一点点小标记就能描述专业结构，学习成本极低。
+2. 有大量生态工具。比如语法解析器、高亮、格式转换、格式化、渲染等工具完备。
+3. 编辑内容便于维护。比如 Markdown 很方便作为源码存储，而其他格式的富文本可能并不方便在源码里维护。
+
+如果把 Markdown 与数据库表结构做比较，那数据库的理解成本真是太高了。
+
+但是在如今后端即服务的时代，数据库访问越来越轻松，甚至出现大量如 AirTable 等 SAAS 产品将结构化数据快速转化为应用，其实接触了这些后才真正发现，结构化数据对开发者有多重要。Markdown 用来写写文章还是不错的，但用来表达逻辑结构最后一定会引发灾难后果，原文作者的团队就深受 Markdown 技术选型的困扰，被迫解决大量远超预期的难题。
+
+如果真的要在 Markdown 的坑越走越深，就必须使用语法拓展来满足自定义诉求。
+
+### Markdown 语法拓展
+
+最初 Markdown 语法是不支持表格的，如果想用 Markdown 绘制一张表格，只能使用原生 HTML 标签：`<table></table>`，当然，这也说明了 Markdown 本质就是给 HTML 加强了便捷的语法，我们完全可以将其当 HTML 使用。
+
+然而并不是所有创作平台都支持 `<table></table>` 语法的，笔者自己就经常受到困扰，比如有些平台会屏蔽原生 HTML 语法，已保障所谓的 “安全性” 或者内容体验的 “一致性”，而这些平台为了弥补缺失的绘制表格能力，往往会支持一些自定义语法，更糟糕的是不支持，这就说到了 Markdown 的语法拓展。
+
+Markdown 有哪些拓展呢？比如：[multiMarkdown](https://fletcherpenney.net/multimarkdown/)、[commonMark](https://commonmark.org/)、[Github Flavored Markdown](https://docs.github.com/en/get-started/writing-on-github) 等等。
+
+这里随便举个例子，比如标准 MD 格式，其实第一行最后要加两个空格才能换行，但 GFM 取消了这个限制。这虽然更方便了，但暴露出平台间规范的不一致性，导致 Markdown 跨平台基本一定被坑。
+
+而各平台拓展的语法，我们是否有足够的精力学习和记忆呢？先不说能不能记得下来，首先值不值得学习就是个问题，为什么一个网络写作平台需要占用写手学习与认知成本，而不是想办法去简化写作流程呢？所以语法拓展看似很美好，但放在写手角度，或者整个互联网各平台林立的角度来看，这种非标准的做法一定不靠谱，没有用户觉得你的平台有资格 “教他语法”，除非你是微信，钉钉或者飞书。
+
+原文提到的观点是：
+
+1. 作为写手，你不知道 Markdown 哪些语法可用，哪些语法不可用。
+2. 标准规范存在一些 [模糊地带](https://johnmacfarlane.net/babelmark2/faq.html#what-is-this-for) 导致开发者实现时也会遇到各种纠结。
+
+原文还提到一个语法拓展导致理解成本增高的例子：slack 平台自定义的 [mrkdown](https://api.slack.com/reference/surfaces/formatting#basics) 就不支持 `[link](https://slack.com)` 方式描述链接，而使用了 `<link|https://slack.com>` 语法。
+
+总结来说，Markdown 语法拓展本应该是件好事，但实际无标准导致了标准的百花齐放，使 Markdown 成为了实际上没有标准的状态，整体来看弊端更多。
+
+### Markdown 面向的用户群
+
+Markdown 的对自己的定位其实很不清晰，这也导致了一直不想确定标准化语法。
+
+最初 Markdown 是服务给熟悉 HTML 的人提供的标记语言，而后来面向用户群实质上转向了开发者，因为开发者才会想到拓展语法以满足更复杂的使用场景，Markdown 原生语法无法适应越来越复杂的视觉展示形态。
+
+如今 Markdown 的主要用户已经是开发人员与对代码感兴趣的人了，这倒不是说开发者有多喜欢它，而是在说 Markdown 的受众变窄了。如今任何一款面向非开发者群体的文档编辑器都不会采用 Markdown 了，而是所见即所得的 WYSIWYG（what you see is what you want）模式。
+
+这个转变的过程是痛苦的，但现在来看，富文本编辑器不应用用 Markdown 语法，而是 WYSIWYG 模式已经是共识了。
+
+### 从段落到区块、从文章到应用
+
+简单来说，即 Markdown 已经不适应当前 HTML 丰富的生态了，能轻松描述段落的标记语言，遇到富有交互的组件区块时，不得不引入例如 [MDX](https://mdxjs.com/) 等方案，但这样的方案根本只适合程序员群体，完全无法移植。
+
+网络浏览形态也从简单的文章发展到具有整体性的应用，这些应用拥有复杂的布局、样式与交互，如果你尝试基于 Markdown 拓展语法来支持，最后可能发现还不如直接用原生 HTML。
+
+### 对结构化内容的诉求
+
+从编程角度理解就是 “组件复用”。Markdown 原生语法无法实现内容的复用，如果必须要复用内容，只能将其重复写在每一处，势必造成巨大同步成本。
+
+比如 Jekyll 就提出了 [FrontMatter](https://jekyllrb.com/docs/front-matter/) 概念用来创建复用的变量：
+
+```yml
+---
+food: Pizza
+---
+
+<h1>{{ page.food }}</h1>
+```
+
+### WYSIWYG 编辑器不应将 HTML 作为底层数据结构
+
+虽然浏览器真正将 HTML 作为底层数据结构，但这并不代表所见即所得的编辑器也可以如此，这也是为什么浏览器只能提供从源码到 UI 的输出，而不能提供从 UI 编辑到源码的反向输入。
+
+因为用户的输入与 HTML 并不是一一对应关系，其中存在大量模糊地带，比如当前光标处在粗体与细体文字中间，那下一个输入到底算加粗还是不加粗呢？从 UI 上看不到加粗标签。再有，如果 HTML 存在冗余，其实当前光标所在位置已经被加粗标签包裹了好几层，但因为光标所在区域又被另一个样式标签覆盖成非加粗模式，当再次输入时可能就跳出了覆盖范围，重新变成了加粗，这个过程符合用户预期吗？从技术上，这种复杂标签结构也几乎无法被处理，因为组合花样实在太多。
+
+现代大多数编辑器都以 JSON 格式存储数据结构，就因为其结构化且易于检索。
+
+结构化最重要的体现是，其生成的 HTML 结构可以是稳定的，即对于一个既加粗又标红的文字，一定包裹在一个 `<strong style="color: red">` 标签里，而不是 `<strong><div style="color: red">`，也就是这种模式根本没把 HTML 作为结构化数据去看待，自然就不会出现歧义。
+
+Markdown 也是一样，其本身也会出现类似 HTML 标签的二义性，不适合作为底层数据结构存储。
+
+## 精读
+
+批判 Markdown 的文章不多见，笔者也是看了之后才恍然发现 Markdown 竟然有这么多缺点。笔者结合自己的经验谈谈 Markdown 的缺点吧。
+
+### 不支持富交互的无奈
+
+Markdown 仅能支持简单的 HTML 结构，而无法描述逻辑区块。Github 上大部分 Readme 都采用图片来实现这些功能，包括状态卡片、构建结果、个人信息名片等，可惜交互能力还是太弱，我觉得有朝一日 Github 应该会推出比如 Block 小区块的概念，让这些区块可以直接插入 Markdown 成为一个可交互的元素。
+
+### MDX 解决了 Markdown 的痛点吗？
+
+看似完美兼容 JSX 与 Markdown 的 MDX 曾经也是笔者写作的救命稻草，但该方案移植性是一大痛点，组件只能在自己部署的网站用，如果你想把文章发布到另一个平台，完全不可能。
+
+这还仅是笔者的视角，如果从 Markdown 生态来看，MDX 面向用户仅是程序员群体，根本没有解决其使命 “方便网络写作”，而程序员最终也会抛弃 MDX 而转向开发所见即所得编辑器解决问题。
+
+### Markdown 到 HTML 的转换存在逻辑问题
+
+Markdown 本质上还是一种脱离 HTML 的文本表示结构，看上去解耦很优雅，实际上会遇到不少不一致的问题。
+
+比如说连续敲击多个空格会出现什么情况呢？在 Markdown 会变成一个引用区块，那如何才能展示多个空格呢？谁也不知道，可能需要查阅具体平台提供的额外语法才可以做到。
+
+这种大体上用起来方便，但细节无法定制，甚至用户无法控制的情况会大大伤害已经深度使用 Markdown 的用户，此时用户要么硬着头皮发明新语法解决这些漏洞，要么就完全放弃 Markdown 了。
+
+### 结构化能力不足
+
+看上去 Markdown 的语法挺具有结构化的，但实际上 Markdown 的结构化不具有强约束力。
+
+拿 JSON 作对比，比如我们可以用 JSON 拓展出 [https://json-schema.org/](jsonSchema) 结构，这个结构甚至可以反推出一个完整的表单应用，其原因是 JSON 可以针对每一个 Key、层级下定义，首先有结构，其次才有内容。
+
+而 Markdown 正好反过来，是先有内容，再有结构。比如我们可以在 Markdown 任何地方写任何 HTML 标签，或者任意段落的问题，这些内容是无法被序列化的，即便我们按照浏览器解析 HTML 的规则解析成 JSON，也无法从中方便的提取信息。
+
+背后的根本原因是，Markdown 本身定位就是 “近乎于 UI 渲染结果” 的，而实际上浏览器渲染 UI 背后是需要一套严谨的 HTML 语法，因为 UI 与背后语法并不能一一建立映射，一个稳定的渲染逻辑只能是从源码推导到渲染，而不能从渲染反推出源码。Markdown 本身定位就近乎于渲染结果，所以结构化能力不足是天然的问题。
+
+## 总结
+
+记得语雀早期内部试用时，编辑态还是采用 Markdown 的，但后来很快就把 Markdown 的编辑入口下掉了，这件事还引发了不少开发者的不满，甚至还有一些 Markdown 编辑的插件被开发出来，一度很受欢迎。但渐渐的我们都习惯用所见即所得方式编辑了，Markdown 唯一留给我们的印象就是快捷键，比如 `###` 后敲入空格可以生成 `h3` 标题段落，而语雀编辑器也在富交互组件区块上越走越远，要是当年被 Markdown 锁定住了技术，也不可能有今天这么高级的编辑体验。
+
+所以技术前瞻性真的很重要，Markdown 所有程序员都爱，但提前看到它在当前互联网发展阶段的局限性，并设计一套结构化数据代替 Markdown 结构不是所有人都能想到的，我们需要以动态的眼光看待技术，也要放下技术人的偏见，把偏爱让位于产品定位。
+
+> 讨论地址是：[精读《对 Markdown 的思考》· Issue #397 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/397)
+
+**如果你想参与讨论，请 [点击这里](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)）
+
+

前沿技术/7.精读《请停止 css-in-js 的行为》.md

@@ -32,7 +32,7 @@ const Title = styled.h1`
 
 ## css-modules
 
-顾名思义，css-modules 将 css 代码模块化，可以很方面的避免本模块样式被污染。并且可以很方便的复用 css 代码。
+顾名思义，css-modules 将 css 代码模块化，可以很方便的避免本模块样式被污染。并且可以很方便的复用 css 代码。
 
 ```css
 // 全局变量

前沿技术/72.精读《REST, GraphQL, Webhooks, & gRPC 如何选型》.md

@@ -36,7 +36,7 @@ RPC 主要用来做服务器之间的方法调用，影响其性能最重要因
 
 gRPC 主要用于服务之间传输，这里拿 Nodejs 举例：
 
-1. 定义接口。由于 gRPC 使用 protobufs，所以接口定义文件就是 `helloword.proto`:
+1. 定义接口。由于 gRPC 使用 protobufs，所以接口定义文件就是 `helloworld.proto`:
 
 ```protobufs
 // The greeting service definition.

源码解读/227. 精读《zustand 源码》.md

@@ -0,0 +1,361 @@
+[zustand](https://github.com/pmndrs/zustand) 是一个非常时髦的状态管理库，也是 2021 年 Star 增长最快的 React 状态管理库。它的理念非常函数式，API 设计的很优雅，值得学习。
+
+## 概述
+
+首先介绍 [zustand](https://github.com/pmndrs/zustand) 的使用方法。
+
+### 创建 store
+
+通过 `create` 函数创建 store，回调可拿到 `get` `set` 就类似 Redux 的 `getState` 与 `setState`，可以获取 store 瞬时值与修改 store。返回一个 hook 可以在 React 组件中访问 store。
+
+```typescript
+import create from 'zustand'
+
+const useStore = create((set, get) => ({
+  bears: 0,
+  increasePopulation: () => set(state => ({ bears: state.bears + 1 })),
+  removeAllBears: () => set({ bears: 0 })
+}))
+```
+
+上面例子是全局唯一的 store，也可以通过 `createContext` 方式创建多实例 store，结合 Provider 使用：
+
+```tsx
+import create from 'zustand'
+import createContext from 'zustand/context'
+
+const { Provider, useStore } = createContext()
+
+const createStore = () => create(...)
+
+const App = () => (
+  <Provider createStore={createStore}>
+    ...
+  </Provider>
+)
+```
+
+### 访问 store
+
+通过 `useStore` 在组件中访问 store。与 redux 不同的是，无论普通数据还是函数都可以存在 store 里，且函数也通过 selector 语法获取。因为函数引用不可变，所以实际上下面第二个例子不会引发重渲染：
+
+```typescript
+function BearCounter() {
+  const bears = useStore(state => state.bears)
+  return <h1>{bears} around here ...</h1>
+}
+
+function Controls() {
+  const increasePopulation = useStore(state => state.increasePopulation)
+  return <button onClick={increasePopulation}>one up</button>
+}
+```
+
+如果嫌访问变量需要调用多次 `useStore` 麻烦，可以自定义 compare 函数返回一个对象：
+
+```typescript
+const { nuts, honey } = useStore(state => ({ nuts: state.nuts, honey: state.honey }), shallow)
+```
+
+### 细粒度 memo
+
+利用 `useCallback` 甚至可以跳过普通 compare，而仅关心外部 id 值的变化，如：
+
+```typescript
+const fruit = useStore(useCallback(state => state.fruits[id], [id]))
+```
+
+原理是 id 变化时，`useCallback` 返回值才会变化，而 `useCallback` 返回值如果不变，`useStore` 的 compare 函数引用对比就会为 `true`，非常巧妙。
+
+### set 合并与覆盖
+
+`set` 函数第二个参数默认为 `false`，即合并值而非覆盖整个 store，所以可以利用这个特性清空 store：
+
+```typescript
+const useStore = create(set => ({
+  salmon: 1,
+  tuna: 2,
+  deleteEverything: () => set({ }, true), // clears the entire store, actions included
+}))
+```
+
+### 异步
+
+所有函数都支持异步，因为修改 store 并不依赖返回值，而是调用 `set`，所以是否异步对数据流框架来说都一样。
+
+### 监听指定变量
+
+还是用英文比较表意，即 `subscribeWithSelector`，这个中间件可以让我们把 selector 用在 subscribe 函数上，相比于 redux 传统的 subscribe，就可以有针对性的监听了：
+
+```typescript
+import { subscribeWithSelector } from 'zustand/middleware'
+const useStore = create(subscribeWithSelector(() => ({ paw: true, snout: true, fur: true })))
+
+// Listening to selected changes, in this case when "paw" changes
+const unsub2 = useStore.subscribe(state => state.paw, console.log)
+// Subscribe also exposes the previous value
+const unsub3 = useStore.subscribe(state => state.paw, (paw, previousPaw) => console.log(paw, previousPaw))
+// Subscribe also supports an optional equality function
+const unsub4 = useStore.subscribe(state => [state.paw, state.fur], console.log, { equalityFn: shallow })
+// Subscribe and fire immediately
+const unsub5 = useStore.subscribe(state => state.paw, console.log, { fireImmediately: true })
+```
+
+后面还有一些结合中间件、immer、localstorage、redux like、devtools、combime store 就不细说了，都是一些细节场景。值得一提的是，所有特性都是正交的。
+
+## 精读
+
+其实大部分使用特性都在利用 React 语法，所以可以说 50% 的特性属于 React 通用特性，只是写在了 [zustand](https://github.com/pmndrs/zustand) 文档里，看上去像是 zustand 的特性，所以这个库真的挺会借力的。
+
+### 创建 store 实例
+
+任何数据流管理工具，都有一个最核心的 store 实例。对 zustand 来说，便是定义在 `vanilla.ts` 文件的 `createStore` 了。
+
+`createStore` 返回一个类似 redux store 的数据管理实例，拥有四个非常常见的 API：
+
+```typescript
+export type StoreApi<T extends State> = {
+  setState: SetState<T>
+  getState: GetState<T>
+  subscribe: Subscribe<T>
+  destroy: Destroy
+}
+```
+
+首先 `getState` 的实现：
+
+```typescript
+const getState: GetState<TState> = () => state
+```
+
+就是这么简单粗暴。再看 `state`，就是一个普通对象：
+
+```typescript
+let state: TState
+```
+
+这就是数据流简单的一面，没有魔法，数据存储用一个普通对象，仅此而已。
+
+接着看 `setState`，它做了两件事，修改 `state` 并执行 `listenser`：
+
+```typescript
+const setState: SetState<TState> = (partial, replace) => {
+  const nextState = typeof partial === 'function' ? partial(state) : partial
+  if (nextState !== state) {
+    const previousState = state
+    state = replace ? (nextState as TState) : Object.assign({}, state, nextState)
+    listeners.forEach((listener) => listener(state, previousState))
+  }
+}
+```
+
+修改 `state` 也非常简单，唯一重要的是 `listener(state, previousState)`，那么这些 `listeners` 是什么时候注册和声明的呢？其实 `listeners` 就是一个 Set 对象：
+
+```typescript
+const listeners: Set<StateListener<TState>> = new Set()
+```
+
+注册和销毁时机分别是 `subscribe` 与 `destroy` 函数调用时，这个实现很简单、高效。对应代码就不贴了，很显然，`subscribe` 时注册的监听函数会作为 `listener` 添加到 `listeners` 队列中，当发生 `setState` 时便会被调用。
+
+最后我们看 `createStore` 的定义与结尾：
+
+```typescript
+function createStore(createState) {
+  let state: TState
+  const setState = /** ... */
+  const getState = /** ... */
+  /** ... */
+  const api = { setState, getState, subscribe, destroy }
+  state = createState(setState, getState, api)
+  return api
+}
+```
+
+虽然这个 `state` 是个简单的对象，但回顾使用文档，我们可以在 `create` 创建 store 利用 callback 对 state 赋值，那个时候的 `set`、`get`、`api` 就是上面代码倒数第二行传入的：
+
+```typescript
+import { create } from 'zustand'
+
+const useStore = create((set, get) => ({
+  bears: 0,
+  increasePopulation: () => set(state => ({ bears: state.bears + 1 })),
+  removeAllBears: () => set({ bears: 0 })
+}))
+```
+
+至此，初始化 store 的所有 API 的来龙去脉就梳理清楚了，逻辑简单清晰。
+
+### create 函数的实现
+
+上面我们说清楚了如何创建 store 实例，但这个实例是底层 API，使用文档介绍的 `create` 函数在 `react.ts` 文件定义，并调用了 `createStore` 创建框架无关数据流。之所 `create` 定义在 `react.ts`，是因为返回的 `useStore` 是一个 Hooks，所以本身具有 React 环境特性，因此得名。
+
+该函数第一行就调用 `createStore` 创建基础 store，因为对框架来说是内部 API，所以命名也叫 api：
+
+```typescript
+const api: CustomStoreApi = typeof createState === 'function' ? createStore(createState) : createState
+
+const useStore: any = <StateSlice>(
+  selector: StateSelector<TState, StateSlice> = api.getState as any,
+  equalityFn: EqualityChecker<StateSlice> = Object.is
+) => /** ... */
+```
+
+接下来所有代码都在创建 `useStore` 这个函数，我们看下其内部实现：
+
+简单来说就是利用 `subscribe` 监听变化，并在需要的时候强制刷新当前组件，并传入最新的 `state` 给到 `useStore`。所以第一步当然是创建 `forceUpdate` 函数:
+
+```typescript
+const [, forceUpdate] = useReducer((c) => c + 1, 0) as [never, () => void]
+```
+
+然后通过调用 API 拿到 `state` 并传给 selector，并调用 `equalityFn`（这个函数可以被定制）判断状态是否发生了变化：
+
+```typescript
+const state = api.getState()
+newStateSlice = selector(state)
+hasNewStateSlice = !equalityFn(
+  currentSliceRef.current as StateSlice,
+  newStateSlice
+)
+```
+
+如果状态变化了，就更新 `currentSliceRef.current`：
+
+```typescript
+useIsomorphicLayoutEffect(() => {
+  if (hasNewStateSlice) {
+    currentSliceRef.current = newStateSlice as StateSlice
+  }
+  stateRef.current = state
+  selectorRef.current = selector
+  equalityFnRef.current = equalityFn
+  erroredRef.current = false
+})
+```
+
+> `useIsomorphicLayoutEffect` 是同构框架常用 API 套路，在前端环境是 `useLayoutEffect`，在 node 环境是 `useEffect`：
+
+说明一下 `currentSliceRef` 与 `newStateSlice` 的功能。我们看 `useStore` 最后的返回值：
+
+```typescript
+const sliceToReturn = hasNewStateSlice
+  ? (newStateSlice as StateSlice)
+  : currentSliceRef.current
+useDebugValue(sliceToReturn)
+return sliceToReturn
+```
+
+发现逻辑是这样的：如果 state 变化了，则返回新的 state，否则返回旧的，这样可以保证 compare 函数判断相等时，返回对象的引用完全相同，这个是不可变数据的核心实现。另外我们也可以学习到阅读源码的技巧，即要经常跳读。
+
+那么如何在 selector 变化时更新 store 呢？中间还有一段核心代码，调用了 `subscribe`，相信你已经猜到了，下面是核心代码片段：
+
+```typescript
+useIsomorphicLayoutEffect(() => {
+  const listener = () => {
+    try {
+      const nextState = api.getState()
+      const nextStateSlice = selectorRef.current(nextState)
+      if (!equalityFnRef.current(currentSliceRef.current as StateSlice, nextStateSlice)) {
+        stateRef.current = nextState
+        currentSliceRef.current = nextStateSlice
+        forceUpdate()
+      }
+    } catch (error) {
+      erroredRef.current = true
+      forceUpdate()
+    }
+  }
+  const unsubscribe = api.subscribe(listener)
+  if (api.getState() !== stateBeforeSubscriptionRef.current) {
+    listener() // state has changed before subscription
+  }
+  return unsubscribe
+}, [])
+```
+
+这段代码要先从 `api.subscribe(listener)` 看，这使得任何 `setState` 都会触发 `listener` 的执行，而 `listener` 利用 `api.getState()` 拿到最新 `state`，并拿到上一次的 compare 函数 `equalityFnRef` 执行一下判断值前后是否发生了改变，如果改变则更新 `currentSliceRef` 并进行一次强制刷新（调用 `forceUpdate`）。
+
+### context 的实现
+
+注意到 context 语法，可以创建多个互不干扰的 store 实例：
+
+```tsx
+import create from 'zustand'
+import createContext from 'zustand/context'
+
+const { Provider, useStore } = createContext()
+
+const createStore = () => create(...)
+
+const App = () => (
+  <Provider createStore={createStore}>
+    ...
+  </Provider>
+)
+```
+
+首先我们知道 `create` 创建的 store 是实例间互不干扰的，问题是 `create` 返回的 `useStore` 只有一个实例，也没有 `<Provider>` 声明作用域，那么如何构造上面的 API 呢？
+
+首先 `Provider` 存储了 `create` 返回的 `useStore`：
+
+```tsx
+const storeRef = useRef<TUseBoundStore>()
+storeRef.current = createStore()
+```
+
+那么 `useStore` 本身其实并不实现数据流功能，而是将 `<Provider>` 提供的 `storeRef` 拿到并返回：
+
+```typescript
+const useStore: UseContextStore<TState> = <StateSlice>(
+  selector?: StateSelector<TState, StateSlice>,
+  equalityFn = Object.is
+) => {
+  const useProviderStore = useContext(ZustandContext)
+  return useProviderStore(
+    selector as StateSelector<TState, StateSlice>,
+    equalityFn
+  )
+}
+```
+
+所以核心逻辑还是是现在 `create` 函数里，`context.ts` 只是利用 ReactContext 将 `useStore` “注入” 到组件，且利用 ReactContext 特性，这个注入可以存在多个实例，且不会相互影响。
+
+### 中间件
+
+中间件其实不需要怎么实现。比如看这个 redux 中间件的例子：
+
+```typescript
+import { redux } from 'zustand/middleware'
+const useStore = create(redux(reducer, initialState))
+```
+
+可以将 zustand 用法改变为 reducer，实际上是利用了函数式理念，redux 函数本身可以拿到 `set, get, api`，如果想保持 API 不变，则原样返回 callback 就行了，如果想改变用法，则返回特定的结构，就是这么简单。
+
+为了加深理解，我们看看 redux 中间件源码：
+
+```typescript
+export const redux = ( reducer, initial ) => ( set, get, api ) => {
+  api.dispatch = action => {
+    set(state => reducer(state, action), false, action)
+    return action
+  }
+  api.dispatchFromDevtools = true
+  return { dispatch: (...a) => api.dispatch(...a), ...initial }
+}
+```
+
+将 `set, get, api` 封装为 redux API：`dispatch` 本质就是调用 `set`。
+
+## 总结
+
+[zustand](https://github.com/pmndrs/zustand) 是一个实现精巧的 React 数据流管理工具，自身框架无关的分层合理，中间件实现巧妙，值得学习。
+
+> 讨论地址是：[精读《zustand 源码》· Issue #392 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/392)
+
+**如果你想参与讨论，请 [点击这里](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)）

源码解读/229.精读《vue-lit 源码》.md

@@ -0,0 +1,308 @@
+[vue-lit](https://github.com/yyx990803/vue-lit) 基于 [lit-html](https://github.com/lit/lit/blob/main/packages/lit-html/README.md) + [@vue/reactivity](https://github.com/vuejs/vue-next/tree/master/packages/reactivity) 仅用 70 行代码就给模版引擎实现了 [Vue Composition API](https://vuejs.org/guide/extras/composition-api-faq.html)，用来开发 web component。
+
+## 概述
+
+```html
+<my-component></my-component>
+
+<script type="module">
+  import {
+    defineComponent,
+    reactive,
+    html,
+    onMounted,
+    onUpdated,
+    onUnmounted
+  } from 'https://unpkg.com/@vue/lit'
+
+  defineComponent('my-component', () => {
+    const state = reactive({
+      text: 'hello',
+      show: true
+    })
+    const toggle = () => {
+      state.show = !state.show
+    }
+    const onInput = e => {
+      state.text = e.target.value
+    }
+
+    return () => html`
+      <button @click=${toggle}>toggle child</button>
+      <p>
+      ${state.text} <input value=${state.text} @input=${onInput}>
+      </p>
+      ${state.show ? html`<my-child msg=${state.text}></my-child>` : ``}
+    `
+  })
+
+  defineComponent('my-child', ['msg'], (props) => {
+    const state = reactive({ count: 0 })
+    const increase = () => {
+      state.count++
+    }
+
+    onMounted(() => {
+      console.log('child mounted')
+    })
+
+    onUpdated(() => {
+      console.log('child updated')
+    })
+
+    onUnmounted(() => {
+      console.log('child unmounted')
+    })
+
+    return () => html`
+      <p>${props.msg}</p>
+      <p>${state.count}</p>
+      <button @click=${increase}>increase</button>
+    `
+  })
+</script>
+```
+
+上面定义了 `my-component` 与 `my-child` 组件，并将 `my-child` 作为 `my-component` 的默认子元素。
+
+```js
+import {
+  defineComponent,
+  reactive,
+  html, 
+  onMounted,
+  onUpdated,
+  onUnmounted
+} from 'https://unpkg.com/@vue/lit'
+```
+
+`defineComponent` 定义 custom element，第一个参数是自定义 element 组件名，必须遵循原生 API  [customElements.define](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements) 对组件名的规范，组件名必须包含中划线。
+
+`reactive` 属于 [@vue/reactivity](https://github.com/vuejs/vue-next/tree/master/packages/reactivity) 提供的响应式 API，可以创建一个响应式对象，在渲染函数中调用时会自动进行依赖收集，这样在 Mutable 方式修改值时可以被捕获，并自动触发对应组件的重渲染。
+
+`html` 是 [lit-html](https://github.com/lit/lit/blob/main/packages/lit-html/README.md) 提供的模版函数，通过它可以用 [Template strings](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals) 原生语法描述模版，是一个轻量模版引擎。
+
+`onMounted`、`onUpdated`、`onUnmounted` 是基于 [web component lifecycle](https://developers.google.com/web/fundamentals/web-components/customelements#reactions) 创建的生命周期函数，可以监听组件创建、更新与销毁时机。
+
+接下来看 `defineComponent` 的内容：
+
+```js
+defineComponent('my-component', () => {
+  const state = reactive({
+    text: 'hello',
+    show: true
+  })
+  const toggle = () => {
+    state.show = !state.show
+  }
+  const onInput = e => {
+    state.text = e.target.value
+  }
+
+  return () => html`
+    <button @click=${toggle}>toggle child</button>
+    <p>
+    ${state.text} <input value=${state.text} @input=${onInput}>
+    </p>
+    ${state.show ? html`<my-child msg=${state.text}></my-child>` : ``}
+  `
+})
+```
+
+借助模版引擎 [lit-html](https://github.com/lit/lit/blob/main/packages/lit-html/README.md) 的能力，可以同时在模版中传递变量与函数，再借助 [@vue/reactivity](https://github.com/vuejs/vue-next/tree/master/packages/reactivity) 能力，让变量变化时生成新的模版，更新组件 dom。
+
+## 精读
+
+阅读源码可以发现，vue-lit 巧妙的融合了三种技术方案，它们配合方式是：
+
+1. 使用 [@vue/reactivity](https://github.com/vuejs/vue-next/tree/master/packages/reactivity) 创建响应式变量。
+2. 利用模版引擎 [lit-html](https://github.com/lit/lit/blob/main/packages/lit-html/README.md) 创建使用了这些响应式变量的 HTML 实例。
+3. 利用 [web component](https://developers.google.com/web/fundamentals/web-components/customelements) 渲染模版引擎生成的 HTML 实例，这样创建的组件具备隔离能力。
+
+其中响应式能力与模版能力分别是 [@vue/reactivity](https://github.com/vuejs/vue-next/tree/master/packages/reactivity)、[lit-html](https://github.com/lit/lit/blob/main/packages/lit-html/README.md) 这两个包提供的，我们只需要从源码中寻找剩下的两个功能：如何在修改值后触发模版刷新，以及如何构造生命周期函数的。
+
+首先看如何在值修改后触发模版刷新。以下我把与重渲染相关代码摘出来了：
+
+```js
+import {
+  effect
+} from 'https://unpkg.com/@vue/reactivity/dist/reactivity.esm-browser.js'
+
+customElements.define(
+  name,
+  class extends HTMLElement {
+    constructor() {
+      super()
+      const template = factory.call(this, props)
+      const root = this.attachShadow({ mode: 'closed' })
+      effect(() => {
+        render(template(), root)
+      })
+    }
+  }
+)
+```
+
+可以清晰的看到，首先 `customElements.define` 创建一个原生 web component，并利用其 API 在初始化时创建一个 `closed` 节点，该节点对外部 API 调用关闭，即创建的是一个不会受外部干扰的 web component。
+
+然后在 `effect` 回调函数内调用 `html` 函数，即在使用文档里返回的模版函数，由于这个模版函数中使用的变量都采用 `reactive` 定义，所以 `effect` 可以精准捕获到其变化，并在其变化后重新调用 `effect` 回调函数，实现了 “值变化后重渲染” 的功能。
+
+然后看生命周期是如何实现的，由于生命周期贯穿整个实现流程，因此必须结合全量源码看，下面贴出全量核心代码，上面介绍过的部分可以忽略不看，只看生命周期的实现：
+
+```js
+let currentInstance
+
+export function defineComponent(name, propDefs, factory) {
+  if (typeof propDefs === 'function') {
+    factory = propDefs
+    propDefs = []
+  }
+
+  customElements.define(
+    name,
+    class extends HTMLElement {
+      constructor() {
+        super()
+        const props = (this._props = shallowReactive({}))
+        currentInstance = this
+        const template = factory.call(this, props)
+        currentInstance = null
+        this._bm && this._bm.forEach((cb) => cb())
+        const root = this.attachShadow({ mode: 'closed' })
+        let isMounted = false
+        effect(() => {
+          if (isMounted) {
+            this._bu && this._bu.forEach((cb) => cb())
+          }
+          render(template(), root)
+          if (isMounted) {
+            this._u && this._u.forEach((cb) => cb())
+          } else {
+            isMounted = true
+          }
+        })
+      }
+      connectedCallback() {
+        this._m && this._m.forEach((cb) => cb())
+      }
+      disconnectedCallback() {
+        this._um && this._um.forEach((cb) => cb())
+      }
+      attributeChangedCallback(name, oldValue, newValue) {
+        this._props[name] = newValue
+      }
+    }
+  )
+}
+
+function createLifecycleMethod(name) {
+  return (cb) => {
+    if (currentInstance) {
+      ;(currentInstance[name] || (currentInstance[name] = [])).push(cb)
+    }
+  }
+}
+
+export const onBeforeMount = createLifecycleMethod('_bm')
+export const onMounted = createLifecycleMethod('_m')
+export const onBeforeUpdate = createLifecycleMethod('_bu')
+export const onUpdated = createLifecycleMethod('_u')
+export const onUnmounted = createLifecycleMethod('_um')
+```
+
+生命周期实现形如 `this._bm && this._bm.forEach((cb) => cb())`，之所以是循环，是因为比如 `onMount(() => cb())` 可以注册多次，因此每个生命周期都可能注册多个回调函数，因此遍历将其依次执行。
+
+而生命周期函数还有一个特点，即并不分组件实例，因此必须有一个 `currentInstance` 标记当前回调函数是在哪个组件实例注册的，而这个注册的同步过程就在 `defineComponent` 回调函数 `factory` 执行期间，因此才会有如下的代码：
+
+```js
+currentInstance = this
+const template = factory.call(this, props)
+currentInstance = null
+```
+
+这样，我们就将 `currentInstance` 始终指向当前正在执行的组件实例，而所有生命周期函数都是在这个过程中执行的，**因此当调用生命周期回调函数时，`currentInstance` 变量必定指向当前所在的组件实例**。
+
+接下来为了方便，封装了 `createLifecycleMethod` 函数，在组件实例上挂载了一些形如 `_bm`、`_bu` 的数组，比如 `_bm` 表示 `beforeMount`，`_bu` 表示 `beforeUpdate`。
+
+接下来就是在对应位置调用对应函数了：
+
+首先在 `attachShadow` 执行之前执行 `_bm` - `onBeforeMount`，因为这个过程确实是准备组件挂载的最后一步。
+
+然后在 `effect` 中调用了两个生命周期，因为 `effect` 会在每次渲染时执行，所以还特意存储了 `isMounted` 标记是否为初始化渲染：
+
+```js
+effect(() => {
+  if (isMounted) {
+    this._bu && this._bu.forEach((cb) => cb())
+  }
+  render(template(), root)
+  if (isMounted) {
+    this._u && this._u.forEach((cb) => cb())
+  } else {
+    isMounted = true
+  }
+})
+```
+
+这样就很容易看懂了，只有初始化渲染过后，从第二次渲染开始，在执行 `render`（该函数来自 `lit-html` 渲染模版引擎）之前调用 `_bu` - `onBeforeUpdate`，在执行了 `render` 函数后调用 `_u` - `onUpdated`。
+
+由于 `render(template(), root)` 根据 `lit-html` 的语法，会直接把 `template()` 返回的 HTML 元素挂载到 `root` 节点，而 `root` 就是这个 web component `attachShadow` 生成的 shadow dom 节点，因此这句话执行结束后渲染就完成了，所以 `onBeforeUpdate` 与 `onUpdated` 一前一后。
+
+最后几个生命周期函数都是利用 web component 原生 API 实现的：
+
+```js
+connectedCallback() {
+  this._m && this._m.forEach((cb) => cb())
+}
+disconnectedCallback() {
+  this._um && this._um.forEach((cb) => cb())
+}
+```
+
+分别实现 `mount`、`unmount`。这也说明了浏览器 API 分层的清晰之处，只提供创建和销毁的回调，而更新机制完全由业务代码实现，不管是 [@vue/reactivity](https://github.com/vuejs/vue-next/tree/master/packages/reactivity) 的 `effect` 也好，还是 `addEventListener` 也好，都不关心，所以如果在这之上做完整的框架，需要自己根据实现 `onUpdate` 生命周期。
+
+最后的最后，还利用 `attributeChangedCallback` 生命周期监听自定义组件 html attribute 的变化，然后将其直接映射到对 `this._props[name]` 的变化，这是为什么呢？
+
+```js
+attributeChangedCallback(name, oldValue, newValue) {
+  this._props[name] = newValue
+}
+```
+
+看下面的代码片段就知道原因了：
+
+```js
+const props = (this._props = shallowReactive({}))
+const template = factory.call(this, props)
+effect(() => {
+  render(template(), root)
+})
+```
+
+早在初始化时，就将 `_props` 创建为响应式变量，这样只要将其作为 [lit-html](https://github.com/lit/lit/blob/main/packages/lit-html/README.md) 模版表达式的参数（对应 `factory.call(this, props)` 这段，而 `factory` 就是 `defineComponent('my-child', ['msg'], (props) => { ..` 的第三个参数），这样一来，只要这个参数变化了就会触发子组件的重渲染，因为这个 `props` 已经经过 Reactive 处理了。
+
+## 总结
+
+[vue-lit](https://github.com/yyx990803/vue-lit) 实现非常巧妙，学习他的源码可以同时了解一下几种概念：
+
+- reative。
+- web component。
+- string template。
+- 模版引擎的精简实现。
+- 生命周期。
+
+以及如何将它们串起来，利用 70 行代码实现一个优雅的渲染引擎。
+
+最后，用这种模式创建的 web component 引入的 runtime lib 在 gzip 后只有 6kb，但却能享受到现代化框架的响应式开发体验，如果你觉得这个 runtime 大小可以忽略不计，那这就是一个非常理想的创建可维护 web component 的 lib。
+
+> 讨论地址是：[精读《vue-lit 源码》· Issue #396 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/396)
+
+**如果你想参与讨论，请 [点击这里](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)）
+
+