【问题标题】:Promise.defer standard?Promise.defer 标准?
【发布时间】:2016-12-26 01:29:56
【问题描述】:

我正在使用 Promises,并且更喜欢这样使用它:

function Deferred() {
    this.resolve = null;
    this.reject = null;
    this.promise = new Promise(function(resolve, reject) {
        this.resolve = resolve;
        this.reject = reject;
    }.bind(this));
    Object.freeze(this);
}

function somethingAsync() {

    var deferred = new Deferred();

    // do stuff then deferred.resolve();

    return deferred.promise;
}

我刚刚在 Firefox Promise.defer() 中遇到了同样的问题,这是标准吗?或者只是特定于 Firefox?我什至在 Firefox 的 Promise 文档中都找不到它 - https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

【问题讨论】:

标签: javascript promise deferred


【解决方案1】:

Promise.defer 曾经是一个建议,但后来决定不在规范中包含它,而是包含使用 the revealing constructor pattern 的 Promise 构造函数。

它在 Firefox 和 Chrome 中实现,后来从 Chrome 中删除。这不是一个标准,而是一个提案。

在设计时明确支持您对 Promise 构造函数的使用作为用例。

委员会决定使用 promise 构造函数的原因是因为它默认防止同步throws:

new Promise((resolve, reject) => {
    thisThrowsSynchronously();
}); 

如果 Promise 构造函数没有这样做 - 您可能不得不在每个 Promise 返回函数调用时使用 .catch} catch(e) {,这可能会令人沮丧。 Promise 构造函数在 .catch 足够的地方建立一个不变量。

我还想指出,除了转换回调 API 之外,我一方面可以计算我使用 Promise 构造函数的次数。通常,您的代码应该具有接近于零的延迟或承诺构造函数的用法。

【讨论】:

  • 感谢 Ben 的精彩回答。但是 jshint 警告动态创建函数(在运行时的函数内)。 jshint 错了吗?而且这样做对性能来说还不错?
  • 我会在 .bind 上使用箭头函数 - 您的代码通常很好,但老实说,我不明白为什么有人会想要非常使用延迟: )
  • 这看起来怎么样 - es6ified!它是如此美丽! function Deferred() { this.promise = new Promise( (...args) => [this.resolve, this.reject] = args); return Object.freeze(this) } :)。就我个人而言,我目前没有理由拒绝我的异步流程。所以任何发生的错误我都需要在开发过程中捕捉到它。但这与“不要为性能动态生成函数”的 jshint 警告相结合,导致我在当前的项目中使用了 deferred。
  • 我认为这是一个很好的代码,可以解决你不应该遇到的问题 :) 如果你看到一个场景,你觉得你 需要 一定要延迟,请随时问关于它在这个网站上。
猜你喜欢
  • 2015-03-09
  • 2023-03-07
  • 2016-04-30
  • 1970-01-01
  • 1970-01-01
  • 2016-11-08
  • 2014-02-27
  • 2013-09-18
  • 1970-01-01
相关资源
最近更新 更多