Meteor:differenza tra nomi per raccolte, variabili, pubblicazioni e abbonamenti?

Distinguiamo tra i diversi nomi con cui potresti avere a che fare durante la programmazione di Meteor:

Nomi delle variabili , come Posts = new Meteor.Collection(...) . Questi vengono utilizzati solo in modo che il tuo codice sappia come accedere a questa variabile. Meteor non sa o non si preoccupa di cosa sia, anche se la convenzione è di capitalizzare.
Nomi delle raccolte , come new Meteor.Collection("posts") . Questo viene mappato al nome di una raccolta MongoDB (sul server) o di una raccolta minimongo (sul client).
Nomi di pubblicazioni e abbonamenti , utilizzato in Meteor.publish("foo", ...) o Meteor.subscribe("foo") . Questi devono corrispondere affinché il client possa iscriversi ad alcuni dati sul server.

Ci sono due cose che devi abbinare nel modello di dati di Meteor:

Nomi delle pubblicazioni e relativi abbonamenti
(di solito) Nomi delle raccolte sul client e sul server, se si utilizza il modello di raccolta predefinito

Il nome di una sottoscrizione deve sempre corrispondere al nome di una pubblicazione. Tuttavia, le raccolte inviate per una determinata sottoscrizione non devono avere nulla a che fare con il nome della sottoscrizione. In effetti, è possibile inviare su più cursori in una pubblicazione o una raccolta su pubblicazioni diverse o anche più abbonamenti per pubblicazione , che appaiono uniti come uno nel client. Puoi anche avere nomi di raccolta diversi nel server e nel client; continua a leggere...

Esaminiamo i diversi casi:

Modello di abbonamento semplice . Questo è quello che di solito vedi nelle semplici demo di Meteor.

Su client e server,
```
Posts = new Meteor.Collection("posts");
```
Solo sul server:
```
Meteor.publish("postsPub", function() { 
    return Posts.find() 
});
```
Solo su client:
```
Meteor.subscribe("postsPub")
```
Questo sincronizza i Posts raccolta (che si chiama posts nel database) utilizzando la pubblicazione denominata postsPub .
Più raccolte in una pubblicazione . Puoi inviare più cursori per una singola pubblicazione, utilizzando una matrice.

Su client e server:
```
Posts = new Meteor.Collection("posts");
Comments = new Meteor.Collection("comments");
```
Solo sul server:
```
Meteor.publish("postsAndComments", function() { 
    return [ 
        Posts.find(), 
        Comments.find() 
    ]; 
});
```
Solo su client:
```
Meteor.subscribe("postsAndComments");
```
Questo sincronizza i Posts raccolta così come i Comments raccolta utilizzando un'unica pubblicazione denominata postsAndComments . Questo tipo di pubblicazione si adatta bene ai dati relazionali; ad esempio, dove potresti voler pubblicare solo determinati post e i commenti associati solo a quei post. Scopri un pacchetto in grado di creare automaticamente questi cursori .
Più pubblicazioni per un'unica raccolta . Puoi utilizzare più pubblicazioni per inviare diverse sezioni di dati per una singola raccolta che vengono unite automaticamente da Meteor.

Su server e client:
```
Posts = new Meteor.Collection("posts");
```
Solo sul server:
```
Meteor.publish("top10Posts", function() { 
    return Posts.find({}, {
        sort: {comments: -1}, 
        limit: 10
    });
});        
Meteor.publish("newest10Posts", function() { 
    return Posts.find({}, {
        sort: {timestamp: -1},
        limit: 10
    }); 
});
```
Solo su client:
```
Meteor.subscribe("top10Posts");
Meteor.subscribe("newest10Posts");
```
Questo spinge sia i 10 post con il maggior numero di commenti sia i 10 post più recenti sul sito all'utente, che vede entrambi i set di dati uniti in un unico Posts collezione. Se uno dei post più recenti è anche un post con più commenti o viceversa, i Posts la raccolta conterrà meno di 20 articoli. Questo è un esempio di come il modello di dati in Meteor ti consente di eseguire potenti operazioni di unione dei dati senza implementare i dettagli da solo.
Più abbonamenti per pubblicazione. Puoi ottenere più set di dati dalla stessa pubblicazione utilizzando argomenti diversi.

Su server e client:
```
Posts = new Meteor.Collection("posts");
```
Solo sul server:
```
Meteor.publish("postsByUser", function(user) { 
    return Posts.find({
        userId: user
    });
});        
```
Solo su client:
```
Meteor.subscribe("postsByUser", "fooUser");
Meteor.subscribe("postsByUser", "barUser");
```
Questo fa sì che i post di fooUser e barUser per apparire entrambi nei posts collezione. Questo modello è utile quando si dispone di diversi calcoli che esaminano sezioni diverse dei dati e possono essere aggiornati dinamicamente. Nota che quando ti iscrivi all'interno di un Deps.autorun(...) , Meteor chiama stop() su qualsiasi abbonamento precedente gestisce automaticamente con lo stesso nome, ma se stai utilizzando questi abbonamenti al di fuori di un autorun dovrai fermarli tu stesso. Al momento, non puoi eseguire due abbonamenti con lo stesso nome all'interno di un autorun calcolo, perché Meteor non può distinguerli.
Invio di dati arbitrari su una pubblicazione. È possibile personalizzare completamente le pubblicazioni per non richiedere gli stessi nomi di raccolta sul server e sul client. In effetti, il server può pubblicare dati che non sono affatto supportati da una raccolta. Per fare ciò, puoi utilizzare l'API per le funzioni di pubblicazione .

Solo sul server:
```
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();
    })    
});
```
Solo su client:
```
NewPosts = new Meteor.Collection("newposts");

Meteor.subscribe("newPostsPub");
```
Questo sincronizza i 10 post più recenti dai Posts raccolta sul server (denominato posts nel database) al NewPosts raccolta sul client (denominato newposts in minimongo) utilizzando la pubblicazione/abbonamento denominata newPostsPub . Nota che observeChanges differisce da observe , che può fare un sacco di altre cose.

Il codice sembra complicato, ma quando restituisci un cursore all'interno di una funzione di pubblicazione, questo è fondamentalmente il codice che Meteor sta generando dietro le quinte. Scrivere pubblicazioni in questo modo ti dà molto più controllo su cosa viene inviato e cosa non viene inviato al cliente. Fai attenzione però, poiché devi disattivare manualmente observe gestisce e segna quando l'abbonamento è pronto. Per ulteriori informazioni, consulta la descrizione di Matt Debergalis di questo processo (tuttavia, quel post non è aggiornato). Naturalmente, puoi combinare questo con gli altri pezzi sopra per ottenere potenzialmente pubblicazioni molto sfumate e complicate.

Scusa per il saggio :-) ma molte persone si confondono su questo e ho pensato che sarebbe utile descrivere tutti i casi.