Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 ascoders
|
f0ab10ac09 | ||
|
ascoders
|
13963fbdd2 | ||
|
ascoders
|
9b9d02b9de | ||
|
黄子毅
|
ec65f684bb | ||
|
ascoders
|
022b1fdbbd | ||
|
黄子毅
|
ff121c7e1b | ||
|
JRoger
|
a04380c1c1 | ||
|
Linear-Enter
|
3646b36db5 | ||
|
ascoders
|
aaaa28953b | ||
|
ascoders
|
9609101870 | ||
|
黄子毅
|
afb601a303 | ||
|
ascoders
|
c72477ed7d | ||
|
ascoders
|
dc09550e0c | ||
|
ascoders
|
dc66e76dd1 | ||
|
黄子毅
|
cecef87d13 | ||
|
Dengju Deng
|
d0ca3a348f | ||
|
ascoders
|
de4e309f39 | ||
|
ascoders
|
ea56ac10ce | ||
|
ascoders
|
90660c6d34 | ||
|
黄子毅
|
fcf04083a5 | ||
|
黄子毅
|
a1ea12a736 | ||
|
黄子毅
|
02a795bb8a | ||
|
黄子毅
|
6bffed8eb5 | ||
|
黄子毅
|
ddd5ceb74a | ||
|
rmlzy
|
3c6cee2f49 | ||
|
rmlzy
|
fc2f0c6f68 | ||
|
rmlzy
|
0dcf208315 | ||
|
rmlzy
|
7730834e83 | ||
|
rmlzy
|
91875ab232 |
@@ -3,19 +3,32 @@
|
||||
* @author 黄子毅
|
||||
*/
|
||||
|
||||
const fs = require('fs')
|
||||
const fs = require("fs");
|
||||
|
||||
const dirs = ['前沿技术', '设计模式', '编译原理', '源码解读', '商业思考']
|
||||
const dirs = [
|
||||
"前沿技术",
|
||||
"设计模式",
|
||||
"编译原理",
|
||||
"源码解读",
|
||||
"商业思考",
|
||||
"算法",
|
||||
];
|
||||
|
||||
dirs.forEach(dir => {
|
||||
dirs.forEach((dir) => {
|
||||
const readDir = fs.readdirSync(`./${dir}`);
|
||||
|
||||
console.log(`### ${dir}\n`)
|
||||
console.log(`### ${dir}\n`);
|
||||
|
||||
readDir.sort((left, right) => left.split('.')[0] - right.split('.')[0]).forEach(dirName=>{
|
||||
console.log(`- <a href="./${dir}/${dirName}">${dirName.replace('.md', '')}</a>`)
|
||||
})
|
||||
|
||||
console.log('')
|
||||
})
|
||||
readDir
|
||||
.sort((left, right) => left.split(".")[0] - right.split(".")[0])
|
||||
.forEach((dirName) => {
|
||||
console.log(
|
||||
`- <a href="./${dir}/${encodeURI(dirName)}">${dirName.replace(
|
||||
".md",
|
||||
""
|
||||
)}</a>`
|
||||
);
|
||||
});
|
||||
|
||||
console.log("");
|
||||
});
|
||||
|
||||
Generated
+2158
File diff suppressed because it is too large
Load Diff
+2
-1
@@ -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 ./"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
前端界的好文精读，每周更新！
|
||||
|
||||
最新精读：<a href="./前沿技术/197.精读《低代码逻辑编排》.md">197.精读《低代码逻辑编排》</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>
|
||||
|
||||
素材来源：[周刊参考池](https://github.com/ascoders/weekly/issues/2)
|
||||
|
||||
@@ -19,215 +19,225 @@
|
||||
|
||||
### 前沿技术
|
||||
|
||||
- <a href="./前沿技术/1.精读《js 模块化发展》.md">1.精读《js 模块化发展》</a>
|
||||
- <a href="./前沿技术/2.精读《模态框的最佳实践》.md">2.精读《模态框的最佳实践》</a>
|
||||
- <a href="./前沿技术/3.精读《前后端渲染之争》.md">3.精读《前后端渲染之争》</a>
|
||||
- <a href="./前沿技术/4.精读《AsyncAwait 优越之处》.md">4.精读《AsyncAwait 优越之处》</a>
|
||||
- <a href="./前沿技术/5.精读《民工叔单页数据流方案》.md">5.精读《民工叔单页数据流方案》</a>
|
||||
- <a href="./前沿技术/6.精读《JavaScript 错误堆栈处理》.md">6.精读《JavaScript 错误堆栈处理》</a>
|
||||
- <a href="./前沿技术/7.精读《请停止 css-in-js 的行为》.md">7.精读《请停止 css-in-js 的行为》</a>
|
||||
- <a href="./前沿技术/8.精读《入坑 React 前没有人会告诉你的事》.md">8.精读《入坑 React 前没有人会告诉你的事》</a>
|
||||
- <a href="./前沿技术/9.精读《Immutable 结构共享》.md">9.精读《Immutable 结构共享》</a>
|
||||
- <a href="./前沿技术/10.精读《Web Components 的困境》.md">10.精读《Web Components 的困境》</a>
|
||||
- <a href="./前沿技术/11.精读《前端调试技巧》.md">11.精读《前端调试技巧》</a>
|
||||
- <a href="./前沿技术/12.精读《React 高阶组件》.md">12.精读《React 高阶组件》</a>
|
||||
- <a href="./前沿技术/13.精读《This 带来的困惑》.md">13.精读《This 带来的困惑》</a>
|
||||
- <a href="./前沿技术/14.精读《架构设计之 DCI》.md">14.精读《架构设计之 DCI》</a>
|
||||
- <a href="./前沿技术/15.精读《TC39 与 ECMAScript 提案》.md">15.精读《TC39 与 ECMAScript 提案》</a>
|
||||
- <a href="./前沿技术/16.精读《CSS Animations vs Web Animations API》.md">16.精读《CSS Animations vs Web Animations API》</a>
|
||||
- <a href="./前沿技术/17.精读《如何安全地使用 React context》.md">17.精读《如何安全地使用 React context》</a>
|
||||
- <a href="./前沿技术/18.精读《设计完美的日期选择器》.md">18.精读《设计完美的日期选择器》</a>
|
||||
- <a href="./前沿技术/19.精读《最佳前端面试题》及面试官技巧.md">19.精读《最佳前端面试题》及面试官技巧</a>
|
||||
- <a href="./前沿技术/20.精读《Nestjs》文档.md">20.精读《Nestjs》文档</a>
|
||||
- <a href="./前沿技术/21.精读《Web fonts: when you need them, when you don’t》.md">21.精读《Web fonts: when you need them, when you don’t》</a>
|
||||
- <a href="./前沿技术/22.精读《V8 引擎特性带来的的 JS 性能变化》.md">22.精读《V8 引擎特性带来的的 JS 性能变化》</a>
|
||||
- <a href="./前沿技术/23.精读《API 设计原则》.md">23.精读《API 设计原则》</a>
|
||||
- <a href="./前沿技术/24.精读《现代 JavaScript 概览》.md">24.精读《现代 JavaScript 概览》</a>
|
||||
- <a href="./前沿技术/25.精读《null >= 0?》.md">25.精读《null >= 0?》</a>
|
||||
- <a href="./前沿技术/26.精读《加密媒体扩展》.md">26.精读《加密媒体扩展》</a>
|
||||
- <a href="./前沿技术/27.精读《css-in-js 杀鸡用牛刀》.md">27.精读《css-in-js 杀鸡用牛刀》</a>
|
||||
- <a href="./前沿技术/28.精读《2017 前端性能优化备忘录》.md">28.精读《2017 前端性能优化备忘录》</a>
|
||||
- <a href="./前沿技术/29.精读《JS 中的内存管理》.md">29.精读《JS 中的内存管理》</a>
|
||||
- <a href="./前沿技术/30.精读《Javascript 事件循环与异步》.md">30.精读《Javascript 事件循环与异步》</a>
|
||||
- <a href="./前沿技术/31.精读《我不再使用高阶组件》.md">31.精读《我不再使用高阶组件》</a>
|
||||
- <a href="./前沿技术/32.精读《React Router4.0 进阶概念》.md">32.精读《React Router4.0 进阶概念》</a>
|
||||
- <a href="./前沿技术/33.精读《30 行 js 代码创建神经网络》.md">33.精读《30 行 js 代码创建神经网络》</a>
|
||||
- <a href="./前沿技术/34.精读《React 代码整洁之道》.md">34.精读《React 代码整洁之道》</a>
|
||||
- <a href="./前沿技术/35.精读《dob - 框架实现》.md">35.精读《dob - 框架实现》</a>
|
||||
- <a href="./前沿技术/36.精读《When You “Git” in Trouble- a Version Control Story》.md">36.精读《When You “Git” in Trouble- a Version Control Story》</a>
|
||||
- <a href="./前沿技术/37.精读《how we position and what we compare》.md">37.精读《how we position and what we compare》</a>
|
||||
- <a href="./前沿技术/38.精读《dob - 框架使用》.md">38.精读《dob - 框架使用》</a>
|
||||
- <a href="./前沿技术/39.精读《全链路体验浏览器挖矿》.md">39.精读《全链路体验浏览器挖矿》</a>
|
||||
- <a href="./前沿技术/40.精读《初探 Reason 与 GraphQL》.md">40.精读《初探 Reason 与 GraphQL》</a>
|
||||
- <a href="./前沿技术/41.精读《Ant Design 3.0 背后的故事》.md">41.精读《Ant Design 3.0 背后的故事》</a>
|
||||
- <a href="./前沿技术/42.精读《前端数据流哲学》.md">42.精读《前端数据流哲学》</a>
|
||||
- <a href="./前沿技术/43.精读《增强现实与可视化》.md">43.精读《增强现实与可视化》</a>
|
||||
- <a href="./前沿技术/44.精读《Rekit Studio》.md">44.精读《Rekit Studio》</a>
|
||||
- <a href="./前沿技术/45.精读《React's new Context API》.md">45.精读《React's new Context API》</a>
|
||||
- <a href="./前沿技术/46.精读《react-rxjs》.md">46.精读《react-rxjs》</a>
|
||||
- <a href="./前沿技术/47.精读《webpack4.0 升级指南》.md">47.精读《webpack4.0 升级指南》</a>
|
||||
- <a href="./前沿技术/49.精读《Compilers are the New Frameworks》.md">49.精读《Compilers are the New Frameworks》</a>
|
||||
- <a href="./前沿技术/50.精读《快速上手构建 ARKit 应用》.md">50.精读《快速上手构建 ARKit 应用》</a>
|
||||
- <a href="./前沿技术/51.精读《Elements of Web Dev》.md">51.精读《Elements of Web Dev》</a>
|
||||
- <a href="./前沿技术/52.精读《图解 ES 模块》.md">52.精读《图解 ES 模块》</a>
|
||||
- <a href="./前沿技术/53.精读《插件化思维》.md">53.精读《插件化思维》</a>
|
||||
- <a href="./前沿技术/54.精读《在浏览器运行 serverRender》.md">54.精读《在浏览器运行 serverRender》</a>
|
||||
- <a href="./前沿技术/55.精读《async await 是把双刃剑》.md">55.精读《async await 是把双刃剑》</a>
|
||||
- <a href="./前沿技术/56.精读《重新思考 Redux》.md">56.精读《重新思考 Redux》</a>
|
||||
- <a href="./前沿技术/57.精读《现代 js 框架存在的根本原因》.md">57.精读《现代 js 框架存在的根本原因》</a>
|
||||
- <a href="./前沿技术/58.精读《Typescript2.0 - 2.9》.md">58.精读《Typescript2.0 - 2.9》</a>
|
||||
- <a href="./前沿技术/59.精读《如何利用 Nodejs 监听文件夹》.md">59.精读《如何利用 Nodejs 监听文件夹》</a>
|
||||
- <a href="./前沿技术/60.精读《如何在 nodejs 使用环境变量》.md">60.精读《如何在 nodejs 使用环境变量》</a>
|
||||
- <a href="./前沿技术/61.精读《React 八种条件渲染》.md">61.精读《React 八种条件渲染》</a>
|
||||
- <a href="./前沿技术/62.精读《JS 引擎基础之 Shapes and Inline Caches》.md">62.精读《JS 引擎基础之 Shapes and Inline Caches》</a>
|
||||
- <a href="./前沿技术/63.精读《React 的多态性》.md">63.精读《React 的多态性》</a>
|
||||
- <a href="./前沿技术/68.精读《衡量用户体验》.md">68.精读《衡量用户体验》</a>
|
||||
- <a href="./前沿技术/69.精读《SQL vs Flux》.md">69.精读《SQL vs Flux》</a>
|
||||
- <a href="./前沿技术/72.精读《REST, GraphQL, Webhooks, & gRPC 如何选型》.md">72.精读《REST, GraphQL, Webhooks, & gRPC 如何选型》</a>
|
||||
- <a href="./前沿技术/74.精读《12 个评估 JS 库你需要关心的事》.md">74.精读《12 个评估 JS 库你需要关心的事》</a>
|
||||
- <a href="./前沿技术/76.精读《谈谈 Web Workers》.md">76.精读《谈谈 Web Workers》</a>
|
||||
- <a href="./前沿技术/77.精读《用 Reduce 实现 Promise 串行执行》.md">77.精读《用 Reduce 实现 Promise 串行执行》</a>
|
||||
- <a href="./前沿技术/79.精读《React Hooks》.md">79.精读《React Hooks》</a>
|
||||
- <a href="./前沿技术/80.精读《怎么用 React Hooks 造轮子》.md">80.精读《怎么用 React Hooks 造轮子》</a>
|
||||
- <a href="./前沿技术/81.精读《使用 CSS 属性选择器》.md">81.精读《使用 CSS 属性选择器》</a>
|
||||
- <a href="./前沿技术/83.精读《React16 新特性》.md">83.精读《React16 新特性》</a>
|
||||
- <a href="./前沿技术/84.精读《Typescript 3.2 新特性》.md">84.精读《Typescript 3.2 新特性》</a>
|
||||
- <a href="./前沿技术/86.精读《国际化布局 - Logical Properties》.md">86.精读《国际化布局 - Logical Properties》</a>
|
||||
- <a href="./前沿技术/87.精读《setState 做了什么》.md">87.精读《setState 做了什么》</a>
|
||||
- <a href="./前沿技术/88.精读《Caches API》.md">88.精读《Caches API》</a>
|
||||
- <a href="./前沿技术/89.精读《如何编译前端项目与组件》.md">89.精读《如何编译前端项目与组件》</a>
|
||||
- <a href="./前沿技术/91.精读《正则 ES2018》.md">91.精读《正则 ES2018》</a>
|
||||
- <a href="./前沿技术/94.精读《Serverless 给前端带来了什么》.md">94.精读《Serverless 给前端带来了什么》</a>
|
||||
- <a href="./前沿技术/95.精读《Function VS Class 组件》.md">95.精读《Function VS Class 组件》</a>
|
||||
- <a href="./前沿技术/96.精读《useEffect 完全指南》.md">96.精读《useEffect 完全指南》</a>
|
||||
- <a href="./前沿技术/97.精读《编写有弹性的组件》.md">97.精读《编写有弹性的组件》</a>
|
||||
- <a href="./前沿技术/99.精读《Scheduling in React》.md">99.精读《Scheduling in React》</a>
|
||||
- <a href="./前沿技术/100.精读《V8 引擎 Lazy Parsing》.md">100.精读《V8 引擎 Lazy Parsing》</a>
|
||||
- <a href="./前沿技术/101.精读《持续集成 vs 持续交付 vs 持续部署》.md">101.精读《持续集成 vs 持续交付 vs 持续部署》</a>
|
||||
- <a href="./前沿技术/102.精读《Monorepo 的优势》.md">102.精读《Monorepo 的优势》</a>
|
||||
- <a href="./前沿技术/104.精读《Function Component 入门》.md">104.精读《Function Component 入门》</a>
|
||||
- <a href="./前沿技术/105.精读《What's new in javascript》.md">105.精读《What's new in javascript》</a>
|
||||
- <a href="./前沿技术/107.精读《Optional chaining》.md">107.精读《Optional chaining》</a>
|
||||
- <a href="./前沿技术/109.精读《Vue3.0 Function API》.md">109.精读《Vue3.0 Function API》</a>
|
||||
- <a href="./前沿技术/111.精读《前端未来展望》.md">111.精读《前端未来展望》</a>
|
||||
- <a href="./前沿技术/112.精读《源码学习》.md">112.精读《源码学习》</a>
|
||||
- <a href="./前沿技术/113.精读《Nodejs V12》.md">113.精读《Nodejs V12》</a>
|
||||
- <a href="./前沿技术/117.精读《Tableau 探索式模型》.md">117.精读《Tableau 探索式模型》</a>
|
||||
- <a href="./前沿技术/118.精读《使用 css 变量生成颜色主题》.md">118.精读《使用 css 变量生成颜色主题》</a>
|
||||
- <a href="./前沿技术/119.精读《前端深水区》.md">119.精读《前端深水区》</a>
|
||||
- <a href="./前沿技术/120.精读《React Hooks 最佳实践》.md">120.精读《React Hooks 最佳实践》</a>
|
||||
- <a href="./前沿技术/121.精读《前端与 BI》.md">121.精读《前端与 BI》</a>
|
||||
- <a href="./前沿技术/123.精读《用 Babel 创造自定义 JS 语法》.md">123.精读《用 Babel 创造自定义 JS 语法》</a>
|
||||
- <a href="./前沿技术/124.精读《用 css grid 重新思考布局》.md">124.精读《用 css grid 重新思考布局》</a>
|
||||
- <a href="./前沿技术/125.精读《深度学习 - 函数式之美》.md">125.精读《深度学习 - 函数式之美》</a>
|
||||
- <a href="./前沿技术/126.精读《Nuxtjs》.md">126.精读《Nuxtjs》</a>
|
||||
- <a href="./前沿技术/127.精读《React Conf 2019 - Day1》.md">127.精读《React Conf 2019 - Day1》</a>
|
||||
- <a href="./前沿技术/129.精读《React Conf 2019 - Day2》.md">129.精读《React Conf 2019 - Day2》</a>
|
||||
- <a href="./前沿技术/132.精读《正交的 React 组件》.md">132.精读《正交的 React 组件》</a>
|
||||
- <a href="./前沿技术/133.精读《寻找框架设计的平衡点》.md">133.精读《寻找框架设计的平衡点》</a>
|
||||
- <a href="./前沿技术/134.精读《我在阿里数据中台大前端》.md">134.精读《我在阿里数据中台大前端》</a>
|
||||
- <a href="./前沿技术/138.精读《精通 console.log》.md">138.精读《精通 console.log》</a>
|
||||
- <a href="./前沿技术/139.精读《手写 JSON Parser》.md">139.精读《手写 JSON Parser》</a>
|
||||
- <a href="./前沿技术/140.精读《结合 React 使用原生 Drag Drop API》.md">140.精读《结合 React 使用原生 Drag Drop API》</a>
|
||||
- <a href="./前沿技术/141.精读《useRef 与 createRef 的区别》.md">141.精读《useRef 与 createRef 的区别》</a>
|
||||
- <a href="./前沿技术/142.精读《如何做好 CodeReview》.md">142.精读《如何做好 CodeReview》</a>
|
||||
- <a href="./前沿技术/143.精读《Suspense 改变开发方式》.md">143.精读《Suspense 改变开发方式》</a>
|
||||
- <a href="./前沿技术/144.精读《Webpack5 新特性 - 模块联邦》.md">144.精读《Webpack5 新特性 - 模块联邦》</a>
|
||||
- <a href="./前沿技术/145.精读《React Router v6》.md">145.精读《React Router v6》</a>
|
||||
- <a href="./前沿技术/146.精读《React Hooks 数据流》.md">146.精读《React Hooks 数据流》</a>
|
||||
- <a href="./前沿技术/147. 精读《@types react 值得注意的 TS 技巧》.md">147. 精读《@types react 值得注意的 TS 技巧》</a>
|
||||
- <a href="./前沿技术/148. 精读《React Error Boundaries》.md">148. 精读《React Error Boundaries》</a>
|
||||
- <a href="./前沿技术/149. 精读《React 性能调试》.md">149. 精读《React 性能调试》</a>
|
||||
- <a href="./前沿技术/150. 精读《Deno 1.0 你需要了解的》.md">150. 精读《Deno 1.0 你需要了解的》</a>
|
||||
- <a href="./前沿技术/152. 精读《recoil》.md">152. 精读《recoil》</a>
|
||||
- <a href="./前沿技术/153. 精读《snowpack》.md">153. 精读《snowpack》</a>
|
||||
- <a href="./前沿技术/154. 精读《用 React 做按需渲染》.md">154. 精读《用 React 做按需渲染》</a>
|
||||
- <a href="./前沿技术/157. 精读《如何比较 Object 对象》.md">157. 精读《如何比较 Object 对象》</a>
|
||||
- <a href="./前沿技术/158. 精读《Typescript 4》.md">158. 精读《Typescript 4》</a>
|
||||
- <a href="./前沿技术/159. 精读《对低代码搭建的理解》.md">159. 精读《对低代码搭建的理解》</a>
|
||||
- <a href="./前沿技术/160. 精读《函数缓存》.md">160. 精读《函数缓存》</a>
|
||||
- <a href="./前沿技术/161.精读《可视化搭建思考 - 富文本搭建》.md">161.精读《可视化搭建思考 - 富文本搭建》</a>
|
||||
- <a href="./前沿技术/162.精读《Tasks, microtasks, queues and schedules》.md">162.精读《Tasks, microtasks, queues and schedules》</a>
|
||||
- <a href="./前沿技术/163.精读《Spring 概念》.md">163.精读《Spring 概念》</a>
|
||||
- <a href="./前沿技术/164.精读《数据搭建引擎 bi-designer API-设计器》.md">164.精读《数据搭建引擎 bi-designer API-设计器》</a>
|
||||
- <a href="./前沿技术/165.精读《数据搭建引擎 bi-designer API-组件》.md">165.精读《数据搭建引擎 bi-designer API-组件》</a>
|
||||
- <a href="./前沿技术/166.精读《BI 搭建 - 筛选条件》.md">166.精读《BI 搭建 - 筛选条件》</a>
|
||||
- <a href="./前沿技术/190.精读《DOM diff 原理详解》.md">190.精读《DOM diff 原理详解》</a>
|
||||
- <a href="./前沿技术/191.精读《高性能表格》.md">191.精读《高性能表格》</a>
|
||||
- <a href="./前沿技术/192.精读《DOM diff 最长上升子序列》.md">192.精读《DOM diff 最长上升子序列》</a>
|
||||
- <a href="./前沿技术/193.精读《React Server Component》.md">193.精读《React Server Component》</a>
|
||||
- <a href="./前沿技术/194.精读《算法基础数据结构》.md">194.精读《算法基础数据结构》</a>
|
||||
- <a href="./前沿技术/195.精读《新一代前端构建工具对比》.md">195.精读《新一代前端构建工具对比》</a>
|
||||
- <a href="./前沿技术/196.精读《前端职业规划 - 2021 年》.md">196.精读《前端职业规划 - 2021 年》</a>
|
||||
- <a href="./前沿技术/197.精读《低代码逻辑编排》.md">197.精读《低代码逻辑编排》</a>
|
||||
- <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:%20when%20you%20need%20them,%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=%200?%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,%20GraphQL,%20Webhooks,%20&%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@types%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,%20microtasks,%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="./设计模式/167.精读《设计模式 - Abstract Factory 抽象工厂》.md">167.精读《设计模式 - Abstract Factory 抽象工厂》</a>
|
||||
- <a href="./设计模式/168.精读《设计模式 - Builder 生成器》.md">168.精读《设计模式 - Builder 生成器》</a>
|
||||
- <a href="./设计模式/169.精读《设计模式 - Factory Method 工厂方法》.md">169.精读《设计模式 - Factory Method 工厂方法》</a>
|
||||
- <a href="./设计模式/170.精读《设计模式 - Prototype 原型模式》.md">170.精读《设计模式 - Prototype 原型模式》</a>
|
||||
- <a href="./设计模式/171.精读《设计模式 - Singleton 单例模式》.md">171.精读《设计模式 - Singleton 单例模式》</a>
|
||||
- <a href="./设计模式/172.精读《设计模式 - Adapter 适配器模式》.md">172.精读《设计模式 - Adapter 适配器模式》</a>
|
||||
- <a href="./设计模式/173.精读《设计模式 - Bridge 桥接模式》.md">173.精读《设计模式 - Bridge 桥接模式》</a>
|
||||
- <a href="./设计模式/174.精读《设计模式 - Composite 组合模式》.md">174.精读《设计模式 - Composite 组合模式》</a>
|
||||
- <a href="./设计模式/175.精读《设计模式 - Decorator 装饰器模式》.md">175.精读《设计模式 - Decorator 装饰器模式》</a>
|
||||
- <a href="./设计模式/176.精读《设计模式 - Facade 外观模式》.md">176.精读《设计模式 - Facade 外观模式》</a>
|
||||
- <a href="./设计模式/177.精读《设计模式 - Flyweight 享元模式》.md">177.精读《设计模式 - Flyweight 享元模式》</a>
|
||||
- <a href="./设计模式/178.精读《设计模式 - Proxy 代理模式》.md">178.精读《设计模式 - Proxy 代理模式》</a>
|
||||
- <a href="./设计模式/179.精读《设计模式 - Chain of Responsibility 职责链模式》.md">179.精读《设计模式 - Chain of Responsibility 职责链模式》</a>
|
||||
- <a href="./设计模式/180.精读《设计模式 - Command 命令模式》.md">180.精读《设计模式 - Command 命令模式》</a>
|
||||
- <a href="./设计模式/181.精读《设计模式 - Interpreter 解释器模式》.md">181.精读《设计模式 - Interpreter 解释器模式》</a>
|
||||
- <a href="./设计模式/182.精读《设计模式 - Iterator 迭代器模式》.md">182.精读《设计模式 - Iterator 迭代器模式》</a>
|
||||
- <a href="./设计模式/183.精读《设计模式 - Mediator 中介者模式》.md">183.精读《设计模式 - Mediator 中介者模式》</a>
|
||||
- <a href="./设计模式/184.精读《设计模式 - Memoto 备忘录模式》.md">184.精读《设计模式 - Memoto 备忘录模式》</a>
|
||||
- <a href="./设计模式/185.精读《设计模式 - Observer 观察者模式》.md">185.精读《设计模式 - Observer 观察者模式》</a>
|
||||
- <a href="./设计模式/186.精读《设计模式 - State 状态模式》.md">186.精读《设计模式 - State 状态模式》</a>
|
||||
- <a href="./设计模式/187.精读《设计模式 - Strategy 策略模式》.md">187.精读《设计模式 - Strategy 策略模式》</a>
|
||||
- <a href="./设计模式/188.精读《设计模式 - Template Method 模版模式》.md">188.精读《设计模式 - Template Method 模版模式》</a>
|
||||
- <a href="./设计模式/189.精读《设计模式 - Visitor 访问者模式》.md">189.精读《设计模式 - Visitor 访问者模式》</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.精读《手写 SQL 编译器 - 词法分析》.md">64.精读《手写 SQL 编译器 - 词法分析》</a>
|
||||
- <a href="./编译原理/65.精读《手写 SQL 编译器 - 文法介绍》.md">65.精读《手写 SQL 编译器 - 文法介绍》</a>
|
||||
- <a href="./编译原理/66.精读《手写 SQL 编译器 - 语法分析》.md">66.精读《手写 SQL 编译器 - 语法分析》</a>
|
||||
- <a href="./编译原理/67.精读《手写 SQL 编译器 - 回溯》.md">67.精读《手写 SQL 编译器 - 回溯》</a>
|
||||
- <a href="./编译原理/70.精读《手写 SQL 编译器 - 语法树》.md">70.精读《手写 SQL 编译器 - 语法树》</a>
|
||||
- <a href="./编译原理/71.精读《手写 SQL 编译器 - 错误提示》.md">71.精读《手写 SQL 编译器 - 错误提示》</a>
|
||||
- <a href="./编译原理/78.精读《手写 SQL 编译器 - 性能优化之缓存》.md">78.精读《手写 SQL 编译器 - 性能优化之缓存》</a>
|
||||
- <a href="./编译原理/85.精读《手写 SQL 编译器 - 智能提示》.md">85.精读《手写 SQL 编译器 - 智能提示》</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.精读《Immer.js》源码.md">48.精读《Immer.js》源码</a>
|
||||
- <a href="./源码解读/73.精读《sqorn 源码》.md">73.精读《sqorn 源码》</a>
|
||||
- <a href="./源码解读/75.精读《Epitath 源码 - renderProps 新用法》.md">75.精读《Epitath 源码 - renderProps 新用法》</a>
|
||||
- <a href="./源码解读/82.精读《Htm - Hyperscript 源码》.md">82.精读《Htm - Hyperscript 源码》</a>
|
||||
- <a href="./源码解读/92.精读《React PowerPlug 源码》.md">92.精读《React PowerPlug 源码》</a>
|
||||
- <a href="./源码解读/93.精读《syntax-parser 源码》.md">93.精读《syntax-parser 源码》</a>
|
||||
- <a href="./源码解读/98.精读《react-easy-state 源码》.md">98.精读《react-easy-state 源码》</a>
|
||||
- <a href="./源码解读/110.精读《Inject Instance 源码》.md">110.精读《Inject Instance 源码》</a>
|
||||
- <a href="./源码解读/122.精读《robot 源码 - 有限状态机》.md">122.精读《robot 源码 - 有限状态机》</a>
|
||||
- <a href="./源码解读/128.精读《Hooks 取数 - swr 源码》.md">128.精读《Hooks 取数 - swr 源码》</a>
|
||||
- <a href="./源码解读/130.精读《unstated 与 unstated-next 源码》.md">130.精读《unstated 与 unstated-next 源码》</a>
|
||||
- <a href="./源码解读/151. 精读《@umijs use-request》源码.md">151. 精读《@umijs use-request》源码</a>
|
||||
- <a href="./源码解读/155. 精读《use-what-changed 源码》.md">155. 精读《use-what-changed 源码》</a>
|
||||
- <a href="./源码解读/156. 精读《react-intersection-observer 源码》.md">156. 精读《react-intersection-observer 源码》</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@umijs%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.精读《极客公园 2019》.md">90.精读《极客公园 2019》</a>
|
||||
- <a href="./商业思考/103.精读《为什么专家不再关心技术细节》.md">103.精读《为什么专家不再关心技术细节》</a>
|
||||
- <a href="./商业思考/106.精读《数据之上·智慧之光 - 2018》.md">106.精读《数据之上·智慧之光 - 2018》</a>
|
||||
- <a href="./商业思考/108.精读《智能商业》.md">108.精读《智能商业》</a>
|
||||
- <a href="./商业思考/114.精读《谁在世界中心》.md">114.精读《谁在世界中心》</a>
|
||||
- <a href="./商业思考/115.精读《Tableau 入门》.md">115.精读《Tableau 入门》</a>
|
||||
- <a href="./商业思考/116.精读《刷新》.md">116.精读《刷新》</a>
|
||||
- <a href="./商业思考/131.精读《从 0 到 1》.md">131.精读《从 0 到 1》</a>
|
||||
- <a href="./商业思考/135.精读《极客公园 IFX - 上》.md">135.精读《极客公园 IFX - 上》</a>
|
||||
- <a href="./商业思考/136.精读《极客公园 IFX - 下》.md">136.精读《极客公园 IFX - 下》</a>
|
||||
- <a href="./商业思考/137.精读《当我在分享的时候，我在做什么？》.md">137.精读《当我在分享的时候，我在做什么？》</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>
|
||||
|
||||
## 关注前端精读微信公众号
|
||||
|
||||
|
||||
@@ -180,7 +180,7 @@ const dragProps = {
|
||||
```jsx
|
||||
const dropProps = {
|
||||
onDragOver: ev => {
|
||||
// 做一些样式处理，提示用户此时松手会将元素防止在何处
|
||||
// 做一些样式处理，提示用户此时松手会将元素放置在何处
|
||||
},
|
||||
onDrop: ev => {
|
||||
ev.stopPropagation()
|
||||
|
||||
@@ -0,0 +1,195 @@
|
||||
React 18 带来了几个非常实用的新特性，同时也没有额外的升级成本，值得仔细看一看。
|
||||
|
||||
下面是几个关键信息：
|
||||
|
||||
- [React 18 工作小组](https://github.com/reactwg/react-18)。利用社区讨论 React 18 发布节奏与新特性。
|
||||
- [发布计划](https://reactjs.org/blog/2021/06/08/the-plan-for-react-18.html)。目前还没有正式发布，不过 `@alpha` 版已经可用了，[安装 alpha 版](https://github.com/reactwg/react-18/discussions/9)。
|
||||
- [React 18 新特性介绍](https://github.com/reactwg/react-18/discussions/4)。虽然还未正式发布，但特性介绍可以先行，本周精读主要就是解读这篇文档。
|
||||
|
||||
## 精读
|
||||
|
||||
总的来说，React 18 带来了 3 大新特性：
|
||||
|
||||
- Automatic batching。
|
||||
- Concurrent APIS。
|
||||
- SSR for Suspense。
|
||||
|
||||
同时为了开启新的特性，需要进行简单的 `render` 函数升级。
|
||||
|
||||
### Automatic batching
|
||||
|
||||
batching 是指，React 可以将回调函数中多个 `setState` 事件合并为一次渲染。
|
||||
|
||||
也就是说，`setState` 并不是实时修改 State 的，而将多次 `setState` 调用合并起来仅触发一次渲染，既可以减少程序数据状态存在中间值导致的不稳定性，也可以提升渲染性能。可以理解为如下代码所示：
|
||||
|
||||
```typescript
|
||||
function handleClick() {
|
||||
setCount((c) => c + 1);
|
||||
setFlag((f) => !f);
|
||||
// 仅触发一次渲染
|
||||
}
|
||||
```
|
||||
|
||||
但可惜的是，React 18 以前，如果在回调函数的异步调用中执行 `setState`，由于丢失了上下文，无法做合并处理，所以每次 `setState` 调用都会立即触发一次重渲染：
|
||||
|
||||
```typescript
|
||||
function handleClick() {
|
||||
// React 18 以前的版本
|
||||
fetch(/*...*/).then(() => {
|
||||
setCount((c) => c + 1); // 立刻重渲染
|
||||
setFlag((f) => !f); // 立刻重渲染
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
而 React 18 带来的优化便是，任何情况都可以合并渲染了！即使在 `promise`、`timeout` 或者 `event` 回调中调用多次 `setState`，也都会合并为一次渲染：
|
||||
|
||||
```typescript
|
||||
function handleClick() {
|
||||
// React 18+
|
||||
fetch(/*...*/).then(() => {
|
||||
setCount((c) => c + 1);
|
||||
setFlag((f) => !f);
|
||||
// 仅触发一次渲染
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
当然如果你非要 `setState` 调用后立即重渲染也行，只需要用 `flushSync` 包裹：
|
||||
|
||||
```typescript
|
||||
function handleClick() {
|
||||
// React 18+
|
||||
fetch(/*...*/).then(() => {
|
||||
ReactDOM.flushSync(() => {
|
||||
setCount((c) => c + 1); // 立刻重渲染
|
||||
setFlag((f) => !f); // 立刻重渲染
|
||||
});
|
||||
});
|
||||
}
|
||||
```
|
||||
|
||||
开启这个特性的前提是，将 `ReactDOM.render` 替换为 `ReactDOM.createRoot` 调用方式。
|
||||
|
||||
### 新的 ReactDOM Render API
|
||||
|
||||
升级方式很简单：
|
||||
|
||||
```typescript
|
||||
const container = document.getElementById("app");
|
||||
|
||||
// 旧 render API
|
||||
ReactDOM.render(<App tab="home" />, container);
|
||||
|
||||
// 新 createRoot API
|
||||
const root = ReactDOM.createRoot(container);
|
||||
root.render(<App tab="home" />);
|
||||
```
|
||||
|
||||
API 修改的主要原因还是语义化，即当我们多次调用 `render` 时，不再需要重复传入 `container` 参数，因为在新的 API 中，`container` 已经提前绑定到 `root` 了。
|
||||
|
||||
`ReactDOM.hydrate` 也被 `ReactDOM.hydrateRoot` 代替：
|
||||
|
||||
```typescript
|
||||
const root = ReactDOM.hydrateRoot(container, <App tab="home" />);
|
||||
// 注意这里不用调用 root.render()
|
||||
```
|
||||
|
||||
这样的好处是，后续如果再调用 `root.render(<Appx />)` 进行重渲染，我们不用关心这个 `root` 来自 `createRoot` 或者 `hydrateRoot`，因为后续 API 行为表现都一样，减少了理解成本。
|
||||
|
||||
### Concurrent APIS
|
||||
|
||||
首先要了解 Concurrent Mode 是什么。
|
||||
|
||||
简单来说，Concurrent Mode 就是一种可中断渲染的设计架构。什么时候中断渲染呢？当一个更高优先级渲染到来时，通过放弃当前的渲染，立即执行更高优先级的渲染，换来视觉上更快的响应速度。
|
||||
|
||||
有人可能会说，不对啊，中断渲染后，之前渲染的 CPU 执行不就浪费了吗，换句话说，整体执行时常增加了。这句话是对的，但实际上用户对页面交互及时性的感知是分为两种的，第一种是即时输入反馈，第二种是这个输入带来的副作用反馈，比如更新列表。其中，即使输入反馈只要能优先满足，即便副作用反馈更慢一些，也会带来更好的体验，更不用说副作用反馈大部分情况会因为即使输入反馈的变化而作废。
|
||||
|
||||
由于 React 将渲染 DOM 树机制改为两个双向链表，并且渲染树指针只有一个，指向其中一个链表，因此可以在更新完全发生后再切换指针指向，而在指针切换之前，随时可以放弃对另一颗树的修改。
|
||||
|
||||
以上是背景输入。React 18 提供了三个新的 API 支持这一模式，分别是：
|
||||
|
||||
- startTransition。
|
||||
- useDeferredValue。
|
||||
- <SuspenseList>。
|
||||
|
||||
后两个文档还未放出，所以本文只介绍第一个 API：startTransition。首先看一下用法：
|
||||
|
||||
```typescript
|
||||
import { startTransition } from "react";
|
||||
|
||||
// 紧急更新：
|
||||
setInputValue(input);
|
||||
|
||||
// 标记回调函数内的更新为非紧急更新：
|
||||
startTransition(() => {
|
||||
setSearchQuery(input);
|
||||
});
|
||||
```
|
||||
|
||||
简单来说，就是被 `startTransition` 回调包裹的 `setState` **触发的渲染** 被标记为不紧急的渲染，这些渲染可能被其他紧急渲染所抢占。
|
||||
|
||||
比如这个例子，当 `setSearchQuery` 更新的列表内容很多，导致渲染时 CPU 占用 100% 时，此时用户又进行了一个输入，即触发了由 `setInputValue` 引起的渲染，此时由 `setSearchQuery` 引发的渲染会立刻停止，转而对 `setInputValue` 渲染进行支持，这样用户的输入就能快速反映在 UI 上，代价是搜索列表响应稍慢了一些。而一个 `transition` 被打断的状态可以通过 `isPending` 访问到：
|
||||
|
||||
```typescript
|
||||
import { useTransition } from "react";
|
||||
const [isPending, startTransition] = useTransition();
|
||||
```
|
||||
|
||||
其实这比较符合操作系统的设计理念，我们知道在操作系统是通过中断响应底层硬件事件的，中断都非常紧急（因为硬件能存储的消息队列非常有限，操作系统不能即使响应，硬件的输入可能就丢失了），因此要支持抢占式内核，并在中断到来时立刻执行中断（可能把不太紧急的操作放到下半部执行）。
|
||||
|
||||
对前端交互来说，用户角度发出的 “中断” 一般来自键盘或鼠标的操作，但不幸的是，前端框架甚至是 JS 都过于上层，它们无法自动识别：
|
||||
|
||||
1. 哪些代码是紧急中断产生的。比如 `onClick` 就一定是用户鼠标点击产生的吗？不一定，可能是 `xxx.onClick` 主动触发的，而非用户触发。
|
||||
2. 用户触发的就一定是紧急中断吗？不一定，比如键盘输入后，`setInputValue` 是紧急的，而更新查询列表的 `setSearchQuery` 就是非紧急的。
|
||||
|
||||
我们要理解到前端场景对用户操作感知的局限性，才能理解为什么必须手动指定更新的紧急程度，而不能像操作系统一样，上层程序无需感知中断的存在。
|
||||
|
||||
### SSR for Suspense
|
||||
|
||||
完整名称是：Streaming SSR with selective hydration。
|
||||
|
||||
即像水流一样，打造一个从服务端到客户端持续不断的渲染管线，而不是 `renderToString` 那样一次性渲染机制。selective hydration 表示选择性水合，水合指的是后端内容打到前端后，JS 需要将事件绑定其上，才能响应用户交互或者 DOM 更新行为，而在 React 18 之前，这个操作必须是整体性的，而水合过程可能比较慢，会引起全局的卡顿，所以选择性水合可以按需优先进行水合。
|
||||
|
||||
所以这个特性其实是转为 SSR 准备的，而功能启用载体就是 Suspense（所以以后不要再认为 Suspense 只是一个 loading 作用）。其实在 Suspense 设计之初，就是为了解决服务端渲染问题，只是一开始只实装了客户端测的按需加载功能，后面你会逐渐发现 React 团地逐渐赋予了 Suspense 更多强大能力。
|
||||
|
||||
SSR for Suspense 解决三个主要问题：
|
||||
|
||||
- SSR 模式下，如果不同模块取数效率不同，会因为最慢的一个模块拖慢整体 HTML 吞吐时间，这可能导致体验还不如非 SSR 来的好。举一个极端情况，假设报表中一个组件依赖了慢查询，需要五分钟数据才能出来，那么 SSR 的后果就是白屏时间拉长到 5 分钟。
|
||||
- 即便 SSR 内容打到了页面上，由于 JS 没有加载完毕，所以根本无法进行 hydration，整个页面处于无法交互状态。
|
||||
- 即便 JS 加载完了，由于 React 18 之前只能进行整体 hydration，可能导致卡顿，导致首次交互响应不及时。
|
||||
|
||||
在 React 18 的 server render 中，只要使用 `pipeToNodeWritable` 代替 `renderToString` 并配合 `Suspense` 就能解决上面三个问题。
|
||||
|
||||
使用 `pipeToNodeWriteable` 可以看 [这个例子](https://codesandbox.io/s/festive-star-9hfqt?file=/server/render.js:1043-1575)。
|
||||
|
||||
最大的区别在于，服务端渲染由简单的 `res.send` 改成了 `res.socket`，这样渲染就从单次行为变成了持续性的行为。
|
||||
|
||||
那么 React 18 的 SSR 到底有怎样的效果呢？[这篇介绍文档](https://github.com/reactwg/react-18/discussions/37) 的图建议看一看，非常直观，这里我简要描述一下：
|
||||
|
||||
1. 被 `<Suspense>` 包裹的区块，在服务端渲染时不会阻塞首次吞吐，而且在这个区块准备完毕后（包括异步取数）再实时打到页面中（以 HTML 模式，此时还没有 hydration），在此之前返回的是 `fallback` 的内容。
|
||||
2. hydration 的过程也是逐步的，这样不会导致一下执行所有完整的 js 导致页面卡顿（hydration 其实就是 React 里写的回调注册、各类 Hooks，整个应用的量非常庞大）。
|
||||
3. hydration 因为被拆成多部，React 还会提前监听鼠标点击，并提前对点击区域优先级进行 hydration，甚至能抢占已经在其他区域正在进行中的 hydration。
|
||||
|
||||
那么总结一下，新版 SSR 性能提高的秘诀在于两个字：按需。
|
||||
|
||||
而这个难点在于，SSR 需要后端到前端的配合，在 React 18 之前，后端到前端的过程完全没有优化，而现在将 SSR HTML 的吞吐改成多次，按需，并且水合过程中还支持抢占，因此性能得到进一步提升。
|
||||
|
||||
## 总结
|
||||
|
||||
结合起来看，React 18 关注点在于更快的性能以及用户交互响应效率，其设计理念处处包含了中断与抢占概念。
|
||||
|
||||
以后提起前端性能优化，我们就多了一些应用侧的视角（而不仅仅是工程化视角），从以下两个应用优化视角有效提升交互反馈速度：
|
||||
|
||||
1. 随时中断的框架设计，第一优先级渲染用户最关注的 UI 交互模块。
|
||||
2. 从后端到前端 “顺滑” 的管道式 SSR，并将 hydration 过程按需化，且支持被更高优先级用户交互行为打断，第一优先水合用户正在交互的部分。
|
||||
|
||||
> 讨论地址是：[精读《React 18》· Issue #336 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/336)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
@@ -0,0 +1,223 @@
|
||||
从代码可维护性角度出发，命名导出比默认导出更好，因为它减少了因引用产生重命名情况的发生。
|
||||
|
||||
但命名导出与默认导出的区别不止如此，在逻辑上也有很大差异，为了减少开发时在这方面栽跟头，有必要提前了解它们的区别。
|
||||
|
||||
本周找来了这方面很好的的文章：[export-default-thing-vs-thing-as-default](https://jakearchibald.com/2021/export-default-thing-vs-thing-as-default/)，先描述梗概，再谈谈我的理解。
|
||||
|
||||
## 概述
|
||||
|
||||
一般我们认为，import 导入的是引用而不是值，也就是说，当导入对象在模块内值发生变化后，import 导入的对象值也应当同步变化。
|
||||
|
||||
```javascript
|
||||
// module.js
|
||||
export let thing = 'initial';
|
||||
|
||||
setTimeout(() => {
|
||||
thing = 'changed';
|
||||
}, 500);
|
||||
```
|
||||
|
||||
上面的例子，500ms 后修改导出对象的值。
|
||||
|
||||
```javascript
|
||||
// main.js
|
||||
import { thing as importedThing } from './module.js';
|
||||
const module = await import('./module.js');
|
||||
let { thing } = await import('./module.js');
|
||||
|
||||
setTimeout(() => {
|
||||
console.log(importedThing); // "changed"
|
||||
console.log(module.thing); // "changed"
|
||||
console.log(thing); // "initial"
|
||||
}, 1000);
|
||||
```
|
||||
|
||||
1s 后输出发现，前两种输出结果变了，第三种没有变。也就是对命名导出来说，前两种是引用，第三种是值。
|
||||
|
||||
但默认导出又不一样：
|
||||
|
||||
```javascript
|
||||
// module.js
|
||||
let thing = 'initial';
|
||||
|
||||
export { thing };
|
||||
export default thing;
|
||||
|
||||
setTimeout(() => {
|
||||
thing = 'changed';
|
||||
}, 500);
|
||||
```
|
||||
|
||||
```javascript
|
||||
// main.js
|
||||
import { thing, default as defaultThing } from './module.js';
|
||||
import anotherDefaultThing from './module.js';
|
||||
|
||||
setTimeout(() => {
|
||||
console.log(thing); // "changed"
|
||||
console.log(defaultThing); // "initial"
|
||||
console.log(anotherDefaultThing); // "initial"
|
||||
}, 1000);
|
||||
```
|
||||
|
||||
为什么对默认导出的导入结果是值而不是引用？
|
||||
|
||||
原因是默认导出可以看作一种对 “default 赋值” 的特例，就像 `export default = thing` 这种旧语法表达的一样，本质上是一种赋值，所以拿到的是值而不是引用。
|
||||
|
||||
那么默认导出的另一种写法 `export { thing as default }` 也是如此吗？并不是：
|
||||
|
||||
```javascript
|
||||
// module.js
|
||||
let thing = 'initial';
|
||||
|
||||
export { thing, thing as default };
|
||||
|
||||
setTimeout(() => {
|
||||
thing = 'changed';
|
||||
}, 500);
|
||||
```
|
||||
|
||||
```javascript
|
||||
// main.js
|
||||
import { thing, default as defaultThing } from './module.js';
|
||||
import anotherDefaultThing from './module.js';
|
||||
|
||||
setTimeout(() => {
|
||||
console.log(thing); // "changed"
|
||||
console.log(defaultThing); // "changed"
|
||||
console.log(anotherDefaultThing); // "changed"
|
||||
}, 1000);
|
||||
```
|
||||
|
||||
可见，这种默认导出，导出的都是引用。所以导出是否是引用，不取决于是否是命名导出，**而是取决于写法**。不同的写法效果不同，哪怕相同含义的不同写法，效果也不同。
|
||||
|
||||
难道是写法的问题吗？是的，只要是 `export default` 导出的都是值而不是引用。但不幸的是，存在一个特例：
|
||||
|
||||
```javascript
|
||||
// module.js
|
||||
export default function thing() {}
|
||||
|
||||
setTimeout(() => {
|
||||
thing = 'changed';
|
||||
}, 500);
|
||||
```
|
||||
|
||||
```javascript
|
||||
// main.js
|
||||
import thing from './module.js';
|
||||
|
||||
setTimeout(() => {
|
||||
console.log(thing); // "changed"
|
||||
}, 1000);
|
||||
```
|
||||
|
||||
为什么 `export default function` 是引用呢？原因是 `export default function` 是一种特例，这种写法就会导致导出的是引用而不是值。如果我们用正常方式导出 Function，那依然遵循前面的规则：
|
||||
|
||||
```javascript
|
||||
// module.js
|
||||
function thing() {}
|
||||
|
||||
export default thing;
|
||||
|
||||
setTimeout(() => {
|
||||
thing = 'changed';
|
||||
}, 500);
|
||||
```
|
||||
|
||||
只要没有写成 `export default function` 语法，哪怕导出的对象是个 Function，引用也不会变化。所以取决效果的是写法，而与导出对象类型无关。
|
||||
|
||||
对于循环引用也有时而生效，时而不生效的问题，其实也取决于写法。下面的循环引用是可以正常工作的：
|
||||
|
||||
```javascript
|
||||
// main.js
|
||||
import { foo } from './module.js';
|
||||
|
||||
foo();
|
||||
|
||||
export function hello() {
|
||||
console.log('hello');
|
||||
}
|
||||
```
|
||||
|
||||
```javascript
|
||||
// module.js
|
||||
import { hello } from './main.js';
|
||||
|
||||
hello();
|
||||
|
||||
export function foo() {
|
||||
console.log('foo');
|
||||
}
|
||||
```
|
||||
|
||||
为什么呢？因为 `export function` 是一种特例，JS 引擎对其做了全局引用提升，所以两个模块都能各自访问到。下面方式就不行了，原因是不会做全局提升：
|
||||
|
||||
```javascript
|
||||
// main.js
|
||||
import { foo } from './module.js';
|
||||
|
||||
foo();
|
||||
|
||||
export const hello = () => console.log('hello');
|
||||
```
|
||||
|
||||
```javascript
|
||||
// module.js
|
||||
import { hello } from './main.js';
|
||||
|
||||
hello();
|
||||
|
||||
export const foo = () => console.log('foo');
|
||||
```
|
||||
|
||||
所以是否生效取决于是否提升，而是否提升取决于写法。当然下面的写法也会循环引用失败，因为这种写法会被解析为导出值：
|
||||
|
||||
```javascript
|
||||
// main.js
|
||||
import foo from './module.js';
|
||||
|
||||
foo();
|
||||
|
||||
function hello() {
|
||||
console.log('hello');
|
||||
}
|
||||
|
||||
export default hello;
|
||||
```
|
||||
|
||||
作者的探索到这里就结束了，我们来整理一下思路，尝试理解其中的规律。
|
||||
|
||||
## 精读
|
||||
|
||||
可以这么理解：
|
||||
|
||||
1. 导出与导入均为引用时，最终才是引用。
|
||||
2. 导入时，除 `{} = await import()` 外均为引用。
|
||||
3. 导出时，除 `export default thing` 与 `export default 123` 外均为引用。
|
||||
|
||||
对导入来说，`{} = await import()` 相当于重新赋值，所以具体对象的引用会丢失，也就是说异步的导入会重新赋值，而 `const module = await import()` 引用不变的原因是 `module` 本身是一个对象，`module.thing` 的引用还是不变的，即便 `module` 是被重新赋值的。
|
||||
|
||||
对导出来说，默认导出可以理解为 `export default = thing` 的语法糖，所以 `default` 本身就是一个新的变量被赋值，所以基础类型的引用无法被导出也很合理。甚至 `export default '123'` 是合法的，而 `export { '123' as thing }` 是非法的也证明了这一点，因为命名导出本质是赋值到 `default` 变量，你可以用已有变量赋值，也可以直接用一个值，但命名导出不存在赋值，所以你不能用一个字面量作命名导出。
|
||||
|
||||
而导出存在一个特例，`export default function`，这个我们尽量少写就行了，写了也无所谓，因为函数保持引用不变一般不会引发什么问题。
|
||||
|
||||
为了保证导入的总是引用，一方面尽量用命名导入，另一方面要注意命名导出。如果这两点都做不到，可以尽量把需要维持引用的变量使用 `Object` 封装，而不要使用简单变量。
|
||||
|
||||
最后对循环依赖而言，只有 `export default function` 存在申明提升的 Magic，可以保证循环依赖正常 Work，但其他情况都不支持。要避免这种问题，最好的办法是不要写出循环依赖，遇到循环依赖时使用第三个模块作中间人。
|
||||
|
||||
## 总结
|
||||
|
||||
一般我们都希望 import 到的是引用而不是瞬时值，但因为语义与特殊语法糖的原因，导致并不是所有写法效果都是一致的。
|
||||
|
||||
我也认为不需要背下来这些导入导出细枝末节的差异，只要写模块时都用规范的命名导入导出，少用默认导出，就可以在语义与实际表现上规避掉这些问题啦。
|
||||
|
||||
|
||||
> 讨论地址是：[精读《export 默认/命名导出的区别》· Issue #342 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/342)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
@@ -31,14 +31,15 @@ Atomic Design 书中提到模块化思路以及原子级的模块抽象的方法
|
||||
体验策略的核心思路是以任务为导向的。主要通过四个方面去构建体验策略：流程与方法、度量体系、运营活动和最佳实践。
|
||||
|
||||
## 精读
|
||||
整个分享感受颇深，但就『自然』这个关键词才生了我自己的疑问。主字号、字阶和行高是否存在关系
|
||||
整个分享感受颇深，但就『自然』这个关键词才生了我自己的疑问：主字号、字阶和行高是否存在关系？
|
||||
|
||||
在梳理的这层关系上，缺少了对字体的讨论，而字体又是非常关键的因素。我在之后，断断续续查阅了不少资料。写下关系背后还要考虑的问题。
|
||||
|
||||
1. 字体
|
||||
我在查阅资料的时候，发现 x-height 在西文字体中的概念。在英文字体的设计中，字体的高度体包含三部份，以基线 (baseline) 为中央，以上称之上行区域 (ascender area)，基准线内称之为 x-height，以下称为下行区域 (descender area)。小写西文字母中的核心部件都位于 x-height 位置中，这一位置也被称为排版的核心位置，是引导视线流动的关键。放一张在 wikipedie 上的图：
|
||||
|
||||
[image:CCC0E19B-0E90-4989-BD91-A2B33D38E8CD-6272-000031C10BD416C0/820px-Typography_Line_Terms.svg.png]
|
||||
我在查阅资料的时候，发现 x-height 在西文字体中的概念。在英文字体的设计中，字体的高度体包含三部份，以基线 (baseline) 为中央，以上称之上行区域 (ascender area)，基准线内称之为 x-height，以下称为下行区域 (descender area)。小写西文字母中的核心部件都位于 x-height 位置中，这一位置也被称为排版的核心位置，是引导视线流动的关键。放一张在 wikimedia 上的图：
|
||||
|
||||
|
||||
|
||||
每一种西文字体的 x-height 是不一样的。非常幸运，Jukka Korpela 做了一网站专门可以测量 web 上字体的 x-height。其中，Arial 的 X-HEIGHT RATIO 是 0.519，而 Tahoma 是 0.545，Times New Roman 是 0.448。Arial 和 Times New Roman 之间的比例差距大概 17%。
|
||||
|
||||
@@ -47,6 +48,7 @@ Atomic Design 书中提到模块化思路以及原子级的模块抽象的方法
|
||||
这是第一个问题，第二个问题是中文字体没有 x-height，也就是说中文字体就等同于西文字体的全大写，错落的美感都没有。而且中文有一个问题是因为字形之前的差异，每个字之间的留白都不尽相同，看上去又会差一些。一般情况下，靠行间距来弥补视觉差，但总体上要排版达到西文字体的效果要花一些功夫。
|
||||
|
||||
2. 屏幕
|
||||
|
||||
我们的字体大小使用的是 points(pt)，points 是一个物理衡量，它的标准是 72 points per inch（PPI）。但我们不同设备的 PPI 都是不一样的，那么造成了同样的设定在不同屏幕下看到的字体也会有差异。
|
||||
|
||||
Macbook Pro 的 PPI 是 220，Dell XPS 的 PPI 是 165，iPhone 7 有 326，但 iPhone 7p 的 PPI 有 401，而一般 HDTV 的 PPI 是 30。其中，iPhone，Macbook 都是 retina 屏。
|
||||
@@ -64,4 +66,4 @@ Macbook Pro 的 PPI 是 220，Dell XPS 的 PPI 是 165，iPhone 7 有 326，但
|
||||
## 总结
|
||||
曾经有国外的设计师有写文用黄金比例来构建字号与行高的关系，在一片喝彩中看到了资深设计师的反对，主要也是从以上和一些其它因素来说关系是比较难设定。
|
||||
|
||||
今天看到我们的设计与理性之间建立的关系，我还是比较坚信建立这种关系背后带来的是更大的价值。
|
||||
今天看到我们的设计与理性之间建立的关系，我还是比较坚信建立这种关系背后带来的是更大的价值。
|
||||
|
||||
@@ -5,14 +5,14 @@ ES 模块为 JavaScript 开发者带来了官方并且标准化的模块系统
|
||||
## 1. 引言
|
||||
|
||||
精读文章主要讨论了下面几点：
|
||||
- 模块旨在解决那些问题；
|
||||
- 模块旨在解决哪些问题；
|
||||
- 模块为开发者带来哪些；
|
||||
- ES 模块化的工作机制；
|
||||
- ES 模块化的现状；
|
||||
|
||||
## 2. 内容概要
|
||||
|
||||
### 模块旨在解决那些问题
|
||||
### 模块旨在解决哪些问题
|
||||
|
||||
JavaScript 开发可以简单地抽象成维护变量，赋值和计算操作。大量的代码在用于操作变量，开发者需要懂得如何去组织和维护这些变量。JavaScript 提供了一种方式，即函数作用域。在一个函数内只需要考虑这个函数的变量问题。不必去担心其他函数会操作这些变量。当然，随之带来的问题是，变量无法共享，无法在不同的函数之间相互共享变量。如果想要在作用域外共享变量，只能通过外层作用域，或者全局作用域。
|
||||
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
|
||||
大家都知道移动端即时通讯是一个唯一寡头市场，因此当米聊看到微信开始反超的时候，就已经知道这场战争已经结束。当时小米重点业务还在手机，米聊是团队试水的一款产品，但看到歪打误撞进入一个如此蓝海的市场，小米自己也很纠结要不要把资源都投入到米聊上。
|
||||
|
||||
反观微信，当时手机 QQ 也在做，本来怎么也轮不到微信出场，但张小龙、马化腾、张志东在微信简历了深夜小组，每天晚上都即时同步微信的进展，这让微信即时获取到了腾讯内部资源，在各种关键节点帮了很多忙，甚至让手机 QQ 技术大牛直接支持微信改善高并发问题，快速完成 QQ 好友导入功能。
|
||||
反观微信，当时手机 QQ 也在做，本来怎么也轮不到微信出场，但张小龙、马化腾、张志东在微信建立了深夜小组，每天晚上都即时同步微信的进展，这让微信即时获取到了腾讯内部资源，在各种关键节点帮了很多忙，甚至让手机 QQ 技术大牛直接支持微信改善高并发问题，快速完成 QQ 好友导入功能。
|
||||
|
||||
雷军总结到 “如果腾讯一年后才有所反应，米聊胜率是 50%，如果是腾讯两三个月就有反应，米聊应该 100% 会死掉”。
|
||||
|
||||
@@ -32,7 +32,7 @@
|
||||
|
||||
前十年，手机设备制造厂商的格局发生了很大变化。国内经历了从小米，到 OPPO、VIVO，再到华为的演化。
|
||||
|
||||
印象深刻的是看了一个雷军创办小米前夕的访谈视频，雷军说 “大家看到苹果的成功，却没有看到这片蓝海的机会，现在手机制造领域竞争太不激烈了”。同时为了对抗苹果，谷歌开源了安卓源代码，小米利用这个机会打造一款符合中国人口味的手机操作系统，并借助用户社区与性价比优势一举占领了早起市场。
|
||||
印象深刻的是看了一个雷军创办小米前夕的访谈视频，雷军说 “大家看到苹果的成功，却没有看到这片蓝海的机会，现在手机制造领域竞争太不激烈了”。同时为了对抗苹果，谷歌开源了安卓源代码，小米利用这个机会打造一款符合中国人口味的手机操作系统，并借助用户社区与性价比优势一举占领了早期市场。
|
||||
|
||||
2015-2018 年出现了 OV 领跑的情况，即 OPPO、VIVO 后来居上，有两点原因：小米还在强调各项参数指标，但 OV 宣传的概念很易懂 “充电五分钟，通话两小时”；同时 OV 还注意到了下沉市场，通过各种综艺节目冠名与 **平均 25 万家线下门店布局**，超越了小米。
|
||||
|
||||
@@ -96,7 +96,7 @@
|
||||
|
||||
切入点是 **融资**。BAT 上市融资额度分别是：百度：1.112 亿美元、**阿里巴巴 69.88 亿美元**、腾讯 0.2188 亿美元，总额 71.2 亿美元。**而滴滴到目前为止的融资已经达到 208 亿美元，** 滴滴融资超过 BAT 总和，这说明了什么？这说明滴滴走了一条不正常的商业路线，即先疯狂再冷静的烧钱路线。
|
||||
|
||||
当一个行业增长速度极速增加时，老玩家将失去优势和壁垒，所以谁能更快扩张谁就能成为最终赢家，此时如果有大量资本投入快速占领市场，让企业成为这个领域的绝对霸主，投资者就可以通过上市退出的方式把之前烧的前赚回来。然而这种烧钱商业模式是有前提的，即 **极度充裕的资本 + 清晰的结构性机会**，滴滴的结构性机会非常清晰，先垄断再收割。
|
||||
当一个行业增长速度极速增加时，老玩家将失去优势和壁垒，所以谁能更快扩张谁就能成为最终赢家，此时如果有大量资本投入快速占领市场，让企业成为这个领域的绝对霸主，投资者就可以通过上市退出的方式把之前烧的钱赚回来。然而这种烧钱商业模式是有前提的，即 **极度充裕的资本 + 清晰的结构性机会**，滴滴的结构性机会非常清晰，先垄断再收割。
|
||||
|
||||
> 传统商业模式：融资 -> 赚钱。
|
||||
>
|
||||
@@ -128,7 +128,7 @@ Uber 创始人 特拉维斯·卡兰尼克 说了一句很经典的话，翻译
|
||||
|
||||
如果资本不充裕了，对创业者来说也还有机会，比如相应的会带来低人力成本与低广告投放成本。
|
||||
|
||||
最后，周航宣传了一个创业孵化项目，即投资人与创业者深度交流几个月，在这几个月内让创业者得到成长，让投资人能看清创业者是否具备潜力，这种投资者与创业者培养感情的孵化方式是比较新颖的，相对面试来说，有更多机会呆在一起可以看人看得更清楚，投资者与创业者更容易简历信任关系。
|
||||
最后，周航宣传了一个创业孵化项目，即投资人与创业者深度交流几个月，在这几个月内让创业者得到成长，让投资人能看清创业者是否具备潜力，这种投资者与创业者培养感情的孵化方式是比较新颖的，相对面试来说，有更多机会呆在一起可以看人看得更清楚，投资者与创业者更容易建立信任关系。
|
||||
|
||||
### 语言 AI 的未来构想
|
||||
|
||||
@@ -247,7 +247,7 @@ Uber 创始人 特拉维斯·卡兰尼克 说了一句很经典的话，翻译
|
||||
1. 食材可见：比如大块杏仁碎、大块黄桃粒等。
|
||||
2. 口味丰富：芝士、椰子、巧克力、曲奇。
|
||||
|
||||
我以为朋友当场就订购了几箱，说实话还是蛮有诱惑力的，产品叫 ffit8，可以天猫自行搜索。
|
||||
我一位朋友当场就订购了几箱，说实话还是蛮有诱惑力的，产品叫 ffit8，可以天猫自行搜索。
|
||||
|
||||
极客大会每个人都送了几袋，尝了一下还是蛮好吃的，有甜味，但为什么说无糖呢，查了一下原因，原来用的是低聚异麦芽糖，这种麦芽糖难以被吸收，所以也就可以认为是无糖的啦。
|
||||
|
||||
|
||||
@@ -93,7 +93,7 @@ VIPKID 起步是依靠朋友圈传播，但随着项目的起量，需要通过
|
||||
|
||||
一加手机做的是高端手机，操作系统主打的是简洁，不会有任何广告，盈利方式则是其较高的定价。而相比手机大厂，一加手机的突破点在于集中力量做旗舰手机，通过集中投入研发资源达到单点突破。
|
||||
|
||||
最近一加也在做电视了，目的是为了占领客厅市场，可能因为手机买的比较火，资金链比较充裕所以做了更大的布局。
|
||||
最近一加也在做电视了，目的是为了占领客厅市场，可能因为手机卖的比较火，资金链比较充裕所以做了更大的布局。
|
||||
|
||||
### 解题 - 社区零售新物种的进化之道
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@
|
||||
|
||||
上面是最基本的写作技巧，我就不继续展开了，接下来要重点聊聊的是前端精读是怎么做分享的。我会从如何写作、如何坚持、如何形成正循环三个方面谈谈自己的感受。
|
||||
|
||||
首先是写作方式，前端精读的命题很明确，就是基于某个文章或者观点进行精读，因此每篇文章都有一个明确的主题。第二步是摘要，讲文章内容精简的表达出来，这可以锻炼你的总结能力，也让读者能了解到背景知识。第三步是精读，这一步需要你有一些私藏干货，毕竟把文章直接翻译一遍是没有任何价值的，我在精读自己不熟悉领域的文章时经常遇到这个问题，此时我一般会找几篇类似的文章结合阅读，并找到一些可以互补的观点，这样的精读可以让文章的观点更加饱满。最后是总结，总结时可以点题，将重要内容再梳理一遍，也可以进行延伸，指出更进一步的思考方向。
|
||||
首先是写作方式，前端精读的命题很明确，就是基于某个文章或者观点进行精读，因此每篇文章都有一个明确的主题。第二步是摘要，将文章内容精简的表达出来，这可以锻炼你的总结能力，也让读者能了解到背景知识。第三步是精读，这一步需要你有一些私藏干货，毕竟把文章直接翻译一遍是没有任何价值的，我在精读自己不熟悉领域的文章时经常遇到这个问题，此时我一般会找几篇类似的文章结合阅读，并找到一些可以互补的观点，这样的精读可以让文章的观点更加饱满。最后是总结，总结时可以点题，将重要内容再梳理一遍，也可以进行延伸，指出更进一步的思考方向。
|
||||
|
||||
为了让分享坚持下来，我在每周结束之前都会提前立好下周精读的 Flag，在 Github 开一个 issue，这样不仅可以提醒我周末的写作，还可以收获很多来自社区的讨论与反馈，让文章聚集了社区的智慧。这种提前立 Flag 的做法让我想到了自家小区物业费的收取方式，每年年初都会提前征收一整年的物业费，抛开商业手法不谈，这至少意味着物业对业务整整一年的承诺，这种承诺支撑了物业后续一整年的服务，也支撑了每周下一次的精读文章。
|
||||
|
||||
|
||||
@@ -0,0 +1,337 @@
|
||||
很多人觉得动态规划很难，甚至认为面试出动态规划题目是在为难候选人，这可能产生一个错误潜意识：认为动态规划不需要掌握。
|
||||
|
||||
其实动态规划非常有必要掌握：
|
||||
|
||||
1. 非常锻炼思维。动态规划是非常锻炼脑力的题目，虽然有套路，但每道题解法思路差异很大，作为思维练习非常合适。
|
||||
2. 非常实用。动态规划听起来很高级，但实际上思路和解决的问题都很常见。
|
||||
|
||||
动态规划用来解决一定条件下的最优解，比如：
|
||||
|
||||
- 自动寻路哪种走法最优？
|
||||
- 背包装哪些物品空间利用率最大？
|
||||
- 怎么用最少的硬币凑零钱？
|
||||
|
||||
其实这些问题乍一看都挺难的，毕竟都不是一眼能看出答案的问题。但得到最优解又非常重要，谁能忍受游戏中寻路算法绕路呢？谁不希望背包放的东西更多呢？所以我们一定要学好动态规划。
|
||||
|
||||
## 精读
|
||||
|
||||
动态规划不是魔法，它也是通过暴力方法尝试答案，只是方式更加 “聪明”，使得实际上时间复杂度并不高。
|
||||
|
||||
### 动态规划与暴力、回溯算法的区别
|
||||
|
||||
上面这句话也说明了，所有动态规划问题都能通过暴力方法解决！是的，所有最优解问题都可以通过暴力方法尝试（以及回溯算法），最终找出最优的那个。
|
||||
|
||||
暴力算法几乎可以解决一切问题。回溯算法的特点是，通过暴力尝试不同分支，最终选择结果最优的线路。
|
||||
|
||||
而动态规划也有分支概念，但不用把每条分支尝试到终点，而是在走到分叉路口时，可以直接根据前面各分支的表现，直接推导出下一步的最优解！然而无论是直接推导，还是前面各分支判断，都是有条件的。动态规划可解问题需同时满足以下三个特点：
|
||||
|
||||
1. 存在最优子结构。
|
||||
2. 存在重复子问题。
|
||||
3. 无后效性。
|
||||
|
||||
### 存在最优子结构
|
||||
|
||||
即子问题的最优解可以推导出全局最优解。
|
||||
|
||||
什么是子问题？比如寻路算法中，走完前几步就是相对于走完全程的子问题，必须保证走完全程的最短路径可以通过走完前几步推导出来，才可以用动态规划。
|
||||
|
||||
不要小看这第一条，动态规划就难在这里，你到底如何将最优子结构与全局最优解建立上关系？
|
||||
|
||||
- 对于爬楼梯问题，由于每层台阶都是由前面台阶爬上来的，因此必然存在一个线性关系推导。
|
||||
- 如果变成二维平面寻路呢？那么就升级为二维问题，存在两个变量 `i,j` 与上一步之间关系了。
|
||||
- 如果是背包问题，同时存在物品数量 `i`、物品重量 `j` 和物品质量 `k` 三个变量呢？那就升级为三位问题，需要寻找三个之间的关系。
|
||||
|
||||
依此类推，复杂度可以上升到 N 维，维度越高思考的复杂度就越高，空间复杂度就越需要优化。
|
||||
|
||||
### 存在重复子问题
|
||||
|
||||
即同一个子问题在不同场景下存在重复计算。
|
||||
|
||||
比如寻路算法中，同样两条路线的计算中，有一段路线是公共的，是计算的必经之路，那么只算一次就好了，当计算下一条路时，遇到这个子路，直接拿第一次计算的缓存即可。典型例子是斐波那契数列，对于 `f(3)` 与 `f(4)`，都要计算 `f(1)` 与 `f(2)`，因为 `f(3) = f(2) + f(1)`，而 `f(4) = f(3) + f(2) = f(2) + f(1) + f(2)`。
|
||||
|
||||
这个是动态规划与暴力解法的关键区别，动态规划之所以性能高，是因为 **不会对重复子问题进行重复计算**，算法上一般通过缓存计算结果或者自底向上迭代的方式解决，但核心是这个场景要存在重复子问题。
|
||||
|
||||
当你觉得暴力解法可能很傻，存在大量重复计算时，就要想想是哪里存在重复子问题，是否可以用动态规划解决了。
|
||||
|
||||
### 无后效性
|
||||
|
||||
即前面的选择不会影响后面的游戏规则。
|
||||
|
||||
寻路算法中，不会因为前面走了 B 路线而对后面路线产生影响。斐波那契数列因为第 N 项与前面的项是确定关联，没有选择一说，所以也不存在后效性问题。
|
||||
|
||||
什么场景存在后效性呢？比如你的人生是否能通过动态规划求最优解？其实是不行的，因为你今天的选择可能影响未来人生轨迹，比如你选择了计算机这个职业，会直接影响到工作的领域，接触到的人，后面的人生路线因此就完全变了，所以根本无法与选择了土木工程的你进行比较，因为人生赛道都变了。
|
||||
|
||||
有同学可能觉得这样局限是不是很大？其实不然，无后效性的问题仍然很多，比如背包放哪件物品、当前走哪条路线、用了哪些零钱，都不会影响整个背包大小、整张地图的地形、以及你最重要付款的金额。
|
||||
|
||||
### 解法套路 - 状态转移方程
|
||||
|
||||
解决动态规划问题的核心就是写出状态转移方程，所谓状态转移，即通过某些之前步骤推导出未来步骤。
|
||||
|
||||
状态转移方程一般写为 `dp(i) = 一系列 dp(j) 的计算`，其中 `j < i`。
|
||||
|
||||
其中 `i` 与 `dp(i)` 的含义很重要，一般 `dp(i)` 直接代表题目的答案，`i` 就有技巧了。比如斐波那契数列，`dp(i)` 表示的答案就是最终结果，`i` 表示下标，由于斐波那契数列直接把状态转移方程告诉你了 `f(x) = f(x-1) + f(x-2)`，那么根本连推导都不必了。
|
||||
|
||||
**对于复杂问题，难在如何定义 `i` 的含义，以及下一步状态如何通过之前状态推导。** 这个做多了题目就有体会，如果没有，那即便再如何解释也难以说明，所以后面还是直接看例子吧。
|
||||
|
||||
先举一个最简单的动态规划例子 - 爬楼梯来说明问题。
|
||||
|
||||
### 爬楼梯问题
|
||||
|
||||
爬楼梯是一道简单题，题目如下：
|
||||
|
||||
> 假设你正在爬楼梯。需要 `n` 阶你才能到达楼顶。每次你可以爬 1 或 2 个台阶。你有多少种不同的方法可以爬到楼顶呢？（给定 `n` 是一个正整数）
|
||||
|
||||
首先 `dp(i)` 就是问题的答案（解法套路，`dp(i)` 大部分情况就是答案，这样解题思路会最简化），即爬到第 `i` 阶台阶的方法数量，那么 `i` 自然就是要爬到第几阶台阶。
|
||||
|
||||
我们首先看是否存在 **最优子结构**？因为只能往上爬，所以第 `i` 阶台阶有几种爬方完全取决于前面有几种爬方，**而一次只能爬 1 或 2 个台阶，所以第 `i` 阶台阶只可能从第 `i-1` 或 `i-2` 个台阶爬上来的**，所以第 `i` 个台阶的爬法就是 `i-1` 与 `i-2` 总爬法之和。所以显然有最优子结构，连状态转移方程都呼之欲出了。
|
||||
|
||||
再看是否存在 **存在重复子问题**，其实爬楼梯和斐波那契数列类似，最终的状态转移方程是一样的，所以显然存在重复子问题。当然直观来看也容易分析出，10 阶台阶的爬法包含了 8、9 阶的爬法，而 9 阶台阶爬法包含了 8 阶的，所以存在重复子问题。
|
||||
|
||||
最后看是否 **无后效性**？由于前面选择一次爬 1 个或 2 个台阶并不会影响总台阶数，也不会影响你下一次能爬的台阶数，所以无后效性。如果你爬了 2 个台阶，因为太累，下次只能爬 1 个台阶，就属于有后效性了。或者只要你一共爬了 3 次 2 阶，就会因为太累而放弃爬楼梯，直接下楼休息，那么问题提前结束，也属于有后效性。
|
||||
|
||||
所以爬楼梯的状态转移方程为：
|
||||
|
||||
- `dp(i) = dp(i-1) + dp(i-2)`
|
||||
- `dp(1) = 1`
|
||||
- `dp(2) = 2`
|
||||
|
||||
注意，因为 1、2 阶台阶无法应用通用状态转移方程，所以要特殊枚举。这种枚举思路在代码里其实就是 **递归终结条件**，也就是作为函数 `dp(i)` 不能无限递归，当 `i` 取值为 1 或 2 时直接返回枚举结果（对这道题而言）。所以在写递归时，一定要优先写上递归终结条件。
|
||||
|
||||
然后我们考虑，对于第一阶台阶，只有一种爬法，这个没有争议吧。对于第二阶台阶，可以直接两步跨上来，也可以走两个一步，所以有两种爬法，也很容易理解，到这里此题得解。
|
||||
|
||||
关于代码部分，仅这道题写一下，后面的题目如无特殊原因就不写代码了：
|
||||
|
||||
```typescript
|
||||
function dp(i: number) {
|
||||
switch (i) {
|
||||
case 1:
|
||||
return 1;
|
||||
case 2:
|
||||
return 2;
|
||||
default:
|
||||
return dp(i - 1) + dp(i - 2);
|
||||
}
|
||||
}
|
||||
|
||||
return dp(n);
|
||||
```
|
||||
|
||||
当然这样写重复计算了子结构，所以我们不要每次傻傻的执行 `dp(i - 1)`（因为这样计算了超多重复子问题），我们需要用缓存兜底：
|
||||
|
||||
```typescript
|
||||
const cache: number[] = [];
|
||||
|
||||
function dp(i: number) {
|
||||
switch (i) {
|
||||
case 1:
|
||||
cache[i] = 1;
|
||||
break;
|
||||
case 2:
|
||||
cache[i] = 2;
|
||||
break;
|
||||
default:
|
||||
cache[i] = cache[i - 1] + cache[i - 2];
|
||||
}
|
||||
|
||||
return cache[i];
|
||||
}
|
||||
|
||||
// 既然用了缓存，最好子底向上递归，这样前面的缓存才能优先算出来
|
||||
for (let i = 1; i <= n; i++) {
|
||||
dp(i);
|
||||
}
|
||||
|
||||
return cache[n];
|
||||
```
|
||||
|
||||
当然这只是简单的一维线性缓存，更高级的缓存模式还有 **滚动缓存**。我们观察发现，这道题缓存空间开销是 `O(n)`，但每次缓存只用了上两次的值，所以计算到 `dp(4)` 时，`cache[1]` 就可以扔掉了，或者说，我们可以滚动利用缓存，让 `cache[3]` 占用 `cache[1]` 的空间，那么整体空间复杂度可以降低到 `O(1)`，具体做法是：
|
||||
|
||||
```typescript
|
||||
const cache: [number, number] = [];
|
||||
|
||||
function dp(i: number) {
|
||||
switch (i) {
|
||||
case 1:
|
||||
cache[i % 2] = 1;
|
||||
break;
|
||||
case 2:
|
||||
cache[i % 2] = 2;
|
||||
break;
|
||||
default:
|
||||
cache[i % 2] = cache[(i - 1) % 2] + cache[(i - 2) % 2];
|
||||
}
|
||||
|
||||
return cache[i % 2];
|
||||
}
|
||||
|
||||
for (let i = 1; i <= n; i++) {
|
||||
dp(i);
|
||||
}
|
||||
|
||||
return cache[n % 2];
|
||||
```
|
||||
|
||||
通过取余，巧妙的让缓存永远交替占用 `cache[0]` 与 `cache[1]`，达到空间利用最大化。当然，这道题因为状态转移方程是连续用了前两个，所以可以这么优化，如果遇到用到之前所有缓存的状态转移方程，就无法使用滚动缓存方案了。然而还有更高级的多维缓存，这个后面提到的时候再说。
|
||||
|
||||
接下来看一个进阶题目，最大子序和。
|
||||
|
||||
### 最大子序和
|
||||
|
||||
最大子序和是一道简单题，题目如下：
|
||||
|
||||
> 给定一个整数数组 `nums` ，找到一个具有最大和的连续子数组（子数组最少包含一个元素），返回其最大和。
|
||||
|
||||
首先按照爬楼梯的套路，`dp(i)` 就表示最大和，由于整数数组可能存在负数，所以越多数相加，和不一定越大。
|
||||
|
||||
接着看 `i`，对于数组问题，大部分 `i` 都可以代表以第 `i` 位结尾的字符串，那么 `dp(i)` 就表示以第 `i` 位结尾的字符串的最大和。
|
||||
|
||||
可能你觉得以 `i` 结尾，就只能是 `[0-i]` 范围的值，那么 `[j-i]` 范围的字符串不就被忽略了？其实不然，`[j-i]` 如果是最大和，也会被包含在 `dp(i)` 里，因为我们状态转移方程可以选择不连上 `dp(i-1)`。
|
||||
|
||||
现在开始解题：首先题目是最大和的连续子数组，一般连续的都比较简单，因为对于 `dp(i)`，要么和前面连上，要么和前面断掉，所以状态转移方程为：
|
||||
|
||||
- `dp(i) = dp(i-1) + nums[i]` 如果 `dp(i-1) > 0`。
|
||||
- `dp(i) = nums[i]` 如果 `dp(i-1) <= 0`。
|
||||
|
||||
怎么理解呢？就是第 `i` 个状态可以直接由第 `i-1` 个状态推导出来，既然 `dp(i)` 是指以第 `i` 个字符串结尾的最大和，那么 `dp(i-1)` 就是以第 `i-1` 个字符串结尾的最大和，而且此时 `dp(i-1)` 已经算出来了，那么 `dp(i)` 怎么推导就清楚了：
|
||||
|
||||
因为字符串是连续的，所以 `dp(i)` 要么是 `dp(i-1)` + `nums[i]`，要么就直接是 `nums[i]`，所以选择哪种，取决于前面的 `dp(i-1)` 是否是正数，**因为以 `i` 结尾一定包含 `nums[i]`，所以 `nums[i]` 不管是正还是负，都一定要带上。** 所以容易得知，`dp(i-1)` 如果是正数就连起来，否则就不连。
|
||||
|
||||
好了，经过这么详细的解释，相信你已经完全了解动态规划的解题套路，后面的题目解释方式我就不会这么啰嗦了！
|
||||
|
||||
这道题如果再复杂一点，不连续怎么办呢？让我们看看最长递增子序列问题吧。
|
||||
|
||||
### 最长递增子序列
|
||||
|
||||
最长递增子序列是一道中等题，题目如下：
|
||||
|
||||
> 给你一个整数数组 `nums` ，找到其中最长严格递增子序列的长度。
|
||||
>
|
||||
> 子序列是由数组派生而来的序列，删除（或不删除）数组中的元素而不改变其余元素的顺序。例如，`[3,6,2,7]` 是数组 `[0,3,1,6,2,2,7]` 的子序列。
|
||||
|
||||
其实之前的 [精读《DOM diff 最长上升子序列》](https://github.com/ascoders/weekly/blob/master/%E5%89%8D%E6%B2%BF%E6%8A%80%E6%9C%AF/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) 有详细解析过这道题，包括还有更优的贪心解法，不过我们这次还是聚焦在动态规划方法上。
|
||||
|
||||
这道题与上一道的区别就是，首先递增，其次不连续。
|
||||
|
||||
按照套路，`dp(i)` 就表示以第 `i` 个字符串结尾的最长上升子序列长度，那么重点是，`dp(i)` 怎么通过之前的推导出来呢？
|
||||
|
||||
由于是不连续的，因此不能只看 `dp(i-1)` 了，因为 `nums[i]` 项与 `dp(j)`（其中 `0 <= j < i`）组合后都可能达到最大长度，因此需要遍历所有 `j`，尝试其中最大长度的组合。
|
||||
|
||||
所以状态转移方程为：
|
||||
|
||||
`dp[i] = max(dp[j]) + 1`，其中 `0<=j<i` 且 `num[j]<num[i]`。
|
||||
|
||||
这道题的出现，预示着较为复杂的状态转移方程的出现，即第 `i` 项不是简单由 `i-1` 推导，而是由之前所有 `dp(j)` 推导，其中 `0<=j<i`。
|
||||
|
||||
除此之外，还有推导变种，即根据 `dp(dp(i))` 推导，即函数里套函数，这类问题由于加深了一层思考脑回路，所以相对更难。我们看一道这样的题目：最长有效括号。
|
||||
|
||||
### 最长有效括号
|
||||
|
||||
最长有效括号是道困难题，题目如下：
|
||||
|
||||
> 给你一个只包含 `'('` 和 `')'` 的字符串，找出最长有效（格式正确且连续）括号子串的长度。
|
||||
|
||||
这道题之所以是困难题，就因为状态转移方程存在嵌套思维。
|
||||
|
||||
我们首先按套路定义 `dp(i)` 为答案，即以第 `i` 下标结尾的字符串中最长有效括号长度。看出来了吗？一般字符串题目中，`i` 都是以字符串下标结尾来定义，很少有定义为开头或者别的定义行为。当然非字符串问题就不是这样了，这个在后面再说。
|
||||
|
||||
我们继续题目，如果 `s[i]` 是 `(`，那么不可能组成有效括号，因为最右边一定不闭合，所以考虑 `s[i]` 为 `)` 的场景。
|
||||
|
||||
如果 `s[i-1]` 为 `(`，那么构成了 `...()` 之势，最后两个自成合法闭合，所以只要看前面的即可，即 `dp(i-2)`，所以这种场景的状态转移方程为：
|
||||
|
||||
`dp(i) = dp(i-2) + 2`
|
||||
|
||||
如果 `s[i-1]` 是 `)` 呢？构成了 `...))` 的状态，那么只有 `i-1` 是合法闭合的，且这个合法闭合段之前必须是 `(` 与第 `i` 项形成闭合，才构成此时最长有效括号长度，所以这种场景的状态转移方程为：
|
||||
|
||||
`dp(i) = dp(i-1) + dp(i - dp(i-1) - 2) + 2`，你可以结合下面的图来理解：
|
||||
|
||||
<img width=300 src="https://img.alicdn.com/imgextra/i1/O1CN016tRvXm1o4p8U1Plfk_!!6000000005172-2-tps-1088-378.png">
|
||||
|
||||
可以看到，`dp(i-1)` 就是第二条横线的长度，然后如果红色括号匹配的话，长度又 +2，最后别忘了最左边如果有满足匹配的也要带上，这就是 `dp(i - dp(i-1) - 2)`，所以加到一起就是这种场景的括号最大长度。
|
||||
|
||||
到这里，一维动态规划问题深度基本上探索完了，在进入多维动态规划问题前，还有一类一维动态规划问题，属于表达式不难，也没有这题这么复杂的嵌套 DP，但是思维复杂度极高，**你一定不要盯着全流程看，那样复杂度太高，你需要充分认可 dp(i-x) 已经算出来部分的含义，进行高度抽象的思考。**
|
||||
|
||||
### 栅栏涂色
|
||||
|
||||
栅栏涂色是一道困难题，题目如下：
|
||||
|
||||
> 有 `k` 种颜色的涂料和一个包含 `n` 个栅栏柱的栅栏，每个栅栏柱可以用其中一种颜色进行上色。
|
||||
>
|
||||
> 你需要给所有栅栏柱上色，并且保证其中相邻的栅栏柱 **最多连续两个** 颜色相同。然后，返回所有有效涂色的方案数。
|
||||
|
||||
这道题 `k` 和 `n` 都非常巨大，常规暴力解法甚至普通 DP 都会超时。选择 `i` 的含义也很重要，这里 `i` 到底代表用几种颜色还是几个栅栏呢？选择栅栏会好做一些，因为栅栏是上色的主体。这样 `dp(i)` 就表示上色前 `i` 个栅栏的所有涂色方案。
|
||||
|
||||
首先看下递归终止条件。由于最多连续两个颜色相同，因此 `dp(0)` 与 `dp(1)` 分别是 `k` 与 `k*k`，因为每个栅栏随便刷颜色，自由组合。那么 `dp(2)` 有三个栅栏，非法情况是三个栅栏全同色，所以用所有可能减掉非法即可，非法场景只有 `k` 中，所以结果是 `k*k*k - k`。
|
||||
|
||||
那么考虑一般情况，对于 `dp(i)` 有几种涂色方案呢？直接思考情况太多，我们把情况一分为二，考虑 `i` 与 `i-1` 颜色相同与不同两种情况考虑。
|
||||
|
||||
如果 `i` 与 `i-1` 颜色相同，那么为了合法，`i-1` 肯定不能与 `i-2` 颜色相同了，否则就三个同色，这样的话，不管 `i-2` 是什么颜色，`i-1` 与 `i` 都只能少取一种颜色，少取的颜色就是 `i-2` 的颜色，因此 `[i-1,i]` 这个区间有 `k-1` 中取色方案，前面有 `dp(i-2)` 种取色方案，相乘就是最终方案数：`dp(i-2) * (k-1)`。
|
||||
|
||||
**这背后其实存在动态思维，即每种场景的 `k-1` 都是不同的颜色组合，只是无论前面 `dp(i-2)` 是何种组合，后面两个栅栏一定有 `k-1` 种取法，虽然颜色组合的色值不同，但颜色组合数量是不变的，所以可以统一计算。理解这一点非常关键。**
|
||||
|
||||
如果 `i` 与 `i-1` 颜色不同，那么第 `i` 项只有 `k-1` 种取法，一样也是动态的，因为永远不能和 `i-1` 颜色相同。最后乘上 `dp(i-1)` 的取色方案，就是总方案数：`dp(i-1) * (k-1)`。
|
||||
|
||||
所以最后总方案数就是两者之和，即 `dp(i) = dp(i-2) * (k-1) + dp(i-1) * (k-1)`。
|
||||
|
||||
这道题的不同之处在于，变化太多，任何一个栅栏取的颜色都会影响后面栅栏要取的颜色，**乍一看觉得是个有后效性的题目，无法用动态规划解决**。但实际上，虽然有后效性，但如果进行合理的拆解，后面栅栏的总可能性 `k-1` 是不变的，**所以考虑总可能性数量，是无后效性的**，因此站在方案总数上进行抽象思考，才可能破解此题。
|
||||
|
||||
接下来介绍多维动态规划，从二维开始。二维动态规划就是用两个变量表示 DP，即 `dp(i,j)`，一般在二维数组场景出现较多，当然也有一些两个数组之间的关系，也属于二维动态规划，为了继续探讨字符串问题，我选择了字符串问题的二维动态规划范例，编辑距离这道题来说明。
|
||||
|
||||
### 编辑距离
|
||||
|
||||
编辑距离是一道困难题，题目如下：
|
||||
|
||||
> 给你两个单词 `word1` 和 `word2`，请你计算出将 `word1` 转换成 `word2` 所使用的最少操作数。
|
||||
>
|
||||
> 你可以对一个单词进行如下三种操作：
|
||||
>
|
||||
> - 插入一个字符
|
||||
> - 删除一个字符
|
||||
> - 替换一个字符
|
||||
|
||||
只要是字符串问题，基本上 `i` 都表示以第 `i` 项结尾的字符串，但这道题有两个单词字符串，**为了考虑任意匹配场景，必须用两个变量表示，即 `i` `j` 分别表示 `word1` 与 `word2` 结尾下标时，最少操作次数。**
|
||||
|
||||
那么对于 `dp(i,j)` 考虑 `word1[i]` 与 `word2[j]` 是否相同，最后通过双重递归，先递归 `i`，在递归内再递归 `j`，答案就出来了。
|
||||
|
||||
假设最后一个字符相同，即 `word1[i] === word2[j]` 时，**由于最后一个字符不用改就相同了，所以操作次数就等价于考虑到前一个字符**，即 `dp(i,j) = dp(i-1,j-1)`
|
||||
|
||||
假设最后一个字符不同，那么 **最后一步** 有三种模式可以得到：
|
||||
|
||||
1. 假设是替换，即 `dp(i,j) = dp(i-1,j-1) + 1`，因为替换最后一个字符只要一步，并且和前面字符没什么关系，所以前面的最小操作次数直接加过来。
|
||||
2. 假设是插入，即 `word1` 插入一个字符变成 `word2`，那么只要变换到这一步再 +1 插入操作就行了，变换到这一步由于插入一个就行了，因此 `word1` 比 `word2` 少一个单词，其它都一样，要变换到这一步，就要进行 `dp(i,j-1)` 的变换，因此 `dp(i,j) = dp(i,j-1) + 1`。。
|
||||
3. 假设是删除，即 `word1` 删除一个字符变成 `word2`，同理，要进行 `dp(i-1,j)` 的变化后多一步删除，因此 `dp(i,j) = dp(i-1,j) + 1`。
|
||||
|
||||
由于题目取操作最少次数，所以这三种情况取最小即可，即 `dp(i,j) = min(dp(i-1,j-1), dp(i,j-1), dp(i-1,j)) + 1`。
|
||||
|
||||
所以同时考虑了最后一个字符是否相同后，合并了的状态转移方程就是最终答案。
|
||||
|
||||
我们再考虑终止条件，即 `i` 或 `j` 为 -1 时的情况，因为状态转移方程 `i` 和 `j` 不断减小，肯定会减少到 0 或 -1，因为 0 是字符串还有一个字符，相对比如考虑 -1 字符串为空时方便，因此我们考虑 -1 时作为边界条件。
|
||||
|
||||
当 `i` 为 -1 时，即 `word1` 为空，此时要变换为 `word2` 很显然，只有插入 `j` 次是最小操作次数，因此此时 `dp(i,j) = j`；同理，当 `j` 为 -1 时，即 `word2` 为空，此时要删除 `i` 次，因此操作次数为 `i`，所以 `dp(i,j) = i`。
|
||||
|
||||
### 非字符串问题
|
||||
|
||||
说到这，相信你在字符串动规问题上已经如鱼得水了，我们再看看非字符串场景的动规问题。非字符串场景的动规比较经典的有三个，第一是矩形路径最小距离，或者最大收益；第二是背包问题以及变种；第三是打家劫舍问题。
|
||||
|
||||
这些问题解决方式都一样，只是对于 `dp(i)` 的定义略有区别，比如对于矩形问题来说，`dp(i,j)` 表示走到 `i,j` 格子时的最小路径；对于背包问题，`dp(i,j)` 表示装了第 `i` 个物品时，背包还剩 `j` 空间时最大价格；对于打家劫舍问题，`dp(i)` 表示打劫到第 `i` 个房间时最大收益。
|
||||
|
||||
因为篇幅问题这里就不一详细介绍了，只简单说明一下矩形问题于打家劫舍问题。
|
||||
|
||||
对于矩形问题，状态转移方程重点看上个状态是如何转移过来的，一般矩形只能向右或者向下移动，路途可能有一些障碍物不能走，我们要做分支判断，然后选择一条符合题目最值要求的路线作为当前 `dp(i)` 的转移方程即可。
|
||||
|
||||
对于打家劫舍问题，由于不能同时打劫相邻的房屋，所以对于 `dp(i)`，要么为了打劫 `i-1` 而不打劫第 `i` 间，或者打劫 `i-2` 于第 `i` 间，取这两种终态的收益最大值即可，即 `dp(i) = max(dp(i-1), dp(i-2) + coins[i])`。
|
||||
|
||||
## 总结
|
||||
|
||||
动态规划的核心分为三步，首先定义清楚状态，即 `dp(i)` 是什么；然后定义状态转移方程，这一步需要一些思考技巧；最后思考验证一下正确性，即尝试证明你写的状态转移方程是正确的，在这个过程要做到状态转移的不重不漏，所有情况都被涵盖了进来。
|
||||
|
||||
动态规划最经典的还是背包问题，由于篇幅原因，可能下次单独出一篇文章介绍。
|
||||
|
||||
> 讨论地址是：[精读《算法 - 动态规划》· Issue #327 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/327)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
@@ -0,0 +1,235 @@
|
||||
滑动窗口算法是较为入门题目的算法，一般是一些有规律数组问题的最优解，也就是说，如果一个数组问题可以用动态规划解，但又可以使用滑动窗口解决，那么往往滑动窗口的效率更高。
|
||||
|
||||
双指针也并不局限在数组问题，像链表场景的 “快慢指针” 也属于双指针的场景，其快慢指针滑动过程中本身就会产生一个窗口，比如当窗口收缩到某种程度，可以得到一些结论。
|
||||
|
||||
因此掌握滑动窗口非常基础且重要，接下来按照我的经验给大家介绍这个算法。
|
||||
|
||||
## 精读
|
||||
|
||||
滑动窗口使用双指针解决问题，所以一般也叫双指针算法，因为两个指针间形成一个窗口。
|
||||
|
||||
什么情况适合用双指针呢？一般双指针是暴力算法的优化版，所以：
|
||||
|
||||
1. 如果题目较为简单，且是数组或链表问题，往往可以尝试双指针是否可解。
|
||||
2. 如果数组存在规律，可以尝试双指针。
|
||||
3. 如果链表问题限制较多，比如要求 O(1) 空间复杂度解决，也许只有双指针可解。
|
||||
|
||||
也就是说，当一个问题比较有规律，或者较为简单，或较为巧妙时，可以尝试双指针（滑动窗口）解法。
|
||||
|
||||
我们还是拿例子说明，首先是两数之和。
|
||||
|
||||
### 两数之和
|
||||
|
||||
两数之和是一道简单题，实际上和滑动窗口没什么关系，但为了引出三数之和，还是先讲这道题。题目如下：
|
||||
|
||||
> 给定一个整数数组 `nums` 和一个整数目标值 `target`，请你在该数组中找出 **和为目标值** `target` 的那 **两个** 整数，并返回它们的数组下标。
|
||||
>
|
||||
> 你可以假设每种输入只会对应一个答案。但是，数组中同一个元素在答案里不能重复出现。
|
||||
|
||||
暴力解法就是穷举所有两数之和，发现和为 `target` 结束，显然这种做法有点慢，我们换一种思路。
|
||||
|
||||
由于可以用空间换时间，又只有两个数，我们可以对题目进行转化，即通过一次遍历，将 `nums` 每一项都减去 `target`，然后找到后面任意一项值为前面的结果，即表示它们和为 `target`。
|
||||
|
||||
可以用哈希表 `map` 加速查询，即将每一项 `target - num` 作为 key，如果后面任何一个 `num` 作为 key 可以在 `map` 中找到，则得解，且上一个数的原始值可以存在 `map` 的 value 中。这要仅需遍历一次，时间复杂度为 O(n)。
|
||||
|
||||
之所以说这道题，是因为这道题是单指针，即只有一个指针在数组中移动，并配合哈希表快速求解。对于稍微复杂的问题，单指针就不够了，需要用双指针解决（一般来说不会用到三或以上指针），那复杂点的题目就是三数之和了。
|
||||
|
||||
### 三数之和
|
||||
|
||||
三数之和是一道中等题，别以为只是两数之和的加强版，其思路完全不同。题目如下：
|
||||
|
||||
> 给你一个包含 `n` 个整数的数组 `nums`，判断 `nums` 中是否存在三个元素 `a`，`b`，`c` ，使得 `a + b + c = 0` ？请你找出所有和为 `0` 且不重复的三元组。
|
||||
|
||||
由于超过了两个数，所以不能像双指针一样求解了，因为即便用了哈希表存储，也会在遍历时遇到 “两数之和” 的问题，而哈希表方案无法继续嵌套使用，即无法进一步降低复杂度。
|
||||
|
||||
为了降低时间复杂度，我们希望只遍历一次数组，这就需要数组满足一定条件我们才能用滑动窗口，所以我们对数组进行排序，使用快排的时间复杂度为 O(nlogn)，时间复杂度已超出两数之和，不过因为题目复杂，这个牺牲是无法避免的。
|
||||
|
||||
假设从小到大排序，那我们就拿到一个递增数组了，此时经典滑动窗口方法就可用了！怎么滑动呢？首先创建两个指针，分别叫 `left` 与 `right`，通过不断修改 `left` 与 `right`，让它们在数组间滑动，这个窗口大小就是符合题目要求的，当滑动完毕时，返回所有满足条件的窗口即可，记录其实很简单，只要在滑动过程中记录一下就行。
|
||||
|
||||
首先排除异常值，即数组长度过小，然后对于常规情况，我们拿一个全局变量存储当前窗口数的和，这样 `right + 1` 只要累加 `nums[right+1]`，`left + 1` 只要减去 `nums[left]` 即可快速拿到求和。
|
||||
|
||||
由于需要考虑所有情况，所以需要一次数组遍历，对于每次遍历的起始点 `i`，如果 `nums[i] > 0` 则直接跳过，因为数组排序后是递增的，后面的和只会永远大于 0；否则进行窗口滑动，先形成三个点 `[i, i+1, n-1]`，这样保持 `i` 不动，不断包夹后两个数字即可，只要它们的和大于 0，就将第三个点左移（数字会变小），否则将第二个点右移（数字会变大），其实第二个和第三个数就是滑动窗口。
|
||||
|
||||
这样的话时间复杂度是 O(n²)，因为存在两次遍历，忽略快排较小的时间复杂度。
|
||||
|
||||
那么四数之和，五数之和呢？
|
||||
|
||||
### 四数之和
|
||||
|
||||
该题和三数之和完全一样，除了要求变成四个数。
|
||||
|
||||
首先还是排序，然后双重递归，即确定前两个数不变，不断包夹后两个数，后两个数就是 `i+1` 和 `n-1`，算法和三数之和一样，所以最终时间复杂度为 O(n³)。
|
||||
|
||||
那么 N 数之和（N > 2）都可以采用这个思路解决。
|
||||
|
||||
为什么没有更优的方法呢？我想可能因为：
|
||||
|
||||
1. 无论几数之和，快排一次时间复杂度都是固定的，所以沿用三数之和的方案其实占了排序算法便宜。
|
||||
2. 滑动窗口只能用两个指针进行移动，而没有三指针但又保持时间复杂度不变的窗口滑动算法存在。
|
||||
|
||||
所以对于 N 数之和，通过排序付出了 O(nlogn) 时间复杂度之后，可以用滑动窗口，将 2 个数时间复杂度优化为 O(n)，所以整体时间复杂度就是 O(N - 2 + 1 个 n)，即 O(N-1 个 n)，而最小的时间复杂度 O(n²) 比 O(nlogn) 大，所以总是忽略快排的时间复杂度，所以三数之和时间复杂度是 O(n²)，四数之和时间复杂度为 O(n³)，依此类推。
|
||||
|
||||
可以看到，我们从最简单的两数之和，到三数之和、四数之和，跨入了滑动窗口的门槛，**本质上是利用排序后数组有序的特性，让我们在不用遍历数组的前提下，可以对窗口进行滑动**，这是滑动窗口算法的核心思想。
|
||||
|
||||
为了加强这个理解，再看一道类似的题目，无重复字符的最长子串。
|
||||
|
||||
### 无重复字符的最长子串
|
||||
|
||||
无重复字符的最长子串是一道中等题，题目如下：
|
||||
|
||||
> 给定一个字符串，请你找出其中不含有重复字符的 **最长子串** 的长度。
|
||||
|
||||
由于最长子串是连续的，所以显然可以考虑滑动窗口解法。其实确定了滑动窗口解法后，问题很简单，只要设定 `left` 和 `right`，并用一个哈希 Set 记录哪些元素存在过，在过程中记录最大长度，并尝试 `right` 右移，如果右移过程中发现出现重复字符，则 `left` 右移，直到消除这个重复字符为止。
|
||||
|
||||
解法并不难，但问题是，我们要想清楚，为什么用滑动窗口遍历一次就可以做到 **不重不漏**？即这道题时间复杂度只有 O(n) 呢？
|
||||
|
||||
只要想明白两个问题：
|
||||
|
||||
1. 由于子串是连续的，既然不存在跳跃的情况，只要一次滑动窗口内能包含所有解，就涵盖了所有情况。
|
||||
2. 一次滑动窗口内不包含什么？由于我们只将 `right` 右移，且出现重复后尝试将 `left` 右移到不重复后，`right` 再继续右移，这忽略了出现重复后， `right` 左移的情况。
|
||||
|
||||
我们重点看二个问题，显然，如果 `abcd` 这四个连续的字符不重复，那么 `left` 右移后，`bcd` 也显然不重复，所以如果此时就可以将 `right` 右移形成 `bcda` 的窗口继续找下去，而不需要尝试 `bc` 这种情况，因为这种情况虽然不重复，但一定不是最优解。
|
||||
|
||||
好了，通过这个例子我们看到，滑动窗口如何缩小窗口范围其实不难，但更要注重的是，背后对于为什么可以用滑动窗口的思考，滑动窗口有没有做到不重不漏，如果没有想清楚，可能整个思路都错了。
|
||||
|
||||
那么滑动窗口的应用已经说透了？其实没有，我们上面只说了缩小窗口这种比较单一的脑回路，其实双指针构成的滑动窗口不一定都是那么正常滑的，一种有意思的场景是快慢指针，即是以相对速度决定窗口如何滑动。
|
||||
|
||||
关于快慢指针，经典的题目有环形链表、删除有序数组中的重复项。
|
||||
|
||||
### 环形链表
|
||||
|
||||
环形链表是一道简单题，题目如下：
|
||||
|
||||
> 给定一个链表，判断链表中是否有环。
|
||||
|
||||
如果不是进阶要求空间复杂度 O(1)，我们可以在遍历时稍稍 “污染” 一下原始链表，这样总能发现是否走了回头路。
|
||||
|
||||
但要求空间开销必须是常数，我们不得不考虑快慢指针。说实话第一次看到这道题时，如果能想到快慢指针的解法，绝对是相当聪明的，因为必须要有知识迁移的能力。怎么迁移呢？想象学校在开运动会，相信每次都有一个跑的最慢的同学，慢到被最快的同学追了一圈。
|
||||
|
||||
等等，操场不就是环形链表吗？**只要有人跑得慢，就会被跑得快的追上，追上不就是相遇了吗？** 所以快慢指针分别跑，只要相遇则判定为环形链表，否则不是环形链表，且一定有一个指针先走完。
|
||||
|
||||
那么细枝末节就是优化效率了，慢指针到底慢多少呢？
|
||||
|
||||
有人会说，运动会上，跑步慢的人如果想被快的人追上，最好就不要跑。对，但环形链表问题中，链表不是操场，可能只有某一段是环，也就是跑步慢的人至少要跑到环里，才可能与跑得快人的相遇，但跑得慢的人又不知道哪里开始成环，这就是难点。
|
||||
|
||||
你有没有想过，为什么快排用二分法，而不是三分法？为什么每次中间来一刀，可以最快排完？原因是二分可以用最小的 “深度” 将数组切割为最小粒度。那么同理，快慢指针中，慢指针要想被尽快追上，速度可能最好是快指针的一半。那从逻辑上分析，为什么呢？
|
||||
|
||||
直观来看，如果慢指针太慢，可能大部分时间都在进入环形之前的位置转悠，快指针虽然快，但永远在环里跑，所以总是无法遇到慢指针，这给我们的启示是，慢指针不能太慢；如果慢指针太快，几乎速度和快指针一样，就像两个运动员都互不相让的争夺第一一样，他们真的想相遇，估计得连续跑几个小时吧，所以慢指针也不能过快。所以这样分析下来，慢指针只能取折中的一半速度。
|
||||
|
||||
但用一半的慢速真的能最快相遇吗？不一定，举一个例子，假设链表是完美环形，一共有 [1,6] 共 6 个节点，那么慢指针一次走 1 步，快指针一次走 2 步，那么一共是 `2,3 3,5 4,1 5,3 6,5 1,1` 共走 6 步，但如果快指针一次走 3 步呢？一共是 `2,4 3,1 4,4` 3 步。这么说一般速度不一定最优？其实不是的，计算机在链表寻址时，节点访问的消耗也要考虑进去，后者虽然看上去更快，但其实访问链表 `next` 的次数更多，对计算机来说，还不如第一种来得快。
|
||||
|
||||
所以准确来说，不是快指针比慢指针快一倍速度，而是慢指针一次走一步，快指针一次走两步最优，因为相遇时，总移动步数最少。
|
||||
|
||||
再说一个简单问题，即用快慢指针判断链表中倒数第k个节点或者链表中点。
|
||||
|
||||
### 判断链表中点
|
||||
|
||||
快指针是慢指针速度 2 倍，当快指针到达尾部，慢指针的位置就是链表中点。
|
||||
|
||||
### 链表中倒数第k个节点
|
||||
|
||||
链表中倒数第k个节点是一道简单题，题目如下：
|
||||
|
||||
> 输入一个链表，输出该链表中倒数第 `k` 个节点。为了符合大多数人的习惯，本题从 `1` 开始计数，即链表的尾节点是倒数第 `1` 个节点。
|
||||
|
||||
这道题就是判断链表中点的变种，只要让慢指针比快指针慢 `k` 个节点，当快指针到达末尾时，慢指针就指向倒数第 `k+1` 个节点了。这道题注意一下数数别数错了即可。
|
||||
|
||||
接下来终于说道快慢指针的另一种经典用法题型，删除有序数组中的重复项了。
|
||||
|
||||
### 删除有序数组中的重复项
|
||||
|
||||
删除有序数组中的重复项是一道简单题，题目如下：
|
||||
|
||||
> 给你一个有序数组 `nums` ，请你 **原地** 删除重复出现的元素，使每个元素 只出现一次 ，返回删除后数组的新长度。
|
||||
|
||||
这道题，要原地删除重复元素，并返回长度，所以只能用快慢指针。但怎么用呢？快多少慢多少？
|
||||
|
||||
其实这道题快多少慢多少并不像前面题目一样预设好了，而是根据遇到的实际数字来判断。
|
||||
|
||||
我们假设慢指针是 `slow` 快指针是 `fast`，注意变量命名也有意思，同样是双指针问题，有的是 `slow right`，有的是 `slow fast`，重点在于用何种方法移动指针。
|
||||
|
||||
我们只要让 `fast` 扫描完全表，把所有不重复的挪到一起就好了，这样时间复杂度是 O(n)，具体做法是：
|
||||
|
||||
1. 让 `slow` 和 `fast` 初始都指向 index 0。
|
||||
2. 由于是 **有序数组**，所以就算有重复也一定连在一起，所以可以让 `fast` 直接往后扫描，只有遇到和 `slow` 不同的值，才把其和 `slow+1` 交换，然后 `slow` 自增，继续递归，直到 `fast` 走到数组尾部结束。
|
||||
|
||||
做完这套操作后，`slow` 的下标值就是答案。
|
||||
|
||||
可以看到，这道题对于慢指针要如何慢，其实是根据值来判断的，如果 `fast` 的值与 `slow` 一样，那么 `slow` 就一直等着，因为相同的值要被忽略掉，让 `fast` 走就是在跳过重复值。
|
||||
|
||||
说完了常见的双指针用法，我们再来看一些比较难啃的特殊问题，这里主要讲两个，分别是 **盛最多水的容器** 与 **接雨水**。
|
||||
|
||||
### 盛最多水的容器
|
||||
|
||||
盛最多水的容器是一道中等题，题目如下：
|
||||
|
||||
> 给你 `n` 个非负整数 `a1，a2，...，an`，每个数代表坐标中的一个点 `(i, ai)` 。在坐标内画 `n` 条垂直线，垂直线 `i` 的两个端点分别为 `(i, ai)` 和 `(i, 0)` 。找出其中的两条线，使得它们与 `x` 轴共同构成的容器可以容纳最多的水。
|
||||
|
||||
<img width=400 src="https://z3.ax1x.com/2021/06/12/25WZZt.png">
|
||||
|
||||
建议先仔细读一读题目再继续，这道题相对比较复杂。
|
||||
|
||||
好了，为什么说这是一道双指针题目呢？因为我们看怎么计算容纳水的体积？其实这道题就简化为长乘宽。
|
||||
|
||||
长度就是选取的两个柱子的间距，宽就是其中最短柱子的高度。问题就是，虽然柱子间距越远，长度越大，但宽度不一定最大，一眼是没法看出来最优解的。
|
||||
|
||||
所以还是得多次尝试，那怎么样可以用最少的尝试次数，但又不重不漏呢？定义 `left` `right` 两个指针，分别指向 `0` 与 `n-1` 即首尾两个位置，此时长度是最大的（柱子间距离是最远的），接下来尝试一下别的柱子，试哪个呢？
|
||||
|
||||
- 较长的那个？如果新的比较短的更短，那么宽度更短了；如果新的比较短的更长，也没用，因为较短的决定了水位。
|
||||
- 较短的那个？如果新的较长，那么才有机会整体体积更大。
|
||||
|
||||
所以我们移动较短的那个，并每次计算一下体积，最后当两根柱子相遇时结束，过程中最大体积就是全局最大体积。
|
||||
|
||||
这道题双指针的移动规则比较巧妙，与上面普通题目不一样，重点不是在是否会运用滑动窗口算法，而是能否找到移动指针的规则。
|
||||
|
||||
当然你可能会说，为什么两个指针要定义在最两端，而非别的地方？因为这样就无法控制变量了。
|
||||
|
||||
如果指针选在中间位置，那么指针外移时，柱子的间距与柱子长度同时变化，就很难找到一条完美路线。比如我们移动较短的柱子，是因为较短的柱子确定了最低水位，改变它，可能让最低水位变高，但问题是两根柱子的间距也在变大，这样移动较短还是较长的柱子哪个更优就说不准了。
|
||||
|
||||
说实话这种方法不太容易想到，需要多找几种选择尝试才能发现。当然，算法如果按照固定套路就能推导出来，也就没有难度了，所以要接受这种思维跳跃。
|
||||
|
||||
接下来我们看一道更特殊的滑动窗口问题，接雨水，它甚至分为多段滑动窗口。
|
||||
|
||||
### 接雨水
|
||||
|
||||
接雨水是一道困难题，题目如下：
|
||||
|
||||
> 给定 `n` 个非负整数表示每个宽度为 `1` 的柱子的高度图，计算按此排列的柱子，下雨之后能接多少雨水。
|
||||
|
||||
<img width=400 src="https://z3.ax1x.com/2021/06/12/25OejP.png">
|
||||
|
||||
与盛雨水不同，这道接雨水看的是整体，我们要算出能接的所有水的数量。
|
||||
|
||||
其实相比上一道题，这道题还算比较好切入，因为我们从左到右计算即可。思考发现，只有产生了 “凹槽” 才能接到雨水，而凹槽由它两边最高的柱子决定，那什么范围算一段凹槽呢？
|
||||
|
||||
显然凹槽是可以明确分组的，一个凹槽也无法被分割为多个凹槽，就像你看水坑一样，无论有多少，多深的坑在一起，总能一个一个数清楚，所以我们就从左到右开始数。
|
||||
|
||||
怎么数凹槽呢？用滑动窗口办法，每个窗口就是一个凹槽，那么窗口的起点 `left` 就是左边第一根柱子，有以下情况：
|
||||
|
||||
- 如果直接相邻的右边柱子更高（或一样高），那从它开始向右看，根本无法接雨水，所以直接抛弃，`left++`。
|
||||
- 如果直接相邻的右边柱子更矮，那就有产生凹槽的机会。
|
||||
- 那么继续往右看，如果右边一直都更矮，那也接不到雨水。
|
||||
- 如果右边出现一个高一些的，就可以接到雨水，那问题是怎么算能接多少，以及找到哪结束呢？
|
||||
- 只要记录最左边柱子高度，右边柱子的结束判断条件是 “遇到一个与最左边一样高的柱子”，因为一个凹槽能接多少水，取决于最短的柱子。当然，如果右边没有柱子了，虽然比最左边低一点，但只要比最深的高，也算一个结束点。
|
||||
|
||||
这道题，一旦遇到凹槽结束点，`left` 就会更新，开始新的一轮凹槽计算，所以存在多个滑动窗口。从这道题可以看出，滑动窗口题型相当灵活，不仅判断条件因题而异，窗口数量可能也有多个。
|
||||
|
||||
## 总结
|
||||
|
||||
滑动窗口本质是双指针的玩法，不同题目有不同的套路，从最简单的按照规律包夹，到快慢指针，再到无固定套路的因题而异的特殊算法。
|
||||
|
||||
其实按照规律包夹的套路属于碰撞指针范畴，一般对于排序好的数组，可以一步一步判断，或者用二分法判断，总之不用根据整体遍历来判断，效率自然高。
|
||||
|
||||
快慢指针也有套路可循，但具体快多少，或者慢多少，可能具体场景要具体看。
|
||||
|
||||
对于无固定套路的滑动窗口，就要根据题目仔细品味啦，如果所有套路都能总结出来，算法也少了乐趣。
|
||||
|
||||
> 讨论地址是：[精读《算法 - 滑动窗口》· Issue #328 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/328)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
@@ -0,0 +1,213 @@
|
||||
如何尝试走迷宫呢？遇到障碍物就从头 “回溯” 继续探索，这就是回溯算法的形象解释。
|
||||
|
||||
更抽象的，可以将回溯算法理解为深度遍历一颗树，每个叶子结点都是一种方案的终态，而对某条路线的判断可能在访问到叶子结点之前就结束。
|
||||
|
||||
<img width=250 src="https://z3.ax1x.com/2021/06/26/R3HBoq.png">
|
||||
|
||||
相比动态规划，回溯可以解决的问题更复杂，尤其是针对具有后效性的问题。
|
||||
|
||||
动态规划之所以无法处理有后效性问题，原因是其 `dp(i)=F(dp(j))` 其中 `0<=j<i` 导致的，因为 `i` 通过 `i-1` 推导，如果 `i-1` 的某种选择会对 `i` 的选择产生影响，那么这个推导就是无效的。
|
||||
|
||||
而回溯，由于每条分支判断是相互独立的，互不影响，所以即便前面的选择具有后效性，这个后效性也可以在这条选择线路持续影响下去，而不影响其他分支。
|
||||
|
||||
所以回溯是一种适用性更广的算法，但相对的，其代价（时间复杂度）也更高，所以只有当没有更优算法时，才应当考虑回溯算法。
|
||||
|
||||
## 精读
|
||||
|
||||
经过上述思考，回溯算法的实现思路就清晰了：递归或迭代。由于两者可以相互转换，而递归理解成本较低，因此我更倾向于递归方式解决问题。
|
||||
|
||||
这里必须提到一点，即工作与算法竞赛思维的区别：由于递归调用堆栈深度较大，整体性能不如迭代好，且迭代写法不如递归自然，所以做算法题时，为了提升那么一点儿性能，以及不经意间流露自己的实力，可能大家更倾向用迭代方式解决问题。
|
||||
|
||||
但工作中，大部分是性能不敏感场景，可维护性反而是更重要的，所以工程代码建议用更易理解的递归方式解决问题，把堆栈调用交给计算机去做。
|
||||
|
||||
其实算法代码追求更简短，能写成一行的绝不换行也是同样的道理，希望大家能在不同环境里自由切换习惯，而不要拘泥于一种风格。
|
||||
|
||||
用递归解决回溯的套路不止一种，我介绍一下自己常用的 TS 语言方法：
|
||||
|
||||
```typescript
|
||||
function func(params: any[], results: any[] = []) {
|
||||
// 消耗 params 生成 currentResult
|
||||
const { currentResult, restParams } = doSomething(params);
|
||||
// 如果 params 还有剩余，则递归消耗，直到 params 耗尽为止
|
||||
if (restParams.length > 0) func(restParams, results.concat(currentResult));
|
||||
}
|
||||
```
|
||||
|
||||
这里 `params` 就类似迷宫后面的路线，而 `results` 记录了已走的最佳路线，当 `params` 路线消耗完了，就走出了迷宫，否则终止，让其它递归继续走。
|
||||
|
||||
所以回溯逻辑其实挺好写的，难在如何判断这道题应该用回溯做，以及如何优化算法复杂度。
|
||||
|
||||
先从两道入门题讲起，分别是电话号码的字母组合与复原 IP 地址。
|
||||
|
||||
### 电话号码的字母组合
|
||||
|
||||
电话号码的字母组合是一道中等题，题目如下：
|
||||
|
||||
> 给定一个仅包含数字 `2-9` 的字符串，返回所有它能表示的字母组合。答案可以按 **任意顺序** 返回。
|
||||
>
|
||||
> 给出数字到字母的映射如下（与电话按键相同）。注意 1 不对应任何字母。
|
||||
>
|
||||
> <img width=200 src="https://z3.ax1x.com/2021/06/26/R3L0wd.png">
|
||||
|
||||
电话号码数字对应的字母其实是个映射表，比如 `2` 映射 `a,b,c`，`3` 映射 `d,e,f`，那么 `2,3` 能表示的字母组合就有 `3x3=9` 种，而要打印出比如 `ad`、`ae` 这种组合，肯定要用穷举法，穷举法也是回溯的一种，只不过每一种可能性都要而已，而复杂点儿的回溯可能并不是每条路径都符合要求。
|
||||
|
||||
所以这道题就好做了，只要构造出所有可能的组合就行。
|
||||
|
||||
接下来我们看一道类似，但有一定分支合法判断的题目，复原 IP 地址。
|
||||
|
||||
### 复原 IP 地址
|
||||
|
||||
复原 IP 地址是一道中等题，题目如下：
|
||||
|
||||
> 给定一个只包含数字的字符串，用以表示一个 IP 地址，返回所有可能从 s 获得的 **有效 IP 地址** 。你可以按任何顺序返回答案。
|
||||
>
|
||||
> **有效 IP 地址** 正好由四个整数（每个整数位于 0 到 255 之间组成，且不能含有前导 0），整数之间用 '.' 分隔。
|
||||
>
|
||||
> 例如："0.1.2.201" 和 "192.168.1.1" 是 有效 IP 地址，但是 "0.011.255.245"、"192.168.1.312" 和 "192.168@1.1" 是 **无效 IP 地址**。
|
||||
|
||||
首先肯定一个一个字符读取，问题就在于，一个字符串可能表示多种可能的 IP，比如 `25525511135` 可以表示为 `255.255.11.135` 或 `255.255.111.35`，原因在于，`11.135` 和 `111.35` 都是合法的表示，所以我们必须用回溯法解决问题，只是回溯过程中，会根据读取数据动态判定增加哪些新分支，以及哪些分支是非法的。
|
||||
|
||||
比如读取到 `[1,1,1,3,5]` 时，由于 `11` 和 `111` 都是合法的，因为这个位置的数字只要在 `0~255` 之间即可，而 `1113` 超过这个范围，所以被忽略，所以从这个场景中分叉出两条路：
|
||||
|
||||
- 当前项：`11`，余项 `135`。
|
||||
- 当前项：`111`，余项 `35`。
|
||||
|
||||
之后再递归，直到非法情况终止，比如以及满了 4 项但还有剩余数字，或者不满足 IP 范围等。
|
||||
|
||||
可见，只要梳理清楚合法与非法的情况，直到如何动态生成新的递归判断，这道题就不难。
|
||||
|
||||
这道题输入很直白，直接给出来了，其实不是每道题的输入都这么容易想，我们看下一道全排列。
|
||||
|
||||
### 全排列
|
||||
|
||||
全排列是一道中等题，题目如下：
|
||||
|
||||
> 给定一个不含重复数字的数组 `nums` ，返回其 **所有可能的全排列** 。你可以 **按任意顺序** 返回答案。
|
||||
|
||||
与还原 IP 地址类似，我们也是消耗给的输入，比如 `123`，我们可以先消耗 `1`，余下 `23` 继续组合。但与 IP 复原不同的是，第一个数字可以是 `1` `2` `3` 中的任意一个，所以其实在生成当前项时有所不同：当前项可以从所有余项里挑选，然后再递归即可。
|
||||
|
||||
比如 `123` 的第一次可以挑选 `1` 或 `2` 或 `3`，对于 `1` 的情况，还剩 `23`，那么下次可以挑选 `2` 或 `3`，当只剩一项时，就不用挑了。
|
||||
|
||||
全排列的输入虽然不如还原 IP 地址的输入直白，但好歹是基于给出的字符串推导而出的，那么再复杂点的题目，输入可能会拆解为多个，这需要你灵活思考，比如括号生成题目。
|
||||
|
||||
### 括号生成
|
||||
|
||||
括号生成是一道中等题，题目如下：
|
||||
|
||||
> 数字 n 代表生成括号的对数，请你设计一个函数，用于能够生成所有可能的并且 **有效的** 括号组合。
|
||||
>
|
||||
> 示例：
|
||||
> 输入：`n = 3`
|
||||
>
|
||||
> 输出：["((()))","(()())","(())()","()(())","()()()"]
|
||||
|
||||
这道题基本思路与上一题很像，而且由于题目问的是所有可能性，而不是最优解，所以无法用动规，所以我们考虑回溯算法。
|
||||
|
||||
上一道 IP 题目的输入是已知字符串，而这道题的输入就要你动动脑经了。这道题的输入是字符串吗？显然不是，因为输入是括号数量，那么只有一个括号数量就够了吗？不够，因为题目要求有效括号，那什么是有效括号？闭合的才是，所以我们想到用左右括号数量表示这个数字，即输入是 `n`，那么转化为 `open=n, close=n`。
|
||||
|
||||
有了输入，如何消耗输入呢？我们每一步都可以用一个左括号 `open` 或一个右括号 `close`，但第一个必须是 `open`，且当前已消耗 `close` 数量必须小于已消耗 `open` 数量时，才可以加上 `close`，因为一个 `close` 左边必须有个 `open` 形成合法闭合。
|
||||
|
||||
所以这道题就迎刃而解了。回顾来看，回溯的入参要能灵活思考，而这个思考取决于你的经验，比如遇到括号问题，下意识就直到拆解为左右括号。所以算法之间是相通的，适当的知识迁移可以事半功倍。
|
||||
|
||||
好了，在此我们先打住，其实不是所有题目都可以用回溯解决，但有些题目看上去只是回溯题目的变种，但其实不然。我们回到上一道全排列题，与之比较像的是 **下一个排列**，这道题看上去好像是基于全排列衍生的，但却无法用回溯算法解决，我们看看这道题。
|
||||
|
||||
### 下一个排列
|
||||
|
||||
下一个排列是一道中等题，题目如下：
|
||||
|
||||
> 实现获取 **下一个排列** 的函数，算法需要将给定数字序列重新排列成字典序中下一个更大的排列。
|
||||
>
|
||||
> 如果不存在下一个更大的排列，则将数字重新排列成最小的排列（即升序排列）。
|
||||
>
|
||||
> 必须 **原地** 修改，只允许使用额外常数空间。
|
||||
|
||||
比如：
|
||||
|
||||
> 输入：nums = [1,2,3]
|
||||
>
|
||||
> 输出：[1,3,2]
|
||||
|
||||
> 输入：nums = [3,2,1]
|
||||
>
|
||||
> 输出：[1,2,3]
|
||||
|
||||
如果你在想，能否借鉴全排列的思想，在全排列过程中自然推导出下一个排列，那大概率是想不通的，因为从整体推导到局部的效率太低，这道题直接给出一个局部值，我们必须用相对 “局部的方法” 快速推导出下一个值，所以这道题无法用回溯算法解决。
|
||||
|
||||
对于 `3,2,1` 的例子，由于已经是最大排列了，所以下个排列只能是初始化的 `1,2,3` 升序，这个是特例。除此之外，都有下一个更大排列，以 `1,2,3` 为例，更大的是 `1,3,2` 而不是 `2,1,3`。
|
||||
|
||||
我们再观察长一点的例子，比如 `3,2,1,4,5,6`，可以发现，无论前面如何降序，只要最后几个是升序的，只要把最后两个扭转即可：`3,2,1,4,6,5`。
|
||||
|
||||
如果是 `3,2,1,4,5,6,9,8,7` 呢？显然 `9,8,7` 任意相邻交换都会让数字变得更小，不符合要求，我们还是要交换 `5,6` .. 不 `6,9`，因为 `65x` 比 `596` 要大更多。到这里我们得到几个规律：
|
||||
|
||||
1. 尽可能交换后面的数。交换 `5,6` 会比交换 `6,9` 更大，因为 `6,9` 更靠后，位数更小。
|
||||
2. 我们将 `3,2,1,4,5,6,9,8,7` 分为两段，分别是前段 `3,2,1,4,5,6` 和后段 `9,8,7`，我们要让前段尽可能大的数和后段尽可能小的数交换，同时还要保证，后段尽可能小的数比前段尽可能大的数还要 **大**。
|
||||
|
||||
为了满足第二点，我们必须从后向前查找，如果是升序就跳过，直到找到一个数字 `j` 比 `j-1` 小，那么前段作为交换的就是第 `j` 项，后段要找一个最小的数与之交换，由于搜索的算法导致后段一定是降序的，因此从后向前找到第一个比 `j` 大的项交换即可。
|
||||
|
||||
最后我们发现，交换后也不一定是完美下一项，因为后段是降序的，而我们已经把前面一个尽可能最小的 “大” 位改大了，后面一定要升序才满足下一个排列，因此要把后段进行升序排列。
|
||||
|
||||
因为后段已经满足降序了，因此采用双指针交换法相互对调即可变成升序，这一步千万不要用快排，会导致整体时间复杂度提高 O(nlogn)。
|
||||
|
||||
最后由于只扫描了一次 + 反转后段一次，所以算法复杂度是 O(n)。
|
||||
|
||||
从这道题可以发现，不要轻视看似变种的题目，从全排列到下一个排列，可能要完全换一个思路，而不是对回溯进行优化。
|
||||
|
||||
我们继续回到回溯问题，回溯最经典的问题就是 N 皇后，也是难度最大的题目，与之类似的还有解决数独问题，不过都类似，我们这次还是以 N 皇后作为代表来理解。
|
||||
|
||||
### N 皇后问题
|
||||
|
||||
N 皇后问题是一道困难题，题目如下：
|
||||
|
||||
> n 皇后问题 研究的是如何将 `n` 个皇后放置在 `n×n` 的棋盘上，并且使皇后彼此之间不能相互攻击。
|
||||
>
|
||||
> 给你一个整数 `n` ，返回所有不同的 `n` 皇后问题 的解决方案。
|
||||
>
|
||||
> 每一种解法包含一个不同的 `n` 皇后问题 的棋子放置方案，该方案中 `'Q'` 和 `'.'` 分别代表了皇后和空位。
|
||||
|
||||
皇后的攻击范围非常广，包括横、纵、斜，所以当 `n<4` 时是无解的，而神奇的时，`n>=4` 时都有解，比如下面两个图：
|
||||
|
||||
<img width=400 src="https://z3.ax1x.com/2021/06/26/R8CtUS.png">
|
||||
|
||||
这道题显然具有 “强烈的” 后效性，因为皇后攻击范围是由其位置决定的，换而言之，一个皇后位置确定后，其他皇后的可能摆放位置会发生变化，因此只能用回溯算法。
|
||||
|
||||
那么如何识别合法与非法位置呢？核心就是根据横、纵、斜三种攻击方式，建立四个数组，分别存储哪些行、列、撇、捺位置是不能放置的，然后将所有合法位置都作为下一次递归的可能位置，直到皇后放完，或者无位置可放为止。
|
||||
|
||||
容易想到的就是四个数组，分别存储被占用的下标，这样的话，只是递归中条件判断分支复杂一些，其它其实并无难度。
|
||||
|
||||
这道题的空间复杂度进阶算法是，利用二进制方式，使用 **4 个数字** 代替四个下标数组，每个数组转化为二进制时，1 的位置代表被占用，0 的位置代表未占用，通过位运算，可以更快速、低成本的进行位置占用，与判断当前位置是否被占用。
|
||||
|
||||
这里只提一个例子，就可以感受到二进制魅力：
|
||||
|
||||
由于按照行看，一行只能放一个皇后，所以每次都从下一行看起，因此行限制就不用看了（至少下一行不可能和前面的行冲突），所以我们只要记录列、撇、捺三个位置即可。
|
||||
|
||||
不同之处在于，我们采用二进制的数字，只要三个数字即可表示列、撇、捺。二进制位中的 1 表示被占用，0 表示不被占用。
|
||||
|
||||
比如列、撇、捺分别是变量 `x,y,z`，对应二进制可能是:
|
||||
|
||||
- `0000001`
|
||||
- `0010000`
|
||||
- `0001100`
|
||||
|
||||
“非” 逻辑是任意为 1 就是 1，因此 “非” 逻辑可以将所有 1 合并，即 `x | y | z` 即 `0011101`。
|
||||
|
||||
然后将这个结果取反，用非逻辑，即 `~(x | y | z)`，结果是 `1100010`，那这里所有的 `1` 就表示可放的位置，我们记这个变量为 `p`，通过 `p & -p` 不断拿最后一位 `1` 得到安放位置，即可调用递归了。
|
||||
|
||||
从这道题可以发现，N 皇后难度不在于回溯算法，而在于如何利用二进制写出高效的回溯算法。所以回溯算法考察的比较综合，因为算法本身很模式化，而且相对比较 “笨拙”，所以需要将更多重心放在优化效率上。
|
||||
|
||||
## 总结
|
||||
|
||||
回溯算法本质上是利用计算机高速计算能力，将所有可能都尝试一遍，唯一区别是相对暴力解法，可能在某个分支提前终止（枝剪），所以其实是一个较为笨重的算法，当题目确实具有后效性，且无法用贪心或者类似下一排列这种巧妙解法时，才应该采用。
|
||||
|
||||
最后我们要总结对比一下回溯与动态规划算法，其实动态规划算法的暴力递归过程就与回溯相当，只是动态规划可以利用缓存，存储之前的结果，避免重复子问题的重复计算，而回溯因为面临的问题具有后效性，不存在重复子问题，所以无法利用缓存加速，所以回溯算法高复杂度是无法避免的。
|
||||
|
||||
回溯算法被称为 “通用解题方法”，因为可以解决许多大规模计算问题，是利用计算机运算能力的很好实践。
|
||||
|
||||
> 讨论地址是：[精读《算法 - 回溯》· Issue #331 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/331)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
@@ -0,0 +1,258 @@
|
||||
二叉树是一种数据结构，并且拥有种类复杂的分支，本文作为入门篇，只介绍一些基本二叉树的题型，像二叉搜索树等等不在此篇介绍。
|
||||
|
||||
二叉树其实是链表的升级版，即链表同时拥有两个 Next 指针，就变成了二叉树。
|
||||
|
||||
二叉树可以根据一些特性，比如搜索二叉树，将查找的时间复杂度降低为 logn，而且堆这种数据结构，也是一种特殊的二叉树，可以以 O(1) 的时间复杂度查找最大值或者最小值。所以二叉树的变种很多，都可以很好的解决具体场景的问题。
|
||||
|
||||
## 精读
|
||||
|
||||
要入门二叉树，就必须理解二叉树的三种遍历策略，分别是：前序遍历、中序遍历、后序遍历，这些都属于深度优先遍历。
|
||||
|
||||
所谓前中后，就是访问节点值在什么时机，其余时机按先左后右访问子节点。比如前序遍历，就是先访问值，再访问左右；后续遍历就是先访问左右，再访问值；中序遍历就是左，值，右。
|
||||
|
||||
用递归方式遍历树非常简单：
|
||||
|
||||
```typescript
|
||||
function visitTree(node: TreeNode) {
|
||||
// 三选一：前序遍历
|
||||
// console.log(node.val)
|
||||
visitTree(node.left)
|
||||
// 三选一：中序遍历
|
||||
// console.log(node.val)
|
||||
visitTree(node.right)
|
||||
// 三选一：后序遍历
|
||||
// console.log(node.val)
|
||||
}
|
||||
```
|
||||
|
||||
当然题目需要我们巧妙利用二叉树三种遍历的特性来解题，比如重建二叉树。
|
||||
|
||||
### 重建二叉树
|
||||
|
||||
重建二叉树是一道中等题，题目如下：
|
||||
|
||||
> 输入某二叉树的前序遍历和中序遍历的结果，请重建该二叉树。假设输入的前序遍历和中序遍历的结果中都不含重复的数字。
|
||||
>
|
||||
> 例如
|
||||
>
|
||||
> 前序遍历 preorder = `[3,9,20,15,7]`
|
||||
>
|
||||
> 中序遍历 inorder = `[9,3,15,20,7]`
|
||||
|
||||
先给你二叉树前序与中序遍历结果，让你重建二叉树，这种逆向思维的题目就难了不少。
|
||||
|
||||
仔细观察遍历特性可以看出，我们也许能推测出一些关键节点的位置，再通过数组切割递归一下就能解题。
|
||||
|
||||
前序遍历第一个访问的一定是根节点，因此 `3` 一定是根节点，然后我们在中序遍历找到 `3`，这样 **左边就是所有左子树的中序遍历结果，右边就是所有右子树的中序遍历结果**，我们只要再找到 **左子树的前序遍历结果与右子树的前序遍历结果**，就可以递归了，终止条件是左或右子树只有一个值，那样就代表叶子节点。
|
||||
|
||||
那么怎么找左右子树的前序遍历呢？上面例子中，我们找到了 `3` 的左右子树的中序遍历结果，由于前序遍历优先访问左子树，因此我们数一下中序遍历中，`3` 左边的数量，只有一个 `9`，那么我们从前序遍历的 `3,9,20,15,7` 在 `3` 之后推一位，那么 `9` 就是左子树前序遍历结果，`9` 后面的 `20,15,7` 就是右子树的前序遍历结果。
|
||||
|
||||
最后只要递归一下就能解题了，我们将输入不断拆解为左右子树的的输入，直到达到终止条件。
|
||||
|
||||
解决此题的关键是，不仅要知道如何写前中后序遍历，还要知道前序遍历第一个节点是根节点，后序遍历最后一个节点是根节点，中序遍历以根节点为中心，左右分别是其左右子树，这几个重要延伸特征。
|
||||
|
||||
说完了反向，我们说正向，即递归一棵二叉树。
|
||||
|
||||
其实二叉树除了递归，还有一种常见的遍历方法是利用栈进行广度优先遍历，典型题目有从上到下打印二叉树。
|
||||
|
||||
### 从上到下打印二叉树
|
||||
|
||||
从上到下打印二叉树是一道简单题，题目如下：
|
||||
|
||||
> 从上到下按层打印二叉树，同一层的节点按从左到右的顺序打印，每一层打印到一行。
|
||||
|
||||
这道题要求从左到右顺序打印，完全遵循广度优先遍历，我们可以在二叉树递归时，先不要急着读取值，而是按照左、中、右，遇到左右子树节点，就推入栈的末尾，利用 `while` 语句不断循环，直到栈空为止。
|
||||
|
||||
利用展开时追加到栈尾，并不断循环处理栈元素的方式非常优雅，而且符合栈的特性。
|
||||
|
||||
当然如果题目要求倒序打印，你就可以以 右、中、左 的顺序进行处理。
|
||||
|
||||
接下来看看深度优先遍历，典型题目是二叉树的深度。
|
||||
|
||||
### 二叉树的深度
|
||||
|
||||
二叉树的深度是一道简单题，题目如下：
|
||||
|
||||
> 输入一棵二叉树的根节点，求该树的深度。从根节点到叶节点依次经过的节点（含根、叶节点）形成树的一条路径，最长路径的长度为树的深度。
|
||||
|
||||
由于二叉树有多种分支，在遍历前，我们并不知道哪条路线是最深的，所以必须利用递归尝试。
|
||||
|
||||
我们可以转换一下思路，用函数式语义方式来理解。假设我们有了这样一个函数 `deep` 来求二叉树深度，那么这个函数内容是什么呢？二叉树只可能存在左右子树，所以 `deep` 必然是左右子树的最大深度的最大值 +1（它自己）。
|
||||
|
||||
而求左右子树深度可以复用 `deep` 函数形成递归，我们只需要考虑边界情况，即访问节点不存在时，返回深度 `0` 即可，因此代码如下：
|
||||
|
||||
```typescript
|
||||
function deep(node: TreeNode) {
|
||||
if (!node) return 0
|
||||
return Math.max(deep(node.left), deep(node.right)) + 1
|
||||
}
|
||||
```
|
||||
|
||||
从这可以看出，二叉树一般能用比较优雅的递归函数解决，如果你的解题思路不包含递归，往往就不是最优雅的解法。
|
||||
|
||||
类似优雅的题目还有，平衡二叉树。
|
||||
|
||||
### 平衡二叉树
|
||||
|
||||
平衡二叉树是一道简单题，题目如下：
|
||||
|
||||
> 输入一棵二叉树的根节点，判断该树是不是平衡二叉树。如果某二叉树中任意节点的左右子树的深度相差不超过 1，那么它就是一棵平衡二叉树。
|
||||
|
||||
同理，我们设函数 `isBalance` 就是答案函数，那么一个平衡二叉树的特征，必然是其左右子树也是平衡的，所以可以写成：
|
||||
|
||||
```typescript
|
||||
function isBalance(node: TreeNode) {
|
||||
if (root == null) return true
|
||||
return isBalance(node.left) && isBalance(node.right)
|
||||
}
|
||||
```
|
||||
|
||||
但是哪里不对，左右子树平衡还不够啊，万一左右子树之间深度相差超过 1 就坏了，所以还要求一下左右子树的深度，我们复用上题的函数 `deep`，整理一下如下：
|
||||
|
||||
```typescript
|
||||
function isBalance(node: TreeNode) {
|
||||
if (root == null) return true
|
||||
return isBalance(root.left) && isBalance(root.right) &&
|
||||
Math.abs(deep(root.left) - deep(root.right)) < 2
|
||||
}
|
||||
```
|
||||
|
||||
这道题提醒我们，不是所有递归都能完美写成仅自己调用自己的模式，不同题目要辅以其他函数，要敏锐的察觉到还缺少哪些条件。
|
||||
|
||||
还有一种递归，不是简单的函数自身递归自身，而是要构造出另一个函数进行递归，原因是递归参数不同。典型的题目有对称的二叉树。
|
||||
|
||||
### 对称的二叉树
|
||||
|
||||
对称的二叉树是一道简单题，题目如下：
|
||||
|
||||
> 请实现一个函数，用来判断一棵二叉树是不是对称的。如果一棵二叉树和它的镜像一样，那么它是对称的。
|
||||
|
||||
我们要注意，一颗二叉树的镜像比较特殊，比如最左节点与最右节点互为镜像，但它们的父节点并不相同，因此 `isSymmetric(tree)` 这样的参数是无法子递归的，我们必须拆解为左右子树作为参数，让它们进行相等判断，在传参时，将父级不同，但互为镜像的左右节点传入即可。
|
||||
|
||||
所以我们必须起一个新函数 `isSymmetricNew(left, right)`，将 `left.left` 与 `right.right` 对比，将 `left.right` 与 `right.left` 对比即可。
|
||||
|
||||
具体代码就不写了，然后注意一下边界情况即可。
|
||||
|
||||
这道题的重点是，由于镜像的关系，并不拥有相同的父节点，因此必须用一个新参数的函数进行递归。
|
||||
|
||||
那如果这道题反过来呢？要求构造一个二叉树镜像呢？
|
||||
|
||||
### 二叉树的镜像
|
||||
|
||||
二叉树的镜像是一道简单题，题目如下：
|
||||
|
||||
> 请完成一个函数，输入一个二叉树，该函数输出它的镜像。
|
||||
|
||||
判断镜像比较容易，但构造镜像就要想一想了：
|
||||
|
||||
```text
|
||||
例如输入：
|
||||
4
|
||||
/ \
|
||||
2 7
|
||||
/ \ / \
|
||||
1 3 6 9
|
||||
|
||||
镜像输出：
|
||||
4
|
||||
/ \
|
||||
7 2
|
||||
/ \ / \
|
||||
9 6 3 1
|
||||
```
|
||||
|
||||
观察发现，其实镜像可以理解为左右子树互换，同时 **其各子树的左右子树再递归互换**，这就构成了一个递归：
|
||||
|
||||
```typescript
|
||||
function mirrorTree(node: TreeNode) {
|
||||
if (node === null) return null
|
||||
|
||||
const left = mirrorTree(node.left)
|
||||
const right = mirrorTree(node.right)
|
||||
node.left = right
|
||||
node.right = left
|
||||
return node
|
||||
}
|
||||
```
|
||||
|
||||
我们要从下到上，因此先生成递归好的左右子树，再进行当前节点的互换，最后返回根节点即可。
|
||||
|
||||
接下来介绍一些有一定难度的经典题。
|
||||
|
||||
### 二叉树的最近公共祖先
|
||||
|
||||
二叉树的最近公共祖先是一道中等题，题目如下：
|
||||
|
||||
> 给定一个二叉树, 找到该树中两个指定节点的最近公共祖先。
|
||||
|
||||
题目很简短，也很明确，就是寻找最近的公共祖先。显然，根节点是所有节点的公共祖先，但不一定是最近的。
|
||||
|
||||
我们还是用递归，先考虑特殊情况：如果任意节点等于当前节点，那么当前节点一定就是最近公共祖先，因为另一个节点一定在其子节点中。
|
||||
|
||||
然后，利用递归思想思考，假设我们利用 `lowestCommonAncestor` 函数分别找到左右子节点的最近公共祖先会怎样？
|
||||
|
||||
```typescript
|
||||
function lowestCommonAncestor(node, a, b) {
|
||||
const left = lowestCommonAncestor(node.left)
|
||||
const right = lowestCommonAncestor(node.right)
|
||||
}
|
||||
```
|
||||
|
||||
如果左右节点都找不到，说明只可能当前节点是最近公共子节点：
|
||||
|
||||
```typescript
|
||||
if (!left && !right) return node
|
||||
```
|
||||
|
||||
如果左节点找不到，则右节点就是答案，否则相反：
|
||||
|
||||
```typescript
|
||||
if (!left) return right
|
||||
return left
|
||||
```
|
||||
|
||||
这里巧妙利用了函数语义进行结果判断。
|
||||
|
||||
### 二叉树的右视图
|
||||
|
||||
二叉树的右视图是一道中等题，题目如下：
|
||||
|
||||
> 给定一棵二叉树，想象自己站在它的右侧，按照从顶部到底部的顺序，返回从右侧所能看到的节点值。
|
||||
|
||||
想象一束光照，从二叉树右侧向左照射，自上而下读取即是答案。
|
||||
|
||||
其实这道题可以认为是一道融合题。右侧的光束可以认为是分层照射的，那么当我们用广度优先算法遍历时，对于每一层，都找到最后一个节点打印，并且按顺序打印就是最终答案。
|
||||
|
||||
有一道二叉树的题目，是根据树的深度，按照广度优先遍历打印成二维数组，记录树的深度其实也有巧妙办法，即在栈尾追加元素时，增加一个深度 key，那么访问时自然就可以读到深度值。
|
||||
|
||||
### 完全二叉树的节点个数
|
||||
|
||||
完全二叉树的节点个数是一道中等题，题目如下：
|
||||
|
||||
> 给你一棵 **完全二叉树** 的根节点 `root` ，求出该树的节点个数。
|
||||
>
|
||||
> **完全二叉树** 的定义如下：在完全二叉树中，除了最底层节点可能没填满外，其余每层节点数都达到最大值，并且最下面一层的节点都集中在该层最左边的若干位置。若最底层为第 `h` 层，则该层包含 `1 ~ 2^h` 个节点。
|
||||
|
||||
用递归解决这道题的话，关键要分几种情况探讨完全二叉树。
|
||||
|
||||
由于最底层可能没有填满，但最底层一定有节点，而且是按照从左到右填的，那么递归遍历左节点就可以获取树的最大深度，通过最大深度我们可以快速计算出节点个树，前提是二叉树必须是满的。
|
||||
|
||||
但最底层节点可能不满，那怎么办呢？分情况即可，首先，如果一直按照 `node.right....right` 递归获得右侧节点深度，发现和最大深度相同，那么就是一个满二叉树，直接计算出结果即可。
|
||||
|
||||
我们再看 `node.right...left` 的深度如果等于最大深度，说明 `node.left` 也就是左子树是个满二叉树，可以通过数学公式 `2^n-1` 快速算出节点个树。
|
||||
|
||||
如果不等于最大深度呢？**则说明右子树深度减 1 是满二叉树**，也可以通过数学公式快速计算节点个数，再通过递归计算另一边即可。
|
||||
|
||||
## 总结
|
||||
|
||||
从题目中可以感受到，二叉树的解题魅力在于递归，二叉树问题中，我们可以同时追求优雅与答案。
|
||||
|
||||
> 讨论地址是：[精读《算法 - 二叉树》· Issue #331 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/331)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
@@ -0,0 +1,150 @@
|
||||
二叉搜索树的特性是，任何一个节点的值：
|
||||
|
||||
- 都大于左子树任意节点。
|
||||
- 都小于右子树任意节点。
|
||||
|
||||
因为二叉搜索树的特性，我们可以更高效的应用算法。
|
||||
|
||||
## 精读
|
||||
|
||||
还记得 [《算法 - 二叉树》](https://github.com/ascoders/weekly/blob/master/%E7%AE%97%E6%B3%95/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) 提到的 [二叉树的最近公公祖先](https://github.com/ascoders/weekly/blob/master/%E7%AE%97%E6%B3%95/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) 问题吗？如果这是一颗二叉搜索树，是不是存在更巧妙的解法？你可以暂停先思考一下。
|
||||
|
||||
### 二叉搜索树的最近公共祖先
|
||||
|
||||
二叉搜索树的最近公共祖先是一道简单题，题目如下：
|
||||
|
||||
> 给定一个二叉搜索树, 找到该树中两个指定节点的最近公共祖先。
|
||||
>
|
||||
> 百度百科中最近公共祖先的定义为：“对于有根树 `T` 的两个结点 `p`、`q`，最近公共祖先表示为一个结点 `x`，满足 `x` 是 `p`、`q` 的祖先且 `x` 的深度尽可能大（一个节点也可以是它自己的祖先）。”
|
||||
|
||||
第一个判断条件是相同的，即当前节点值等于 `p` 或 `q` 任意一个，则当前节点就是其最近公共祖先。
|
||||
|
||||
如果不是呢？同时考虑二叉搜索树与公共祖先的特性可以发现：
|
||||
|
||||
1. 如果 `p` `q` 两个节点分别位于当前节点的左 or 右边，则当前节点符合要求。
|
||||
2. 如果 `p` `q` 值一个大于，一个小于当前节点，说明 `p` `q` 分布在当前节点左右两侧。
|
||||
|
||||
基于以上考虑，可以仅通过值大小来判断，因此题目就被简化了。
|
||||
|
||||
接下来看一道入门题，即如何验证一颗二叉树是二叉搜索树。
|
||||
|
||||
### 验证二叉搜索树
|
||||
|
||||
验证二叉搜索树是一道中等题，题目如下：
|
||||
|
||||
> 给定一个二叉树，判断其是否是一个有效的二叉搜索树。
|
||||
>
|
||||
> 假设一个二叉搜索树具有如下特征：
|
||||
>
|
||||
> - 节点的左子树只包含小于当前节点的数。
|
||||
> - 节点的右子树只包含大于当前节点的数。
|
||||
> - 所有左子树和右子树自身必须也是二叉搜索树。
|
||||
|
||||
这道题看上去就应该用非常优雅的递归来实现。
|
||||
|
||||
二叉搜索树最重要的就是对节点值的限制，我们如果能正确卡住每个节点的值，就可以判断了。
|
||||
|
||||
如何判断节点值是否正确呢？我们可以用递归的方式倒推，即从根节点开始，假设根节点值为 `x`，那么左树节点的值就必须小于 `x`，再往左，那么值就要小于（假设第一个左节点值为 `x1`） `x1`，右树也是一样判断，因此就可以写出答案：
|
||||
|
||||
```typescript
|
||||
function isValidBST(node: TreeNode, min = -Infinity, max = Infinity) {
|
||||
if (node === null) return true
|
||||
// 判断值范围是否合理
|
||||
if (node.val < min || node.val > max) return false
|
||||
// 继续递归，并且根据二叉搜索树特定，进一步缩小最大、最小值的锁定范围
|
||||
return
|
||||
// 左子树值 max 为当前节点值
|
||||
isValidBST(node.left, min, node.val) &&
|
||||
// 右子树值 min 为当前节点值
|
||||
isValidBST(node.right, node.val, max) &&
|
||||
}
|
||||
```
|
||||
|
||||
接下来看一些简单的二叉搜索树操作问题，比如删除二叉搜索树中的节点。
|
||||
|
||||
### 删除二叉搜索树中的节点
|
||||
|
||||
删除二叉搜索树中的节点是一道中等题，题目如下：
|
||||
|
||||
> 给定一个二叉搜索树的根节点 root 和一个值 key，删除二叉搜索树中的 key 对应的节点，并保证二叉搜索树的性质不变。返回二叉搜索树（有可能被更新）的根节点的引用。
|
||||
>
|
||||
> 一般来说，删除节点可分为两个步骤：
|
||||
>
|
||||
> 1. 首先找到需要删除的节点；
|
||||
> 2. 如果找到了，删除它。
|
||||
>
|
||||
> 说明： 要求算法时间复杂度为 `O(h)`，`h` 为树的高度。
|
||||
|
||||
要删除二叉搜索树的节点，找到节点本身并不难，因为如果值小了，就从左子树找；如果值大了，就从右子树找，这本身查找起来是非常简单的。难点在于，如何保证删除元素后，这棵树还是一颗二叉搜索树？
|
||||
|
||||
假设我们删除的是叶子结点，很显然，二叉搜索树任意子树都是二叉搜索树，我们又没有破坏其他节点的关系，因此直接删除就行了，最简单。
|
||||
|
||||
如果删除的不是叶子结点，那么谁来 “上位” 代替这个节点呢？题目要求复杂度为 `O(h)` 显然不能重新构造，我们需要仔细考虑。
|
||||
|
||||
假设删除的节点存在右节点，那么肯定从右节点找到一个代替值移上来，找谁呢？找右节点的最小值呀，最小值很好找的，找完代替后，相当于 **问题转移为删除这个最小值节点，递归就完事了。**
|
||||
|
||||
假设删除的节点存在左节点，但是没有右节点，那就从左节点找一个最大的替换掉，同理递归删除找到的节点。
|
||||
|
||||
可以看到，删除二叉搜索树，为了让二叉搜索树性质保持不变，需要不断进行重复子问题的递归删除节点。
|
||||
|
||||
当你掌握二叉搜索树特性后，可以尝试构造二叉搜索树了，下面就是一道让你任意构造二叉搜索树的题目：不同的二叉搜索树。
|
||||
|
||||
### 不同的二叉搜索树
|
||||
|
||||
不同的二叉搜索树是一道中等题，题目如下：
|
||||
|
||||
> 给你一个整数 `n` ，求恰由 `n` 个节点组成且节点值从 `1` 到 `n` 互不相同的 **二叉搜索树** 有多少种？返回满足题意的二叉搜索树的种数。
|
||||
|
||||
这道题重点在于动态规划思维 + 笛卡尔积组合的思维。
|
||||
|
||||
需要将所有可能性想象为确定了根节点后，左右子树到底有几种组合方式？
|
||||
|
||||
举个例子，假设 `n=10`，那么这 10 个节点，假设我取第 3 个节点为根节点，那么左子树有 2 个节点，右子树有 7 个节点，这种组合情况就有 `DP(2) * DP(7)` 这么多，假设 `DP(n)` 表示 n 个节点能组成任意二叉搜索树的数量。
|
||||
|
||||
这仅是第 3 个节点为根节点的情况，实际上每个节点作为根节点都是不同的树（轴对称也算不同的），那么我们就要从第 1 个节点计算到第 `n` 个节点。
|
||||
|
||||
因此答案就出来了，我们先考虑特殊情况 `DP(0)=1` `DP(1)=1`，所以：
|
||||
|
||||
```typescript
|
||||
function numTrees(n: number) {
|
||||
const dp: number[] = [1, 1]
|
||||
|
||||
for (let i = 2; i <= n; i++) {
|
||||
for (let j = 1; j <= i; j++) {
|
||||
dp[i] += dp[j - 1] * dp[i - j]
|
||||
}
|
||||
}
|
||||
|
||||
return dp[n]
|
||||
}
|
||||
```
|
||||
|
||||
最后再看一道找值题，并不是找最大值，而是找第 k 大值。
|
||||
|
||||
### 二叉搜索树的第 K 大节点
|
||||
|
||||
二叉搜索树的第 K 大节点是一道简单题，题目如下：
|
||||
|
||||
> 给定一棵二叉搜索树，请找出其中第 `k` 大的节点。
|
||||
|
||||
这道题之所以简单，是因为二叉搜索树的中序遍历是从小到大的，因此只要倒序中序遍历，就可以找到第 `k` 大的节点。
|
||||
|
||||
倒序中序遍历，即右、根、左。
|
||||
|
||||
这道题就解决啦。
|
||||
|
||||
## 总结
|
||||
|
||||
二叉搜索树的特性很简单，就是根节点值夹在左右子树中间，利用这个特性几乎可以解决一切相关问题。
|
||||
|
||||
但通过上面几个例子可以发现，仅熟悉二叉搜索树特性还是不够的，一些题目需要结合二叉树中序遍历、公共祖先特征等通用算法思路结合来解决，因此学会融会贯通很重要。
|
||||
|
||||
> 讨论地址是：[精读《算法 - 二叉搜索树》· Issue #337 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/337)
|
||||
|
||||
**如果你想参与讨论，请 [点击这里](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)）
|
||||
Reference in New Issue
Block a user