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

> If this becomes a blocker, the return type could switch on fetch(url, {controllable: true}), which is a little hacky, but IMO less hacky than the callback.

Sharing my thoughts. I think cancellable promises are not the right way. I would keep Promises as _values-in-time abstractions_ and I would not mess with fetch-specific details.

I always thought fetch API is missing an intermediate type to represent the ongoing operation so I'm more inclined to create this _control_ object once and for all.

To be honest, I really like the `new FetchControl()` option proposed by @stuartpb It's optional, enables progressive adding of functionality (like observers as @jakearchibald suggested), leverage separation of concerns and encourage dependency inversion.

In the future, it could offer the possibility of controlling multiple requests (to cancel all the fetches involved in the _start/middle/end_ example) and keeps regular `fetch` mechanisms lightweigh.

Following @wanderview suggestion, I would make `.cancel()` to return a promise which resolves if the fetch is actually cancelled or rejects with a reason (no op) if cancellation is not possible.

For the _big-stop-button_ case. I'm not sure if we should allow the requests to be continued. I'm happy with providing a way to notificate the SW about this action (or page closing) but perhaps we should stop all ongoing fetches since this is user's will.

In this case, maybe `hardstop` and `allclosed` could be functional events.

If I haven't convinced you, I'm more inclined for @stuartpb `event.addEventListener()` example.

Hope it helps.

-- 
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-270642584