Meteor Publish/Subscribe-Strategien für einzigartige clientseitige Sammlungen

In einem gemeinsamen Bereich:

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
}

Auf dem Server:

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

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

Die wichtigste Erkenntnis daraus ist, dass es nicht offensichtlich ist, was hinter den Kulissen passiert, wenn die Daten über das Kabel übertragen werden. Meteor scheint zu kombinieren die Datensätze, die in den verschiedenen Abfragen auf dem Server abgeglichen wurden, und diese an den Client senden. Es ist dann Sache des Clients, dieselbe Abfrage erneut auszuführen, um sie zu trennen.

Angenommen, Sie haben 20 Datensätze in einer serverseitigen Sammlung. Sie haben dann zwei Veröffentlichungen:die erste stimmt mit 5 Datensätzen überein, die zweite mit 6, von denen 2 gleich sind. Meteor sendet 9 Aufzeichnungen nach unten. Auf dem Client führen Sie dann genau die gleichen Abfragen aus, die Sie auf dem Server durchgeführt haben, und Sie sollten am Ende 5 bzw. 6 Datensätze haben.