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

fix: typo

helper.js

@@ -0,0 +1,34 @@
+/**
+ * 发布辅助脚本
+ * @author 黄子毅
+ */
+
+const fs = require("fs");
+
+const dirs = [
+  "前沿技术",
+  "设计模式",
+  "编译原理",
+  "源码解读",
+  "商业思考",
+  "算法",
+];
+
+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,245 @@
 # 前端精读
 
-<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="./前沿技术/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>
+
+素材来源：[周刊参考池](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="./设计模式/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="./商业思考/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>
 
 ## 关注前端精读微信公众号
 
 <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 年前，通过后端模版定义、注释定义模块依赖。对经历过来的人来说，历史的模块化方式还停留在脑海中，反而新上手的同学会更快接受现代的模块化规范。
 
@@ -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 不需要重新下载。
 
 可见，**即使不断的有新技术出现，也依然需要配套的工具来将前端工程问题解决方案推向极致。**
 

前沿技术/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
 

前沿技术/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)

前沿技术/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 实例是个纯对象，没有将方法挂载到原型链上，简单易懂。
 

前沿技术/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)）

前沿技术/141.精读《useRef 与 createRef 的区别》.md

@@ -0,0 +1,108 @@
+## 1 引言
+
+`useRef` 是常用的 API，但还有一个 `createRef` 的 API，你知道他们的区别吗？通过 [React.useRef and React.createRef: The Difference](https://blog.bitsrc.io/react-useref-and-react-createref-the-difference-afedb9877d0f) 这篇文章，你可以了解到何时该使用它们。
+
+## 2 概述
+
+其实原文就阐述了这样一个事实：`useRef` 仅能用在 FunctionComponent，`createRef` 仅能用在 ClassComponent。
+
+第一句话是显然的，因为 Hooks 不能用在 ClassComponent。
+
+第二句话的原因是，`createRef` 并没有 Hooks 的效果，其值会随着 FunctionComponent 重复执行而不断被初始化：
+
+```tsx
+function App() {
+  // 错误用法，永远也拿不到 ref
+  const valueRef = React.createRef();
+  return <div ref={valueRef} />;
+}
+```
+
+上述 `valueRef` 会随着 App 函数的 Render 而重复初始化，**这也是 Hooks 的独特之处，虽然用在普通函数中，但在 React 引擎中会得到超出普通函数的表现，比如初始化仅执行一次，或者引用不变**。
+
+为什么 `createRef` 可以在 ClassComponent 正常运行呢？这是因为 ClassComponent 分离了生命周期，使例如 `componentDidMount` 等初始化时机仅执行一次。
+
+原文完。
+
+## 3 精读
+
+那么知道如何正确创建 Ref 后，还知道如何正确更新 Ref 吗？
+
+由于 Ref 是贯穿 FunctionComponent 所有渲染周期的实例，理论上在任何地方都可以做修改，比如：
+
+```tsx
+function App() {
+  const valueRef = React.useRef();
+
+  valueRef.current += 1;
+
+  return <div />;
+}
+```
+
+但其实上面的修改方式是不规范的，React 官方文档里要求我们避免在 Render 函数中直接修改 Ref，请先看下面的 FunctionComponent 生命周期图：
+
+<img width=600 src="https://img.alicdn.com/tfs/TB12aHDwQL0gK0jSZFtXXXQCXXa-3300-2550.png">
+
+从图中可以发现，在 `Render phase` 阶段是不允许做 “side effects” 的，也就是写副作用代码，这是因为这个阶段可能会被 React 引擎随时取消或重做。
+
+修改 Ref 属于副作用操作，因此不适合在这个阶段进行。我们可以看到，在 `Commit phase` 阶段可以做这件事，或者在回调函数中做（脱离了 React 生命周期）。
+
+当然有一种情况是可以的，即 [懒初始化](https://reactjs.org/docs/hooks-faq.html#how-to-create-expensive-objects-lazily)：
+
+```ts
+function Image(props) {
+  const ref = useRef(null);
+
+  // ✅ IntersectionObserver is created lazily once
+  function getObserver() {
+    if (ref.current === null) {
+      ref.current = new IntersectionObserver(onIntersect);
+    }
+    return ref.current;
+  }
+
+  // When you need it, call getObserver()
+  // ...
+}
+```
+
+懒初始化的情况下，副作用最多执行一次，而且仅用于初始化赋值，所以这种行为是被允许的。
+
+为什么对副作用限制的如此严格？因为 FunctionComponent 增加了内置调度系统，为了优先响应用户操作，可能会暂定某个 React 组件的渲染，具体可以看第 99 篇精读：[精读《Scheduling in React》](https://github.com/dt-fe/weekly/blob/v2/099.%E7%B2%BE%E8%AF%BB%E3%80%8AScheduling%20in%20React%E3%80%8B.md)
+
+Ref 不仅可以拿到组件引用、创建一个 Mutable 副作用对象，还可以配合 `useEffect` 存储一个较老的值，最常用来拿到 `previousProps`，React 官方利用 Ref 封装了一个简单的 Hooks 拿到上一次的值：
+
+```tsx
+function usePrevious(value) {
+  const ref = useRef();
+  useEffect(() => {
+    ref.current = value;
+  });
+  return ref.current;
+}
+```
+
+由于 `useEffect` 在 Render 完毕后才执行，因此 `ref` 的值在当前 Render 中永远是上一次 Render 时候的，我们可以利用它拿到上一次 Props：
+
+```tsx
+function App(props) {
+  const preProps = usePrevious(props);
+}
+```
+
+要实现这个功能，还是要归功于 `ref` 可以将值 “在各个不同的 Render 闭包中传递的特性”。最后，不要滥用 Ref，Mutable 引用越多，对 React 来说可维护性一般会越差。
+
+## 4 总结
+
+你还挖掘了 `useRef` 哪些有意思的使用方式？欢迎在评论区留言。
+
+> 讨论地址是：[精读《useRef 与 createRef 的区别》 · Issue #236 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/236)
+
+**如果你想参与讨论，请 [点击这里](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)）

前沿技术/142.精读《如何做好 CodeReview》.md

@@ -0,0 +1,97 @@
+## 1 引言
+
+任何软件都是协同开发的，所以 CodeReview 非常重要，它可以帮助你减少代码质量问题，提高开发效率，提升稳定性，同时还能保证软件架构的稳定性，防止代码结构被恶意破坏导致难以维护。
+
+所以 CodeReview 机制是否健全是一个工程团队能否长期健康发展的决定因素之一，这次我们读一篇关于 CodeReview 如何做得更好的文章： [how-to-make-good-code-reviews-better](https://stackoverflow.blog/2019/09/30/how-to-make-good-code-reviews-better/)。
+
+## 2 概述 & 精读
+
+作者结合自己在 Uber、微软的工作经历介绍了自己对如何做好 CodeReview 的看法。
+
+### CodeReview 的覆盖范围
+
+**Good CodeReview** 会检查代码的正确性、测试覆盖率、功能变化、是否遵循代码规范与最佳实践、可以指出一些较为明显的改进点，比如难以阅读的写法、未使用到变量、一些边界问题、commit 数量过大需要拆分等等。
+
+**Better CodeReview** 会检查引入代码的必要性，与已有系统是否适配，是否具有可维护性，从抽象角度思考代码是否与已有系统逻辑能够自洽。
+
+> Better CodeReview 会关注在可维护性层面，并具有全局性，往往几个局部正确的代码组合在一起会产生错误的结果，或者是没必要的代码，或者是相互冲突的逻辑。Better CodeReview 更多用在底层架构场景，因为架构底层模块关联比较紧密，需要有整体视角，而业务上层模块间最好采用解耦模式，这样不仅不需要更耗费精力的 Better CodeReview，也是一种更正确的架构设计。
+
+### CodeReview 的语气
+
+**Good CodeReview** 会给出建设性意见，而不是发表强硬措辞要求对方改正，或认为自己的意见是唯一正确的答案，因为这样的评论其实具有一定攻击性，激发对方的防御心理，产生敌对心态，这样会从内部瓦解一个团队。最好能给出建议，或者多个选择，给对方留有余地。
+
+**Better CodeReview** 永远是考虑全面且正向积极的，会对写的好的地方进行鼓励，对写的不好的地方也体现出善解人意的关怀，考虑到对方可能花费了很多心血，以一种换位思考的鼓励心态进行评论。
+
+> 其实读到语气这一章节，逐渐发现 CodeReview 不仅是一个技术专业行为，还是一个人与人相处的社交行为，有的人平时与人打交道非常谦逊，但在 CodeReview 中就变得尖酸刻薄，显然是只关注到了 CodeReview 的专业性这一面，忽略了社交性这一点。而要做到 Better CodeReview 还要学会换位思考，体现出包容、正向积极的态度，因为你技术经验更丰富，能指出别人的问题很正常，但能保持谦逊，让别人容易接受并受到鼓励，可以让你成为一个有气度的技术专家。
+
+### 如何完成 CodeReview 的审阅
+
+**Good CodeReview** 不会轻易通过那些开放式 PR，至少在其被得到充分讨论前，但每个 Review 者对自己关注的部分完成 Review 后需要进行反馈，无论是 “看起来不错” 或者用缩写单词 “LGTM”，之后需要有明确的跟进，比如通过协作软件通知作者进行进一步反馈。
+
+**Better CodeReview** 实际执行中会更加灵活一些，对于一些比较紧急的改动会留下改进建议，但快速通过，让作者通过后续代码提交解决遗留的问题。
+
+> 实际工作场景会遇到一些开放式或紧急的提交，良好的 CodeReview 习惯自然是要严谨一些，讨论清楚再通过，并且要及时反馈。但某些比较紧急的提交就要区别对待了，更好的态度是在实践中灵活对待，但及时紧急通过了，也要保证问题在后续得以修复，比如在代码中留一些 "TODO" 或 "FIXME" 的标记，写上对应的负责人与预期解决时间。
+
+### 从 CodeReview 到直接交流
+
+**Good CodeReview** 会给出完整的评论和修改建议，如果后续提交的代码不符合预期，Review 者可以直接与代码提交者面对面交流，这样可以避免后续花费更多沟通时间。
+
+**Better CodeReview** 会在第一次给出完整的评论和修改建议，如果后续提交代码不符合预期，会立即与代码提交者当面沟通，避免异步沟通带来更多的理解偏差。
+
+> 补充一下，在 PR 内容过多时也可以选择直接与提交者当面沟通，这样可以更多理解作者的想法，使 Review 准确性更高。另外并不要每次都直接交流，异步的 CodeReview 本身就是一种提效方案，这会使你工作节奏把握在自己手中，仅在这种方案出现沟通问题时再选择当面交流。
+
+### 区分重点
+
+**Good CodeReview** 可以区分提示的重要程度，并在不太重要的改动前面加上 “nit:” 标记，这样可以使提交者的注意力集中在重要的问题上。
+
+**Better CodeReview** 会采取工具手段解决这些问题，比如一些代码 lint 工具，因为这些问题往往是可以被工具自动化解决的。
+
+> 代码自动化工具的目的，很大一部分也是为了保证代码一致性，从而降低 CodeReview 成本，也减少不重要的评论信息出现，让 CodeReview 尽可能反馈逻辑问题而不是格式问题。
+
+### 针对新人的 CodeReview
+
+**Good CodeReview** 对任何人都是用相同评判标准，可以遵循上面几点注意事项。
+
+**Better CodeReview** 会对新人区分对待，对新人给予对多的耐心、解释和评论，甚至给出解决方法，并更积极的给出鼓励。
+
+> 任何人到一家新公司都有适应过程，一视同仁是 base 要求，但如果能给予新人更多关怀就更好啦。
+
+### 跨办公区、时区的 CodeReview
+
+**Good CodeReview** 仅在工作时间有重叠的时间范围内进行 CodeReview，这样能保证对方可以积极响应，在必要时进行语音、视频沟通。
+
+**Better CodeReview** 会注意到更本质的问题，留意跨团队协作的必要性，如果某个模块经常被另一个时区同时修改，也许可以将这个模块交给对方维护，或者将 CodeReview 交给对方团队内部进行会更加高效。
+
+> 笔者所在公司也有跨时区协作情况，但绝大部分场景会避免跨时区的 CodeReview，因为 CodeReview 一般会在同一时区团队内部进行，这样效率更高，应对跨时区协作时，往往也是电话、视频会议优先。
+
+### 公司支持
+
+**Good CodeReview** 会得到公司组织支持，公司能意识到这么做虽然看起来占用开发时间，但长远来看提升了开发效率，因此能任何 CodeReview 价值。
+
+**Better CodeReview** 会得到公司进一步支持，公司甚至不断研发并完善 CodeReview 系统与流程，通过系统化方案保证上面几项 CodeReview 注意事项是否有在团队内落实，可以全员参与。
+
+> CodeReview 也是一种团队文化和公司文化，公司文化带来的是规章制度与系统工具，团队文化带来的是良好 CodeReview 氛围与更高 CodeReview 的效率。
+
+## 3 总结
+
+总结一下，良好的 CodeReview 需要做到以下几点：
+
+1. 更全面，从正确性到系统影响评估。
+2. 注意语气，从给出建设性一觉到换位思考。
+3. 及时完成审阅，从充分讨论到随机应变。
+4. 加强交流，从面对面交流到灵活选择最高效的沟通方式。
+5. 区分重点，从添加标记到利用工程化工具自动解决。
+6. 对新人要更友好。
+7. 尽量避免跨时区协作，必要时选择视频会议。
+
+最后，希望 CodeReview 能够得到公司的支持，如果你们公司还没有认可 CodeReview 的价值，可以将这篇文章分享给你的领导。
+
+> 讨论地址是：[精读《如何做好 CodeReview》 · Issue #237 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/237)
+
+**如果你想参与讨论，请 [点击这里](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)）

前沿技术/143.精读《Suspense 改变开发方式》.md

@@ -0,0 +1,302 @@
+## 1 引言
+
+很多人都用过 React Suspense，但如果你认为它只是配合 React.lazy 实现异步加载的蒙层，就理解的太浅了。实际上，React Suspense 改变了开发规则，要理解这一点，需要作出思想上的改变。
+
+我们结合 [Why React Suspense Will Be a Game Changer](https://medium.com/react-in-depth/why-react-suspense-will-be-a-game-changer-37b40fea71ec) 这篇文章，带你重新认识 React Suspense。
+
+## 2 概述
+
+异步加载是前端开发的重要环节，也是一直以来样板代码最严重的场景之一，原文通过三种取数方案的对比，逐渐找到一种最佳的异步取数方式。
+
+在讲解这三种取数方案之前，首先通过下面这张图说明了 Suspense 的功能：
+
+![](https://img.alicdn.com/tfs/TB12.npyoz1gK0jSZLeXXb9kVXa-1024-808.gif)
+
+从上图可以看出，子元素在异步取数时会阻塞父组件渲染，并一直冒泡到最外层第一个 Suspense，此时 Suspense 不会渲染子组件，而是渲染 `fallback`，当所有子组件异步阻塞取消后才会正常渲染。
+
+下面介绍文中给出的三种取数方式，首先是最原始的本地状态管理方案。
+
+### 本地异步状态管理，直白但不利于维护
+
+在 Suspense 方案出来之前，我们一般都在代码中利用本地状态管理异步数据。
+
+即便代码做了一定抽象，那也只是把逻辑从一个文件移到了另一个问题，可维护性与可拓展性都没有本质的改变，因此基本可以用下面的结构说明：
+
+```javascript
+class DynamicData extends Component {
+  state = {
+    loading: true,
+    error: null,
+    data: null
+  };
+
+  componentDidMount() {
+    fetchData(this.props.id)
+      .then(data => {
+        this.setState({
+          loading: false,
+          data
+        });
+      })
+      .catch(error => {
+        this.setState({
+          loading: false,
+          error: error.message
+        });
+      });
+  }
+
+  componentDidUpdate(prevProps) {
+    if (this.props.id !== prevProps.id) {
+      this.setState({ loading: true }, () => {
+        fetchData(this.props.id)
+          .then(data => {
+            this.setState({
+              loading: false,
+              data
+            });
+          })
+          .catch(error => {
+            this.setState({
+              loading: false,
+              error: error.message
+            });
+          });
+      });
+    }
+  }
+
+  render() {
+    const { loading, error, data } = this.state;
+    return loading ? (
+      <p>Loading...</p>
+    ) : error ? (
+      <p>Error: {error}</p>
+    ) : (
+      <p>Data loaded ?</p>
+    );
+  }
+}
+```
+
+如上所述，首先申明本地状态管理至少三种数据：异步状态、异步结果与异步错误，其次在不同的生命周期中处理初始化发请求与重新发请求的问题，最后在渲染函数中根据不同的状态渲染不同的结果，所以实际上我们写了三个渲染组件。
+
+从下面几个角度对上述代码进行评价：
+
+- **冗余的三种状态 - 糟糕的开发体验**
+  - 很明显，存储了三套数据，渲染三种结果，不利于开发维护。
+- **冗余的样板代码 - 糟糕的开发体验**
+  - 为了管理异步状态，上述代码非常冗长，显然这个问题是存在的。
+- **数据与状态封闭性 - 糟糕的用户体验 + 开发体验**
+  - 所有数据与状态管理都存储在每一个这种组件中，将取数状态与组件绑定的结果就是，我们只能忍受组件独立运行的 Loading 逻辑，而无法对他们进行统一管理。
+- **重新取数 - 糟糕的开发体验**
+  - 需要在另一个生命周期中申明重新取数，很明显是个麻烦的行为。
+- **一闪而过的短暂 Loading - 糟糕的用户体验**
+  - 如果用户网速足够快，则 Loading 时间会非常短，此时一闪而过的 Loading 反而比没有 Loading 更烦人，我们应该在用户感知到卡的时候再出现 Loading 状态。
+
+### Context 管理状态，有进步但问题依然很多
+
+如果利用 Context 做状态共享，我们将取数的数据管理与逻辑代码写在父组件，子组件专心用于展示，效果会好一些，代码如下：
+
+```javascript
+const DataContext = React.createContext();
+
+class DataContextProvider extends Component {
+  // We want to be able to store multiple sources in the provider,
+  // so we store an object with unique keys for each data set +
+  // loading state
+  state = {
+    data: {},
+    fetch: this.fetch.bind(this)
+  };
+
+  fetch(key) {
+    if (this.state[key] && (this.state[key].data || this.state[key].loading)) {
+      // Data is either already loaded or loading, so no need to fetch!
+      return;
+    }
+
+    this.setState(
+      {
+        [key]: {
+          loading: true,
+          error: null,
+          data: null
+        }
+      },
+      () => {
+        fetchData(key)
+          .then(data => {
+            this.setState({
+              [key]: {
+                loading: false,
+                data
+              }
+            });
+          })
+          .catch(e => {
+            this.setState({
+              [key]: {
+                loading: false,
+                error: e.message
+              }
+            });
+          });
+      }
+    );
+  }
+
+  render() {
+    return <DataContext.Provider value={this.state} {...this.props} />;
+  }
+}
+
+class DynamicData extends Component {
+  static contextType = DataContext;
+
+  componentDidMount() {
+    this.context.fetch(this.props.id);
+  }
+
+  componentDidUpdate(prevProps) {
+    if (this.props.id !== prevProps.id) {
+      this.context.fetch(this.props.id);
+    }
+  }
+
+  render() {
+    const { id } = this.props;
+    const { data } = this.context;
+
+    const idData = data[id];
+
+    return idData.loading ? (
+      <p>Loading...</p>
+    ) : idData.error ? (
+      <p>Error: {idData.error}</p>
+    ) : (
+      <p>Data loaded ?</p>
+    );
+  }
+}
+```
+
+`DataContextProvider` 组件承担了状态管理与异步逻辑工作，而 `DynamicData` 组件只需要从 Context 获取异步状态渲染即可，这样来看至少解决了一部分问题，我们还是从之前的角度进行评价：
+
+- **冗余的三种状态 - 糟糕的开发体验**
+  - 问题依然存在，只不过代码的位置转移了一部分到父组件。
+- **冗余的样板代码 - 糟糕的开发体验**
+  - 将展示与逻辑分离，成功降低了样板代码数量，至少当一个异步数据复用于多个组件时，不需要写多份样板代码了。
+- **数据与状态封闭性 - 糟糕的用户体验 + 开发体验**
+  - 这个问题得到一定程度解决，但是引入了新问题，即这个子组件仅在特定环境下可以正常运行。但在一个良好的设计下，组件运行不应该依赖于它所处的位置。
+- **重新取数 - 糟糕的开发体验**
+  - 问题依然存在。
+- **一闪而过的短暂 Loading - 糟糕的用户体验**
+  - 问题依然存在。
+
+### Suspense 管理状态，最棒的方案
+
+利用 Suspense 进行异步处理，代码处理大概是这样的：
+
+```javascript
+import createResource from "./magical-cache-provider";
+const dataResource = createResource(id => fetchData(id));
+
+class DynamicData extends Component {
+  render() {
+    const data = dataResource.read(this.props.id);
+    return <p>Data loaded ?</p>;
+  }
+}
+
+class App extends Component {
+  render() {
+    return (
+      <Suspense fallback={<p>Loading...</p>}>
+        <DeepNesting>
+          <DynamicData />
+        </DeepNesting>
+      </Suspense>
+    );
+  }
+}
+```
+
+在原文写作的时候，Suspense 仅能对 React.lazy 生效，但现在已经可以对任何异步状态生效了，只要符合 Pending 中 throw promise 的规则。
+
+我们再审视一下上面的代码，可以发现代码量减少了很多，其中和转换成 Function Component 的写法也有关系。
+
+最后还是从如下几个角度进行评价：
+
+- **冗余的三种状态 - 糟糕的开发体验** - ⭐️
+  - 可以看到，组件只要处理成功得到数据的状态即可，三种状态合并成了一种状态。
+- **冗余的样板代码 - 糟糕的开发体验** - ⭐️
+  - 展示与逻辑完全分离，展示只要拿到数据展示 UI 即可。
+- **数据与状态封闭性 - 糟糕的用户体验 + 开发体验** - ⭐️
+  - 这个问题得到了完美的解决，具体看下面详细介绍。
+- **重新取数 - 糟糕的开发体验** - ⭐️
+  - 不需要关心何时需要重新取数，当数据变化时会自动执行。
+- **一闪而过的短暂 Loading - 糟糕的用户体验**
+  - 问题依然存在。
+
+为了进一步说明 Suspense 的魔力，笔者特意把这段代码单独拿出来说明：
+
+```javascript
+class App extends Component {
+  render() {
+    return (
+      <Suspense fallback={<p>Loading...</p>}>
+        <DeepNesting>
+          <MaybeSomeAsycComponent />
+          <Suspense fallback={<p>Loading content...</p>}>
+            <ThereMightBeSeveralAsyncComponentsHere />
+          </Suspense>
+          <Suspense fallback={<p>Loading footer...</p>}>
+            <DeeplyNestedFooterTree />
+          </Suspense>
+        </DeepNesting>
+      </Suspense>
+    );
+  }
+}
+```
+
+上面代码表明了逻辑与展示的完美分离。
+
+从代码结构上来看，我们可以在任何需要异步取数的组件父级添加 Suspense 达到 Loading 的效果，也就是说，如果只在最外层加一个 Suspense，那么整个应用所有 Loading 都结束后才会渲染，然而我们也能随心所欲的在任何层级继续添加 Suspense，那么对应作用域内的 Loading 就会首先执行完毕，并由当前的 Suspense 控制。
+
+**这意味着我们可以自由决定 Loading 状态的范围组合。** 试想当 Loading 状态交由组件控制的方案一与方案二，是不可能做到合并 Loading 时机的，而 Suspense 方案做到了将 Loading 状态与 UI 分离，我们可以通过添加 Suspense 自由控制 Loading 的粒度。
+
+## 3 精读
+
+Suspense 对所有子组件异步都可以作用，因此无论是 React.lazy 还是异步取数，都可以通过 Suspense 进行 Pending。
+
+异步时机被 Suspense pending 需要遵循一定规则，这个规则在之前的 [精读《Hooks 取数 - swr 源码》](https://github.com/dt-fe/weekly/blob/v2/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) 有介绍过，即 Suspense 要求代码 suspended，即抛出一个可以被捕获的 Promise 异常，在这个 Promise 结束后再渲染组件，因此取数函数需要在 Pending 状态时抛出一个 Promise，使其可以被 Suspense 捕获到。
+
+另外，关于文中提到的 fallback 最小出现时间的保护间隔，目前还是一个 [Open Issue](https://github.com/facebook/react/issues/17351)，也许有一天 React 官方会提供支持。
+
+不过即便官方不支持，我们也有方式实现，即让这个逻辑由 fallback 组件实现：
+
+```jsx
+<Suspense fallback={MyFallback} />;
+
+const MyFallback = () => {
+  // 计时器，200 ms 以内 return null，200 ms 后 return <Spin />
+};
+```
+
+## 4 总结
+
+之所以说 Suspense 开发方式改变了开发规则，是因为它做到了将异步的状态管理与 UI 组件分离，所有 UI 组件都无需关心 Pending 状态，而是当作同步去执行，这本身就是一个巨大的改变。
+
+另外由于状态的分离，我们可以利用纯 UI 组件拼装任意粒度的 Pending 行为，以整个 App 作为一个大的 Suspense 作为兜底，这样 UI 彻底与异步解耦，哪里 Loading，什么范围内 Loading，完全由 Suspense 组合方式决定，这样的代码显然具备了更强的可拓展性。
+
+> 讨论地址是：[精读《Suspense 改变开发方式》 · Issue #238 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/238)
+
+**如果你想参与讨论，请 [点击这里](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)）

前沿技术/144.精读《Webpack5 新特性 - 模块联邦》.md

@@ -0,0 +1,132 @@
+## 1 引言
+
+先说结论：Webpack5 模块联邦让 Webpack 达到了线上 Runtime 的效果，让代码直接在项目间利用 CDN 直接共享，不再需要本地安装 Npm 包、构建再发布了！
+
+我们知道 Webpack 可以通过 DLL 或者 Externals 做代码共享时 Common Chunk，但不同应用和项目间这个任务就变得困难了，我们几乎无法在项目之间做到按需热插拔。
+
+模块联邦是 Webpack5 新内置的一个重要功能，可以让跨应用间真正做到模块共享，所以这周让我们通过 [webpack-5-module-federation-a-game-changer-in-javascript-architecture](https://indepth.dev/webpack-5-module-federation-a-game-changer-in-javascript-architecture/#its-important-to-note-these-are-special-entry-points-they-are-only-a-few-kb-in-size-containing-a-special-webpack-runtime-that-can-interface-with-the-host-it-is-not-a-standard-entry-point--7/) 这篇文章了解什么是 “模块联邦” 功能。
+
+## 2 概述 & 精读
+
+### NPM 方式共享模块
+
+想象一下正常的共享模块方式，对，就是 NPM。
+
+如下图所示，正常的代码共享需要将依赖作为 Lib 安装到项目，进行 Webpack 打包构建再上线，如下图：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1MoLPy.z1gK0jSZLeXXb9kVXa-2494-1478.png">
+
+对于项目 Home 与 Search，需要共享一个模块时，最常见的办法就是将其抽成通用依赖并分别安装在各自项目中。
+
+虽然 Monorepo 可以一定程度解决重复安装和修改困难的问题，但依然需要走本地编译。
+
+### UMD 方式共享模块
+
+真正 Runtime 的方式可能是 UMD 方式共享代码模块，即将模块用 Webpack UMD 模式打包，并输出到其他项目中。这是非常普遍的模块共享方式：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1rQnSy4n1gK0jSZKPXXXvUXXa-2404-1484.png">
+
+对于项目 Home 与 Search，直接利用 UMD 包复用一个模块。但这种技术方案问题也很明显，就是包体积无法达到本地编译时的优化效果，且库之间容易冲突。
+
+### 微前端方式共享模块
+
+微前端：micro-frontends (MFE) 也是最近比较火的模块共享管理方式，微前端就是要解决多项目并存问题，多项目并存的最大问题就是模块共享，不能有冲突。
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1vqvTy1T2gK0jSZFvXXXnFXXa-2410-1520.png">
+
+由于微前端还要考虑样式冲突、生命周期管理，所以本文只聚焦在资源加载方式上。微前端一般有两种打包方式：
+
+1. 子应用独立打包，模块更解耦，但无法抽取公共依赖等。
+2. 整体应用一起打包，很好解决上面的问题，但打包速度实在是太慢了，不具备水平扩展能力。
+
+### 模块联邦方式
+
+终于提到本文的主角了，作为 Webpack5 内置核心特性之一的 Federated Module：
+
+<img width=500 src="https://img.alicdn.com/tfs/TB1qLz1yYj1gK0jSZFuXXcrHpXa-2414-1474.png">
+
+从图中可以看到，这个方案是直接将一个应用的包应用于另一个应用，同时具备整体应用一起打包的公共依赖抽取能力。
+
+让应用具备模块化输出能力，其实开辟了一种新的应用形态，即 “中心应用”，这个中心应用用于在线动态分发 Runtime 子模块，并不直接提供给用户使用：
+
+<img width=300 src="https://img.alicdn.com/tfs/TB1ymbWy7Y2gK0jSZFgXXc5OFXa-1346-1442.png">
+
+对微前端而言，这张图就是一个完美的主应用，因为所有子应用都可以利用 Runtime 方式复用主应用的 Npm 包和模块，更好的集成到主应用中。
+
+模块联邦的使用方式如下：
+
+```js
+const HtmlWebpackPlugin = require("html-webpack-plugin");
+const ModuleFederationPlugin = require("webpack/lib/container/ModuleFederationPlugin");
+
+module.exports = {
+  // other webpack configs...
+  plugins: [
+    new ModuleFederationPlugin({
+      name: "app_one_remote",
+      remotes: {
+        app_two: "app_two_remote",
+        app_three: "app_three_remote"
+      },
+      exposes: {
+        AppContainer: "./src/App"
+      },
+      shared: ["react", "react-dom", "react-router-dom"]
+    }),
+    new HtmlWebpackPlugin({
+      template: "./public/index.html",
+      chunks: ["main"]
+    })
+  ]
+};
+```
+
+模块联邦本身是一个普通的 Webpack 插件 `ModuleFederationPlugin`，插件有几个重要参数：
+
+1. `name` 当前应用名称，需要全局唯一。
+2. `remotes` 可以将其他项目的 `name` 映射到当前项目中。
+3. `exposes` 表示导出的模块，只有在此申明的模块才可以作为远程依赖被使用。
+4. `shared` 是非常重要的参数，制定了这个参数，可以让远程加载的模块对应依赖改为使用本地项目的 React 或 ReactDOM。
+
+比如设置了 `remotes: { app_two: "app_two_remote" }`，在代码中就可以直接利用以下方式直接从对方应用调用模块：
+
+```js
+import { Search } from "app_two/Search";
+```
+
+这个 `app_two/Search` 来自于 `app_two` 的配置：
+
+```js
+// app_two 的 webpack 配置
+export default {
+  plugins: [
+    new ModuleFederationPlugin({
+      name: "app_two",
+      library: { type: "var", name: "app_two" },
+      filename: "remoteEntry.js",
+      exposes: {
+        Search: "./src/Search"
+      },
+      shared: ["react", "react-dom"]
+    })
+  ]
+};
+```
+
+正是因为 `Search` 在 `exposes` 被导出，我们因此可以使用 `[name]/[exposes_name]` 这个模块，这个模块对于被引用应用来说是一个本地模块。
+
+## 3 总结
+
+模块联邦为更大型的前端应用提供了开箱解决方案，并已经作为 Webpack5 官方模块内置，可以说是继 Externals 后最终的运行时代码复用解决方案。
+
+另外 Webpack5 还内置了大量编译时缓存功能，可以看到，无论是性能还是多项目组织，Webpack5 都在尝试给出自己的最佳思路，期待 Webpack5 正式发布，前端工程化会迈向一个新的阶段。
+
+> 讨论地址是：[精读《Webpack5 新特性 - 模块联邦》 · Issue #239 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/239)
+
+**如果你想参与讨论，请 [点击这里](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)）

前沿技术/145.精读《React Router v6》.md

@@ -0,0 +1,384 @@
+## 1 引言
+
+[React Router v6](https://github.com/ReactTraining/react-router) alpha 版本发布了，本周通过 [A Sneak Peek at React Router v6](https://alligator.io/react/react-router-v6/) 这篇文章分析一下带来的改变。
+
+## 2 概述
+
+### <Switch> 更名为 <Routes>
+
+一个不痛不痒的改动，使 API 命名更加规范。
+
+```jsx
+// v5
+import { BrowserRouter, Switch, Route } from "react-router-dom";
+
+function App() {
+  return (
+    <BrowserRouter>
+      <Switch>
+        <Route exact path="/">
+          <Home />
+        </Route>
+        <Route path="/profile">
+          <Profile />
+        </Route>
+      </Switch>
+    </BrowserRouter>
+  );
+}
+```
+
+在 React Router v6 版本里，直接使用 `Routes` 替代 `Switch`：
+
+```jsx
+// v6
+import { BrowserRouter, Routes, Route } from "react-router-dom";
+
+function App() {
+  return (
+    <BrowserRouter>
+      <Routes>
+        <Route path="/" element={<Home />} />
+        <Route path="profile/*" element={<Profile />} />
+      </Routes>
+    </BrowserRouter>
+  );
+}
+```
+
+### <Route> 升级
+
+在 v5 版本里，想要给组件传参数是不太直观的，需要利用 RenderProps 的方式透传 `routeProps`：
+
+```jsx
+import Profile from './Profile';
+
+// v5
+<Route path=":userId" component={Profile} />
+<Route
+  path=":userId"
+  render={routeProps => (
+    <Profile {...routeProps} animate={true} />
+  )}
+/>
+
+// v6
+<Route path=":userId" element={<Profile />} />
+<Route path=":userId" element={<Profile animate={true} />} />
+```
+
+而在 v6 版本中，`render` 与 `component` 方案合并成了 `element` 方案，可以轻松传递 props 且不需要透传 `roteProps` 参数。
+
+### 更方便的嵌套路由
+
+在 v5 版本中，嵌套路由需要通过 `useRouteMatch` 拿到 `match`，并通过 `match.path` 的拼接实现子路由：
+
+```jsx
+// v5
+import {
+  BrowserRouter,
+  Switch,
+  Route,
+  Link,
+  useRouteMatch
+} from "react-router-dom";
+
+function App() {
+  return (
+    <BrowserRouter>
+      <Switch>
+        <Route exact path="/" component={Home} />
+        <Route path="/profile" component={Profile} />
+      </Switch>
+    </BrowserRouter>
+  );
+}
+
+function Profile() {
+  let match = useRouteMatch();
+
+  return (
+    <div>
+      <nav>
+        <Link to={`${match.url}/me`}>My Profile</Link>
+      </nav>
+
+      <Switch>
+        <Route path={`${match.path}/me`}>
+          <MyProfile />
+        </Route>
+        <Route path={`${match.path}/:id`}>
+          <OthersProfile />
+        </Route>
+      </Switch>
+    </div>
+  );
+}
+```
+
+在 v6 版本中省去了 `useRouteMatch` 这一步，支持直接用 `path` 表示相对路径：
+
+```jsx
+// v6
+import { BrowserRouter, Routes, Route, Link, Outlet } from "react-router-dom";
+
+// Approach #1
+function App() {
+  return (
+    <BrowserRouter>
+      <Routes>
+        <Route path="/" element={<Home />} />
+        <Route path="profile/*" element={<Profile />} />
+      </Routes>
+    </BrowserRouter>
+  );
+}
+
+function Profile() {
+  return (
+    <div>
+      <nav>
+        <Link to="me">My Profile</Link>
+      </nav>
+
+      <Routes>
+        <Route path="me" element={<MyProfile />} />
+        <Route path=":id" element={<OthersProfile />} />
+      </Routes>
+    </div>
+  );
+}
+
+// Approach #2
+// You can also define all
+// <Route> in a single place
+function App() {
+  return (
+    <BrowserRouter>
+      <Routes>
+        <Route path="/" element={<Home />} />
+        <Route path="profile" element={<Profile />}>
+          <Route path=":id" element={<MyProfile />} />
+          <Route path="me" element={<OthersProfile />} />
+        </Route>
+      </Routes>
+    </BrowserRouter>
+  );
+}
+
+function Profile() {
+  return (
+    <div>
+      <nav>
+        <Link to="me">My Profile</Link>
+      </nav>
+
+      <Outlet />
+    </div>
+  );
+}
+```
+
+注意 `Outlet` 是渲染子路由的 Element。
+
+### useNavigate 替代 useHistory
+
+在 v5 版本中，主动跳转路由可以通过 `useHistory` 进行 `history.push` 等操作：
+
+```jsx
+// v5
+import { useHistory } from "react-router-dom";
+
+function MyButton() {
+  let history = useHistory();
+  function handleClick() {
+    history.push("/home");
+  }
+  return <button onClick={handleClick}>Submit</button>;
+}
+```
+
+而在 v6 版本中，可以通过 `useNavigate` 直接实现这个常用操作：
+
+```jsx
+// v6
+import { useNavigate } from "react-router-dom";
+
+function MyButton() {
+  let navigate = useNavigate();
+  function handleClick() {
+    navigate("/home");
+  }
+  return <button onClick={handleClick}>Submit</button>;
+}
+```
+
+react-router 内部对 history 进行了封装，如果需要 `history.replace`，可以通过 `{ replace: true }` 参数指定：
+
+```jsx
+// v5
+history.push("/home");
+history.replace("/home");
+
+// v6
+navigate("/home");
+navigate("/home", { replace: true });
+```
+
+### 更小的体积 8kb
+
+由于代码几乎重构，v6 版本的代码压缩后体积从 20kb 缩小到 8kb。
+
+## 3 精读
+
+react-router v6 源码中有一段比较核心的理念，笔者拿出来与大家分享，对一些框架开发是大有裨益的。我们看 `useRoutes` 这段代码节选：
+
+```jsx
+export function useRoutes(routes, basename = "", caseSensitive = false) {
+  let {
+    params: parentParams,
+    pathname: parentPathname,
+    route: parentRoute
+  } = React.useContext(RouteContext);
+
+  if (warnAboutMissingTrailingSplatAt) {
+    // ...
+  }
+
+  basename = basename ? joinPaths([parentPathname, basename]) : parentPathname;
+
+  let navigate = useNavigate();
+  let location = useLocation();
+  let matches = React.useMemo(
+    () => matchRoutes(routes, location, basename, caseSensitive),
+    [routes, location, basename, caseSensitive]
+  );
+
+  // ...
+
+  // Otherwise render an element.
+  let element = matches.reduceRight((outlet, { params, pathname, route }) => {
+    return (
+      <RouteContext.Provider
+        children={route.element}
+        value={{
+          outlet,
+          params: readOnly({ ...parentParams, ...params }),
+          pathname: joinPaths([basename, pathname]),
+          route
+        }}
+      />
+    );
+  }, null);
+
+  return element;
+}
+```
+
+可以看到，利用 `React.Context`，v6 版本在每个路由元素渲染时都包裹了一层 `RouteContext`。
+
+拿更方便的路由嵌套来说：
+
+> 在 v6 版本中省去了 `useRouteMatch` 这一步，支持直接用 `path` 表示相对路径。
+
+这就是利用这个方案做到的，因为给每一层路由文件包裹了 Context，所以在每一层都可以拿到上一层的 `path`，因此在拼接路由时可以完全由框架内部实现，而不需要用户在调用时预先拼接好。
+
+再以 `useNavigate` 举例，有人觉得 `navigate` 这个封装仅停留在形式层，但其实在功能上也有封装，比如如果传入但是一个相对路径，会根据当前路由进行切换，下面是 `useNavigate` 代码节选：
+
+```jsx
+export function useNavigate() {
+  let { history, pending } = React.useContext(LocationContext);
+  let { pathname } = React.useContext(RouteContext);
+
+  let navigate = React.useCallback(
+    (to, { replace, state } = {}) => {
+      if (typeof to === "number") {
+        history.go(to);
+      } else {
+        let relativeTo = resolveLocation(to, pathname);
+
+        let method = !!replace || pending ? "replace" : "push";
+        history[method](relativeTo, state);
+      }
+    },
+    [history, pending, pathname]
+  );
+
+  return navigate;
+}
+```
+
+可以看到，利用 `RouteContext` 拿到当前的 `pathname`，并根据 `resolveLocation` 对 `to` 与 `pathname` 进行路径拼接，而 `pathname` 就是通过 `RouteContext.Provider` 提供的。
+
+### 巧用多层 Context Provider
+
+很多时候我们利用 Context 停留在一个 `Provider`，多个 `useContext` 的层面上，这是 Context 最基础的用法，但相信读完 React Router v6 这篇文章，我们可以挖掘出 Context 更多的用法：多层 Context Provider。
+
+**虽然说 Context Provider 存在多层会采取最近覆盖的原则，但这不仅仅是一条规避错误的功能，我们可以利用这个功能实现 React Router v6 这样的改良。**
+
+为了更仔细说明这个特性，这里再举一个具体的例子：比如实现搭建渲染引擎时，每个组件都有一个 id，但这个 id 并不透出在组件的 props 上：
+
+```jsx
+const Input = () => {
+  // Input 组件在画布中会自动生成一个 id，但这个 id 组件无法通过 props 拿到
+};
+```
+
+此时如果我们允许 Input 组件内部再创建一个子元素，又希望这个子元素的 id 是由 Input 推导出来的，我们可能需要用户这么做：
+
+```jsx
+const Input = ({ id }) => {
+  return <ComponentLoader id={id + "1"} />;
+};
+```
+
+这样做有两个问题：
+
+1. 将 id 暴露给 Input 组件，违背了之前设计的简洁性。
+2. 组件需要对 id 进行拼装，很麻烦。
+
+这里遇到的问题和 React Router 遇到的一样，我们可以将代码简化成下面这样，但功能不变吗？
+
+```jsx
+const Input = () => {
+  return <ComponentLoader id="1" />;
+};
+```
+
+答案是可以做到，我们可以利用 Context 实现这种方案。关键点就在于，渲染 Input 但组件容器需要包裹一个 Provider：
+
+```jsx
+const ComponentLoader = ({ id, element }) => {
+  <Context.Provider value={{ id }}>{element}</Context.Provider>;
+};
+```
+
+那么对于内部的组件来说，在不同层级下调用 `useContext` 拿到的 id 是不同的，这正是我们想要的效果：
+
+```jsx
+const ComponentLoader = ({id,element}) => {
+  const { id: parentId } = useContext(Context)
+
+  <Context.Provider value={{ id: parentId + id }}>
+    {element}
+  </Context.Provider>
+}
+```
+
+这样我们在 `Input` 内部调用的 `<ComponentLoader id="1" />` 实际上拼接的实际 id 是 `01`，而这完全抛到了外部引擎层处理，用户无需手动拼接。
+
+## 4 总结
+
+React Router v6 完全利用 Hooks 重构后，不仅代码量精简了很多，还变得更好用了，等发正式版的时候可以快速升级一波。
+
+另外从 React Router v6 做的这些优化中，我们从源码中挖掘到了关于 Context 更巧妙的用法，希望这个方法可以帮助你运用到其他更复杂的项目设计中。
+
+> 讨论地址是：[精读《React Router v6》 · Issue #241 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/241)
+
+**如果你想参与讨论，请 [点击这里](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)）

前沿技术/146.精读《React Hooks 数据流》.md

@@ -0,0 +1,354 @@
+## 1 引言
+
+React Hooks 渐渐被国内前端团队所接受，但基于 Hooks 的数据流方案却还未固定，我们有 “100 种” 类似的选择，却各有利弊，让人难以取舍。
+
+本周笔者就深入谈一谈对 Hooks 数据流的理解，相信读完文章后，可以从百花齐放的 Hooks 数据流方案中看到本质。
+
+## 2 精读
+
+基于 React Hooks 谈数据流，我们先从最不容易产生分歧的基础方案说起。
+
+### 单组件数据流
+
+单组件最简单的数据流一定是 `useState`：
+
+```jsx
+function App() {
+  const [count, setCount] = useState();
+}
+```
+
+`useState` 在组件内用是毫无争议的，那么下个话题就一定是跨组件共享数据流了。
+
+### 组件间共享数据流
+
+跨组件最简单的方案就是 `useContext`：
+
+```jsx
+const CountContext = createContext();
+
+function App() {
+  const [count, setCount] = useState();
+  return (
+    <CountContext.Provider value={{ count, setCount }}>
+      <Child />
+    </CountContext.Provider>
+  );
+}
+
+function Child() {
+  const { count } = useContext(CountContext);
+}
+```
+
+用法都是官方 API，显然也是毫无争议的，但问题是数据与 UI 不解耦，这个问题 [unstated-next](https://github.com/jamiebuilds/unstated-next) 已经为你想好解决方案了。
+
+### 数据流与组件解耦
+
+[unstated-next](https://github.com/jamiebuilds/unstated-next) 可以帮你把上面例子中，定义在 `App` 中的数据单独出来，形成一个自定义数据管理 Hook：
+
+```jsx
+import { createContainer } from "unstated-next";
+
+function useCounter() {
+  const [count, setCount] = useState();
+  return { count, setCount };
+}
+
+const Counter = createContainer(useCounter);
+
+function App() {
+  return (
+    <Counter.Provider>
+      <Child />
+    </Counter.Provider>
+  );
+}
+
+function Child() {
+  const { count } = Counter.useContainer();
+}
+```
+
+数据与 `App` 就解耦了，这下 `Counter` 再也不和 `App` 绑定了，`Counter` 可以和其他组件绑定作用了。
+
+这个时候性能问题就慢慢浮出了水面，首当其冲的就是 `useState` 无法合并更新的问题，我们自然想到利用 `useReducer` 解决。
+
+### 合并更新
+
+`useReducer` 可以让数据合并更新，这也是 React 官方 API，毫无争议：
+
+```jsx
+import { createContainer } from "unstated-next";
+
+function useCounter() {
+  const [state, dispath] = useReducer(
+    (state, action) => {
+      switch (action.type) {
+        case "setCount":
+          return {
+            ...state,
+            count: action.setCount(state.count),
+          };
+        case "setFoo":
+          return {
+            ...state,
+            foo: action.setFoo(state.foo),
+          };
+        default:
+          return state;
+      }
+      return state;
+    },
+    { count: 0, foo: 0 }
+  );
+
+  return { ...state, dispatch };
+}
+
+const Counter = createContainer(useCounter);
+
+function App() {
+  return (
+    <Counter.Provider>
+      <Child />
+    </Counter.Provider>
+  );
+}
+
+function Child() {
+  const { count } = Counter.useContainer();
+}
+```
+
+这下即便要同时更新 `count` 和 `foo`，我们也能通过抽象成一个 `reducer` 的方式合并更新。
+
+然而还有性能问题：
+
+```jsx
+function ChildCount() {
+  const { count } = Counter.useContainer();
+}
+
+function ChildFoo() {
+  const { foo } = Counter.useContainer();
+}
+```
+
+更新 `foo` 时，`ChildCount` 和 `ChildFoo` 同时会执行，但 `ChildCount` 没用到 `foo` 呀？这个原因是 `Counter.useContainer` 提供的数据流是一个引用整体，其子节点 `foo` 引用变化后会导致整个 Hook 重新执行，继而所有引用它的组件也会重新渲染。
+
+此时我们发现可以利用 Redux `useSelector` 实现按需更新。
+
+### 按需更新
+
+首先我们利用 Redux 对数据流做一次改造：
+
+```jsx
+import { createStore } from "redux";
+import { Provider, useSelector } from "react-redux";
+
+function reducer(state, action) {
+  switch (action.type) {
+    case "setCount":
+      return {
+        ...state,
+        count: action.setCount(state.count),
+      };
+    case "setFoo":
+      return {
+        ...state,
+        foo: action.setFoo(state.foo),
+      };
+    default:
+      return state;
+  }
+  return state;
+}
+
+function App() {
+  return (
+    <Provider store={store}>
+      <Child />
+    </Provider>
+  );
+}
+
+function Child() {
+  const { count } = useSelector(
+    (state) => ({ count: state.count }),
+    shallowEqual
+  );
+}
+```
+
+`useSelector` 可以让 `Child` 在 `count` 变化时才更新，而 `foo` 变化时不更新，这已经接近较为理想的性能目标了。
+
+但 `useSelector` 的作用仅仅是计算结果不变化时阻止组件刷新，但并不能保证返回结果的引用不变化。
+
+### 防止数据引用频繁变化
+
+对于上面的场景，拿到 `count` 的引用是不变的，**但对于其他场景就不一定了**。
+
+举个例子：
+
+```jsx
+function Child() {
+  const user = useSelector((state) => ({ user: state.user }), shallowEqual);
+
+  return <UserPage user={user} />;
+}
+```
+
+**假设 `user` 对象在每次数据流更新引用都会发生变化**，那么 `shallowEqual` 自然是不起作用，那我们换成 `deepEqual`深对比呢？结果是引用依然会变，只是重渲染不那么频繁了：
+
+```jsx
+function Child() {
+  const user = useSelector(
+    (state) => ({ user: state.user }),
+    // 当 user 值变化时才重渲染
+    deepEqual
+  );
+
+  // 但此处拿到的 user 引用还是会变化
+
+  return <UserPage user={user} />;
+}
+```
+
+是不是觉得在 `deepEqual` 的作用下，没有触发重渲染，`user` 的引用就不会变呢？答案是会变，因为 `user` 对象在每次数据流更新都会变，`useSelector` 在 `deepEqual` 作用下没有触发重渲染，但因为全局 reducer 隐去组件自己的重渲染依然会重新执行此函数，此时拿到的 `user` 引用会不断变化。
+
+因此 `useSelector` `deepEqual` 一定要和 `useDeepMemo` 结合使用，才能保证 `user` 引用不会频繁改变：
+
+```jsx
+function Child() {
+  const user = useSelector(
+    (state) => ({ user: state.user }),
+    // 当 user 值变化时才重渲染
+    deepEqual
+  );
+
+  const userDeep = useDeepMemo(() => user, [user]);
+
+  return <UserPage user={userDeep} />;
+}
+```
+
+当然这是比较极端的情况，只要看到 `deepEqual` 与 `useSelector` 同时作用了，就要问问自己其返回的值的引用会不会发生意外变化。
+
+### 缓存查询函数
+
+对于极限场景，即便控制了重渲染次数与返回结果的引用最大程度不变，还是可能存在性能问题，这最后一块性能问题就处在查询函数上。
+
+上面的例子中，查询函数比较简单，但如果查询函数非常复杂就不一样了：
+
+```jsx
+function Child() {
+  const user = useSelector(
+    (state) => ({ user: verySlowFunction(state.user) }),
+    // 当 user 值变化时才重渲染
+    deepEqual
+  );
+
+  const userDeep = useDeepMemo(() => user, [user]);
+
+  return <UserPage user={userDeep} />;
+}
+```
+
+我们假设 `verySlowFunction` 要遍历画布中 1000 个组件的 n 3 次方次，那组件的重渲染时间消耗与查询时间相比完全不值一提，我们需要考虑缓存查询函数。
+
+一种方式是利用 [reselect](https://github.com/reduxjs/reselect) 根据参数引用进行缓存。
+
+想象一下，如果 `state.user` 的引用不频繁变化，但 `verySlowFunction` 非常慢，理想情况是 `state.user` 引用变化后才重新执行 `verySlowFunction`，但上面的例子中，`useSelector` 并不知道还能这么优化，只能傻傻的每次渲染重复执行 `verySlowFunction`，哪怕 `state.user` 没有变。
+
+此时我们要告诉引用，`state.user` 是否变化才是重新执行的关键：
+
+```jsx
+import { createSelector } from "reselect";
+
+const userSelector = createSelector(
+  (state) => state.user,
+  (user) => verySlowFunction(user)
+);
+
+function Child() {
+  const user = useSelector(
+    (state) => userSelector(state),
+    // 当 user 值变化时才重渲染
+    deepEqual
+  );
+
+  const userDeep = useDeepMemo(() => user, [user]);
+
+  return <UserPage user={userDeep} />;
+}
+```
+
+在上面的例子中，通过 `createSelector` 创建的 `userSelector` 会一层层进行缓存，当第一个参数返回的 `state.user` 引用不变时，会直接返回上一次执行结果，直到其应用变化了才会继续往下执行。
+
+> 这也说明了函数式保持幂等的重要性，如果 `verySlowFunction` 不是严格幂等的，这种缓存也无法实施。
+
+看上去很美好，然而实战中你可能发现没有那么美好，因为上面的例子都建立在 **Selector 完全不依赖外部变量**。
+
+### 结合外部变量的缓存查询
+
+如果我们要查询的用户来自于不同地区，需要传递 `areaId` 加以识别，那么可以拆分为两个 Selector 函数：
+
+```jsx
+import { createSelector } from "reselect";
+
+const areaSelector = (state, props) => state.areas[props.areaId].user;
+
+const userSelector = createSelector(areaSelector, (user) =>
+  verySlowFunction(user)
+);
+
+function Child() {
+  const user = useSelector(
+    (state) => userSelector(state, { areaId: 1 }),
+    deepEqual
+  );
+
+  const userDeep = useDeepMemo(() => user, [user]);
+
+  return <UserPage user={userDeep} />;
+}
+```
+
+所以为了不在组件函数内调用 `createSelector`，我们需要尽可能将用到外部变量的地方抽象成一个通用 Selector，并作为 `createSelector` 的一个先手环节。
+
+但 `userSelector` 提供给多个组件使用时缓存会失效，原因是我们只创建了一个 Selector 实例，因此这个函数还需要再包装一层高阶形态：
+
+```jsx
+import { createSelector } from "reselect";
+
+const userSelector = () =>
+  createSelector(areaSelector, (user) => verySlowFunction(user));
+
+function Child() {
+  const customSelector = useMemo(userSelector, []);
+
+  const user = useSelector(
+    (state) => customSelector(state, { areaId: 1 }),
+    deepEqual
+  );
+}
+```
+
+所以对于外部变量结合的环节，还需要 `useMemo` 与 `useSelector` 结合使用，`useMemo` 处理外部变量依赖的引用缓存，`useSelector` 处理 Store 相关引用缓存。
+
+## 3 总结
+
+基于 Hooks 的数据流方案不能算完美，我在写作这篇文章时就感觉到这种方案属于 “浅入深出”，简单场景还容易理解，随着场景逐步复杂，方案也变得越来越复杂。
+
+但这种 Immutable 的数据流管理思路给了开发者非常自由的缓存控制能力，只要透彻理解上述概念，就可以开发出非常 “符合预期” 的数据缓存管理模型，只要精心维护，一切就变得非常有秩序。
+
+> 讨论地址是：[精读《React Hooks 数据流》 · Issue #242 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/242)
+
+**如果你想参与讨论，请 [点击这里](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)）

前沿技术/147. 精读《@types react 值得注意的 TS 技巧》.md

@@ -0,0 +1,141 @@
+## 1 引言
+
+从 [@types/react](https://unpkg.com/browse/@types/react@16.9.34/index.d.ts) 源码中挖掘一些 Typescript 使用技巧吧。
+
+## 2 精读
+
+### 泛型 extends
+
+泛型可以指代可能的参数类型，但指代任意类型范围太模糊，当我们需要对参数类型加以限制，或者确定只处理某种类型参数时，就可以对泛型进行 extends 修饰。
+
+问题：`React.lazy` 需要限制返回值是一个 `Promise<T>` 类型，且 `T` 必须是 React 组件类型。
+
+方案：
+
+```typescript
+function lazy<T extends ComponentType<any>>(
+  factory: () => Promise<{ default: T }>
+): LazyExoticComponent<T>;
+```
+
+`T extends ComponentType` 确保了 T 这个类型一定符合 `ComponentType` 这个 React 组件类型定义，我们再将 T 用到 `Promise<{ default: T }>` 位置即可。
+
+## 泛型 extends + infer
+
+如果有一种场景，需要拿到一个类型，这个类型是当某个参数符合某种结构时，这个结构内的一种子类型，就需要结合 泛型 extends + infer 了。
+
+问题：`React.useReducer` 第一个参数是 Reducer，第二个参数是初始化参数，其实第二个参数的类型是第一个参数中回调函数第一个参数的类型，那我们怎么将这两个参数的关系联系到一起呢？
+
+方案：
+
+```typescript
+function useReducer<R extends Reducer<any, any>, I>(
+  reducer: R,
+  initializerArg: I & ReducerState<R>,
+  initializer: (arg: I & ReducerState<R>) => ReducerState<R>
+): [ReducerState<R>, Dispatch<ReducerAction<R>>];
+
+type ReducerState<R extends Reducer<any, any>> = R extends Reducer<infer S, any>
+  ? S
+  : never;
+```
+
+`R extends Reducer<any, any>` 的意思在上面已经提过了，也就是 R 必须符合 `Reducer` 结构，也就是 `reducer` 必须符合这个结构，之后重点来了：`initializerArg` 利用 `ReducerState` 这个类型直接从 `reducer` 的类型 `R` 中将第一个回调参数挖了出来并返回。
+
+`ReducerState` 定义中 `R extends Reducer<infer S, any> ? S : never` 的含义是：如果 R 符合 `Reducer<infer S, any>` 类型，则返回类型 `S`，这个 `S` 是 `Reducer<infer S>` 也就是 State 位置的类型，否则返回 `never` 类型。
+
+所以 infer 表示待推断类型，是非常强大的功能，可以指定在任意位置代指其类型，并配合 extends 判断是否符合结构，可以使类型推断具备一定编程能力。
+
+要用 extends 的另一个原因是，只有 extends 才能将结构描述出来，我们才能精确定义 infer 指代类型的位置。
+
+### 类型重载
+
+当一个类型拥有多种使用可能性时，可以采用类型重载定义复数类型，Typescript 作用时会逐个匹配并找到第一个满足条件的。
+
+问题：`createElement` 第一个参数支持 FunctionComponent 与 ClassComponent，而且传入参数不同，返回值的类型也不同。
+
+方案：
+
+```typescript
+function createElement<P extends {}>(
+  type: FunctionComponent<P>,
+  props?: (Attributes & P) | null,
+  ...children: ReactNode[]
+): FunctionComponentElement<P>;
+function createElement<P extends {}>(
+  type: ClassType<
+    P,
+    ClassicComponent<P, ComponentState>,
+    ClassicComponentClass<P>
+  >,
+  props?: (ClassAttributes<ClassicComponent<P, ComponentState>> & P) | null,
+  ...children: ReactNode[]
+): CElement<P, ClassicComponent<P, ComponentState>>;
+```
+
+将 `createElement` 写两遍及以上，并配合不同的参数类型与返回值类型即可。
+
+### 自定义类型收窄
+
+我们可以通过 `typeof` 或 `instanceof` 做一些类型收窄工作，但有些类型甚至自定义类型的收窄判断函数需要自定义，我们可以通过 `is` 关键字定义自定义类型收窄判断函数。
+
+问题：`isValidElement` 判断对象是否是合法的 React 元素，我们希望这个函数具备类型收窄的功能。
+
+方案：
+
+```typescript
+function isValidElement<P>(
+  object: {} | null | undefined
+): object is ReactElement<P>;
+
+const element: string | ReactElement = "";
+
+if (isValidElement(element)) {
+  element; // 自动推导类型为 ReactElement
+} else {
+  element; // 自动推导类型为 string
+}
+```
+
+基于这个方案，我们可以创建一些很有用的函数，比如 `isArray`，`isMap`，`isSet` 等等，通过 `is` 关键字时其被调用时具备类型收窄的功能。
+
+### 用 Interface 定义函数
+
+一般定义函数类型我们用 `type`，但有些情况下定义的函数既可被调用，也有一些默认属性值需要定义，我们可以继续用 Interface 定义。
+
+问题：`FunctionComponent` 既可以当作函数调用，同时又能定义 `defaultProps` `displayName` 等固定属性。
+
+方案：
+
+```typescript
+interface FunctionComponent<P = {}> {
+  (props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null;
+  propTypes?: WeakValidationMap<P>;
+  contextTypes?: ValidationMap<any>;
+  defaultProps?: Partial<P>;
+  displayName?: string;
+}
+```
+
+`(props: PropsWithChildren<P>, context?: any): ReactElement<any, any> | null` 表示这种类型的变量可以作为函数执行：
+
+```jsx
+const App: FunctionComponent = () => <div />;
+App.displayName = "App";
+```
+
+## 3 总结
+
+看完文章内容，相信你已经可以独立读懂 [@types/react](https://unpkg.com/browse/@types/react@16.9.34/index.d.ts) 这个包的所有类型定义！ 
+
+更多基础内容可以阅读 [精读《Typescript2.0 - 2.9》](https://github.com/dt-fe/weekly/blob/7de3c77c3bdd7304c9e4b0c0f70c3ba6968ebd29/058.%E7%B2%BE%E8%AF%BB%E3%80%8ATypescript2.0%20-%202.9%E3%80%8B.md) 与 [精读《Typescript 3.2 新特性》](https://github.com/dt-fe/weekly/blob/v2/084.%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)，由于 TS 更新频繁，后续 TS 技巧可能继续以阅读源码方式进行，希望这次选用的 React 类型源码可以让你印象深刻。
+
+> 讨论地址是：[精读《@types/react 值得注意的 TS 技巧》 · Issue #245 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/245)
+
+**如果你想参与讨论，请 [点击这里](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)）