Strategie publikowania/subskrybowania przez Meteor dla unikalnych kolekcji po stronie klienta

We wspólnym obszarze:

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
}

Na serwerze:

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

Na kliencie:

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

Kluczowym wnioskiem z tego jest to, że to, co dzieje się za kulisami, gdy dane są przesyłane przez sieć, nie jest oczywiste. Meteor wydaje się połączyć rekordy, które zostały dopasowane w różnych zapytaniach na serwerze i wyślij je do klienta. Następnie klient musi ponownie uruchomić to samo zapytanie, aby je rozdzielić.

Załóżmy na przykład, że w kolekcji po stronie serwera masz 20 rekordów. Masz wtedy dwa publikacje:pierwsze pasuje do 5 rekordów, drugie do 6, z których 2 są takie same. Meteor wyśle ​​9 rekordów. Na kliencie uruchamiasz dokładnie te same zapytania, które wykonałeś na serwerze i powinieneś otrzymać odpowiednio 5 i 6 rekordów.