I think it's important to note that the last example is slightly different than the first in that the wrapping function runFiles will not actually wait for the promises to resolve. You could always prepend the Promise.all call with an await, but in this instance, I think you might not really need await at all. In my experience, await is just syntactic sugar for Promise chaining. It's only necessary if you need synchronous steps in your asynchronous function. Your example could just be written as this:
This gives you some flexibility, because you aren't forcing any Promises to resolve before moving on to the next Promise. In a consuming function, you now have two options.
constsomeFunction=async(files)=>{// wait for runFiles to resolve all promisesawaitrunFiles(files)// or just allow it to run in the backgroundrunFiles(files)}
I think it's important to note that the last example is slightly different than the first in that the wrapping function
runFiles
will not actually wait for the promises to resolve. You could always prepend thePromise.all
call with anawait
, but in this instance, I think you might not really needawait
at all. In my experience,await
is just syntactic sugar for Promise chaining. It's only necessary if you need synchronous steps in your asynchronous function. Your example could just be written as this:This gives you some flexibility, because you aren't forcing any Promises to resolve before moving on to the next Promise. In a consuming function, you now have two options.
Wow, many thanks for your reply!
This way of doing things is new to me, and you're opening my eyes to think outside the single threaded box.
I will definitely try this approach, since it's more flexible.