Proposal, tighter integration
jerradpatch opened this issue · comments
Hello,
I have been using MeteorObservable for a while (much better than Meteor.find). However, to get data from a publication (particularly one that takes an input variable to select results) I have to "subscribe to the publication", .subscribe to a MeteorObservable. On destroy, I have to unsubscribe to the publication and MeteorObservable. When desiring new results, I need to subscribe two times and unsubscribe two times. It would be nice if both of these could be combined, in which when subscribing to the MeteorObservable.find, I would also subscribe to a publication (that is generated) that would send the results to the client. Perhaps there is a better implementation pattern I am not aware of?
@jerradpatch
Meteor's approach is to create a single Collection, with multiple publications, that merges in the client's MiniMongo into a unique Collection.
That means, that coupling between the Collection and the subscription might limit usage for other users.
If you want to make it easier to use, and you only need a single publication per Collection, you can always wrap MongoObservable.find with a method that will also do MeteorObservable.subscribe, and return a merged streams with the Collection data and the status of the publication.
What would be a limitation? I'm not talking about doing away with subscriptions, just subscribing to data that isn't in the local. With this proposal, the data on the local would be returned immediately and then server fetches the rest (just like a find does now).
@jerradpatch , can you provide an example?
My meaning was that when find also do the subscription to the data, it will couple the publication of the data to the collection.
The use case would be a large database with a lot of shared data, that I would not want a client to have entirly on their local db. Subscriptions work great when I have data the is distinct to groups of users or a single user, b/c then I can just subscribe to it all and call finds on the local all day. However for the large shared collection subscriptions actually create more overhead (previously described).
I think I will wrap my finds like you suggested for these collections. In that my collection will have a default subscription, and on my client I will have a simple wrapper function the subscribes to it. (somthing like)
server:
default: function(anyQuery:{}){
limiter code here
}
client:
function findSubscribe(query){
let sub: subscription = this.collection.subscribe('default', query).subscribe();
let ret: Observable = this.collection.find(query);
ret.unsubscribe = function(){
sub.unsubscribe();
ret.unsubscribe();
}
return ret;
Closing due to inactivity and cleanup.