关于前端:Promise拆解计划由规范深入从原理浅出

大家好，欢送来到前端研习圈的今日分享。上期跟大家浅析了为什么要理解 Promises/A+ 标准

明天咱们就来拆解一下 Promises/A+，从标准动手，重塑对 Promise 的了解, 接下来间接进入正题~

什么是 Promise

首先，咱们看一下 标准 中如何定义 Promise

能够看到，标准中对 Promise 的形容是 一个异步操作的最终后果。咱们能够通过 then 办法注册回调来接管它的最终的 value 或者失败的 reason。

这也是为什么在很多无关 Promise 的介绍中把它称为 状态机 的起因。由此可见，标准也并非处处都是艰涩难懂的黑话，定义还是十分简洁明了的。

凋谢的规范

同时 A+ 标准还是很凋谢的一套规范, 在前言中，有这样一段形容

标准并没有束缚 创立 一个 Promise 的形式，也没有限度将一个 Promise 的状态批改为 胜利 或者 失败 的形式，而是抉择聚焦于提供一个可互用的 then 办法。

如何了解这个 可互用 呢，其实也很简略，假如有两个基于 Promises/A+ 实现 A 和 B，针对 A 创立的 promise 的 then 解决逻辑，放在 B 上也同样实用，这也就意味着，这套标准会为 then 减少很多约束条件，以实现 可互用。

实际上也的确如此，A+ 中大部分的条例其实都是在规定 then 办法应该如何实现

约定俗成的术语

在进入 A+ 的为 Promise 制订的需要列表之前，咱们先理解一下其中的 术语

对于 promise 和 thenable 的形容大家可能会有点纳闷，为什么都是一个具备 then 办法的 对象（函数实质上也是对象），却要叫两个名字？其实很好解释，promise 是官网实现的叫法，而 thenable 是非官方实现的统称（社区实现的叫法）

value, reason, exception 标准中说得很明确，这里就不做多余的论述了

状态的解决细则

标准中规定了一个 promise 的状态必须为 pending，fulfilled,rejected 三者之一

处在 pending 时, 能够变为 fulfilled,rejected 两者之一

变为 fulfilled 时，状态不能再扭转，同时必须产出 value，且 value 也不能被扭转

变为 rejected 时，状态不能再扭转，同时必须产出 reason，且 reason 也不能被扭转

说简略一点，promise 的状态只能被扭转一次，要么胜利要么失败, 有点不胜利便成仁的滋味了。

then 办法

对于 then 形容中, 规定了它须要接管两个参数

这里onFulfilled 和 onRejected 也就是咱们日常说的 胜利的回调 和 失败的回调

束缚条例

onFulfilled 和 onRejected 不是函数的场景将间接被疏忽

当 onFulfilled 是一个函数，它必须在 promise 变为 fulfilled 后调用，同时把 value 作为参数，且只能调用一次

当 onRejected 是一个函数，它必须在 promise 变为 rejected 后调用，同时把 reason 作为参数，且只能调用一次

onFulfilled 和 onRejected 必须在平台代码的执行上下文完结之后调用。

这句话怎么了解呢，假如在 executor 中同步执行了 resolve 或 reject，胜利 / 失败的回调也必须等同步逻辑全副执行完后，能力执行。这也就是为什么 onFulfilled 和 onRejected 会被搁置在 micro task 中执行，而不是立刻执行的起因

const p = new Promise((resolve, reject) => {resolve(3)
  console.log(1)
})
console.log(2)
p.then((value) => {console.log(value)
})
// 输入 1 2 3

onFulfilled 和 onRejected 必须作为一般函数调用，也就是说不思考外部 this 的指向

当 then 在同一个 promise 上被调用屡次，所注册的回调须要在 promise 变为 fulfilled 或 rejected 后，依照注册的程序执行

then 办法的返回值，必须是一个新的 promise（promise2），这也就是 promise 可能被 链式调用 的起因

onFulfilled 和 onRejected 的返回值 x，须要交给一个名为 Promise Resolution Procedure 的流程去解决，次要是思考 x 还是一个 promise 的场景，因而须要设计一个 递归 流程来解决，这个流程的条例在下文会讲

onFulfilled 和 onRejected 如果执行报错，抛出异样 e，那么 新返回的promise2 的状态将变为 rejected

当 promise1 状态变为 fulfilled 且 onFulfilled 不是一个函数时，promise2 将以雷同的 value 变为 fulfilled

当 promise1 状态变为 rejected 且 onRejected 不是一个函数时，promise2 将以雷同的 reason 变为 rejected

Promise Resolution Procedure

最初就是上文中提及的 Promise Resolution Procedure 流程，这是一个形象进去的概念并非某个具体实现。它会接管一个两个参数，一个 promise 和一个 x

这里标准中提到，当 x 是一个 thenable 时, 会尝试让 promise 应用 x 最终的状态

看个例子吧

联合例子就不难发现，这样做的意义是保障 then 办法返回的 p2 的状态是由 p1 的 onFulfilled 或 onRejected 的返回值的状态决定的。

接下来咱们来看整体流程的条例

当promise 和 x 的援用是同一个对象，则将 promise 置为 rejected 并抛出 TypeError 作为失败的 reason

也就是如下场景

当 x 是一个 promise，则会依据其状态做不同的解决

如果 x 处于 pending，那么 promise 须要等 x 胜利或失败后再同步其状态；如果 x 曾经胜利或失败，那么 promise 则间接同步其状态

当 x 是一个一般对象或者函数时，这部分场景是 A+ 中最简单的局部，思考到单纯用文字描述可能会很形象，这部分将搁置在下期的 源码实现篇 中着重拆解

有能力的同学能够尝试间接原文

当 x 既不是一个一般对象也不是函数时，promise 和 x 都将间接被置位 fulfilled

以上就是 Promises/A+ 标准中全副条例了

结尾

-> Promises/A+ 原文

通过对标准的拆解后，置信大家对 promise 的意识又有了不小的晋升。不过还保留了一个大坑等着下期来补 （条例 2.3.3）。下期咱们将从 标准 -> 实现 来切实的感触 promise 的工作流程

最初心愿大家每天提高一点点，咱们下期见~