Promise-returning delay function

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Oct 28 07:41:17 PDT 2014


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



On Tue, Oct 28, 2014 at 2:13 PM, C. Scott Ananian <ecmascript at cscott.net>
wrote:

> So throw a different class of Error, or resolve with a different type of
> object.  Can you substantiate your assertion better?
>
> In my experience, regularity of control flow constructs is a feature, not
> a bug. I don't want to have to reason about some "third way" control flow.
>   --scott
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20141028/19b80c30/attachment.html>


More information about the es-discuss mailing list