Promise.race use case?

[benjamingr]

I'd love to hear what are some use cases to the more obscure functions like Promise.race :)

[spion]

I think the example in the API docs is pretty nice. Its probably mostly useful for building cancelable actions.

[benjamingr]

@spion isn't this just as easy with Promise.any ?

[spion]

@benjamingr I think not - the difference is that any will continue to wait for the successful fulfillment of one of the promises.

Basically:

.all - wait success of all, fail if just one

.some(arr, N) - wait success of N, fail when impossible to fulfill N (because arr.length - N + 1 have failed)

.any(arr) - wait for success of 1, fail when impossible to fulfill 1 (only when everyone fails)

.race(arr) - wait for 1 promise to succeed, fail if just a single one fails.

.settle(arr) - wait for all promises to settle (either with a value or with an error, doesnt matter)

[petkaantonov]

.any is the opposite of .all, and seems more useful.. Race is only implemented because it's in ES6 promises and the only use case I can think of is indeed easier implementation of .timeout but there is already a far better implementation out of the box :D

[benjamingr]

"it's in ES6 promises" is all I needed to hear. Thanks :)

[spion]

@petkaantonov you might also want to cancel on other things :D like for example

fetchData().then(renderThings);

vs

Promise.race(fetchData(), orRouteChangedFail()).then(renderThings);

to prevent further actions to happen if the route has changed in the meantime.

Although I like the switch pattern better for those

[benjamingr]

@spion I realize they're not the same but for that specific example - I think .any works better than a race.

For the second example I'd probably do:

 Promise.all(fetchData(),changeRoute()).then(renderThings); 

Or something like that, listening for a route change failure and generally the on prefix seems very "callbackish" and eventish to me. I want to fetch the data and change the route and then act when they're both done.

[spion]

Sorry, I didn't explain it very well. In a client side framework for example, I want the UI update to fail if the router's route changes -- there is no point in updating it anymore.

orRouteChangedFail() will fail if the route changes, causing the race to also fail.

Also,

Promise.any(someAction(), Promise.delay(1000)).then(value => ...)

will result with value == undefined -- so if the action we're waiting for also has no return results, we will be unable to distinguish the timeout from the successful completion of the action.

[benjamingr]

@spion I'm merely saying I'd approach the first case differently.

Instead of having orRouteChangedFail I'd have a changeRoute (which would presumably be created earlier and started when changing the route started) and I'd pass that to Promise.all creating:

 Promise.all(fetchData(),routeChangePromiseFromBefore).then(renderThings); 

Which would in turn reject the .all if changing the route failed.

As for Promise.any(someAction(), Promise.delay(1000)).then(value => ...) the undefined use case is interesting.

For the record in C# Task.WhenAny returns the Task that resolved first, you can access its return value in .Result .

I'd probably use a Promise.timeout here anyway instead of Promise.delay though so this issue wouldn't exist here anyway.

[spion]

Umm, the goal is not to cancel renderThings if changing the route failed. The goal is to cancel it if it succeeded. "There is a different UI active now and it would be pointless to try and process things further towards rendering"

Let me try to word things better

Promise.race([waitSomeRequest(), stillSameRoute()]).then(renderDataFromRequest);