1

Consider small helper functions, some of which are obvious candidates for async / promise (as I think I understand them):

exports.function processFile(file){
  return new Promise(resolve => {
    // super long processing of file
    resolve(file);
  });
}

While this:

exports.function addOne(number){
  return new Promise(resolve => {
    resolve(number + 1);
  });
}

Seems overkill.

What is the rule by which one determines whether they should promise-fy their functions?

Trees4theForest
  • 1,267
  • 2
  • 18
  • 48
  • 1
    See [When to make a function asynchronous using Promises](https://stackoverflow.com/a/28994043/1048572), [What is the best way to wrap synchronous functions in to a promise](https://stackoverflow.com/q/36826592/1048572) and [Is it useful to always return a promise?](https://stackoverflow.com/q/22473728/1048572) – Bergi Aug 15 '17 at 01:28

2 Answers2

1

I generally use a promise if I need to execute multiple async functions in a certain order. For example, if I need to make three requests and wait for them all to come back before I can combine the data and process them, that's a GREAT use case for promises. In your case, let's say you have a file, and you need to wait until the file and metadata from a service are both loaded, you could put them in a promise.

If you're looking to optimize operations on long running processes, I'd look more into web workers than using promises. They operate outside the UI thread and use messages to pass their progress back into the UI thread. It's event based, but no need for a promise. The only caveat there is that you can't perform actions on the DOM inside a web worker.

More on web workers here: https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

nixkuroi
  • 2,259
  • 1
  • 19
  • 25
1

What is the rule by which one determines whether they should promise-fy their functions?

It's quite simple actually:

  • When the function does something asynchronous, it should return a promise for the result
  • When the function does only synchronous things, it should not return a promise
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • I guess that's the point: what inherently makes makes X+1 synchronous aside from its speed? – Trees4theForest Aug 15 '17 at 03:36
  • 1
    That it doesn't do anything after it returns ("in the background")? I thought you knew [what "asynchronous" means](https://stackoverflow.com/q/748175/1048572). In general, everything is synchronous by default, and [you have to know it when it's not](https://stackoverflow.com/q/19083357/1048572). – Bergi Aug 15 '17 at 04:14
  • A function that does one asynchronous thing and that doesn't need to be done in a specific sequence, or wait on other events to complete, is overkill and probably unnecessary overhead. A simple callback can be used instead. – nixkuroi Aug 15 '17 at 11:54
  • @nixkuroi Can you elaborate? Are you saying that for some asynchronous functions a callback is better than returning promise? – Bergi Aug 15 '17 at 15:27
  • Yes. Think about what a promise does. A promise is essentially a wrapper for managing one or more async events. It marshals those events and let's you decide how/when/threshold to process the output they produce. If you have a single function that only needs to do one thing when it's finished (return the value, or pass the results of the function to another function), why bother creating a wrapper and doing a then() with the results, when you can simply pass a callback into the function and pass the result into the callback? – nixkuroi Aug 15 '17 at 20:06
  • 1
    @nixkuroi It seems you were [missing the point of promises](https://blog.domenic.me/youre-missing-the-point-of-promises/). Promises are result values, and they're much easier and safer to work with than callbacks. They even have [hardly any overhead](https://spion.github.io/posts/why-i-am-switching-to-promises.html). But that discussion is irrelevant anyway, the OP already decided to use promises. If he were using callbacks, his question would have been "*How to determine whether my function should take a callback or not?*". – Bergi Aug 15 '17 at 20:56
  • @Bergi - actually he didn't. His question was "How to determine whether to promisefy a function?", which implies that he hadn't decided to use a promise or not. And the callback suggestion was for you, because you didn't seem to understand that you don't need to add any overhead (even hardly any), if you don't need any of the features of a promise. – nixkuroi Aug 16 '17 at 18:00
  • @nixkuroi If something is asynchronous, I *always* use a promise instead of a callback for *consistency*. I usually need the features of promises, and even when I don't need them I don't want to incur the overhead of thinking about callback-vs-promise on my development process. It's just more maintainable that way. – Bergi Aug 16 '17 at 18:25
  • @Bergi - Maintainability and consistency are good goals, however adding overhead into every single async process in the name of "the overhead of thinking" seems wasteful to me. You're editing the code a few times, but it's getting executed hundreds or thousands or millions of times. I'd rather have the cost be in thinking than electricity. At scale, those extra calculations and that extra memory mean something. – nixkuroi Aug 16 '17 at 20:00
  • @nixkuroi Most asynchronous processes are not executed that often - and most processing power goes into the task itself anyway, not the promise. Spending electricity during a complicated development process won't make up the savings in electricity during runtime in over 99% of the cases, and there are more tradeoffs to make like the likelihood for mistakes introduced. Of course, [i]when necessary[/i] in a tight spot, I can micro-optimise code and do away with abstractions (both callbacks and promises) by inlining, but it's almost never necessary. – Bergi Aug 16 '17 at 21:02
  • @Bergi - Most of the applications I've worked on in the past few years have made async calls continuously, sometimes as often as every five seconds and/or processed massive amounts of data (usually for immediate visualization) in real time. My guess is that you and I have just had vastly different experiences in terms of how and why we use async calls/processing. Thanks for explaining, and I think I understand your perspective, and thank you for it. – nixkuroi Aug 16 '17 at 21:31
  • @nixkuroi Yes, we have different experiences. Every five seconds is not often at all :-) There are bigger fish to optimise. – Bergi Aug 16 '17 at 21:35
  • @Bergi It can actually be quite often depending on the amount of data you're getting. Knowing the size of the fish is important to understand before making assumptions :) – nixkuroi Aug 16 '17 at 22:03