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

While this thread is about `fetch(..)` and not explicitly about the `async function` functionality, they are extremely symmetric and I think solutions should make sense for both.

If we don't consider both concerns together (or rather, how/if to pair promise observation with upstream cancelation signaling in general), rather than *only* narrowly thinking about `fetch(..)`' API, I think we'll end up at a solution that only works for `fetch(..)` and is inconsistent/incoherent compared to how these problems are solved elsewhere.

What's being currently discussed would mean that somehow an `async function` would have to be able to declare what its `ifCanceled` cleanup code should be in some way... I'm failing to see how that would make any sense:

```js
async function fetchLike(url) {
   var response = await ajax(url);
   return response.text;
}

fetchLike("http://some.url.1").then(..);
```

Since the ultimately returned promise is implicitly created by the `async function`, I don't see any way that you could specify this `ifCanceled` callback to its creation, without some sort of awkward and composition-killing hijacking of its first parameter (as someone on another thread seems to have suggested, of sorts).

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

Received on Monday, 30 March 2015 14:09:26 UTC