The presentation about the proposal linked in a comment above [0] and the proposal itself [1] explain the difference to an exception quite well

[0] https://docs.google.com/presentation/d/1V4vmC54gJkwAss1nfEt9...

[1] https://github.com/tc39/proposal-cancelable-promises/blob/0e...

The use case I heard was if for example the user clicks to load a view, which launches a background request, but then changes their mind and clicks to load a different view, which launches a different background request.

The user no longer cares about the original request. You could just discard the data when it arrives, but what if it's an expensive request for the client, or server, or both? You'd want a way to opt out of all that extra load on the system.

I have been waiting for cancellable promises for a while primarily for cancelling long lasting fetch requests which is a very common thing to need.

(Not really sure how to parse non determinism and throwing being related to cancelling promises)

What's a good existing way to deal with this use-case? Is there a useful library that wraps setTimeout / other logic to determine the quality of a user's internet connection in case of very poor connectivity (2G etc) ?

The way to handle this case is to use Promise.race with 2 promises. The first promise is your logic. The second promise is rejected after a timeout. For more detail read the section "never calling the callback" from "you don't know js" book on "async" in chapter 3 https://github.com/getify/You-Dont-Know-JS/blob/master/async...

But that doesn't actually cancel the request, and thusly the data is downloaded anyway? Or am I missing something?

Thanks I'll check it out

In react native, NetInfo has an api to detect network changes and I use that to stop all my setIntervals and start again with a different set of args, including wait time before calling again.

This was deterministic (cooperative).

And yes, you can absolutely handle it by throwing an exception. But cancellation is such a common mechanism that you'd want to have 1) a standard exception type that can be used to indicate it, and that other async operations can handle in a composable fashion, and 2) a standard mechanism to request cancellation cooperatively, again, so that various layers can collaborate on handling a high-level cancellation request all the way to the lowest level like an I/O read.

And that's what this proposal was all about.

A common case is for typeahead completion. You have a requst to the sever in flight to get typeaheads but the user has entered more characters and triggered another request. Now you would like to ignore the old one. Since async calls are not guaranteed to arrive in the same order they were sent, it would be nice to cancel the old one instead of maintaining logic to ignore it.