Cancel Promise pattern (no cancellable promises)

Herby Vojčík herby at
Mon Oct 31 18:39:50 UTC 2016

Jan-Ivar Bruaroey wrote:
> On 10/28/16 8:39 AM, Bergi wrote:
>> Jan-Ivar Bruaroey wrote:
>>> If you try the fiddle - - you'll see
>>> cancelling terminates the chain. If you intersperse non-cancellable
>>> operations, there'd be a delay if cancel is detected during those.
>> Yes, that's what I mean. Sure, I could use `Promise.race` to get the
>> cancellation even if the non-cancellable operation resumes, but that's
>> quite ugly:
>> Promise.race([
>> promise()
>> …chain…,
>> cancelToken
>> ]).then(callback);
>> especially when you'll need to nest that pattern.
> To be clear, the non-cancellable operation won't "resume" in the face of
> a CancelledError. Only if the cancel happened to trigger during one of
> the non-cancellable actions would there be a slight delay until that
> non-cancellable operation finished (which I consider a feature) and if a
> cancellable operation follows it, cancellation will happen at that point.
> In someone can't tolerate that, then Promise.race is well-defined to do
> exactly what you show, and works in harmony with this pattern. Why
> reinvent the wheel?
> And you'd Promise.race against the entire chain, so no need to nest this
> pattern typically. This is what I mean with focusing on the minimal
> use-case. Most people just want us to solve fetch already, so that
> expensive network resources can be freed. To get out of the current
> inertia, why not define:
> fetch (url, { cancelPromise: token })

OTOH, why not to just use Promise.race directly and promote the pattern 
of "specify alternate result".
   1. This is more general;
   2. This allows creating decorators and use them like
     shortcutAfter(5000, Promise.reject())(fetch(url))

> now and use this pattern, and leave the more desirable { cancel } name
> for whatever future invention we hope will replace it (or annex it if
> nothing better materializes)?
> .: Jan-Ivar :.


More information about the es-discuss mailing list