kadirahq/subs-manager

Elaborate on the backwards compatibility of subs.subscribe

dandv opened this issue · 7 comments

Related to the iron-router .wait() issue: How much of a drop-in replacement is subs.subscribe vs. Meteor.subscribe? For example, how does it handle the onError and onReady callbacks?

The code below works fine with this.subscribe(), but never completes with subs.subscribe():

onBeforeAction: function () {
  var user = Meteor.user();
  if (user) {
    Session.set('contentLoaded', false);
    this.subscribe('content-portfolio', user, function onReady() {  // user is a temporary placeholder for a more specific key in the user object
      Session.set('contentLoaded', true);  // PROBLEM: never here if this is replaced with subs
    });
  }
},

Nope. This is not possible yet. Need some core API changes.
But not impossible.

@arunoda any updates to this and the onReady callback ?

Would really like this when subscriptions code on the server checks roles/permissions and the client code can then use the onError callback ...

Now you can pass onReady callback.
But I'm not sure it's semantics. Give it a try.

what about onStop callback?

oles commented

I'd would really really love to see support for onError - or at least some examples on how to work around this limitation.

@arunoda got some hints on how I should approach this, if I were to try to implement it myself?
Going to try to tinker with https://github.com/kadirahq/subs-manager/blob/master/lib/sub_manager.js#L169 when I get the time :)

Huh. Is this still not fixed? Is there a more up to date version of this package? :/