when.all() vs when.join()

[Paul Tiseo]

What's the difference? The only seeming difference is that when.all() takes an array and when.join() takes promises as individual params. Am I missing something?

[Charilaos Skiadas]

On Jul 6, 2013, at 3:56 PM, Paul Tiseo wrote:

> What's the difference? The only seeming difference is that when.all() takes an array and when.join() takes promises as individual params. Am I missing something?

I think that's correct, except for the extra bit that what is provided in when.all can actually be a promise for an array of promises/values, instead of just an array. In other words, the number of items involved in the array for when.all is something that might be determined during resolution time, at which point the promise passed to when.all reveals the array of promises that it had promised, and then you wait for those promises to be resolved.

This may sound complicated, but consider the following use case. I haven't implemented it yet but here is my situation:

Imagine a pubsub system. So publishers publish topics, and subscribers consume them. Imagine you want to use such a system to "publish" a request for a computation, and have the various subscribers perform it. You have no idea and might not even care right now how many those subscribers are. But what you do need is some way to get back their "results". You could arrange to subscribe to some other topic and have those subscribers publish their results to that topic, but another approach is the following:

Your pubsub system implements some sort of promises system, namely:

1. When you publish a topic the return value of that Publish call is a promise.
2. The pubsub system then, perhaps asynchronously, publishes that topic to the various handlers that had subscribed to it, and stores the return values of those calls.
3. If any of those subscribers wanted to promise a result, they would return that promise from the handler, and the pubsub system gets hold of it.
3. The pubsub system then puts together all those values returned from the handlers that are actually promises (as some handlers might be there just for logging purposes; then they wouldn't be returning promises). That becomes an array of promises.
4. The pubsub system uses this array of promises to fulfill the promise it had made to the original publisher (the "you" in 1).

Now you as a consumer of this "return value", must effectively wait for a 2-tier resolution. the promise you got back from the publish call needs to be resolved into an array of promises, and then all those promises need to be resolved by the respective handlers. I believe when.all will allow you to conveniently wait for that whole mess to be over.

Haris Skiadas

[Brian Cavalier]

Hey Paul and Haris,

Yep, you guys are correct.  Good explanation, Haris.

There are a few scenarios that we kept seeing when multiple promises were involved:

1. You have exactly N promises, and N is small.  For example, I want to do 2 parallel XHRs.  In this case when.join is very convenient.

2. You have an arbitrary number of promises you need to wait for.  when.all is convenient here, since you can build an array containing the arbitrary number of promises, and then hand it to when.all

3. You have a promise for an array, which might itself contain promises, as Haris said.  when.all will do all of the dirty work for you here.  Also, see when.map and when.reduce, as they will similarly attempt to "fully resolve" everything.

Brian