Publishing to an Alternative Client-side Collection in Meteor
When publishing a bunch of documents to the client with Meteor.publishComposite
, we sometimes end up with a perplexing problem on the client side of things. How do we figure out which published documents were intended for which purpose?
Note: This post assumes some familiarity with Meteor.publishComposite. If you haven’t used Meteor.publishComposite before, I recommend reading my previous post, Publishing Reactive Joins in Meteor, first.
Maybe this problem can be better illustrated through example. Say we are publishing a list of the top ten articles on our site and want to include some related articles for each one. These related articles will be published via the children
option of Meteor.publishComposite
. Normally, all the articles, both parents and children, would end up in the same collection on the client (e.g., Articles) making it difficult to determine which ones are the top ten articles and which are the related articles. What if, instead, we could publish the related articles into a separate client-side collection (e.g., RelatedArticles)? That would be amazingly helpful, wouldn’t it? Well, it’s a good thing you’re reading this blog post, because you can do exactly that with Meteor.publishComposite
using the collectionName
option.
The collectionName
option instructs Meteor.publishComposite
to tell the client a little lie and say that whatever documents come out of the cursor returned by the find
option came from a different collection. Here’s an example to demonstrate.
Got any comments or questions about this post? Let me have it in the comments section below.