Please just use Promise.allSettled() Keywords JAVASCRIPT JS TS TYPESCRIPT ASYNC SYNC ASYNCHRONOUS SYNCHRONOUS PROMISES ALL MY VIDEOS ARE POSTED EARLY ON PATREON / t3dotgg Everything else (Twitch, Twitter, Discord & my blog): t3.gg/links
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
@@kartashuvit4971 that question is a bit orthogonal to how you handle promises. If a transaction would prevent significant bugs then yes, otherwise you get better performance committing a single statement at a time.
@awmy3109 I think it's that they less worry about bullshit and more and more that the majority use case doesn't require a surgical solution like this. If you have some really slow process that runs many times (let's say some api call that costs for time used), it would make sense to try and cache the successful results and retry the failures, because it could save a lot of time and money in the long-term. For loading 1kb of json from your own api for a component to render "hello [user]", yeah that can be retried wholesale.
4:09 Bruh, that's what Exclude 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.
@@alexandrucaraus233 Nothing about throwing or returning is inherently OOP or functional. Throwing is just the model most commonly used by Java, which happens to be the most widely taught OOP language. In an alternate universe, returning errors or result types could have been the standard way of doing things in Java. OOP != throwing.
@@bryanleebmy yes, java, c#, c++ and all other other OOP languages use more the throwing approach, and all other pure functional prefer returning values. So blue!=green, like I said :D.
If people are interested for the partial success result from the promises, you can wrap the async call with a function which have a catch block inside. Then you may still get the results even some are failed.
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.
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.
I find using a promise pool is a good balance. They usually return results and errors as separate objects, and have other features such as setting concurrency
How might our understanding and application of asynchronous functions change if we were to prioritize clarity and predictability of outcomes over simplicity or convention in our coding practices?
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).
@@xinaesthetic like if you had promises foo and bar, and you want to init them at the same time, then cancel bar if foo fails? Personally, I wouldn't, I'd just let bar finish.
@@MKorostoff fair enough. No point coding it when you don't need it. In a situation where it did matter I suppose I'd probably have some shared reference to a bit of state that flags if the operation should be cancelled, but not sure what particular patterns there are that might be good to know.
Nothing dangerous about promise.all if you know what it does (You might argue with me because I said "if you know what it does" but I say that because the function itself is not dangerous, it's the misuse of the function that is dangerous). Promise.all requires all functions to resolve otherwise nothing is returned (which does resolve in discarded work being done). Promise.allSettled is a good alternative though but if the requirement is that all promises MUST resolve (and you don't have a retry mechanism which could potentially also cause other complexities because endless retries would cause your program to hang) then promise.all is the preffered choice.
Maybe this is an anti-pattern but what if you catch inside the promises? If there's an error return null, otherwise return the result. That way the promises always resolve and we can filter out results after
I actually just used promise.all in a project that to me was appropriate. Essentially I'm running two async functions in parallel that return an array of values. Once I get back both arrays I compare the two arrays and keep the values that are shared between the two. If one promise rejects (which only happens because they found no values to return in their array) I don't need to know what the returned values in the other async function will be because I know there will be no matching values for me to pull. So the fact that it jumps to the catch statement, and I don't get the values for the other promises, all work out.
I use it with something that's not an array. When you request multiple things, but definitely need all of it. An array api in that situation is kinda bad, I even defined a dictionary version of Promise.all, where you give names to each entry.
I use it when building my test environment on the backend. I don't really care if the server or database failed to standup, if either of them fails then its pointless to run the test suite. Same with performing a bunch of bulkCreates with sequelize. If one of the bulkCreates fails then the database is corrupted anyway and I'm going to have to find out whats wrong and fix it regardless so it doesn't matter if the promises still run in the background or send back results.
The bulk case if you work with a bunch of operations of that nature you might use a Sagas pattern and revert/delete the corrupted data and retry it in some cases, but yeah I get what you mean
8 месяцев назад
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.
You could also implement error catching in your asynchronous function (e.g., WORK) and have it return the potentially caught error. Then you can filter the returned array by instanceof Error
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.
promises is sucks because they are not lazy and not cancellable and this might leads to unexpected results, data-race in async useEffect in react for example
It was super hard not to notice and resist commenting, but why is waitFor declared as async? Seems kinda extra to wrap the return value when you're already returning a promise? Obviously, js handles it behind the scenes gracefully, but still, there's no await used inside.
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.
I only used promise.all when theres a dependancy chain, a relies on b relies on c. If A failed we dont want to continue. Otherwise I agree settled for everything else.
@@t3dotgg Right my example wasnt clear, they would rely on eachother or another dependant requires all 3. Not sequentially. not in fact a proper "chain" more like a web
I haven't finished the video yet, but I'm going to guess most of the time taking a less FP approach and using "for...in" within an already async function is the recommendation coming up, rather than managing the nesty confusion of Promise.all
JS error handling in general sucks IMHO, especially with promises. Even with typescript you have no way of knowing if a function could throw and what it would throw, I hate it
@Theo telemetry is a common place for me. I usually push up data in a fire and forget manner and for some metrics (granted, these are not actually all that many) it's better to use all instead of allSettled just because it allows the publishing function to return faster, reducing the time the function has to run. Those promises in the background can fail and it'll just be treated as a missing data point, which for a lot of metric types is actually not critical.
@@NuncNuncNuncNunc it depends on the metric being sent. Something like network tx and rx for example it's okay if publishing fails once every so often. A user may also select a metric to be non essential and that would be treated the same way. Of course, if every publish fails then that's a different matter that we do look out for, though all we do in that case is log to console, as we can't be sure whether the problem is ours or if the user has something in their config or something like a proxy
I agree on the correctness side but disagree on the efficiency side. If you need _all_ request to complete to perform a task, exiting early is more efficient. If you want some retry logic, placing it in the catch handler of each individual promise would allow you to retry immediately instead of having to wait on the slowest to resolve first. Also, isn't that be the use case for AbortController ? You tie every request to a signal and as soon as the controller abort, you interrupt as early as possible because the result is no longer required. That said, I remember node logging a warning for memory leak for trying to have more than 10 listener to a signal...
I have exactly such a case in a current project: It does a few async operations in parallel, all of which must resolve. In case of an error, the shared signal cancels the rest. Works very well since we do not need the individual results in case of an error - and an early result is more valuable than having all error messages should more than one fail. But that's clearly very situation dependent.
@@CottidaeSEA catch(() => {}) is always an option if you don't care what kind of error each promise encounters. If you're looking for stat on which action succeeded and which one failed, then yeah, allSettled might fit better. Also, at the end of the day, allSettled is just a promise.all with a well chosen then applied to each promise (e.g. .then((e) => ({e, ok:true}), (e) => ({e, ok:false})))
Another thing is that the Promise concurrency functions are only useful for IO / network related tasks, since the requests are in flight in parallel. However, if you just have a very expensive task computationally, splitting it up and Promise.alling it wont speed it up at all, since JS is single-threaded and it will only ever work on one task at a time. If, however, you used multiple threads operating on multiple cores, then it would make sense.
You kind always turn computation heavy task into io with webWorker. It just requires a lot more setup (create worker, send relevant data, await response from worker)
This is a bit of an oversimplification, since while it can result in performance issues compared to threads, single-thread concurrency with delaying Promises until next tick can still improve performance in many situations.
@@NickServ do you mean performance (how fast your code run end to end) or reactivity (how long your code take to react to an event)? If reactivity, I agree. If performance, if you have say 1000 lines of code to run to complete a function, splitting it into 10 group of 100 lines won't make things end faster.
There’s an opportunity to make all these suggestions accessible. Something a kin to ESLint warnings / recommendations. I’m imagining a plugin that shows brief descriptions of “avoid this” with some if “logical/situation”. Then we the community can add their own, vote, attach RU-vid videos. So if you write Promise.all you see this video / a code example.
I use this helper here to group data by the 'type' field. Could obviously also be a used with a 'status' field. export type Visitor = { [P in T["type"]]?: Extract[]; }; const groupByType = (data: T[]): Visitor => A.groupBy(data, (item) => item.type) as unknown as Visitor;
