Meteor:różnica między nazwami kolekcji, zmiennych, publikacji i subskrypcji?

Rozróżnijmy różne nazwy, z którymi możesz mieć do czynienia podczas programowania Meteora:

Nazwy zmiennych , na przykład Posts = new Meteor.Collection(...) . Są one używane tylko po to, aby Twój kod wiedział, jak uzyskać dostęp do tej zmiennej. Meteor nie wie ani nie dba o to, co to jest, chociaż konwencja polega na kapitalizacji.
Nazwy kolekcji , na przykład new Meteor.Collection("posts") . Odwzorowuje to nazwę kolekcji MongoDB (na serwerze) lub kolekcji minimongo (na kliencie).
Nazwy publikacji i subskrypcji , używany w Meteor.publish("foo", ...) lub Meteor.subscribe("foo") . Muszą one być zgodne, aby klient mógł zasubskrybować niektóre dane na serwerze.

W modelu danych Meteor musisz dopasować dwie rzeczy:

Nazwy publikacji i odpowiadające im subskrypcje
(zwykle) Nazwy kolekcji na kliencie i serwerze, jeśli używany jest domyślny model kolekcji

Nazwa subskrypcji musi zawsze zgadzać się z nazwą publikacji. Jednak kolekcje wysyłane w ramach danej subskrypcji nie muszą mieć nic wspólnego z nazwą subskrypcji. W rzeczywistości można wysłać wiele kursorów w jednej publikacji lub jedna kolekcja w różnych publikacjach a nawet wiele subskrypcji na publikację , które pojawiają się jako połączone w kliencie. Możesz także mieć różne nazwy kolekcji na serwerze i kliencie; czytaj dalej...

Przyjrzyjmy się różnym przypadkom:

Prosty model subskrypcji . To jest ten, który zwykle widzisz w prostych demonstracjach Meteora.

Na kliencie i serwerze,
```
Posts = new Meteor.Collection("posts");
```
Tylko na serwerze:
```
Meteor.publish("postsPub", function() { 
    return Posts.find() 
});
```
Tylko na kliencie:
```
Meteor.subscribe("postsPub")
```
To synchronizuje Posts kolekcja (o nazwie posts w bazie danych) za pomocą publikacji o nazwie postsPub .
Wiele kolekcji w jednej publikacji . Możesz wysłać wiele kursorów dla pojedynczej publikacji, używając tablicy.

Na kliencie i serwerze:
```
Posts = new Meteor.Collection("posts");
Comments = new Meteor.Collection("comments");
```
Tylko na serwerze:
```
Meteor.publish("postsAndComments", function() { 
    return [ 
        Posts.find(), 
        Comments.find() 
    ]; 
});
```
Tylko na kliencie:
```
Meteor.subscribe("postsAndComments");
```
To synchronizuje Posts kolekcji oraz Comments kolekcja przy użyciu jednej publikacji o nazwie postsAndComments . Ten rodzaj publikacji jest odpowiedni dla danych relacyjnych; na przykład, gdy możesz chcieć publikować tylko niektóre posty i komentarze związane tylko z tymi postami. Zobacz pakiet, który może automatycznie budować te kursory .
Wiele publikacji w jednej kolekcji . Możesz użyć wielu publikacji, aby wysłać różne wycinki danych dla jednej kolekcji, które są automatycznie łączone przez Meteor.

Na serwerze i kliencie:
```
Posts = new Meteor.Collection("posts");
```
Tylko na serwerze:
```
Meteor.publish("top10Posts", function() { 
    return Posts.find({}, {
        sort: {comments: -1}, 
        limit: 10
    });
});        
Meteor.publish("newest10Posts", function() { 
    return Posts.find({}, {
        sort: {timestamp: -1},
        limit: 10
    }); 
});
```
Tylko na kliencie:
```
Meteor.subscribe("top10Posts");
Meteor.subscribe("newest10Posts");
```
Spowoduje to wysłanie zarówno 10 postów z największą liczbą komentarzy, jak i 10 najnowszych postów w witrynie do użytkownika, który widzi oba zestawy danych połączone w jeden Posts kolekcja. Jeśli jeden z najnowszych postów jest jednocześnie postem z największą liczbą komentarzy lub odwrotnie, Posts kolekcja będzie zawierać mniej niż 20 pozycji. To jest przykład tego, jak model danych w Meteor umożliwia wykonywanie potężnych operacji łączenia danych bez samodzielnego wdrażania szczegółów.
Wiele subskrypcji na publikację. Możesz uzyskać wiele zestawów danych z tej samej publikacji, używając różnych argumentów.

Na serwerze i kliencie:
```
Posts = new Meteor.Collection("posts");
```
Tylko na serwerze:
```
Meteor.publish("postsByUser", function(user) { 
    return Posts.find({
        userId: user
    });
});        
```
Tylko na kliencie:
```
Meteor.subscribe("postsByUser", "fooUser");
Meteor.subscribe("postsByUser", "barUser");
```
Powoduje to posty przez fooUser i barUser aby oba pojawiły się w posts kolekcja. Ten model jest wygodny, gdy masz kilka różnych obliczeń, które analizują różne wycinki danych i mogą być aktualizowane dynamicznie. Zwróć uwagę, że kiedy subskrybujesz w Deps.autorun(...) , Meteor wywołuje stop() na dowolnym wcześniejszym uchwycie subskrypcji o tej samej nazwie automatycznie, ale jeśli używasz tych subskrypcji poza autorun będziesz musiał sam je powstrzymać. W tej chwili nie możesz zrobić dwóch subskrypcji o tej samej nazwie w autorun obliczenia, ponieważ Meteor nie może ich odróżnić.
Przesyłanie dowolnych danych do publikacji. Publikacje można całkowicie dostosować, aby nie wymagały tych samych nazw kolekcji na serwerze i kliencie. W rzeczywistości serwer może publikować dane, które nie są w ogóle obsługiwane przez kolekcję. Aby to zrobić, możesz użyć API dla funkcji publikowania .

Tylko na serwerze:
```
Posts = new Meteor.Collection("posts"); 

Meteor.publish("newPostsPub", function() {
    var sub = this;
    var subHandle = null;

    subHandle = Posts.find({}, {
        sort: {timestamp: -1},
        limit: 10
    })
    .observeChanges({
        added: function(id, fields) {
            sub.added("newposts", id, fields);            
        },
        changed: function(id, fields) {
            sub.changed("newposts", id, fields);            
        },
        removed: function(id) {
            sub.removed("newposts", id);
        }
    });

    sub.ready();

    sub.onStop(function() {
        subHandle.stop();
    })    
});
```
Tylko na kliencie:
```
NewPosts = new Meteor.Collection("newposts");

Meteor.subscribe("newPostsPub");
```
To synchronizuje 10 najnowszych postów z Posts kolekcja na serwerze (zwana posts w bazie danych) do NewPosts kolekcja na kliencie (zwana newposts w minimongo) za pomocą publikacji/subskrypcji o nazwie newPostsPub . Zauważ, że observeChanges różni się od observe , który może zrobić wiele innych rzeczy.

Kod wydaje się skomplikowany, ale kiedy zwracasz kursor wewnątrz funkcji publikowania, jest to w zasadzie kod, który Meteor generuje za kulisami. Pisanie publikacji w ten sposób daje dużo większą kontrolę nad tym, co jest, a co nie jest wysyłane do klienta. Bądź jednak ostrożny, ponieważ musisz ręcznie wyłączyć observe uchwyty i zaznacz, kiedy subskrypcja jest gotowa. Aby uzyskać więcej informacji, zobacz Opis tego procesu autorstwa Matta Debergalisa (jednak ten post jest nieaktualny). Oczywiście możesz połączyć to z innymi elementami powyżej, aby potencjalnie uzyskać bardzo zniuansowane i skomplikowane publikacje.

Przepraszam za esej :-), ale wiele osób jest z tym zdezorientowanych i pomyślałem, że warto opisać wszystkie przypadki.