Promise-returning delay function

Dean Landolt dean at
Tue Oct 28 08:21:28 PDT 2014

On Tue, Oct 28, 2014 at 10:41 AM, Andrea Giammarchi <
andrea.giammarchi at> wrote:

> The moment you pass a promise you have no control on who's adding what as
> callback or errorback which means you have no control over a .reject() or
> over a .success()
> .cancel() would eventually keep both queues unresolved so that nothing
> should happen at all: no error handling, no error happened, and no actions
> needed ... it's simply canceled.
> This is the same reason .fetch() API needs also events to work properly
> (including `progress`) ... you "cannot" base as example typeahead on
> promises right now 'cause it's a mess to handle since response order is not
> guaranteed but you need to handle the .cancel() case without telling the
> user something else went wrong ... what you suggest, a `new Noop()` where
> `Noop.prototype = Object.create(Error.prototype)` ?
> And how do you instruct unknown surrounding code that an `if (err
> instanceof Noop)` should be the first line of every errback ?
> This is the reason few devs cannot adopt current standard Promises.
> `.cancel()` as well as `.abort()` is **very** important when many network
> operations are in place and/or you want to switch to a different state
> without waiting for the previous one to be fulfilled.
> `new Promise(function (resolve, reject, cancel) {});` is the dumbest idea
> I could have now beside `new Promise(function (resolve, reject)
> {}).on('cancel', cancelback).then(whatever)` one
> Anyway, this would deserve IMO a thread a part but I hope this topic will
> be discussed at some point.
> Best Regards

I agree w/ Scott re: regularity of flow control, and I'd be particularly
uneasy if a `cancel` method on a promise had any impact on upstream
handlers. But ISTM something like this could be made to work (even if it
looks a bit silly):

var cancelled;
var never = new Promise(function () {});
Promise.delay(100/*ms*/).then(function(value) {
    return cancelled ? never : value;
}, function (error) {
    return cancelled ? never : throw error;
function cancel() { cancel = true };

This could be cleaned up into a cancellation helper to quash downstream
promises (this kind of utility would be a good use case for an `always`
method if one isn't yet spec'd).

Though I do wonder what happens to promises like these that get dropped on
the floor? Will downstream handlers be GC'd? Is this specified in any way?
I imagine dev tools want to warn about these kinds of promises — it may be
helpful to have a way to signal that a promise was intentionally quashed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list