Care to give some examples of the helpers? I always just use new Promise()
Promise.resolve()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
You can use this in place of new Promise() (though you rarely need it, as an async function automatically wraps any non-promise return value in a promise.)
----------
Promise.all()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
For making requests in parallel, and returning when all have been successful.
----------
Promise.allSettled()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
For making requests in parallel, and returning when all have completed whether successful or not.
----------
Promise.any()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
For making requests in parallel, and returning the first successful response.
--------
As mentioned in sibling comment, things like fetch and DB calls return promises anyway, so the above are mostly only useful for working with multiple other promises.
async function getData() {
return new Promise((resolve) => {
const res = fetch(…);
resolve(res);
});
}
The code above behaves exactly the same as
function getData() {
return fetch(…);
}
fetch(…);> usually junior front-end
So you agree with each other then?
I feel like there are advantages to making it `async function`, even if it's superfluous, because it signals to readers and to static code analysis that the function returns a promise. That's assuming the return type of fetch(...) can't be inferred by static analysis and developer tooling.
That is preposterous.
Would you say the same thing about
function getData() { return mysteryFunction(…); }
[0] https://www.youtube.com/watch?v=8aGhZQkoFbQ
[1] https://javascript.info/async
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
It doesn't mean it can't be mastered, it can, but the whole paradigm is so fraught with pitfalls and conceptual difficulties that an codebase that uses it in any extensive way will forever be unstable. The whole thing is supposed to help against callback hell, but that can be better solved by a simple thenable object.
Not a popular opinion I know, but there you go.
Wouldn't you simply be reinventing promises?
The usage of such an object won't be as terse and seemingly elegant as await syntax, but this is part of the problem: with await/promises so much of the complex logic is hidden from view and instead needs to reside the head of each dev, where it needs to compete with a thousand other things that need attention. It's an expression of the constant but unhealthy tendency towards golfing that pervades our field IMO.
That is NOT what async/await is about — after all, async explicitly marks functions as asynchronous. Not exactly trying to hide that.
Async/await is syntactic sugar. It is there to make working with Promises less verbose.
That is almost all: await pauses current function execution in the main event loop, which is an important detail
With Node APIs, there's a promisified version of pretty much everything. With browser APIs, there's usually a version with promises, and I'm struggling to think of an asynchronous API without promises that hasn't been superseded by something else (e.g. XMLHttpRequest -> fetch). If I'm converting from an event-emitter API to promises, there's usually going to be an impedance mismatch between the expectations of the event-based system and the promise-based system, and I probably need to explore another option.
I agree that any competent JS dev should understand how to create promises "from scratch" like this. But it still should probably be a fairly rare occurrence, and if I see a lot of `new Promise` calls in one place, it's pretty much always a sign that someone doesn't really understand how promises work.