Meteorのユニークなクライアントサイドコレクションのパブリッシュ/サブスクライブ戦略

共有エリア内：

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
}

サーバー上：

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

クライアントの場合：

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

これからの重要なポイントは、データがネットワークを介して転送されているときに舞台裏で何が起こるかが明らかではないということです。 Meteorは結合しているように見えます サーバー上のさまざまなクエリで一致したレコードをクライアントに送信します。次に、クライアントが同じクエリを再度実行して、それらを分割します。

たとえば、サーバー側のコレクションに20個のレコードがあるとします。次に、2つの公開があります。1つ目は5つのレコードに一致し、2つ目は6つに一致し、そのうち2つは同じです。 Meteorは9つのレコードを送信します。次に、クライアントで、サーバーで実行したのとまったく同じクエリを実行すると、それぞれ5レコードと6レコードになります。