I use Promise.any A LOT. I'm using it again on a project right now. I was overjoyed to see it proposed to become part of the spec. Frankly, it is what Promice.race should have been in the first place. So, let me ask you a question back - while you might not need Promise.any for you code, have you every used Promise.race?
I would also disagree with your assertion that it is different in nature from other in-build Promise calls. It is actually the dual of Promise.all. Promise.any will return with the FIRST SUCCESS or ALL FAILURES. Promise.all will return the FIRST FAILURE or ALL SUCCESSES (which points to a quick and dirty way of implementing it, although I wouldn't really recommend it).
It is true that the aggregate error feels a bit clunky to say the least, however I can't see an alternative and I'm certainly willing to put up with it.
My typical use case is that I have a number of possible locations of a given resource. There may be multiple servers for the same thing (e.g. primary and backup, or different geographical locations). Some of these might fail, but you don't care so long as you can find one which succeeds. In this case Promise.any is the right pattern as it only rejects if ALL of the endpoints reject.
A second use case is that I have multiple routes to the same server. One might be a route via the internet and one might be locally over a LAN - both or neither of these routes might be available. Again Promise.any is the right pattern.
If what you do is work with cloud services then it is possible you will never need this - you don't have availability or routing complications. However I work with distributed services and IoT devices (we develop the hardware and the software) sometimes operating in networks with poor or otherwise limited connectivity. In this case Promise.any is an essential tool in establishing a connection.
I use Promise.any A LOT. I'm using it again on a project right now. I was overjoyed to see it proposed to become part of the spec. Frankly, it is what Promice.race should have been in the first place. So, let me ask you a question back - while you might not need Promise.any for you code, have you every used Promise.race?
I would also disagree with your assertion that it is different in nature from other in-build Promise calls. It is actually the dual of Promise.all. Promise.any will return with the FIRST SUCCESS or ALL FAILURES. Promise.all will return the FIRST FAILURE or ALL SUCCESSES (which points to a quick and dirty way of implementing it, although I wouldn't really recommend it).
It is true that the aggregate error feels a bit clunky to say the least, however I can't see an alternative and I'm certainly willing to put up with it.
I use
Promise.racefor implementing timeout. See, for example, here to see howPromise.racecan be used to implement timeout.Currently I am looking for good real world examples of the use case of
Promise.anyand I would appreciate if you could share your use case.My typical use case is that I have a number of possible locations of a given resource. There may be multiple servers for the same thing (e.g. primary and backup, or different geographical locations). Some of these might fail, but you don't care so long as you can find one which succeeds. In this case Promise.any is the right pattern as it only rejects if ALL of the endpoints reject.
A second use case is that I have multiple routes to the same server. One might be a route via the internet and one might be locally over a LAN - both or neither of these routes might be available. Again Promise.any is the right pattern.
If what you do is work with cloud services then it is possible you will never need this - you don't have availability or routing complications. However I work with distributed services and IoT devices (we develop the hardware and the software) sometimes operating in networks with poor or otherwise limited connectivity. In this case Promise.any is an essential tool in establishing a connection.
Thanks for sharing! That makes sense.
we will use
Promise.anyhere github.com/nsfw-filter/nsfw-filter...