$subcribe & $collection aren't clearing mini mongo cache

[jpgilchrist]

@Urigo,

I've also noticed that when going from one route to another and changing $collection and $subscribe methods the data isn't wiped. It's carried over from one page to the other. Even when specifying a narrower subscription on the latter pages.

Example:

First Page Controller:

$subscribe.susbcribe("allItems");
$collection.collection(Items).bind($scope, "items", true, true);

Second Page Controller:

$subscribe.subscribe("publicItems");
$collection(Items).bind($scope, "publicItems", true, true);

Publisher:

Meteor.publish("allItems", function() {
  return Items.find();
});

Meteor.publish("publicItems", function() {
  return Items.find({public: true});
});

If I console.dir($scope.publicItems) in the second page by navigating from the first page through links, the collection remains a cumulative total of the two (which in this case happens to be the first page's collection). Whereas, it should wipe the data cache and only contain the limited scope where {public: true}.

Thoughts?

[Urigo]

@jpgilchrist good question, and for that it is important to understand better how publish/subscribe works in Meteor.
Here is a good article:
http://www.meteorpedia.com/read/Understanding_Meteor_Publish_and_Subscribe

The main thing - minimogo is just for cache, it's not for filtering. it is suppose to contain everything you subscribed to in client, so this behaviour is good.

Filtering should be done by Mongo selectors, like this:

var publicPosts = BlogPosts.find({public: true});

So in our case:

$collection(Items, {public: true}).bind($scope, "publicItems", true, true);

[jpgilchrist]

I'm not sure I 100% agree. Because the point especially in regards to mobile applications is to limit the data necessary for the UI to work. Therefore, I do not want all the Items, just the public Items. In this manner, I don't have to filter it further and I don't have to worry about slowing down the client with too much data (obviously more of a scaling problem, which I don't really have to deal with yet - just want to keep it in mind).

[Urigo]

So why subscribing to $subscribe.susbcribe("allItems");?

And if you did, it's already there, no need to delete them and it will help you a lot when you do:
$subscribe.subscribe("publicItems"); because it's already there.

In mobile or not in mobile you should subscribe only to what you need.
subscribing fetches the data to the client, ones its there, no need to fetch it again if it's not changed

[jpgilchrist]

Makes sense. I 100% agree with you on not fetching data that's already there.

Just seems redundant to have to filter the $collection when you are $subscribing to a specific publication that should already be limited in scope. This means, that I would have to make sure that (on almost all $collections) I reuse the same filter from the publication.

I.e.,

Meteor.publish("publicItems", function() {
  Items.find({public: true});
});

$collection(Items, {public: true}).bind(...)

Seems simple with a simple query such as {public: true}, but what happens when you have to use a more complex query. I'd rather not have to maintain it in two separate locations.

[Urigo]

That is the main difference between AngularJS and Meteor.
In Meteor, everything in the client is global, so you can do it once.
In Angular, it is per scope.
If you want to make it global, you can put it in $rootScope

[jpgilchrist]

Right. I feel like that's where some of my confusion comes into play. I'm assuming that the $scope will be unique, but it's actually pulling global data from the data cache in mini mongo. Therefore, in the $scope we have to force it to filter.

Thanks for being so responsive. It's much appreciated. Feel free to close.

[Urigo]

No problem, those are good questions and they give me more material for the tutorial.

I'll think about how better to explain those differences in the tutorial, would love your thoughts and maybe even your pull requests for the tutorial, I think your perspective would be very valuable to the tutorial

[jpgilchrist]

Sounds good. I'll take another read through the tutorial and see if there's any place where I can help.