Meteor strategieën voor publiceren/abonneren voor unieke client-side collecties

In een gedeelde ruimte:

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
}

Op de server:

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

Op de klant:

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();
  }
});

De belangrijkste conclusie hiervan is dat het niet duidelijk is wat er achter de schermen gebeurt wanneer de gegevens via de kabel worden overgedragen. Meteor lijkt te samenvoegen de records die overeenkomen met de verschillende zoekopdrachten op de server en stuur deze naar de client. Het is dan aan de client om dezelfde query opnieuw uit te voeren om ze uit elkaar te splitsen.

Stel bijvoorbeeld dat u 20 records in een server-side verzameling hebt. Je hebt dan twee publicaties:de eerste matcht 5 records, de tweede matcht 6, waarvan er 2 hetzelfde zijn. Meteor zal 9 records naar beneden sturen. Op de client voer je dan exact dezelfde query's uit die je op de server hebt uitgevoerd en je zou respectievelijk 5 en 6 records moeten krijgen.