Meteor publish/subscribe strategies for unique client-side collections

In a shared area:

function getSearchUsers(query) {
  var re = new RegExp(query, "i");
  return Users.find({name: {$regex: re}});
}

function getFriendUsers() {
  return Users.find({friend: true});    // or however you want this to work
}

On the server:

Meteor.publish("searchUsers", getSearchUsers);
Meteor.publish("friendUsers", getFriendUsers);

On the client:

Template.search.onCreated(function () {
   var self = this;
   self.autorun(function () {
     self.subscribe("searchUsers", Session.get("searchQuery"));
   });
});

Template.friends.onCreated(function () {
  this.subscribe("friendUsers");
});

Template.search.helpers({
  searchResults: function () {
    return getSearchUsers(Session.get("searchQuery"));
  }
});

Template.friends.helpers({
  results: function () {
    return getFriendUsers();
  }
});

The key takeaway from this is that what happens behind the scenes when the data
is getting transferred over the wire isn’t obvious. Meteor appears to combine
the records that were matched in the various queries on the server and send this
down to the client. It’s then up the client to run the same query again to split
them apart.

For example, say you have 20 records in a server-side collection. You then have
two publishes: the first matches 5 records, the second matches 6, of which 2 are
the same. Meteor will send down 9 records. On the client, you then run the exact
same queries you performed on the server and you should end up with 5 and 6
records respectively.

Leave a Comment