Jeśli chcesz, aby ta konfiguracja działała, musisz wykonać następujące czynności:
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();
});
});
Nie po stronie klienta, musisz zdefiniować kolekcję tylko po stronie klienta:
directories = new Meteor.Collection('thisNameMatters');
i zasubskrybuj odpowiedni zestaw danych:
Meteor.subscribe('thisNameDoesNotMatter');
To powinno działać teraz. Daj mi znać, jeśli uważasz, że to wyjaśnienie nie jest wystarczająco jasne.
EDYTUJ
Tutaj self.added/changed/removed metody działają mniej więcej jako dyspozytor zdarzeń. Krótko mówiąc, udzielają instrukcji każdemu klientowi, który zadzwonił
Meteor.subscribe('thisNameDoesNotMatter');
o aktualizacjach, które należy zastosować w kolekcji klienta o nazwie thisNameMatters zakładając, że ta kolekcja istnieje. Nazwa - przekazana jako pierwszy parametr - może być wybrana niemal dowolnie, ale jeśli nie ma odpowiedniej kolekcji po stronie klienta, wszystkie aktualizacje zostaną zignorowane. Pamiętaj, że ta kolekcja może być tylko po stronie klienta, więc niekoniecznie musi odpowiadać „prawdziwej” kolekcji w Twojej bazie danych.
Zwracanie kursora z publish metoda jest tylko skrótem do powyższego kodu, z tą różnicą, że zamiast naszego theNameMatters używana jest nazwa aktualnej kolekcji . Ten mechanizm w rzeczywistości pozwala na tworzenie tylu „luster” zestawów danych, ile tylko zechcesz. W niektórych sytuacjach może to być całkiem przydatne. Jedynym problemem jest to, że te „kolekcje” będą tylko do odczytu (co ma sens BTW), ponieważ jeśli nie są zdefiniowane na serwerze, odpowiednie metody „wstaw/aktualizuj/usuń” nie istnieją.
