0

I came across the source code of tiny-async-pool npm package, in there there's this composition

const p = Promise.resolve().then(() => iterator(index, array))

I am a bit confused by this implementation, so I started to do some checks, my understanding is that what it actually does is creating a pending promise, when I log in my terminal I get this: enter image description here

;(async () => {
  const store = []

  const promiseFn1 = () => 'I say one'
  const promise1 = Promise.resolve().then(() => promiseFn1())
  console.log('promise1: ', promise1)
  store.push(promise1)

  const promiseFn2 = () => 'I say two'
  const promise2 = Promise.resolve(promiseFn2())
  console.log('promise2: ', promise2)
  store.push(promise2)

  const promiseFn3 = () => 'I say three'
  const promise3 = new Promise((resolve) => resolve(promiseFn3()))
  console.log('promise3: ', promise3)
  store.push(promise3)

  await Promise.all(store)
})()

Is this what the code is doing and if so, is this the only way to create a pending promise that can be stored on an array of promises?

Thanks.

Álvaro
  • 2,255
  • 1
  • 22
  • 48
  • Why exactly do you need a *pending* promise? It shouldn't matter whether a promise is pending or resolved if you have an array of them – VLAZ Oct 10 '21 at 13:23
  • I don't, tiny-async-pool apparently does, hence my question – Álvaro Oct 10 '21 at 13:24
  • And I don't see anything in the question that indicates that. You said you're using the library, then you asked how to get a pending promise. I miss where the connection is between the two. – VLAZ Oct 10 '21 at 13:25
  • I am just trying to understand what it does, that's all – Álvaro Oct 10 '21 at 13:26
  • It creates a promise. It doesn't really matter whether it's "pending" or not. It's fulfilling an async contract, at the end of the day, and it most likely does it for consistency. https://blog.izs.me/2013/08/designing-apis-for-asynchrony – VLAZ Oct 10 '21 at 13:27
  • Thanks, so are you saying that the thing I do in `promise2` on my snippet is doing the same thing? – Álvaro Oct 10 '21 at 13:29
  • 1
    They all do the same thing as they all end up with the same value (would be exactly the same if only one function was used, right now it's just the same kind of value) . The first one just takes extra ticks to resolve. Your console displays them different because it tries to show you the internal state of the promise but that's to be considered an implementation detail. If you run the snippet and *then* open the browser console, you'd see a different representation than if you open the console first and then run it. – VLAZ Oct 10 '21 at 13:34
  • For what `tiny-async-pool` is doing, runing promises in parallel with a limit, do you thing this extra 'ticks' are needed to ensure it works as intented? – Álvaro Oct 10 '21 at 13:39
  • 1
    No, because promises do not "run". And there is no way to ensure they are parallel, either. Promises are just a notification mechanism. [See my answer here for more details](https://stackoverflow.com/a/65836893). See also [What is the correct terminology for javascript promises](https://stackoverflow.com/q/29268569) for more information on promises. As for *why* the library does that - most likely to ensure the operation is done asynchronously. See the article Iinked above and especially the other article it links to: https://blog.ometer.com/2011/07/24/callbacks-synchronous-and-asynchronous/ – VLAZ Oct 10 '21 at 13:55
  • 2
    See also [this](https://stackoverflow.com/q/30082237/1048572) and [that](https://stackoverflow.com/q/45079887/1048572) for more explanations of the pattern. In short, `Promise.resolve().then(() => …)` is equivalent to `new Promise(resolve => resolve(…))`. You can't do just `const p = iteratorFn(index, array)` because `iteratorFn` might return a plain value and you need to resolve it to a promise. You can't just do `const p = Promise.resolve(iteratorFn(index, array))` because `iteratorFn` might throw an exception, and you want a rejected promise in that case. – Bergi Oct 10 '21 at 15:09

0 Answers0