- From: Kyle Simpson <notifications@github.com>
- Date: Mon, 30 Mar 2015 07:09:02 -0700
- To: whatwg/fetch <fetch@noreply.github.com>
- Message-ID: <whatwg/fetch/issues/27/87692836@github.com>
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