The Dangers Of Promise.all()

Keywords JAVASCRIPT JS TS TYPESCRIPT ASYNC SYNC ASYNCHRONOUS SYNCHRONOUS PROMISES

[Cableguyyy]

This video left me fulfilled. Thanks Theo

[tuomaskoivistoinen]

Promise.all is good for doing multiple queries with no side effects where you need all to succeed before the next step. You could do all settled and add retry logic but I’d rather have it in the work function or have the whole thing retried instead

[robgioeli]

I’m glad you got this all settled, thanks Theo 😉

[Alec.Vision]

4:09 Bruh, that's what Exclude<typeof promises, {status: rejected}> is for. The best thing about Exclude is that it will exclude anything that EXTENDS the second type param... so you can exclude a whole object type from a discriminated union by specifying only the discriminating property. You don't have to know the types, just the difference.

[samuelgunter]

if you use all instead of allSettled, this video would be over at 0:10 because that's when the first Exception is thrown

[EvanBoldt]

Seems like another example of how returning errors results in better error handling than throwing errors.

[Xe]

I love this type of content where you share new discoveries about a language. Please make more videos like this.

[alanscodelog]

I usually use .all and catch in the entry promises and handle any errors and cleanup there and return or push the errors to an array (I find this nicer and more flexible than allSettled). The final .all then only serves to send off /format the errors if needed, or to take the final decision on what to do, not handle the errors themselves.

[schlopping]

honestly this is the best argument I've seen for a Result<Some<T>, None> type, and it wasn't even intended.

[Bluesourboy]

I have this issue in some production apps that were not written by me that this will fix. Theo you are a godsend!

[theoneandonlymeshe]

“I hate JavaScript” ~ Theo, Aug 2023 1:34

[gosnooky]

To be fair the "^" operator being XOR and not exponent is common to most languages? As for the topic at hand, I'm guilty. I use Promise.all all the time.

[MKorostoff]

Great video, but for the most part, I want Promise.all to reject if a single underlying promise rejects. For instance, I was recently writing some code that split PDFs into chunks for search indexing. If one single page cannot be chunked, I don't want to store incomplete data, I want to show a message like "example.pdf failed on page X." Promise.all is essentially like a database transaction in that way, and very convenient for that purpose (though I agree, allSettled has many great use cases).

Basically if your requirement is to process a bunch of steps sequentially, which means one after the other, please forget Promise.all because it process everything CONCURRENTLY.

[williamdrum]

"Don't make promises you can't keep" seems to be the moral here

[guilhermegoncalves]

Promise.all is good when youre using puppeteer. Great video!

[elevyg]

It is easier to check if the item of the result has value as key, then you know that the status is fulfilled

[xaviersavinon]

Thanks, I didn't know that allSettled existed.
Before this video, I only used Promise.All like this:
The function WORK would be an async func with a try/catch so, if the promise got resolved would returned the value if not returned a null. After that filter the array of nulls.

[dtinth]

4:54 - When seeing `.filter` followed by `.map`, using `.flatMap` will usually result in a cleaner code: `results.flatMap(r => r.status === 'fulfilled' ? [r.value] : [])`

When you use flatMap, filtering and mapping is done in a single step, so there is no loss of type information between these 2 steps.

[AlexSpieslechner]

summoning ts wizard matt to make a video on this type