针对唯一客户端集合的Meteor发布/订阅策略 [英] Meteor publish/subscribe strategies for unique client-side collections

问题描述

使用Meteor，我想知道如何最好地处理共享相同服务器端数据库集合的不同客户端集合。请考虑以下示例：我有一个用户集合，在我的客户端，我有一个用户列表，我有一个搜索功能，对整个用户数据库执行查询，返回与查询匹配的用户名列表。

Using Meteor, I'm wondering how best to handle different client-side collections that share the same server-side database collection. Consider the following example: I have a User collection, and on my client-side I have a list of users that are friends and I have a search feature that performs a query on the entire users database, returning a list of usernames that match the query.

在发布服务器端方法上，我对同一个集合有两个查询，它们返回不同的文档集。这些数据应该在客户端分成两个独立的集合吗？或者，与两个查询匹配的所有用户文档是否最终都在同一个集合中？如果是后者，我会重复用于服务器端和客户端查询的代码吗？

On the Publish server-side method, I have two queries against the same collection that return different sets of documents. Should this data go into two separate collections on the client-side? Or should all of the User documents that match both queries end up in the same collection? If the latter, would I then duplicate code used for both the server-side and client-side query?

在服务器上：

Meteor.publish('searchResults', function(query){
  var re = new RegExp(query, 'i')
  return Users.find({ 'name' : {$regex: re}})
})

在客户端：

Session.set('searchQuery', null)

Meteor.autosubscribe(function(){
  Meteor.subscribe('searchResults', Session.get('searchQuery'))
})

Template.search.events = {
  'keyup #user-search' : function(e){
    Session.set('searchQuery', e.target.value)
  }
}

_.extend(Template.search, {

  searchResults: function() {
    var re = new RegExp(Session.get('searchQuery'), 'i')
    return Users.find({ 'name' : {$regex: re}})
  }
})

这似乎是一个看似合理的解决方案，但不是最佳解决方案。如果我想创建一个新的客户端集合，该集合由来自多个服务器端集合的搜索结果组成，该怎么办？

This seems like a plausible solution, but not an optimal one. What if I wanted to create a new client-side collection that consisted of search results from multiple server-side Collections?

推荐答案

在共享区域：

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似乎组合
在服务器上的各种查询中匹配的记录，并将此
发送到客户端。然后，客户端再次运行相同的查询以将
拆分。

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.

例如，假设您在服务器端集合中有20条记录。然后你有
两个发布：第一个匹配5个记录，第二个匹配6个，其中2个是
相同。 Meteor将发送9条记录。在客户端上，然后运行您在服务器上执行的完全
相同的查询，并且您应该分别以5和6
记录结束。

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.

这篇关于针对唯一客户端集合的Meteor发布/订阅策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！