Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
This might be little opinion based, but an important question.
Should you use promises only for async operations? If you have an api, then very likely, the full stack of functions in there should use promises. So then if I make some business logic functions, they also should return a promise. I wonder if this is good, that you make everything return a promise. I mean, I'm calling functions inside a while loop, where each of them returns a promise (the functions are chained). Is it slower to use promises inside a function? Is it good idea in a stack to combine promises and regular return values? I really need to learn this, so please don't close
If your function is (sometimes) asynchronous, it needs to return a promise.
If your function never does anything asynchronous, there's no good reason for it to return a promise, and you should avoid it. Keep it simple and synchronous.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm new to asynchronous programming and I would like to know if using await is considered a bad coding practice. I am asking this because it looks like it is possible to let the callback function do the waiting instead of letting the entire program suspend everythng until the rpocess complete.
Thank you and I appreciate your idea on this.
No, it’s not. It’s just an approach (very useful sometimes).
In modern systems complexity is so high, that in many cases having clear code is much better that having super effective code. Just an example: imagine the case when you need to make several async things one by one (maybe, fetch data based one previously fetched results). You can do it making a chain of several .then(). After that you’ll need to also add .catch(). And at this point you’ll find yourself writing spaghetti code which is a bit messy.
The other option is just make this async function with sequential calls and some logic between them. And this will look much better
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm using Typescript for a Node application and I love to fully use the power of Javascript with all the good stuff of Typescript. Line after line I took up the habit to chain functions, to use arrow functions, to user carrying and partial functions and so on.
What I really cannot understand is why the forEach function return void instead of something useful I can use to perform a chainable, just one-line and elegant piece of code.
My question is about the design considerations behind this choice that at first glance seems to be just annoying and the implications a return value can cause.
Because that's what forEach does. It's like a for loop; it isn't meant to evaluate to anything useful. It's intended to be used to carry out side effects using a function. If you need it for anything other than that purpose, it's the wrong tool for the job.
If you want a looping function that evaluates to something, use map or reduce instead. map will return a new list based on the old list, and reduce will return a reduced value from iterating over the list.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I often hear something like "working knowledge of asynchronous programming" regards JavaScript in job descriptions etc, but I'm not sure what it mean - is it about callbacks and promises or is there something else to it? I'd appreciate if someone could explain this to me.
Yes, effectively. More generally, it's about understanding the asynchronous nature of the most common JavaScript environments (web browsers, Node.js) and being fully versed in using callbacks, promises, async/await (in modern environments), etc. Understanding the closures-in-loops problem, why you can't return the result from an asynchronous call, that code that looks like it's below other code in a function may run earlier than the code apparently above it (because the code above it is in a callback), etc.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm creating a Firebase cloud function that routes events to another system by making http calls for every event.
I noticed that if I don't return the promise, the http gets called most of the times (can't be 100% sure). I don't care about the response
Execution time decreases substantially if I don't return it. (155ms vs 13ms)
Does anyone know if a non returned promise is guaranteed to execute?
If your function does not return a Promise, it may be killed prematurely by Cloud Functions.
Also you might come across something like this in your console:
Function execution took 60023 ms, finished with status: 'timeout'
This happens, when a function does not return a Promise to Cloud Functions.
All types of functions except HTTPS type functions require that you return a promise that becomes resolved when asynchronous work is complete. If you don't do this, there is no guarantee that your work will complete, because the Cloud Functions runtime could clean up your function before the work is done.
It doesn't matter if you care about the response or result of the work, you should still be waiting until it's complete before allowing your function to terminate.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm new to NodeJs and to JS actually. I coded my first application using callbacks everywhere and I reached a state where I couldn't handle the number of nested callbacks anymore (callback hell). So I searched for solutions and I read that Promises are one of the best ways to solve this problem. Btw, here's a good explanation for those who are interested: https://blog.risingstack.com/node-js-async-best-practices-avoiding-callback-hell-node-js-at-scale/
Therefore, I made a refactoring in the most critical functions using Promises and it works very well. However, I don't know if I should refactor all the application. How do JS developers do nowadays? Do they use Promises everywhere or do they keep using callbacks the most part of the time and use Promises only when there are too many nested callbacks? Is there a best practice for that?