别犹豫 去行动

前言：在接触 Tailwind 的刚开始，并没有感受到它的好处，反而觉得这是一种非常繁琐的事情，非常不适应。为了更好的使用 Tailwindcss，便有了该系列：梳理总结使用规律和用法。

章节系列共分为 7 个小节，每小节开头介绍使用规律，再介绍具体使用方法，各自小节独立可依照需求进行查阅。

迭代器的协议规范是：一个对象必须实现一个特定的接口，该接口包含一个名为 next 的方法，该方法返回一个对象，该对象包含两个属性：value 和 done。

value 属性表示迭代器返回的当前值，done 属性是一个布尔值，表示迭代器是否已经迭代完所有元素。

{
  value: any,
  done: boolean
}

title: React 之 Fiber 算法 icon: react date: 2024-03-16 category:

• 框架 tag:
• React sticky: false

Fiber 是 React 16 引入的，是 React 内部为了解决 异步可中断渲染 而设计的 核心架构和算法。

简单理解：Fiber 是 React 重新设计的虚拟 DOM 树结构，将一次复杂的更新任务拆成小块，每一块都是一个 Fiber 节点，允许中断和恢复，提高流畅性和优先级控制。

出现原因:

一直以来，对 Promise 的状态吸收问题，我都没有很好理解，今天终于理顺了，因此记录一下。

由于 Promise 规范中对这块没有详细定义，因此这里的 Promise 处理机制均是基于 V8 引擎的。

Promise 回顾

Promise 有三种状态：pending、fulfilled、rejected。当使用 resolve 或 reject 时，Promise 的状态会发生变化，但一旦状态发生变化，就不会再变。

简单入门一下 Mobx~

MobX 是一个用于 JavaScript 应用程序的状态管理库，它通过响应式编程原则简化和扩展了状态管理。它在 React 应用程序中特别受欢迎，但也可以与任何 JavaScript 框架或库一起使用。

Koa 是通过将中间件组织成一个“洋葱模型”（Onion Model），并使用 async/await 或 Promise 链式执行机制实现异步中间件的。

核心机制

1. 中间件存储：

   • 中间件被存储为一个数组（middlewares）。
   • 每个中间件是一个函数，接受 ctx（上下文）和 next（下一个中间件的执行函数）作为参数。

2. 组合中间件（compose）：

   • Koa 使用一个函数（类似于 compose）将多个中间件组合成一个函数，并按顺序执行。
   • 每个中间件调用 await next() 来手动控制下一个中间件的执行时机。

3. 递归调用：

   • 当一个中间件调用 await next() 时，它会等待下一个中间件执行完成后再继续执行当前中间件后面的逻辑。

这里用于梳理 React 的一些技术实现细节，以作技术回顾。

setState 的更新逻辑

这里主要讨论的是 React18 以前的策略。React18 之后，全部采用异步调用。可见setstate-的更新逻辑

React18 以前，setState 的更新逻辑有时是同步的有时是异步的，这取决于调用 setState 的环境。实际上，在 React 控制之内的事件处理过程中，setState 是异步的，而在 React 控制之外的事件处理过程中，setState 是同步的。

在此前系列中，笔者梳理了 Cesium 的基本使用方法，但是为了更进阶了解 Cesium，我们需要了解 Cesium 的核心机制，其中之一就是 Property 属性机制。

先总览一遍 Property 类型分类。

最新需要批量修复 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.

最近需要检查多语言文件中是否有重复的 key，于是写了一个 Node.js 脚本来实现这个功能。

这个脚本会在 git 提交代码时，对提交的多语言文件进行校验。通过遍历指定目录下的所有 JSON 文件，检查每个文件中的 key 是否有重复，并将结果输出到控制台。同时，脚本还会将所有 key 存入一个缓存文件中，以便下次运行时可以快速查询。

实现逻辑

理论依据：由于 lint-staged 会将暂存区中被修改的文件路径作为参数传入定义的脚本。这意味着可以在 lint-staged 中配置的命令中直接访问提交的文件列表，而不需要手动指定文件路径。