Expose when.all() and/or when.join()

[tkem]

Disclaimer: I'm not that much of a JS guru, so if I'm completely wrong on this issue or there are already much easier ways to do what I'm trying to achieve, I'd be glad to be corrected or pointed to the right direction...

The when.js CommonJS Promises/A implementation used by mopidy.js provides some useful "static" methods, which are not available easily through the mopidy.js interface. I especially like to use when.all() and/or when.join(), which somewhat resemble pykka.join(), which I like ;-)

I currently use what I consider a very ugly hack to get that functionality without loading when.js seperately, to do something like this:

var all = mopidy.getVersion().__proto__.constructor.all;
return all([
  mopidy.tracklist.getConsume(),
  mopidy.tracklist.getRandom(),
  mopidy.tracklist.getRepeat(),
  mopidy.tracklist.getSingle()
]).then(function(results) {
  return {
    consume: results[0],
    random: results[1],
    repeat: results[2],
    single: results[3]
  };
});

Now, it would be nice if all and/or the similar when.join() would be exposed by Mopidy directly, since I think this use case might not be uncommon for clients. I guess all could be easily added as a property to either the Mopidy constructor or a mopidy instance.

As stated before, I don't know if there's an easier or cleaner way to achieve this. However, what I don't want to do is add another

<script src="when.js">

since the functionality is already there...

[tkem]

Thinking a little more about that, I guess something like

Mopidy.when = when;

would make me happy, without polluting namespaces and such...

[jodal]

Yes, that's the direction I've been thinking too.

One one side I don't want to expose any dependencies of Mopidy.js since that's really an implementation detail, but from a more pragmatic point of view, you got a good point about the library needed to work effectively with promises already being there, just not very available.

[tkem]

Yeah, "pragmatic" is the right word...

It seems like there's a gazillion of deferred/promises libraries out there that follow the specs on the client interface side, but don't provide much interoperability. For example, AngularJS has $q which provides $q.all() which is just what I was looking for... Turns out, AFAICS, it only works with $q promises, since it looks for some magic $$... variables inside the promise object. Sigh.

Guess I could try and implement some implementation-agnostic helper functions for that, but I'm quite busy with that other project, so I'd really appreciate if you chose to expose this...

[tkem]

Thinking a little more about it (two days of Zeitausgleich really help ;-)), if you're unsure about whether to expose the internal dependencies of Mopidy.js, adding a Mopidy.join() would be a really good start. Chances are, you can keep the function signature if you ever want to change to a different implementation, whereas exposing when.js directly gives you all sorts of crazy (but fun!) stuff...

[jodal]

I think I'll go with exposing when. If we ever move away from it, users of Mopidy.when can simply depend on when directly themselves.