Em uma área compartilhada:
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
}
No servidor:
Meteor.publish("searchUsers", getSearchUsers);
Meteor.publish("friendUsers", getFriendUsers);
No cliente:
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();
}
});
A principal conclusão disso é que o que acontece nos bastidores quando os dados são transferidos pela rede não é óbvio. Meteor parece combinar os registros que foram correspondidos nas várias consultas no servidor e enviam isso para o cliente. Cabe então ao cliente executar a mesma consulta novamente para separá-los.
Por exemplo, digamos que você tenha 20 registros em uma coleção do lado do servidor. Você então tem duas publicações:a primeira corresponde a 5 registros, a segunda corresponde a 6, dos quais 2 são iguais. Meteor enviará 9 registros. No cliente, você executa exatamente as mesmas consultas que executou no servidor e deve terminar com 5 e 6 registros, respectivamente.
