9 ms·
That one is super interesting. For the first example, I'm not even really sure how I'd expect that to behave, it feels like no matter how it works it becomes sl
by roblh 3y ago
That one is super interesting. For the first example, I'm not even really sure how I'd expect that to behave, it feels like no matter how it works it becomes slightly inconsistent with my expectations of the language. Like, if it were changed to somehow let a .catch grab the synchronous errors or have it somehow evaluate all of the compute functions synchronously first before making the promises, it still feels wrong. Maybe the only good solution is run the compute args separately beforehand?
For the second example, it's kind of a weird one, but I'm actually a fan of using async .reduce to accomplish that. It took me a minute the first time I saw someone do it, but I think it more cleanly solves the problem and gives you more control over the result.
- polishdude20 3y agoHow would you use reduce for that?
- roblh 3y agoReduce can use an async function which wraps the collector in a promise and gives you a ton of control over how it executes because you can choose at what point you want the function to block waiting for previous results. In this particular case it's a lot more verbose, obviously, but if you're doing any kind of further processing of each element, you can move it into the reduce and be able to control exactly what you get out of it if something fails for any reason, while still running mostly concurrently like all or allSettled would. const result = await elements.reduce(async (collector, x) => { const arg3 = computeArg3(x) // explicitly handle whatever errors, try catch, whatever you need const asyncResult = await someAsyncFunction3(arg3) // this has to happen after calling someAsyncFunction because it will block until the previous iteration finishes collector = await collector; collector.push(result) return collector }, []);