Hacker News new | ask | show | jobs
by longlho 3683 days ago
Not sure if this is needed. A Promise is basically an async representation of a transaction where "cancel" can mean a slew of things. Even w/ `fetch`, what's supposed to happen when you cancel? (connection abort? resource modification reverse?) Cancel should just be a `rejection`, because the Promise's purpose (update a remote resource) wasn't fulfilled
1 comments
PhrosTT 3683 days ago
Yes - fetch should abort. https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequ...

Think about an autocomplete search. Every additional letter should abort the prior ajax call and fire a new one. Right now I'm hammering my server because I want to use fetch().

link
dcherman 3683 days ago
The request is already in flight, it's too late - you can't abort those packets from getting to your server, you can only send new ones (which maybe instruct the server to disregard your search or something).

The correct way to accomplish what you want is to either throttle or debounce your searching such that you reduce the amount of requests made in the first place.

link
_jezell_ 3683 days ago
Doesn't matter that you can't cancel in flight packets:

1) because clients throttle connections. Suppose a user wants to navigate, you may need to be able to cancel in flight requests or the next page load might be significantly delayed.

2) file uploads can have potentially gigs of packets that haven't been sent yet, which you definitely need to be able to cancel.

link
longlho 3682 days ago
canceling GET is the simplest use case, XMLHttpRequest/fetch is already able to abort. POST/PUT/DELETE, however, modifies remote resources which cannot be easily "canceled" (it might corrupt server state and/or transaction might even have to extend to client being able to fully "resolve" the Promise?)
link
lomnakkus 3682 days ago
> POST/PUT/DELETE, however, modifies remote resources which cannot be easily "canceled" (it might corrupt server state and/or transaction might even have to extend to client being able to fully "resolve" the Promise?)

If those can corrupt state then you're already at the complete mercy of the network... which is never a good idea regardless of whether this proposal is accepted or not.

link
longlho 3682 days ago
yup, so why bloat up the spec? Introducing a 3rd option that represents a non-deterministic remote state isn't entirely helpful IMO. Having the ability to abort the connection should be enough (which is a rejection).
link