5

I don't know if SO is the right place for such a question.

I know a bit Promises, and I use them in a Node/Express environment to 'fix' the asynchronous behavior of Node when querying database (= Wait for DB answer, then do something).

However, the more I use them, the less I know when not use them.

For example, I wrote a piece of code like this (for a local script querying Google Matrix API)...

 ....
 for (var i = 0; i < rows.length; i++) { // loop over a CSV file by line
    var cell = rows[i].split(/;/)
    var origin = cell[1]
    var destination = cell[2]
    var id = cell[0]
    Promise.all([origin, destination, id]).then((p) => {}
 ...

I don't know if using here a Promise.all makes sense at all...

Is there a rule to know? A behavior I do not get?

Say differently, when do I know there is a "risk" that my script runs a function without its right argument (argument being returned from another function which is not "over") ...?

Thanks.

charnould
  • 2,480
  • 3
  • 19
  • 23
  • 6
    You use promises to help deal with asynchronous processes. If there is nothing asynchronous then there is no need to use promises. In your example, `origin`, `destination` and `id` are **strings**, not promises. It doesn't make sense to pass those values to `Promise.all`. I think you should continue to learn about promises so that you really understand which problem they are solving. Then the question "when not to use them" should be obvious. – Felix Kling Dec 28 '16 at 20:29
  • You wouldn't use Promises in the case above because it's not async. You would generally use promises anytime you would need a callback or are waiting for some async behavior to complete. – Keith Rousseau Dec 28 '16 at 20:29
  • It doesn't make sense, `Promise.all(list)` returns a promise that runs once all promises on `list` fulfill, but you're passing a list of... cells? Text? Certainly not promises. – ranieri Dec 28 '16 at 20:32
  • 4
    _to 'fix' the asynchronous behavior_ don't fix it, love it. async is great and very usefull, you just need to learn what you can do with it. – baao Dec 28 '16 at 20:34
  • `I use them ... to 'fix' the asynchronous behavior` - actually, by using Promises you are **using** asynchronous behaviour - nothing can make an asynchronous operation synchronous - once you go async, you can't go back – Jaromanda X Dec 28 '16 at 22:30

2 Answers2

2

When you have entirely synchronous code (no async operations you are trying to track the completion of), you do NOT want to use promises.

Trying to use promises with synchronous code only adds unnecessary complication to the logic of the code and slows down the execution of your code. With all synchronous code, there is nothing to wait for the completion of or to coordinate with the completion of so you can just execute your code and have the result immediately. Adding promises just complicates your code unnecessarily.

In addition, Promise.all() expects that you pass it an array of promises, not an array of values like you are doing so in addition to be unnecessary, what you were doing was also incorrect.

So, there's really no reason to not just do this:

 ....
 for (var i = 0; i < rows.length; i++) { // loop over a CSV file by line
    var cell = rows[i].split(/;/)
    var origin = cell[1]
    var destination = cell[2]
    var id = cell[0]
    // operate on id, destination and origin here
    // no need to wait on a promise before doing so
 }
 ...

Promise would be used with asynchronous operations such as database operations, file operations, networking operations, timing operations, etc... You can use them to either know when an individual asynchronous operation is done or to coordinate multiple operations (some of which are asynchronous).

jfriend00
  • 683,504
  • 96
  • 985
  • 979
1

Generally you don't use native promise yourself, you use promise because what you currently use require some asynchonous process :

  • http request client side
  • database / other request server-side

Usually the connectors/libraries you use for them already impose you a Promise or a callback, in which you can just resolve the promise in order to use promise everywhere.

Another very specific kind of asynchronous process is when you client side do some heavy thing (which generally it shouldn't!) and you need to make it like it's running on background and resolve it asynchronously.

You could use a promise and resolve it when it's done.

See on this SO's post if you didn't understand what I meant by "running on background", since Javascript is monothreaded, there isn't such a thing it's just an emulation of it.

Community
  • 1
  • 1
Walfrat
  • 5,363
  • 1
  • 16
  • 35