Make sure all reasonable APIs have reactive and callback version of it

[mitar]

So many APIs currently available in Meteor have some mix of reactive and callback APIs. The issue is that they are not really synced and which one is there is pretty arbitrary. I would suggest we take care and define equal APIs for both approaches. Sometimes it is more useful to have a simple callback, but sometimes it is useful to have reactivity. For example, in subscription, you can have onReady callback, and the returned handle has ready reactive API. This is great. But it has only onStop callback, while no isStopped API on the returned handle. So one cannot write things like:

Tracker.autorun((computation) => {
  if (handle.isStopped()) {
    computation.stop();
  }
  if (!handle.ready()) {
    return;
  }
  if (!someOtherVar.get()) {
    return;
  }
  computation.stop();

  // Do something with someOtherVar.
});

I would suggest that we for example add to the subscription handle things like handle.error(), handle.isStopped() or handle.stopped().

Similarly for method calls. It would be great it method calls would return a reactive handle on which you can wait. And some other APIs I have seen through time, we could try to enumerate them.

Especially if we also make it so that handle.ready() is also a promise. :-) Then you can do things like handle.ready().then(...) which would be equal to passing onReady.

[zimme]

Especially if we also make it so that handle.ready() is also a promise. :-) Then you can do things like handle.ready().then(...) which would be equal to passing onReady.

In this case I'd rather see handle.ready (no need for a function when it's a promise?) being a promise and if we want we can keep the boolean in handle.isReady().

[zimme]

But I do get the point of this. It would be nice have parity between callback style and reactive style

[mitar]

I would like that it is also reactive. So that it works inside Tracker's computation.

One issue is that there is slight difference between promises and reactive values. Reactive values can change through time. While promises can change only once. So while all promises can be reactive values, not all reactive values can be promises.

But I think having a general way to do it would be great. Similarly to how we on the server can have fiber and promises combined. It would be great to have fibers, promises, and reactivity combined.

But you are right, my code above would not work. Maybe the crazy idea could be that we use something like reactive field for ready. And then extend it so that you can do:

handle.ready.then(...)
handle.ready()

And then resolves the first time ready() returns a non-initial value.

In general I would replace reactive vars with my reactive fields anywhere. :-)