Promise.defer 的正确模式是什么？

Question

我使用 TypeScript 和async/await来表示异步工作流程。该工作流程的一部分是调用 Web Worker 并在其回调结果时继续。

在 C# 中，我将创建一个TaskCompletionSource，await其Task代码中的其他位置将调用SetResult来解析TaskCompletionSource.

我可以在 JavaScript 中执行相同的操作，方法是使用Promise.defer()、awaiting初始化 Deferrer 对象Promise，并在其他地方，在window.onmessage侦听器中调用resolve(或reject) 方法来让异步工作流程继续。

听起来不错，但 MDN 说defer已经过时了。使用构造函数的建议解决方案Promise需要委托执行工作并调用resolve/reject方法，这对我来说不起作用，因为该逻辑可能超出了我的能力范围，我只想在对象上调用resolve或reject以完全不同的词法进行调用范围，我不能用那个函数做到这一点。

有一个向后和向前兼容的帮助器，它通过绑定resolve和reject函数来为我提供这样的对象，我可以使用这些对象而无需更改代码的语义。但这是一种不好的做法吗？有没有公​​认的更好的模式？JavaScript 中的惯用用法是什么TaskCompletionSource？

Answer 1

只要您确定确实需要延迟，那么进行延迟的帮助程序绝对没有任何问题。在我所有的 Promise 编程中，我只发现一种情况，我实际上需要延迟，并且不能仅仅重组我的代码以使用典型的 Promise 构造函数模式。

当创建承诺/延迟对象的代码与解析或拒绝它的代码之间存在分离时，似乎会发生我发现的情况和其他人指出的情况。通常，您将它们放在一起，但有时它们是完全不同的代码部分，并且这样做是有逻辑原因的。在这些情况下，基于常规 Promise 构建的延迟对象可能是更简洁的实现方法。

这是另一个简单的延迟实现，它也向后和向前兼容：

为什么 Promise 构造函数需要执行器？

但这是一种不好的做法吗？

我知道有些纯粹主义者认为你永远不应该这样做。但是，我想说，如果您确定这是实现代码的最干净、最简单的方法，并且使用典型的 Promise 构造函数执行器回调来实现它并不那么实用，那么这是一个非常好的做法。有些人想要使用 deferred ，甚至没有尝试或学习 Promise 构造函数/执行器，这不是一个好的做法。由于多种原因，应在实际情况下使用 Promise 构造函数。

首选 Promise 构造函数的一大原因是执行器回调函数中所有特定于 Promise 的代码都是“抛出安全”的。如果该代码中抛出异常，它将自动被捕获并拒绝承诺（这是一件好事）。一旦您使用了 deferred 并拥有一堆在该回调之外操作 Promise 的代码，它就不会自动抛出安全。事实上，您的代码甚至可以同步抛出，这对于调用者来说是一场噩梦。您可以在此处查看该问题的描述： https: //stackoverflow.com/a/37657831/816620。因此，延迟模式不是首选，但通过适当的保护，仍然存在某些情况（通常很少见），它会导致更干净的实现。

有没有公​​认的更好的模式？

与上面的答案几乎相同。首选是使用 Promise 构造函数/执行器，但在不切实际的情况下（通常是不同的代码部分创建 Promise，然后解析/拒绝它），并且没有简单的方法来重新组织代码以使其能够很好地工作Promise 构造函数/执行器，那么延迟对象可能是首选实现。您通常应该发现这些情况很少见，因为大多数时候您可以构建代码，因此相同的代码块正在创建和解析/拒绝承诺，并且您不需要延迟。

JavaScript 中 TaskCompletionSource 的惯用等效项是什么？

Javascript 中没有内置的等效项。因此，您必须构建自己的，并且 Promise 似乎是一种自然的方式，因为它们自然地构建为表示完成或错误。您必须向我们展示您的实际代码，以便我们就您的具体情况是否可以在不使用延迟对象的情况下干净地实现提供意见。