独特的客户端集合的流星发布/订阅策略 [英] Meteor publish/subscribe strategies for unique client-side collections

问题描述

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

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

从中得出的关键结论是，当数据通过电线传输并不明显.流星似乎结合在服务器上的各种查询中匹配的记录并发送到客户端.然后由客户端再次运行相同的查询来拆分他们分开.

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.

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