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

I have read through most of this discussion, and while I don't typically like to be involved in these things, I feel compelled to ask why there is so much discussion around "cancelable promises" and nobody has brought up simply adding an `abort()` method to `Request` objects. I've seen a lot of people say the words "cancel the request", but I haven't seen that said the form of an API.

As @getify has been arguing all along, and as @benjamingr quoted @kriskowal ("If any dependee cancels a promise, it would be able to interfere with future dependees"), a promise represents a end result (or an error that occurred in trying to get that result). You should be able to freely pass that promise of a result around without fear of one consumer ruining the party for everyone else (i.e. tight coupling, which we all despise). The promise should absolutely remain **externally immutable**.

It seems fitting that only the creator of the request should have the power to cancel it. That's the beauty of giving the `Request` object the power of `abort()` (or `cancel()` if you prefer). Obviously, calling `fetch('/some/url')` would not have it, but in the simplest cases you don't typically need to abort a request anyways.

The more interesting discussion would be what happens when a request is aborted? If the promise hasn't resolved a response, should it be rejected with a special error type or should it be resolved to special response type (just like the "error" response, that has its status set to 0 and its body set to null)? I would vote for the former (reject) so it could be consistent with the response's "body" promises (`text()`, `json()`, etc.) being rejected with the same error type, but my opinion are not nearly as strong there.

I really hope you guys see the light and don't create a `CancelablePromise` type to solve this problem! :sweat_smile:

 

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