6 ms·
new 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
by dataflow 5y ago
new 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.
- wiml 5y agoWell, they're junior devs. You're supposed to help them get past that stage, not just throw away all your tools.
- eurasiantiger 5y agoWhat made you think I haven’t been helping them?
- joe_guy 5y agoI'm going out on a limb here and assuming the issues with their code don't begin and end with async.
- cercatrova 5y ago> 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. > usually junior front-end So you agree with each other then?
- eurasiantiger 5y agoGood day, axe handle.
- hn_throwaway_99 5y agoI mean, I know its a bit of linguistic flourish, but considering NodeJS was only initially released 12 years ago, that's quite a feat!
- Cpoll 5y ago> function getData() { return fetch(…); } 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.
- Kwantuum 5y ago> the type of fetch() can't be inferred by static analysis That is preposterous.
- Cpoll 5y agoIt's not. One might assume it's Node fetch, but parent post was just using a specific example to make a general point. Fetch can be `any`thing. Would you say the same thing about function getData() { return mysteryFunction(…); }
- garyrob 5y agoI'm a newbie with respect to JS and especially promises and async/await, but I need to learn. If you could point me to some resource that does a really good job of explaining all this, I'd appreciate it very much. I expect that I wouldn't be the only one. What's something you'd recommend to a junior developer so that they wouldn't be one of the "many devs", as you put it, who do the wrong thing?
- lmc 5y agoThis doesn't directly answer your question, but... something to watch out for is experienced developers can also struggle with promises and async code if they've spent most of their career working with sync code. And when we 'get' it, the difficulty of the journey is often understated. This stuff can be hard, so don't sweat it if it seems frustrating. (On the other hand, it may be easier if you don't have years of sync patterns to mentally set aside )
- garyrob 5y agoThanks for this feedback.
- magnio 5y agoNot the parent, but I recommend understanding the event loop first: here [0] is a very good talk. Then, read the chapter on promise on javascript.info [1], as it explains the problems Promise set out to solve (callback hell), then as usual the excellent MDN article [2]. [0] https://www.youtube.com/watch?v=8aGhZQkoFbQ https://www.youtube.com/watch?v=8aGhZQkoFbQ [1] https://javascript.info/async https://javascript.info/async [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...
- garyrob 5y agoJust watched that video. Thanks! Excellent resource. Moving on to your other links.
- stareatgoats 5y ago
- eurasiantiger 5y agoNobody has yet noticed that it’s only wrapped in TWO Promises. I take it nobody really understands the syntax, author included.
- savanaly 5y agoThis is absolutely correct why is it being downvoted lol
- Kwantuum 5y agoIt really isn't, most native/standard APIs do not return Promises. Lots of things use callbacks. Being comfortable creating Promises from a callback-based API is definitely something any competent JS dev ought to be able to do.
- MrJohz 5y agoA lot of APIs produce promises these days. The big one that I always need to promisify is `setTimeout`, but apart from that, I tend to find that if I'm using the `new Promise` API, I'm usually doing something wrong. 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.
- lmc 5y agoHere's a few. The docs link to some others that may also be useful... Promise.resolve() https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/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/Reference/Global_Objects/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/Reference/Global_Objects/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/Reference/Global_Objects/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.