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.
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?
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? :/