Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
I have a feature request for Tracker.Computation.onStop. I couldn't find in the codebase where subscriptions are defined -- I was curious how subscriptions are stopped when Meteor.subscribe is called inside a reactive computation. I could be wrong, but I figured it listened to Tracker.currentComputation.onInvalidate to see if the computation is stopped. I came up with this, and its pretty convenient. I'm creating a package that allows you to cache subscriptions so it is very useful.
Tracker.Computation.prototype.onStop = (func) -> checkNextInvalidate = => this.onInvalidate (comp) -> if comp.stopped func() else Tracker.afterFlush(checkNextInvalidate) checkNextInvalidate()
This is basically how I'm using it.
c = Tracker.currentComputation sub = Tracker.nonreactive -> Meteor.subscribe('posts') c.onStop -> Meteor.setTimeout( (-> sub.stop, 1000*60*10) )
This will unsubscribe 10 minutes after the current reactive computation is stopped.
Thanks for the feature request! We welcome discussions about how to make Meteor better. If you haven't yet, check out our wiki page about feature requests on GitHub.
I'm still not sure that I understand your use case, though. When Meteor.subscribe is called in a reactive context, the subscription is stopped on any invalidation, not just on stop. While I can't see anything wrong with adding yet another event callback, I am not sure why onInvalidate doesn't help with your use case. It seems weird to me that you would want to keep subscriptions going for the next run of the computation even if they don't get renewed.
If the computation is stopped, we may not want to throw away the subscription immediately -- what if the user resubscribes to the same thing a minute later? That would be a waste to send the same data again, so it may make sense to cache these subscriptions.
I think I understand why you think its weird though. It actually makes more sense to use onInvalidate here... I would just need to keep track of which subscription to invalidate each time.
@mitar, I give a good explanation of why I'm making my own subscription caching package.
So I'm actually using onInvalidate instead of onStop now (version 0.0.4). It just makes much more sense.
I can't actually think of a specific situation when onStop would be more useful than onInvalidate so I'm going to close this request. Maybe someone will find it here and find a use for it.