Not sure, but does this mean that I can't cancel a heavy file upload if a user changes his mind?
So I cancel my GET request, all is fine with the world. I cancel my POST, and now I have no idea at which layer it was cancelled, if at all. Certainly the cancel doesn't propagate to the server.
I've used cancellation in C# and agree that it's super useful, but it's not a panacea and has to be handled thoughtfully. JS can manage without it IMHO
Canceling them is now a big deal if it's needed.
Personally, I think they could be handled by the WebStreams API, so when you want to "cancel" a download or upload, you just throw in the function which is consuming or creating the actual data which will reject the promise entirely.
However only ReadableStreams are available in some browsers right now, and WritableStreams are still a bit away AFAIK, so it's not possible to do that right now with promises, but i don't think that warrants adding even more features to a language which will most likely never be removed.
Due to the very nature of asynchronous operations, it is, in general, impossible to even determine which layer will ultimately handle that request (e.g. in your example, whether the POST won't happen, or it'll be aborted, or it's already completed), much less how it'll be handled.
The assumption is that all layers will do their best effort (defined vaguely in a "common sense" way) to service that request.
That is a very useful abstraction to have, and I don't see why JS is special in that regard.
Those applications that already aren't robust to this (I sadly assume that is most) aren't going to be helped by cancellation
I currently utilize cancellation tokens myself in nodejs(TypeScript) when creating libraries or wrapping the stdlib event/stream based stuff.
I know this is probably a typo (patients => patience) but that spelling seems to work as well.
> So cancelable promises reignite all the old debates plus there's no obvious right way to do it, like should it be a 3rd state which could cause compatibility issues and would add complexity, or should cancellations just be a sort of forced rejection, which would be a lot more backwards compatibility but with less features.
IMHO neither as cancelability isn't a common requirement. People that need it tend to have more complex requirements and end up tying the cancellation to other chains of logic anyway. Also, unlike say catching an error, you generally want all cancellation handlers to fire rather than just the first one (like with errors).