I'm using the async.eachLimit
function to control the maximum number of operations at a time.
const { eachLimit } = require("async");
function myFunction() {
return new Promise(async (resolve, reject) => {
eachLimit((await getAsyncArray), 500, (item, callback) => {
// do other things that use native promises.
}, (error) => {
if (error) return reject(error);
// resolve here passing the next value.
});
});
}
As you can see, I can't declare the myFunction
function as async because I don't have access to the value inside the second callback of the eachLimit
function.
You're effectively using promises inside the promise constructor executor function, so this the Promise constructor anti-pattern.
Your code is a good example of the main risk: not propagating all errors safely. Read why there.
In addition, the use of
async
/await
can make the same traps even more surprising. Compare:with a naive (wrong)
async
equivalent:Look in your browser's web console for the last one.
The first one works because any immediate exception in a Promise constructor executor function conveniently rejects the newly constructed promise (but inside any
.then
you're on your own).The second one doesn't work because any immediate exception in an
async
function rejects the implicit promise returned by theasync
function itself.Since the return value of a promise constructor executor function is unused, that's bad news!
Your code
There's no reason you can't define
myFunction
asasync
:Though why use outdated concurrency control libraries when you have
await
?