3 ms·

Serious question - why is cancelling a promise a reasonable use case? Doesn't cancelling potentially invite non-deterministic state into your program? If not, w

Serious question - why is cancelling a promise a reasonable use case? Doesn't cancelling potentially invite non-deterministic state into your program? If not, what would be the difference from throwing?

detaro 10y ago
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/1V4vmC54gJkwAss1nfEt9ywc-QOVOfleRxD5qtpMpc8U/mobilepresent?slide=id.gc6f9e470d_0_0 https://docs.google.com/presentation/d/1V4vmC54gJkwAss1nfEt9... [1] https://github.com/tc39/proposal-cancelable-promises/blob/0e769fda8e16bff0feffe964fddc43dcd86668ba/Not%20an%20Error.md https://github.com/tc39/proposal-cancelable-promises/blob/0e...
daleharvey 10y ago
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)
- fareesh 10y ago
  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) ?
  - fermuch 10y ago
    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.
  - jdesjean 10y ago
    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%20%26%20performance/ch3.md https://github.com/getify/You-Dont-Know-JS/blob/master/async...
    - fareesh 10y ago
      Thanks I'll check it out
    - soft_dev_person 10y ago
      But that doesn't actually cancel the request, and thusly the data is downloaded anyway? Or am I missing something?
_greim_ 10y ago
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.
msane 10y ago
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.
int_19h 10y ago
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.

detaro 10y ago

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/1V4vmC54gJkwAss1nfEt9ywc-QOVOfleRxD5qtpMpc8U/mobilepresent?slide=id.gc6f9e470d_0_0 https://docs.google.com/presentation/d/1V4vmC54gJkwAss1nfEt9... [1] https://github.com/tc39/proposal-cancelable-promises/blob/0e769fda8e16bff0feffe964fddc43dcd86668ba/Not%20an%20Error.md https://github.com/tc39/proposal-cancelable-promises/blob/0e...

daleharvey 10y ago

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)

fareesh 10y ago
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) ?
- fermuch 10y ago
  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.
- jdesjean 10y ago
  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%20%26%20performance/ch3.md https://github.com/getify/You-Dont-Know-JS/blob/master/async...
  - fareesh 10y ago
    Thanks I'll check it out
  - soft_dev_person 10y ago
    But that doesn't actually cancel the request, and thusly the data is downloaded anyway? Or am I missing something?

_greim_ 10y ago

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.

msane 10y ago

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.

int_19h 10y ago

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.