Closed annevk closed 8 years ago
I'd love to see an example of what the eventual API looks like for cancelling network activity.
https://github.com/domenic/cancelable-promise/blob/master/Cancel%20Tokens.md#example, which is probably what you're referring to, should cover it all.
but it's not immediately clear to me how that propagates to a stream you might end up using if the HTTP headers came in before cancellation.
Although we have a choice in how we design things, I think the most intuitive design for users would be that there's no propagation. If you want to cancel either of the two operations (fetching the response or reading the stream), you pass the same cancel token to both operations, as is shown in that example (both fetch
and json
take the same cancelToken).
It's true that we could automatically assign any cancel token passed to fetch to the stream as well, but I think this would go against typical expectations of how you use cancel tokens, which is that platform APIs accept them, and developers choose which platform APIs they cancel.
(Also how can you get away with only passing a name to the object/dictionary?)
ES6
That example does not really cover using the streams API. But okay, the idea is that there would be no formalized equivalent to XMLHttpRequest
's abort()
...
@domenic I agree that it's cleaner design to not tie cancellation of the stream and cancellation of the request as they are two distinct actions - the request giving you the headers and the stream giving you the body. However, as a user my intuitive expectation would be for the stream to abort if I cancel the request.
(Fun fact: I checked what it does in C# and in C# there is no obvious way to do it)
We're really okay with not having an abort()
equivalent? Hmm.
@annevk I was chatting about this with @domenic. If we want this, we could suck it up and add request.abort()
. Or even request.error()
if we want to land it before cancelable promises. The latter would act as if the connection were broken.
That is weird though since fetch()
creates its own Request
object.
I'd love to see an example of what the eventual API looks like for cancelling network activity. I saw
fetch(url, { token })
, but it's not immediately clear to me how that propagates to a stream you might end up using if the HTTP headers came in before cancellation. (Also how can you get away with only passing a name to the object/dictionary?)