Meteor:forskel mellem navne på samlinger, variabler, publikationer og abonnementer?

Lad os skelne mellem de forskellige navne, du muligvis skal forholde dig til, når du programmerer Meteor:

Variabelnavne , såsom Posts = new Meteor.Collection(...) . Disse bruges kun, så din kode ved, hvordan man får adgang til denne variabel. Meteor ved ikke eller er ligeglad med, hvad det er, selvom konventionen er at bruge stort.
Samlingsnavne , såsom new Meteor.Collection("posts") . Dette er knyttet til navnet på en MongoDB-samling (på serveren) eller en minimongo-samling (på klienten).
Udgivelses- og abonnementsnavne , brugt i Meteor.publish("foo", ...) eller Meteor.subscribe("foo") . Disse skal matche, for at klienten kan abonnere på nogle data på serveren.

Der er to ting, du skal matche i Meteor-datamodellen:

Navne på publikationer og deres tilhørende abonnementer
(normalt) Navne på samlinger på klienten og serveren, hvis du bruger standardindsamlingsmodellen

Et abonnementsnavn skal altid stemme overens med navnet på en publikation. De samlinger, der sendes for et givet abonnement, behøver dog ikke at have noget at gøre med abonnementsnavnet. Faktisk kan man sende over flere markører i én publikation eller én samling over forskellige publikationer eller endda flere abonnementer pr. publikation , som vises sammenlagt som én i klienten. Du kan også have forskellige samlingsnavne i serveren og klienten; læs videre...

Lad os gennemgå de forskellige sager:

Simpel abonnementsmodel . Dette er den, du normalt ser i enkle Meteor-demoer.

På klient og server,
```
Posts = new Meteor.Collection("posts");
```
Kun på serveren:
```
Meteor.publish("postsPub", function() { 
    return Posts.find() 
});
```
Kun på klient:
```
Meteor.subscribe("postsPub")
```
Dette synkroniserer Posts samling (som hedder posts i databasen) ved hjælp af publikationen kaldet postsPub .
Flere samlinger i én publikation . Du kan sende flere markører over for en enkelt publikation ved hjælp af et array.

På klient og server:
```
Posts = new Meteor.Collection("posts");
Comments = new Meteor.Collection("comments");
```
Kun på serveren:
```
Meteor.publish("postsAndComments", function() { 
    return [ 
        Posts.find(), 
        Comments.find() 
    ]; 
});
```
Kun på klient:
```
Meteor.subscribe("postsAndComments");
```
Dette synkroniserer Posts samling samt Comments samling ved hjælp af en enkelt publikation kaldet postsAndComments . Denne type publikation er velegnet til relationelle data; for eksempel, hvor du måske kun ønsker at udgive bestemte indlæg og de kommentarer, der kun er knyttet til disse indlæg. Se en pakke, der kan bygge disse markører automatisk .
Flere publikationer til en enkelt samling . Du kan bruge flere publikationer til at sende forskellige udsnit af data til en enkelt samling, som automatisk flettes af Meteor.

På server og klient:
```
Posts = new Meteor.Collection("posts");
```
Kun på serveren:
```
Meteor.publish("top10Posts", function() { 
    return Posts.find({}, {
        sort: {comments: -1}, 
        limit: 10
    });
});        
Meteor.publish("newest10Posts", function() { 
    return Posts.find({}, {
        sort: {timestamp: -1},
        limit: 10
    }); 
});
```
Kun på klient:
```
Meteor.subscribe("top10Posts");
Meteor.subscribe("newest10Posts");
```
Dette skubber både de 10 indlæg med flest kommentarer såvel som de 10 nyeste indlæg på webstedet til brugeren, som ser begge datasæt slået sammen til et enkelt Posts kollektion. Hvis et af de nyeste indlæg også er et indlæg med flest kommentarer eller omvendt, vises Posts samlingen vil indeholde mindre end 20 genstande. Dette er et eksempel på, hvordan datamodellen i Meteor giver dig mulighed for at udføre kraftfulde datafusionsoperationer uden selv at implementere detaljerne.
Flere abonnementer pr. publikation. Du kan få flere sæt data fra den samme publikation ved hjælp af forskellige argumenter.

På server og klient:
```
Posts = new Meteor.Collection("posts");
```
Kun på serveren:
```
Meteor.publish("postsByUser", function(user) { 
    return Posts.find({
        userId: user
    });
});        
```
Kun på klient:
```
Meteor.subscribe("postsByUser", "fooUser");
Meteor.subscribe("postsByUser", "barUser");
```
Dette forårsager indlæg fra fooUser og barUser for både at blive vist i posts kollektion. Denne model er praktisk, når du har flere forskellige beregninger, der ser på forskellige udsnit af dine data og kan blive opdateret dynamisk. Bemærk, at når du abonnerer i en Deps.autorun(...) , Meteor kalder stop() på ethvert tidligere abonnement håndteres automatisk med det samme navn, men hvis du bruger disse abonnementer uden for en autorun du bliver nødt til at stoppe dem selv. Lige nu kan du ikke lave to abonnementer med samme navn inde i en autorun beregning, fordi Meteor ikke kan skelne dem fra hinanden.
Skubning af vilkårlige data over en publikation. Du kan fuldstændigt tilpasse publikationer til ikke at kræve de samme samlingsnavne på serveren og klienten. Faktisk kan serveren udgive data, der slet ikke er understøttet af en samling. For at gøre dette kan du bruge API'et til publiceringsfunktionerne .

Kun på serveren:
```
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();
    })    
});
```
Kun på klient:
```
NewPosts = new Meteor.Collection("newposts");

Meteor.subscribe("newPostsPub");
```
Dette synkroniserer de nyeste 10 indlæg fra Posts samling på serveren (kaldet posts). i databasen) til NewPosts indsamling på klienten (kaldet newposts i minimongo) ved hjælp af publikationen/abonnementet kaldet newPostsPub . Bemærk at observeChanges adskiller sig fra observe , som kan en masse andre ting.

Koden virker kompliceret, men når du returnerer en markør inde i en publiceringsfunktion, er dette dybest set den kode, som Meteor genererer bag kulisserne. At skrive publikationer på denne måde giver dig meget mere kontrol over, hvad der sendes og ikke sendes til kunden. Vær dog forsigtig, da du manuelt skal slå observe fra håndterer og markerer, hvornår abonnementet er klar. For mere information, se Matt Debergalis' beskrivelse af denne proces (det indlæg er dog forældet). Selvfølgelig kan du kombinere dette med de andre stykker ovenfor for potentielt at få meget nuancerede og komplicerede publikationer.

Beklager essayet :-) men mange mennesker bliver forvirrede over dette, og jeg syntes, det ville være nyttigt at beskrive alle sagerne.