Разбиране на Meteor Публикуване / Абониране

Промяна на записи

Това е мястото, където Meteor прави нещата много удобни:когато промените запис (документ) в колекцията Minimongo на клиента, Meteor незабавно ще актуализира всички шаблони, които зависят от него, и също така ще изпрати промените обратно на сървъра, който от своя страна ще съхранява промените в MongoDB и ще ги изпрати до съответните клиенти, които са се абонирали за набор от записи, включващ този документ. Това се нарича компенсация на латентността и е един от седемте основни принципа на Meteor.

Множество абонамента

Можете да имате куп абонаменти, които изтеглят различни записи, но всички те ще се озоват в една и съща колекция на клиента, ако идват от същата колекция на сървъра, въз основа на техния _id . Това не е обяснено ясно, но се подразбира от документите на Meteor:

Когато се абонирате за набор от записи, той казва на сървъра да изпрати записи на клиента. Клиентът съхранява тези записи в локални колекции Minimongo, със същото име като колекция аргумент, използван в добавено на манипулатора на публикуване , променен и премахнати обратни повиквания. Meteor ще постави в опашка входящи атрибути, докато не декларирате Mongo.Collection на клиента със съответстващото име на колекцията.

Това, което не е обяснено, е какво се случва, когато не изрично използвайте добавено , променен и премахнати , или изобщо публикувайте манипулатори - което е през повечето време. В този най-често срещан случай аргументът за колекция е (не е изненадващо) взет от името на колекцията MongoDB, която сте декларирали на сървъра на стъпка 1. Но това означава, че можете да имате различни публикации и абонаменти с различни имена и всички записите ще попаднат в същата колекция на клиента. Надолу до нивото на полета от най-високо ниво , Meteor се грижи да изпълни зададено обединение между документите, така че абонаментите да могат да се припокриват - публикувайте функции, които изпращат различни полета от най-високо ниво към работата на клиента една до друга и на клиента, документът в колекцията ще бъде обединението на двете набори от полета.

Пример:множество абонаменти, попълващи една и съща колекция на клиента

Имате колекция BlogPosts, която декларирате по един и същи начин както на сървъра, така и на клиента, въпреки че прави различни неща:

BlogPosts = new Mongo.Collection('posts');

На клиента BlogPosts може да получите записи от:

1. абонамент за най-новите 10 публикации в блог

   // server
   Meteor.publish('posts-recent', function publishFunction() {
     return BlogPosts.find({}, {sort: {date: -1}, limit: 10});
   }
   // client
   Meteor.subscribe('posts-recent');
   

2. абонамент за публикациите на текущия потребител

   // server
   Meteor.publish('posts-current-user', function publishFunction() {
     return BlogPosts.find({author: this.userId}, {sort: {date: -1}, limit: 10});
     // this.userId is provided by Meteor - http://docs.meteor.com/#publish_userId
   }
   Meteor.publish('posts-by-user', function publishFunction(who) {
     return BlogPosts.find({authorId: who._id}, {sort: {date: -1}, limit: 10});
   }
   
   // client
   Meteor.subscribe('posts-current-user');
   Meteor.subscribe('posts-by-user', someUser);
   

3. абонамент за най-популярните публикации

4. и др.

Всички тези документи идват от posts колекция в MongoDB, чрез BlogPosts колекция на сървъра и се озовават в BlogPosts събиране на клиента.

Сега можем да разберем защо трябва да извикате find() повече от веднъж - вторият път е на клиента, защото документите от всички абонаменти ще попаднат в една и съща колекция и трябва да извлечете само тези, които ви интересуват. Например, за да получите най-новите публикации на клиента, просто отразявате заявката от сървъра:

var recentPosts = BlogPosts.find({}, {sort: {date: -1}, limit: 10});

Това ще върне курсора към всички документи/записи, които клиентът е получил до момента, както на горните публикации, така и на публикациите на потребителя. (благодаря Джефри).