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

@blesh by the way, that single values but unicast primitive you speak of is what Kris calls a [task](https://github.com/kriskowal/gtor#singular-and-plural) and is what I suggested in [here](https://groups.google.com/d/msg/angular-data-dev/AdULPprCkbI/XozasYXH600J) in the first place.

That said, in bluebird semantics if you opt in to cancellation promise cancellation has _disinterest_ semantics - like refcounted `unsubscribe` in Rx. Cancellation describes you are no longer _interested_ in the value but you can't "abort" it - this is also discussed a little in [this thread](https://esdiscuss.org/topic/promises-as-cancelation-tokens).

In a disinterest model, calling `cancel` on a promise means "I'm not interested in that promise's result" ad not "do whatever it takes to destroy the data for subscribers". Once a promise resolves - calling `.cancel` on it is a no-op, you can still access the `then`'d value. If you cancel a promise while subscribers are waiting for it - the `then` handlers won't run but `finally` blocks and disposers would. So: 

> If it's cancelled after it's resolved, and then you then it out again, do you still get the value?

Yes. 

> What happens if you cancel while processing the resolution? Will the following still log a value? I mean, I'd think it would, but I really don't know.

In this example, you cancel it _after_ resolution (as cancelling it _while processing_ the resolution isn't really possible) which is a no-op, the `console.log` will execute. 

>  Adding cancellation would pollute the type

As always - anything added dilutes everything else. I agree that adding cancellation pollutes the type in a sense but it's a necessity for client-side code. Fetch will need to be cancellable regardless of promise cancellation, either with direct cancellation, with tokens or even with a `cancel` method on the `Request` object. 

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

Received on Thursday, 28 January 2016 07:47:07 UTC