Stratégies de publication/abonnement Meteor pour des collections uniques côté client

Dans un espace partagé :

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
}

Sur le serveur :

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

Sur le client :

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

La principale conclusion à retenir est que ce qui se passe dans les coulisses lorsque les données sont transférées via le réseau n'est pas évident. Meteor semble se combiner les enregistrements qui ont été mis en correspondance dans les différentes requêtes sur le serveur et l'envoient au client. C'est alors au client d'exécuter à nouveau la même requête pour les séparer.

Par exemple, supposons que vous ayez 20 enregistrements dans une collection côté serveur. Vous avez alors deux publications :la première correspond à 5 enregistrements, la seconde à 6, dont 2 identiques. Meteor enverra 9 enregistrements. Sur le client, vous exécutez alors exactement les mêmes requêtes que vous avez effectuées sur le serveur et vous devriez vous retrouver avec respectivement 5 et 6 enregistrements.