Cancelable promises

Andrea Giammarchi andrea.giammarchi at
Thu Feb 26 23:43:09 PST 2015

AFAIK bluebird did:

But I agree once you've made Promises more complex than events ( xhr in
this case ) nobody wins :-/

Although, specially for fetch or anything network related, there **must**
be a way to bloody cancel that!


On Fri, Feb 27, 2015 at 7:31 AM, Kevin Smith <zenparsing at> wrote:

> The discussion on that github issue surrounding promise subclassing makes
> my head spin, especially when it comes to working out how cancelation is
> supposed to flow through a graph of promise dependencies.  We should be
> wary of adding complexity to the core.
> The simple way to view the situation is to say that promises are simply
> transparent containers for asynchronous values. Control capabilities should
> therefore be represented by a separate abstraction. This will help keep
> complexity at the edges.
> Has any library experimented with the cancelation token approach yet?
> On Feb 27, 2015 1:46 AM, "Anne van Kesteren" <annevk at> wrote:
>> As a heads up, there's some debate around the fetch() API how exactly
>> request termination should work and how that affects promises:
>> The WebRTC WG has also been discussing canceling in the context of
>> terminating a request for permission from the user. I think they
>> decided to postpone for now until there's a bit more progress on what
>> cancelable promises means, but I would not expect everyone to wait
>> forever.
>> --
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list