As an alternative one could also store the promise of each async chain (axios->then->catch, asyncSomething -> then, ...) and then use Promise.all to wait for them all to finish. Just remember Promises are eagerly evaluated in JS so they immediately begin executing upon their creation.
(The above is a mix between pseudo code and code, the elipse is like in literature not the spread op)
Better still, I like to apply the "waiting on data" pattern to those elements which are waiting on data and those elements which are not waiting on data I immediately render. For example if you have a list of items that are populated with data, you render out all the layout and page and where there are "cards" or "items" that are constructed from fetched data you add a pulsing grey "loading element" which switches to a populated thing once the data is fetched. Imagine YouTube search where the thumbnails have yet to be loaded. It's a popular pattern. With pagination you could load 3-5 items at a time and the elements in the UI would "load in" over time. With server side events or web sockets you could "stream" the data to the page and avoid polling all together.
That's a great example! I work in Flutter and Dart as well and like the approach from Riverpod.
Other examples, albeit on the more extreme end of the gradient, are most things in Rust. There is no null ; you have Option of Some generic over T or None, and Result with either an Ok generic over T or Err (Data baring enums). In rust they go so far as to make it a compiler error to not address the result of an async op or handle all "control flow" operation "cases". You can "cheat" with handling funcs which return Result and "ignore" the result by saying "let _ = await someOpWhichReturnsOptionOrResult" and you can add a "default case" to a "switch like op" but you must consciously make those decisions; it's not by happenstance or by ignorance. The compiler also gives you the answer 99% of the time (exaggerating but it's often the case the compiler tells you exactly what to do); The errors in Rust are the most helpful messages I've ever been graced with by a conpiler. I am in love with Rust if you can't tell lol.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As an alternative one could also store the promise of each async chain (axios->then->catch, asyncSomething -> then, ...) and then use Promise.all to wait for them all to finish. Just remember Promises are eagerly evaluated in JS so they immediately begin executing upon their creation.
const asyncThingOne = ...
const asyncThingTwo = ...
Promise.all([asyncThingOne, asyncThingTwo, ...]).then(updateIsLoadingToFalse)
(The above is a mix between pseudo code and code, the elipse is like in literature not the spread op)
Better still, I like to apply the "waiting on data" pattern to those elements which are waiting on data and those elements which are not waiting on data I immediately render. For example if you have a list of items that are populated with data, you render out all the layout and page and where there are "cards" or "items" that are constructed from fetched data you add a pulsing grey "loading element" which switches to a populated thing once the data is fetched. Imagine YouTube search where the thumbnails have yet to be loaded. It's a popular pattern. With pagination you could load 3-5 items at a time and the elements in the UI would "load in" over time. With server side events or web sockets you could "stream" the data to the page and avoid polling all together.
Thank you for the comment 🙏
I also really like this approach, in Flutter I saw something similar with Riverpod AsyncValue which I found very intuitive and readable 😉
That's a great example! I work in Flutter and Dart as well and like the approach from Riverpod.
Other examples, albeit on the more extreme end of the gradient, are most things in Rust. There is no null ; you have Option of Some generic over T or None, and Result with either an Ok generic over T or Err (Data baring enums). In rust they go so far as to make it a compiler error to not address the result of an async op or handle all "control flow" operation "cases". You can "cheat" with handling funcs which return Result and "ignore" the result by saying "let _ = await someOpWhichReturnsOptionOrResult" and you can add a "default case" to a "switch like op" but you must consciously make those decisions; it's not by happenstance or by ignorance. The compiler also gives you the answer 99% of the time (exaggerating but it's often the case the compiler tells you exactly what to do); The errors in Rust are the most helpful messages I've ever been graced with by a conpiler. I am in love with Rust if you can't tell lol.