问题一:在给定的时间只允许一个API请求，所以真正的网络请求在排队，而还有一个还没有完成。应用程序可以随时调用 API 级别并期望得到 promise 。当 API 调用排队时，网络请求的 promise 将在未来的某个时间点创建 - 返回应用程序什么？这就是用延迟的“代理” promise 解决问题的方法:

var queue = [];
function callAPI (params) {
  if (API_available) {
    API_available = false;
    return doRealNetRequest(params).then(function(data){
      API_available = true;
      continueRequests();
      return data;
    });
  } else {
    var deferred = Promise.defer();
    function makeRequest() {
      API_available = false;
      doRealNetRequest(params).then(function(data) {
        deferred.resolve(data);
        API_available = true;
        continueRequests();
      }, deferred.reject);
    }
    queue.push(makeRequest);
    return deferred.promise;
  }
}

function continueRequests() {
  if (queue.length) {
    var makeRequest = queue.shift();
    makeRequest();
  }
}

问题2:对部分API调用进行去抖动，使得待发送的数据会随着时间累积，超时后批量发送。调用 API 的应用期望得到一个 promise 。

var queue = null;
var timeout = 0;
function callAPI2(data) {
  if (!queue) {
    queue = {data: [], deferred: Promise.defer()};
  }
  queue.data.push(data);
  clearTimeout(timeout);
  timeout = setTimeout(processData, 10);
  return queue.deferred.promise;
}

function processData() {
  callAPI(queue.data).then(queue.deferred.resolve, queue.deferred.reject);
  queue = null;
}

由于 deferred 被认为是一种反模式(另见 When would someone need to create a deferred? )，问题是 - 是否有可能在没有 deferred 的情况下实现相同的事情(或类似的黑客攻击，如 new Promise(function (resolve, reject) {outerVar = [resolve, reject]});), 使用标准的 Promise API？

最佳答案

Promises for promises that are yet to be created

...通过将 then 调用与创建 promise 的回调链接起来很容易构建， promise 代表将来创建它的可用性。

如果您正在为一个 promise 做出 promise ，您应该永远使用延迟模式。您应该使用 deferreds 或 Promise 构造函数，当且仅当有您想要等待的异步内容，并且它还没有涉及 promises 时。在所有其他情况下，您应该编写多个 promise 。

当你说

When the API call is queued, the promise for the network request would be created at some point in the future

那么你不应该创建一个延迟，你可以在创建后用 promise 解决(或者更糟，一旦 promise 解决，就用 promises 结果解决它)，而是你应该得到一个 promise将发出网络请求的 future 。基本上你要写

return waitForEndOfQueue().then(makeNetworkRequest);

当然，我们需要分别改变队列。

var queue_ready = Promise.resolve(true);
function callAPI(params) {
  var result = queue_ready.then(function(API_available) {
    return doRealNetRequest(params);
  });
  queue_ready = result.then(function() {
    return true;
  });
  return result;
}

这还有一个额外的好处，就是您需要明确处理队列中的错误。在这里，一旦一个请求失败，每个调用都会返回一个被拒绝的 promise (您可能想要更改它)——在您的原始代码中，queue 只是卡住了(您可能没有注意到)。

第二种情况有点复杂，因为它确实涉及到 setTimeout 调用。这是一个异步原语，我们需要手动为其构建一个 promise ——但仅针对超时，除此之外别无其他。同样，我们将获得超时 promise ，然后简单地将我们的 API 调用链接到它以获得我们想要返回的 promise 。

function TimeoutQueue(timeout) {
  var data = [], timer = 0;
  this.promise = new Promise(resolve => {
    this.renew = () => {
      clearTimeout(timer);
      timer = setTimeout(resolve, timeout);
    };
  }).then(() => {
    this.constructor(timeout); // re-initialise
    return data;
  });
  this.add = (datum) => {
    data.push(datum);
    this.renew();
    return this.promise;
  };
}

var queue = new TimeoutQueue(10);
function callAPI2(data) {
  return queue.add(data).then(callAPI);
}

你可以在这里看到 a) 去抖动逻辑是如何完全从 callAPI2 中分解出来的(这可能不是必需的，但提出了一个很好的观点)和 b) promise 构造函数如何只关注它自己超时，仅此而已。它甚至不需要像 deferred 那样“泄漏”resolve 函数，它唯一对外可用的是允许扩展计时器的 renew 函数.

关于javascript - 未使用延迟[反]模式的情况下尚未创建的 promise 的 promise ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/37426037/