从另一个承诺返回承诺的理由？ [复制]

Question

在以下代码中，从success 或err 方法返回另一个承诺的原因是什么？如您所见，someFunction 已经返回了一个承诺，我们可以轻松地将其返回给调用者。

我不明白在我们不装饰/操纵响应或错误时做出另一个承诺的原因。有没有我不知道的用例？

function() {
    var p = $q.defer();

    someModule.someFunction(input)
    .then(
      function(success) {
        return p.resolve(success);
      },

      function(err) {
        return p.reject(err)
      }
    );

  return p.promise;
};

Answer 1

这整件事可以替换为：

function someFunc() {
    return someModule.someFunction(input);
}

创建自己的 Promise 被认为是一种反模式，然后当您可以使用已经存在的 Promise 时解决并拒绝它。

无所事事的成功和错误处理程序基本上只执行默认行为已经是的，这被认为是一种反模式。

真的，你的代码 sn-p 与直接返回承诺不同的唯一一件事是，它确保返回的承诺是 Q 承诺，而不是任何类型的承诺 .someFunction() 返回。但是，如果这是一个要求，那么它可以更直接地转换为 Q 承诺，而无需所有额外的代码。

这里有一个要避免的discussion of promise anti-patterns，因为有更好的方法。

Answer 2

您没有理由在您的情况下使用延迟承诺。事实上，使用 defer 是使用 Promise 时最常见的反模式之一，并且只应在非常特殊的情况下使用。

在延迟反模式中，“延迟”对象是无缘无故创建的，使代码复杂化。

这种多余的包装也是危险的，任何类型的错误和 拒绝被吞下，不会传播给 this 的调用者 功能。

代码不应该使用 Deferred 反模式，而是应该简单地 返回它已经拥有的承诺并使用 return 传播值

快速阅读讨论此主题的 bluebird（最好的 Promise 库之一）文档https://github.com/petkaantonov/bluebird/wiki/Promise-anti-patterns#the-deferred-anti-pattern