Re: [fetch] Aborting a fetch (#27)

> So now Promise.all has to be aware of cancellation and cancellable promises?

if it returns a cancellable which invokes `.cancel()` to all Promises there's nothing we should do since it will simply throws as soon as one of these promises is not cancellable. KISS enough so no need to overload ;-)


> Do we want CancellablePromise.all instead or something like that?

That's another way to go ... I personally don't think it's needed, if developers invoke `cancel` just for fun they'll have errors as soon as they encounter a non cancellable promise. I honestly think cancellability is a less common case and when exposed is well known to developers. Do we want a specific contructor so that we cannot again use `instanceof` but we need to write more? I think having a third optionally used parameter to current `Promise` is good enough solution.


> That makes sense - a second time noop'ing has advantages - so does throwing an exception. I agree that noop is more similar to existing resolve/reject semantics.

I don't have strong opinion here, I've played consistently with current `resolve` and `reject` behavior.


> is do you think that more constructs need to be introduced as static promise methods to the library or not in the light of cancellation?

I don't think this is a concern right now but I have a counter question: shouldn't `.cancel()` avoid the notification on console? Maybe I can set a `.catch(Object)` when `.cancel()` is invoked so if there was one, it won't show the error, if there wasn't, it will just be there as proxy for the Error

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/27#issuecomment-88092349