Closed bergus closed 8 years ago
This is to preserve the invariant that token.promise
is not a promise for a promise.
I see. In my approach I just used a token.subscribe(…)
method instead of token.promise.then(…)
where the callback is called directly with the cancellation reason - no promise resolution involved at all.
Of course that means that you'd have to do getEvent().then(cancel)
instead of cancel(getEvent())
, but I figured the latter is uncommon enough and doesn't provide any advantages.
The
cancel
function passed to the executor of aCancelToken
is the [[resolve]] function of its.promise
. This does let us do weird things likeAre there any use cases for this? They don't make much sense to me. The first one would probably only lead to a huge lot of unhandled rejections. Are token subscribers expected to deal with this?