1

I am new to JavaScript and learning about Promises. I am having some trouble figuring out when you would want to create your own Promise. Initially I was under the impression that the "executor function" (the function you pass into the Promise constructor) was handled asynchronously by the browser API (if your JavaScript is running in a browser). With that understanding you could then, for example, use your created Promise to perform some long-running calculation asynchronously in the background.

However, I learned that the executor function is actually executed synchronously as soon as the Promise is created (thus blocking the main thread of execution if you have a some long running code in that executor function). So now I'm wondering in what cases would you want to define your own Promises. My understanding is that a lot of the asynchronous functions like fetch for example already return promises - and thus it would be redundant to wrap those functions in a promise.

Can someone give me an example of when you would want to create your own Promise? Sorry if this is a silly question or if my understanding is off, still learning.

Thanks in advance!

  • 1
    Look at the [implementation](https://stackoverflow.com/questions/46654265/promise-all-consumes-all-my-ram/46654592#46654592) of `mapConcurrent()` which asynchronously iterates an array N at a time. It creates a promise that it can manually resolve or reject when everything it is tracking is done and the existing multi-promise tracking functions such as `Promise.all()` or `Promise.allSettled()` or `Promise.race()` don't offer this level of functionality. – jfriend00 May 11 '22 at 00:27
  • 1
    I've used promise when I needed add an image into canvas in multiple places, and had to wait until the image was loaded or when fetched something and had to return additional information with the fetch. – vanowm May 11 '22 at 00:29
  • 1
    Most of the time you won't create your own promise. You will either use the existing promise interface (that already returns a promise) or you will "promisify" a non-promise interface with something like [`util.promisify()`](https://nodejs.org/api/util.html#utilpromisifyoriginal) which will put a promise wrapper around a plain-callback style asynchronous operation for you. – jfriend00 May 11 '22 at 00:30
  • 1
    @jfriend00 `mapConcurrent` can be implemented without `new Promise`, see [here](https://stackoverflow.com/a/38778887/1048572) or [there](https://stackoverflow.com/a/39197252/1048572) – Bergi May 11 '22 at 00:43
  • Not everything that is asynchronous supports promises. – epascarello May 11 '22 at 01:48
  • @Bergi - I looked at that first one and I would NOT say that is easy to follow code. So, just because something can be done without creating a promise doesn't necessarily mean that's the best way to write it. The OP asked when you might want to create your own promise and I stand by my example. Are you somehow saying that one should never create a new promise if there's some way to avoid it, no matter how obscure that other code might be? Or are you just being contra for the sake of argument here? – jfriend00 May 11 '22 at 02:20

1 Answers1

3

My understanding is that a lot of the asynchronous functions like fetch for example already return promises

Actually, most don't. setTimeout, addEventListener, etc - they all take a callback and need to be promisified when you want to use a promise.

The trend to native functions that already return promises is still a recent occurrence, only new APIs like fetch do this. For libraries, the picture is similar - modern libraries will provide promises, but old ones are still around.

Apart from that, you're right - you rarely need new Promise, in normal code all you'll do is promise chaining (or even just use async/await). However, new Promise is still the primitive building block that underlies all these abstractions, and it won't go away.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • @Amadan Only in the context of "*… if you want to use them in a promise chain or `await` them*", of course. Regarding `addEventListener`, that has a `{once: true}` option – Bergi May 11 '22 at 01:34
  • As I would assume you know, there are promisified versions of `setTimeout()` and `.once()` in nodejs already. – jfriend00 May 11 '22 at 02:27