[pull] master from tsejx:master

.github/workflows/deploy.yml

@@ -9,16 +9,14 @@ jobs:
   build-and-deploy:
     runs-on: ubuntu-latest
     steps:
-      - name: Ready to build  and deploy 🤓
-        uses: fifsky/dingtalk-action@master
-        with:
-          url: ${{ secrets.DINGTALK_WEBHOOK }}
-          type: text
-          content: Github：JavaScript-Guidebook 构建开始
       - name: Checkout 🛎️
         uses: actions/checkout@v2 # If you're using actions/checkout@v2 you must set persist-credentials to false in most cases for the deployment to work correctly.
         with:
           persist-credentials: false
+      - name: Set Node Version
+        uses: actions/setup-node@v3
+        with:
+          node-version: '14.21.2'
       - name: Install and Build 🔧 # This example project is built using npm and outputs the result to the 'build' folder. Replace with the commands required to build your project, or remove this step entirely if your site is pre-built.
         run: |
           yarn install
@@ -30,9 +28,3 @@ jobs:
           BRANCH: gh-pages # The branch the action should deploy to.
           FOLDER: dist # The folder the action should deploy.
           CLEAN: true
-      - name: Complete ✅
-        uses: fifsky/dingtalk-action@master
-        with:
-          url: ${{ secrets.DINGTALK_WEBHOOK }}
-          type: text
-          content: Github：JavaScript-Guidebook 构建完成

.gitignore

@@ -7,4 +7,6 @@ yarn.lock
 .umi/*
 .temp/*
 todo/
-dist/
+dist/
+.umi-production/*
+.vscode/

docs/basic-concept/expressions/operators/detructing-assignment.md

@@ -567,7 +567,7 @@ let { foo, bar } = example();
 
 ```js
 // 参数是一组有次序的值
-function f({x, y, z}) { ... }
+function f([x, y, z]) { ... }
 f([1, 2, 3]);
 
 // 参数是一组无次序的值
@@ -625,7 +625,7 @@ map.set('first', 'hello');
 map.set('second', 'world!');
 
 for (let [key, value] of map) {
-  console.log(ket + ' is ' + value);
+  console.log(key + ' is ' + value);
 }
 // first is hello
 // second is world

docs/browser-object-model/binary-data-and-files/url.md

@@ -56,10 +56,3 @@ URL 接口实现的在 URLUtils 中定义的方法。
 | :-------------------- | :----------------------------------------------------------- |
 | URL.createObjectURL() | 返回一个 DOMString，包含一个唯一的 Blob URL（该 URL 协议）。 |
 | URL.revokeObjectURL() | 销毁之前使用 `URL.createObjectURL()` 创建的 URL 实例。       |
-
-```js
-const blobUrl = 'blob://'
-
-const URL
-
-```

docs/browser-object-model/observer/mutation-observer.md

@@ -13,11 +13,11 @@ order: 2
 
 MutationObservr API 用于监视 DOM 的任何变动，比如节点的增减、属性的变动、文本内容的变动，这个 API 都可以得到通知。
 
-DOM 发生变动都会触发 Mutation Observer 事件。但是，它跟事件还是有不同点：事件是同步触发的，DOM 变化立即触发相应的事件；Mutation Observer 是一部触发，DOM 变化不会马上触发，而是等当前所有 DOM 操作都结束后才触发。
+DOM 发生变动都会触发 Mutation Observer 事件。但是，它跟事件还是有不同点：事件是同步触发的，DOM 变化立即触发相应的事件；Mutation Observer 是异步触发，DOM 变化不会马上触发，而是等当前所有 DOM 操作都结束后才触发。
 
 总的来说，特点如下：
 
-- 它等待所有脚本任务完成后，才会运行（即一步触发方式）
+- 它等待所有脚本任务完成后，才会运行（即异步触发方式）
 - 它把 DOM 变动记录封装成一个数组进行处理，而不是一条条个别处理 DOM 变动
 - 它既可以观察 DOM 的所有类型变动，也可以指定只观察某类变动
 

docs/computer-networks/http/https.md

@@ -67,7 +67,7 @@ export default () => <img alt="否认" src={img} width={720} />;
 - **混合加密**：公钥加密密钥，密钥加密数据，私钥解密密钥，密钥解密数据（非对称传送密钥，密钥传送数据）。解决非对称加密效率问题
 - **中间人攻击**：秘密替换公钥窃取数据，源于服务端无法确认客户端公钥是否合法
 - **消息鉴别码**：`MAC` 密钥和密文组成的字符串的哈希值。能够解决 `伪造` 问题，但无法解决 `否认` 问题
-- **数字签名**：服务端创建数字签名，而客户端只验证签名是否争取。解决 `否认` 问题
+- **数字签名**：服务端创建数字签名，而客户端只验证签名是否正确。解决 `否认` 问题
 - **数字证书**：由权威机构背书创建证书，保证公钥不被篡改。解决 `中间人攻击` 问题
 
 ### 对称加密

docs/core-modules/executable-code-and-execution-contexts/compilation/blocks-as-scopes.md

@@ -86,7 +86,7 @@ function foo() {
   console.log(number);
 }
 
-function bar(） {
+function bar() {
   if(true) {
     let number = 5;
     console.log(number);

docs/core-modules/executable-code-and-execution-contexts/concurrency-model/event-loop.md

@@ -56,7 +56,7 @@ setTimeout(() => {
   console.log(2);
 }, 0);
 
-let promise = new Promise((res) => {
+let promise = new Promise((resolve) => {
   console.log(3);
   resolve();
 })

docs/design-patterns/behavioral/chain-of-responsibility.md

@@ -6,39 +6,94 @@ group:
   title: 行为型
   order: 4
 title: 职责链模式
-order: 5
+order: 1
 ---
 
 # 职责链模式
 
-**职责链模式（Chain of Responsibility）**：解决请求的发送者和请求的接受者之间的耦合，通过职责链上的多个对象对分解请求流程，实现请求在多个对象之间的传递，直到有对象处理它为止。
-
-## 概述
-
-- **解决问题**：职责链上的处理者负责处理请求，客户只需要将请求发送到职责链上即可，无须关心请求的处理细节和请求的传递，所以职责链将请求的发送者和请求的处理者解耦了。
-- **何时使用**：在处理消息的时候以过滤很多道
-- **如何解决**：拦截的类都实现统一接口
-- **核心代码**：Handler 里面聚合它自己，在 HandlerRequest 里判断是否合适，如果没达到条件则向下传递，向谁传递之前 set 进去。
-- **应用实例**：
-  - 如果早高峰能顺利挤上公交车的话，那么估计这一天都会过得很开心。因为公交车上人实在太多了，经常上车后却找不到售票员在哪，所以只好把两块钱硬币往前面递。除非你运气够好，站在你前面的第一个人就是售票员，否则，你的硬币通常要在 N 个人手上传递，才能最终到达售票员的手里。
-  - 中学时代的期末考试，如果你平时不太老实，考试时就会被安排在第一个位置。遇到不会答的题目，就把题目编号写在小纸条上往后传递，坐在后面的同学如果也不会答，他就会把这张小纸条继续递给他后面的人。
-- **优点**：
-  - 降低耦合度。它将请求的发送者和接收者解耦。
-  - 简化对象。使得对象不需要知道链的结构。
-  - 增强给对象指派职责的灵活性。通过改变链内的成员活着调动它们的次序，允许动态地新增活着删除责任。
-  - 增加新的请求处理类很方便
-- **缺点**：
-  - 不能保证请求一定被接收
-  - 系统性能将受到一定影响，而且在进行代码调试时不太方便，可能会造成循环调用
-  - 可能不容易观察运行时的特征，有碍于除错
-- **使用场景**：
-  - 有多个对象可以处理同一个请求，具体哪个对象处理该请求由运行时刻自动确定
-  - 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求
-  - 可动态指定一组对象处理请求
-
-## 结构
-
-职责链模式包含如下角色：
-
-- 抽象处理者（Handler）：定义一个处理请求的抽象类。如果需要，可以定义一个方法以设定返回对下家的引用。
-- 具体处理者（ConcreteHandler）：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给下家。由于具体处理者持有对下家的引用，因此，如果需要，具体处理者可以访问下家。
+职责链模式（Chain of Responsibility Pattern）是一种行为型设计模式，它允许你构建一个对象链，每个对象都包含了请求的一部分处理逻辑，并且请求沿着这条链传递，直到有一个对象处理它为止。这种模式使得一个请求发送者无需知道是哪个对象处理了请求，而只需要知道请求会被处理。
+
+在职责链模式中，通常涉及三种主要角色：
+
+1. **请求类（Request）**： 表示需要被处理的请求，包含了请求的信息和状态。在实际应用中，请求类通常包含了与具体业务相关的数据。
+2. **处理者基类（Handler）**： 定义了一个处理请求的接口或抽象类，具体的处理者类继承自这个基类。处理者基类通常包含一个指向下一个处理者的引用，形成了一个链条。
+3. **具体处理者（Concrete Handler）**： 继承自处理者基类，实现了处理请求的具体逻辑。具体处理者决定了它能够处理的请求类型，如果无法处理，则将请求传递给下一个处理者。
+
+在一些实现中，还可能包含以下两个角色：
+
+1. **客户端（Client）**： 创建请求对象并将请求提交给处理者链的起始点。客户端通常不需要知道具体的处理者，只需通过处理者基类与处理者链交互。
+2. **具体客户端（Concrete Client）**： 实现了客户端接口，负责创建具体的请求对象并将其提交给处理者链。这个角色在一些场景中可能会省略，因为客户端的工作通常是由系统的其他部分来完成。
+
+这些角色共同协作，使得请求在处理者链上传递，每个处理者负责判断自己是否能够处理请求，如果能够处理，则处理之；如果不能处理，则将请求传递给下一个处理者。这种方式实现了请求的解耦和责任的分担，提高了系统的灵活性和可维护性。
+
+假设我们有一个报销审批的场景，有不同级别的审批人（经理、副总裁、总裁），每个审批人有不同的审批权限，如果一个审批人无法处理该报销请求，请求将被传递给下一个级别的审批人。
+
+```typescript
+// 请求类
+class ExpenseRequest {
+    constructor(amount) {
+        this.amount = amount;
+        this.approved = false;
+    }
+}
+
+// 处理者基类
+class Approver {
+    constructor(name, approvalLimit, nextApprover = null) {
+        this.name = name;
+        this.approvalLimit = approvalLimit;
+        this.nextApprover = nextApprover;
+    }
+
+    processRequest(request) {
+        if (request.amount <= this.approvalLimit) {
+            request.approved = true;
+            console.log(`${this.name} approved the expense request of $${request.amount}`);
+        } else if (this.nextApprover) {
+            console.log(`${this.name} cannot approve. Escalating to ${this.nextApprover.name}`);
+            this.nextApprover.processRequest(request);
+        } else {
+            console.log(`No one is able to approve the expense request of $${request.amount}`);
+        }
+    }
+}
+
+// 具体处理者
+class Manager extends Approver {
+    constructor() {
+        super("Manager", 1000);
+    }
+}
+
+class VicePresident extends Approver {
+    constructor() {
+        super("Vice President", 5000);
+    }
+}
+
+class President extends Approver {
+    constructor() {
+        super("President", 10000);
+    }
+}
+
+// 客户端代码
+const manager = new Manager();
+const vp = new VicePresident();
+const president = new President();
+
+// 构建职责链
+manager.nextApprover = vp;
+vp.nextApprover = president;
+
+// 创建报销请求
+const expenseRequest = new ExpenseRequest(8000);
+
+// 提交报销请求
+manager.processRequest(expenseRequest);
+
+```
+
+在这个例子中，Approver 是处理者的基类，包含了处理请求的通用逻辑，每个具体的处理者（Manager、VicePresident、President）都继承自 Approver，并在构造函数中设置了自己的审批限额和下一个处理者。
+
+在客户端代码中，我们创建了一个报销请求对象，并创建了处理者对象（经理、副总裁、总裁）。然后，通过设置处理者之间的关系，形成了一个处理者链。当请求提交时，会依次经过链上的处理者，直到有一个处理者能够处理该请求为止。

docs/design-patterns/behavioral/command.md

@@ -6,37 +6,73 @@ group:
   title: 行为型
   order: 4
 title: 命令模式
-order: 6
+order: 2
 ---
 
 # 命令模式
 
-**命令模式（Command Pattern）**：将一个请求封装为一个对象，从而使我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作（Action）模式或事务（Transaction）模式。
-
-### 模式概述
-
-- **解决问题**：在软件系统中，行为请求者与行为实现者通常是一种紧耦合的关系，但某些场合，比如需要对行为进行记录、撤销或重做、事务等处理时，这种无法抵御变化的紧耦合的设计就不太合适。
-- **何时使用**：在某些场合，比如要对行为进行"记录、撤销/重做、事务"等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将"行为请求者"与"行为实现者"解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。
-- **如何解决**：通过调用者调用接受者执行命令，顺序：调用者→接受者→命令。
-- **核心代码**：定义三个角色：1、received 真正的命令执行对象 2、Command 3、`invoker` 使用命令对象的入口
-- **应用实例**：
-  -
-- **优点**：
-  - 降低耦合度
-  - 新的命令可以很容易添加到系统中去
-- **缺点**：
-  - 使用命令模式可能会导致某些系统有过多的具体命令类
-- **使用场景**：
-  - 认为是命令的地方都可以使用命令模式
-    - GUI 中每一个按钮都是一条命令
-    - 模拟 CMD
-
-### 模式结构
-
-职责链模式包含如下角色：
-
-- Command（抽象命令类）：
-- ConcreteCommand（具体命令类）：
-- Invoker（调用者）：
-- Receiver（接收者）：
-- Client（客户类）：
+命令模式（Command Pattern）是一种行为型设计模式，其主要目的是将请求封装成对象，以便对请求的参数化、排队、操作、以及日志记录等进行处理。这使得我们能够在不同的请求发送者和接收者之间解耦，同时也能够轻松地添加新的命令，实现撤销和恢复操作。
+
+在命令模式中，通常涉及以下几种角色：
+
+1. **命令（Command）**： 定义了执行操作的接口。具体的命令类实现了这个接口，并包含了执行该操作所需的具体逻辑。
+2. **具体命令（Concrete Command）**： 实现了命令接口，封装了对接收者的调用。具体命令负责调用接收者的相应操作。
+3. **接收者（Receiver）**： 知道如何执行与请求相关的操作。实际的业务逻辑将在接收者中执行。
+4. **调用者/请求者（Invoker）**： 请求的发送者，负责向命令对象发起请求。调用者不需要知道命令的具体实现，只需要知道如何发起请求。
+5. **客户端（Client）**： 创建具体命令对象并将其与接收者关联，构建命令和调用者之间的关系。
+
+下面是一个简单的 JavaScript 伪代码示例，演示了命令模式的基本结构：
+
+```typescript
+// 命令接口
+class Command {
+  execute() {
+    throw new Error("This method should be overridden by concrete commands");
+  }
+}
+
+// 具体命令
+class ConcreteCommand extends Command {
+  constructor(receiver) {
+    super();
+    this.receiver = receiver;
+  }
+
+  execute() {
+    this.receiver.action();
+  }
+}
+
+// 接收者
+class Receiver {
+  action() {
+    console.log("Receiver: Performing action");
+  }
+}
+
+// 请求者
+class Invoker {
+  constructor(command) {
+    this.command = command;
+  }
+
+  setCommand(command) {
+    this.command = command;
+  }
+
+  executeCommand() {
+    console.log("Invoker: Executing command");
+    this.command.execute();
+  }
+}
+
+// 客户端
+const receiver = new Receiver();
+const concreteCommand = new ConcreteCommand(receiver);
+const invoker = new Invoker(concreteCommand);
+
+// 客户端发起请求
+invoker.executeCommand();
+```
+
+在这个示例中，`Command` 是命令接口，`ConcreteCommand` 是具体的命令类，`Receiver` 是接收者，实际业务逻辑将在这里执行。`Invoker` 是请求者，负责发起命令的执行。客户端创建了一个具体的命令对象，并将其与接收者关联，然后通过请求者发起了命令的执行。这种方式使得命令的发起者和执行者解耦，同时也为实现撤销、恢复等操作提供了方便。

docs/design-patterns/behavioral/interpreter.md

@@ -6,7 +6,7 @@ group:
   title: 行为型
   order: 4
 title: 解释器模式
-order: 12
+order: 3
 ---
 
 # 解释器模式

docs/design-patterns/behavioral/iterator.md

@@ -6,7 +6,7 @@ group:
   title: 行为型
   order: 4
 title: 迭代器模式
-order: 10
+order: 4
 ---
 
 # 迭代器模式

docs/design-patterns/behavioral/mediator.md

@@ -6,7 +6,7 @@ group:
   title: 行为型
   order: 4
 title: 中介者模式
-order: 8
+order: 5
 ---
 
 # 中介者模式

docs/design-patterns/behavioral/memento.md

@@ -6,7 +6,7 @@ group:
   title: 行为型
   order: 4
 title: 备忘录模式
-order: 9
+order: 6
 ---
 
 # 备忘录模式

docs/design-patterns/behavioral/observer.md

@@ -6,7 +6,7 @@ group:
   title: 行为型
   order: 4
 title: 观察者模式
-order: 2
+order: 7
 ---
 
 # 观察者模式

docs/design-patterns/behavioral/state.md

@@ -6,7 +6,7 @@ group:
   title: 行为型
   order: 4
 title: 状态模式
-order: 3
+order: 8
 ---
 
 # 状态模式