Re: [whatwg/fetch] Aborting a fetch: The Next Generation (#447)

> stuffs about tokens and Observables

@jakearchibald FYI: as the _author_ of an observable library, I liked tokens. They cleaned up my code considerably. However, they are slightly less ergonomic for the users of the library _especially_ once they've been withdrawn from consideration at the TC39. If tokens were used with promises, fetch and async/await, they'd have been ubiquitous. That would mean that using them with observables would never be a big deal because users would usually have easy access to a token. 

However, since they're not coming for promises in JavaScript, the observable proposal is going to stay with it's tried and true form involving subscriptions.

### Interests in this issue from a consuming library

1. I'd like it if it were easy for me to detect/use cancellation on the result of a fetch.
2. It would be nice if fetch's returned promise cancellation semantic was congruent with other prior art like Bluebird.
3. I want interop with fetch to be as smooth as possible.

So in the case of RxJS, we have interop with promises all over the place. Pretty much any anything that accepts an observable will also accept a promise. I'd very much like it if I could detect any "special" promises that allowed some form of cancellation (like Bluebird and fetch). It would be ideal if I could find them both with one check.

The idea is that you'd be able to use fetch with RxJS directly like so:

```js
Rx.Observable.interval(1000).switchMap(() => fetch('some/data.json'))
   .subscribe(x => console.log(x))
```

This would enable RxJS (and possibly other libraries like Angular) to stop supporting XHR-wrapping Observable implementations as rely on fetch, at least in the long run as support improves. That would be a huge win in my opinion.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/447#issuecomment-273633060