Why does the guide bother with writing publication to then make query on client that is same with the selector {listId: “yada”}. I don’t see why publications can’t just go by collection.find() security restrictions aside? Is this suppose to improve performance when you explicitly make it know that client will query by this param, because publication itself can’t tell what selectors are used as client hands them over asking for data?
I think you’ll see it’s quite common to be “passively” subscribed to data outside of what your current template may be looking at. For example, say I’m building a shopping app. All of my shirt items are in a Shirts collection. You navigate to the t-shirts, and add one to your cart. You then navigate to the long-sleeve shirts. If your template-scoped query doesn’t mirror your template-level subscription, then it’s possible that the item in your cart (which is in a separate pub/sub) would show up in your list of long-sleeve shirts.
It may sound far-fetched, but as your application grows, you’ll find these scenarios happen quite regularly.
I don’t see how that has anything to do with what @janat08 was talking about. That’s an issue of relying on your subscriptions to filter data and not adding the appropriate filters to find() on the client.
I think the reason that dynamic subscriptions aren’t in the guide is security. I think they’re perfectly fine to use though, especially for collections that don’t contain any sensitive data. For those you might as well just have a single dynamic pub, and let the client pass any selector and options arguments they want.
Ah, I misread this as “why subscriptions can’t just go by collection.find()”. My bad!
The meteor guide examples pass listID to publication.
I read the question as you did.
1 Like
Wait, I re-read the post, and now I’m no longer sure what the question is… 
@janat08 Can you give some code examples?
this.subscribe("posts", id: listId)
why not just Posts.find({list: listId})
You’re wondering why you have to subscribe at all?
Subscribing retrieves the data from the server. Find just searches through the client collection, if you haven’t subscribed to any data, find won’t find anything, unless you’re still using the autopublish package, which would be a major security and performance issue.
It does feel a bit redundant to specify the same query in both the find and the subscription/publication though. Grapher, which I’m using now, actually combines them into one, and introduces a “firewall” feature for security.
Yes I was hoping there’s a reason for why query is performed on publication and then the client, too, according to the guide in case that publication happens to stop performing that query.