8 ms·
This, very much this. async function() {} is much nicer than function() { return new Promise( (resolve) => resolve() ) }
by eurasiantiger 5y ago
This, very much this.
async function() {}
is much nicer than
function() {
return new Promise(
(resolve) => resolve()
)
}
- bin_bash 5y agoI prefer async/await but this is a contrived example. For starters you can just write: const myfunc = () => new Promise(resolve => resolve()) or Promise.resolve()
- wildrhythms 5y agoAs soon as you need to chain Promises, this gets very annoying and you quickly find yourself in a nested callback hell.
- bin_bash 5y agoIf you’re nesting “new Promise” you’re almost certainly doing it wrong. This is for generating new promises not executing them.
- Aeolun 5y agoconst myfunc = () => new Promise(resolve => resolve()) Is there anyone that actually likes this structure? I find it really hard to reason about what a line like this does. What is the upper limit on double arrows in one line?
- bin_bash 5y agohere's a real world example I use all the time: const wait = (ms = 500) => new Promise(resolve => setTimeout(resolve, ms)); then: async function () { await wait(1000); } Perhaps it's hard to grok but it sure is a handy one-liner. Of course in newer versions of node we can now do: import { setTimeout, } from 'timers/promises'; await setTimeout(100);
- love2read 5y agothis works in older versions of node too: const wait = require(‘util’).promisify(setTimeout)
- oauea 5y agobut not in the browser
- joe_guy 5y agoThere's no merit of what should be a project wide function being a single line instead of 3 to avoid "hard to grok" syntax.
- deschutes 5y agoWait till you see the rest of javascript...
- eurasiantiger 5y agoYour comment is snarky and categorically dismissive. Care to explain why you have taken such an aggressive stance against JS?
- eurasiantiger 5y agoIt’s the cleanest way to wrap a event-emitting library, for example. async/await is not applicable in such a case where resolve needs to be explicitly called in a callback. async function process() { return new Promise((resolve, reject) => { emitter.on(”error”, (err) => reject(err)); emitter.on(”end”, (result) => resolve(result)); emitter.start(); }); } async is not strictly needed here, but I find it a good practice to use it on functions which immediately return a Promise anyway.
- deleted 5y ago[deleted]
- zkldi 5y agoI don't think it's a good practice, atleast if you have typescript jn your stack. It's redundant and wraps the promise in another promise.
- eurasiantiger 5y agoIIRC that doesn’t actually happen if a native Promise is returned.
- eyelidlessness 5y agoIt does, but only if you also add a redundant await. Which I still do, even in TypeScript, unless there’s a compelling performance reason not to. I disagree with the article overall, but I do agree that making asynchrony as explicit as possible is a good idea. Otherwise you end up with code like: async function foo(bar) { // ... } function nonObviousAsyncFn() { // ... return foo(quux); } Explicit return types would help, but most people don’t write them unless they’re forced by a linter.
- eurasiantiger 5y agoYes, this is a common anti-pattern return await foo();
- albedoa 5y agoYour gripe is that there are two arrows on one line? The second is an argument to the promise constructor. You should be able to reason about this line easily.
- dataflow 5y agonew Promise() is not how you want to create a promise in JS (except when you really have to), just like 'new'/'delete' are not how you ant to allocate memory in C++ (except when you really have to). There are lots of helpers in that class that make promises significantly more ergonomic.
- michaelsalim 5y agoCare to give some examples of the helpers? I always just use new Promise()
- aGHz 5y agoYou really end up creating promises manually, the vast majority are downstream from an IO call like fetch() or a database query.
- eurasiantiger 5y agoMany devs unnecessarily nest Promises like that. async function getData() { return new Promise((resolve) => { const res = fetch(…); resolve(res); }); } The response above is wrapped in THREE different Promises! One from fetch, one manually created, and one implicitly created by `async`. The code above behaves exactly the same as function getData() { return fetch(…); } or even just fetch(…);
- RobertWHurst 5y agoI've been on teams working on node projects for like 15 years. I've never seen someone who understands promises or async await do that. You'd have to know nothing about what the async keyword actually does to be compelled to do that.
- eurasiantiger 5y agoI have seen plenty of (usually junior front-end) devs resort to exactly this kind of cargo cult coding and magical thinking.
- kabes 5y agoI agree but second one could just be `() => Promise.resolve()`
- adamauckland 5y agoIt could, but depending on how you use it, you're changing scoping.
- kabes 5y agoTrue. But these days it's rare to see a scope other than what you'd expect from the short hand version. Old school JS with plain prototypes and flexible 'this' scope is very powerful, but is too hard to understand and thus rare these days.
- eurasiantiger 5y agoThat’s one of the neat things about JS: even outside the prototypal inheritance chain, classes can be (partially) composed of generalized, reusable functions, a bit like traits. Just import a function and bind it in the constructor (call).