Question on subscribing to extra fields when drilling into detail


#1

I’ve got 2 publications:

Meteor.publish("books", function () {
    var foundOnServer = Books.find({}, {sort: {"title": 1}, fields: {"_id": 1, "title": 1, "author": 1 }});
    console.log("returning books")
    return foundOnServer;
  });
  Meteor.publish("book", function (id) {
    var foundOnServer = Books.find({_id:id}, {fields: {"_id": 1, "title": 1, "author": 1, "extra":1 }});
    console.log("returning a single book with full info, id: " + id);
    return foundOnServer;
  });

and I’ve noticed by watching the debugging provided by mongol that when I am displaying all the books (subscribing to the “books” publication), the documents include just the title and author fields, but when I drill into detail on a book, (subscribing to the “book” publication), the local minimongo collection correctly hits the server to get the additional field, storing it in the local Books collection on the client.

That’s great, but what I also noticed is that when I route back to my list of all the books, and look in minimongo, I see that the additional “extra” field (for that book I just drilled into) goes away. And If I drill back into it, it gets fetched again from the server.

Just looking for comments. I can see pros and cons to this approach, and wondering if it might be made configurable somehow…

Just to clarify, I’m noticing that the extra fields are fetched, but then thrown away when going back to the listing of all books.

This is a good thing if you think about a client looking at the full list of books, they aren’t receiving DDP messages about the detail fields they don’t care about… but the downside is that it seems that if you drill into a document once and pull up the details, it might make some sense to keep those details on the client side, in case one drills back into the same book, then it won’t have to fetch details again from the server.

screencast example here
and github repo example here


#2

You could take a look at meteorhacks:subs-manager.


#3

Thanks @robfallows … Yep, I had forgotten about that when I put together this simple example. I updated the github project to use subs manager… because of things like this, I can’t see any reason NOT to use subs manager…