Om du vill att den här inställningen ska fungera måste du göra följande:
Meteor.publish('thisNameDoesNotMatter', function () {
var self = this;
var handle = Meteor.users.find({}, {
fields: {emails: 1, profile: 1}
}).observeChanges({
added: function (id, fields) {
self.added('thisNameMatters', id, fields);
},
changed: function (id, fields) {
self.changed('thisNameMatters', id, fields);
},
removed: function (id) {
self.removed('thisNameMatters', id);
}
});
self.ready();
self.onStop(function () {
handle.stop();
});
});
Nej på klientsidan behöver du definiera en samling endast på klientsidan:
directories = new Meteor.Collection('thisNameMatters');
och prenumerera på motsvarande datamängd:
Meteor.subscribe('thisNameDoesNotMatter');
Detta borde fungera nu. Låt mig veta om du tycker att den här förklaringen inte är tillräckligt tydlig.
REDIGERA
Här, self.added/changed/removed
metoder fungerar mer eller mindre som en händelseförmedlare. Kort sagt ger de instruktioner till varje kund som ringde
Meteor.subscribe('thisNameDoesNotMatter');
om uppdateringarna som ska tillämpas på klientens samling som heter thisNameMatters
förutsatt att denna samling finns. Namnet - som skickas som den första parametern - kan väljas nästan godtyckligt, men om det inte finns någon motsvarande samling på klientsidan kommer alla uppdateringar att ignoreras. Observera att den här samlingen endast kan vara klientsidan, så den behöver inte nödvändigtvis motsvara en "riktig" samling i din databas.
Returnerar en markör från din publish
metod är det bara en genväg för ovanstående kod, med den enda skillnaden att namnet på en faktisk samling används istället för vår theNameMatters
. Denna mekanism låter dig faktiskt skapa så många "speglar" av dina datauppsättningar som du vill. I vissa situationer kan detta vara ganska användbart. Det enda problemet är att dessa "samlingar" kommer att vara skrivskyddade (vilket är helt vettigt förresten) eftersom om de inte är definierade på servern så existerar inte motsvarande "infoga/uppdatera/ta bort"-metoder.