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

One of the benefits of a signal object over just the Controller and Observer design that I originally pitched is that it lets you pass a value that *only lets requests follow your request's changes* - ie. observers wouldn't be able to hitch a ride on your fetch's progress events, or any of the other details that might be exposed via FetchObserver that wouldn't be needed to follow it.

Another advantage would be that it'd let all this control happen *outside of the JavaScript thread*, rather than having to rendezvous with a callback every time a request needs to be aborted in response to another request being aborted.

In any case, it's definitely polyfillable (or prollyfillable or ponyfillable or whatever the kids are calling it these days) using the other concepts, following a clearer spec to come at some point down the line, *after* the basics of fetch observation and control have been surfaced to define this kind of functionality.

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