Cancel Promise pattern (no cancellable promises)

Jan-Ivar Bruaroey jib at
Tue Nov 1 11:53:00 UTC 2016

On 10/31/16 2:39 PM, Herby Vojčík wrote:
> 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))

Because it doesn't make fetch stop fetching, which is what people want 
as I understand it (to not have the fetch keep going even though they've 
stopped waiting for it).

.: Jan-Ivar :.

More information about the es-discuss mailing list