前言：在接触 Tailwind 的刚开始，并没有感受到它的好处，反而觉得这是一种非常繁琐的事情，非常不适应。为了更好的使用 Tailwindcss，便有了该系列：梳理总结使用规律和用法。
章节系列共分为 7 个小节，每小节开头介绍使用规律，再介绍具体使用方法，各自小节独立可依照需求进行查阅。
提示
Unocss 兼容 Tailwind，因此仅需学习 Tailwind 的用法即可。
大约 2 分钟
Koa 是通过将中间件组织成一个“洋葱模型”（Onion Model），并使用 async/await 或 Promise 链式执行机制实现异步中间件的。
核心机制
-
中间件存储：
- 中间件被存储为一个数组（
middlewares）。 - 每个中间件是一个函数，接受
ctx（上下文）和next（下一个中间件的执行函数）作为参数。
- 中间件被存储为一个数组（
-
组合中间件（compose）：
- Koa 使用一个函数（类似于
compose）将多个中间件组合成一个函数，并按顺序执行。 - 每个中间件调用
await next()来手动控制下一个中间件的执行时机。
- Koa 使用一个函数（类似于
-
递归调用：
- 当一个中间件调用
await next()时，它会等待下一个中间件执行完成后再继续执行当前中间件后面的逻辑。
- 当一个中间件调用
大约 2 分钟
这里用于梳理 React 的一些技术实现细节，以作技术回顾。
setState 的更新逻辑
这里主要讨论的是 React18 以前的策略。React18 之后，全部采用异步调用。可见setstate-的更新逻辑
React18 以前，setState 的更新逻辑有时是同步的有时是异步的，这取决于调用 setState 的环境。实际上，在 React 控制之内的事件处理过程中，setState 是异步的，而在 React 控制之外的事件处理过程中，setState 是同步的。
大约 2 分钟
在项目目录中我有如下目录文件，想将其转化为对象结构：
.
├── bar
│ ├── a
│ │ ├── n1.js
│ │ └── n2.js
│ └── b
│ ├── n1.js
│ └── n2.js
└─── foo
├── a
│ ├── n1.ts
│ └── n2.ts
└── b
├── n1.ts
└── n2.ts
小于 1 分钟
最新需要批量修复 git 分支问题，记录一下。
需求是有很多项目分支存在一些共性 bug，需要批量修复这些分支。每个分支都 cherry-pick 或者 merge 的话又太费时间。因此有了这个脚本实现，顺便也学习一下 bash 的一些语法。
最终效果如下,有合并进度条、状态表格等提示输出：
=========================================
🌿 Starting the Merge Process
=========================================
[############# ] 33% ➜ Switching to feature/branch1...
[############# ] 33% ➜ Merging fix/common-issue into feature/branch1...
✔ Successfully merged into feature/branch1.
➜ Attempting to push feature/branch1 to remote...
✘ Failed to push feature/branch1 to remote.
[########################## ] 66% ➜ Switching to feature/branch2...
[########################## ] 66% ➜ Merging fix/common-issue into feature/branch2...
✘ Merge conflict detected in feature/branch2!
➜ Aborting merge and restoring clean working directory...
[########################################] 100% ➜ Switching to feature/branch3...
[########################################] 100% ➜ Merging fix/common-issue into feature/branch3...
✔ Successfully merged into feature/branch3.
➜ Attempting to push feature/branch3 to remote...
✘ Failed to push feature/branch3 to remote.
=========================================
Merge Summary:
=========================================
Branch | Status
=========================================
feature/branch1 | ✘ PushFailed
feature/branch2 | ✘ Conflict
feature/branch3 | ✘ PushFailed
=========================================
➜ Returning to the fix branch...
=========================================
Merge process completed.
大约 9 分钟
最近需要检查多语言文件中是否有重复的 key，于是写了一个 Node.js 脚本来实现这个功能。
这个脚本会在 git 提交代码时，对提交的多语言文件进行校验。通过遍历指定目录下的所有 JSON 文件，检查每个文件中的 key 是否有重复，并将结果输出到控制台。同时，脚本还会将所有 key 存入一个缓存文件中，以便下次运行时可以快速查询。
实现逻辑
理论依据：由于 lint-staged 会将暂存区中被修改的文件路径作为参数传入定义的脚本。这意味着可以在 lint-staged 中配置的命令中直接访问提交的文件列表，而不需要手动指定文件路径。
大约 5 分钟
将下面的虚拟 dom 转换为真实 dom：
const vnode = {
tag: 'div',
attrs: {
id: 'app',
},
children: [
{
tag: 'span',
children: [
{
tag: 'a',
text: 'hello',
children: [],
},
],
},
{
tag: 'span',
children: [
{
tag: 'a',
text: 'world',
children: [],
},
{
tag: 'a',
text: 'javascript',
children: [],
},
],
},
],
}
render(vnode, document.querySelector('#root'))
function render(vnode, container) {}
小于 1 分钟
CommonJS
概念
CommonJS 是一种模块化规范，它允许我们在一个文件中定义模块，然后在另一个文件中引入和使用这些模块。CommonJS 是运行时的这点和 ESModule 不同。
可以简单思考一下，这个文件导出后的结果是什么？
// commonjs 待导出文件
this.a = 1
exports.b = 2
exports = {
c: 3,
}
module.exports = {
d: 4,
}
exports.e = 5
this.f = 6
大约 2 分钟
由于工作需要用到 eCharts，虽然官网样例已经非常丰富了，本文旨在对 eCharts 的使用进行快速入门，方便后续查阅。实际使用中同 AntDesign 和 Element 等框架一样，可依据官网文档进行扩展。不用记住各个 API 的配置规则，只需知道如何使用即可。
基本配置项
除基本数据外，图标最基础的三种配置项为：标题 title、图例 legend、工具提示 tooltip。
大约 4 分钟
集成 Node.js
企业级桌面应用的资源都是本地化的，离线也能使用，所以需要把 html、js、css 这些资源都打包进去，接下来我们就在 src/renderer 目录下创建 index.html 和 index.js 两个文件：
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>Electron Desktop</title>
</head>
<body>
<p id="platform">操作系统：</p>
<p id="release">版本号：</p>
<script src="./index.js"></script>
</body>
</html>
大约 18 分钟
...