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

Every proposal that tries to expose cancellation semantics along with promises has an analog in synchronous programming. 

Reject the promise on cancellation? You're just using error handling paths for normal program control flow. Is it an error that a user closes a form while a network request is in flight? Is it an error that a user types another key and auto complete box while a network request is in flight for the previous search? These are not exceptional cases, but common and expected situations.

What if we resolve with a special return code? (undefined? Null? 0?) Now we are back to the days of C before exceptions where every API used a special sentinel return value for error conditions, and your algorithm was lost in endless branch conditions. 

These approaches were abandoned for good reason. Just because we are building asynchronous APIs does not mean every well-established principle of good API design is up for debate.

Let's say we can stomach either of these approaches? What will we have accomplished? Now any module may be able to cancel a promise that any number of other modules may depend on. The ability for anyone party to cancel a fetch will turn every fetch Promise into shared, mutable state. This a foot gun, and we should not be promoting this anti-pattern when better alternatives are available.

I have a concrete proposal: if you need cancellation, don't use fetch. 

Fetch is not the world's first less-than-perfect standard. Well intentioned standard bodies can certainly make mistakes. I know, I'm on one that has made a few despite my the effort to avoid them. If standardized APIs don't meet developer's use-cases, they go unused and are gradually deprecated. It is not ideal, but it is not fatal either.

When standards do not meet their needs, developers use libraries instead. If the libraries are successful enough, standards bodies will move to make these successful libraries part of the web platform. That is how the extensible web is supposed to work. 

I propose that we create a fetch-like API that uses Tasks ("fetchTask"). Ideally the API should be designed so that if developers run up against the limitations of fetch, they can easily modify their code to use fetchTask.

If cancellation is a rare edge case (which it may well be), the library will not pick up a lot of steam. However if developers hit this limitation regularly, the library will gradually become more popular. This will hopefully sway those who make standards by demonstrating to them the demand for this kind of API. That is a great path to standardization, and a better idea than trying to bolt cancellation semantics onto a promise-returning API.

JH

> On Apr 3, 2015, at 1:10 PM, Arthur Stolyar <notifications@github.com> wrote:
> 
> @WebReflection all except creators of spec. because they still think it was good idea to make whole fetch design around promises. Anyway, I should stop here because this comment is candidate for removal.
> 
> —
> Reply to this email directly or view it on GitHub.
> 


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