Meteor:diferença entre nomes para coleções, variáveis, publicações e assinaturas?

Vamos distinguir entre os diferentes nomes com os quais você pode ter que lidar ao programar o Meteor:

Nomes de variáveis , como Posts = new Meteor.Collection(...) . Eles são usados apenas para que seu código saiba como acessar essa variável. Meteor não sabe ou se importa com o que é, embora a convenção seja capitalizar.
Nomes de coleção , como new Meteor.Collection("posts") . Isso mapeia para o nome de uma coleção do MongoDB (no servidor) ou uma coleção do minimongo (no cliente).
Nomes de publicação e assinatura , usado em Meteor.publish("foo", ...) ou Meteor.subscribe("foo") . Eles precisam corresponder para que o cliente assine alguns dados no servidor.

Há duas coisas que você precisa combinar no modelo de dados do Meteor:

Nomes de publicações e suas assinaturas correspondentes
(geralmente) Nomes de coleções no cliente e no servidor, se estiver usando o modelo de coleção padrão

Um nome de assinatura precisa sempre corresponder ao nome de uma publicação. No entanto, as coleções enviadas para uma determinada assinatura não precisam ter nada a ver com o nome da assinatura. Na verdade, pode-se enviar vários cursores em uma publicação ou uma coleção em diferentes publicações ou até mesmo várias assinaturas por publicação , que aparecem mesclados como um no cliente. Você também pode ter nomes de coleção diferentes no servidor e no cliente; Leia...

Vamos analisar os diferentes casos:

Modelo de assinatura simples . Este é o que você normalmente vê em demonstrações diretas do Meteor.

No cliente e no servidor,
```
Posts = new Meteor.Collection("posts");
```
Apenas no servidor:
```
Meteor.publish("postsPub", function() { 
    return Posts.find() 
});
```
Somente no cliente:
```
Meteor.subscribe("postsPub")
```
Isso sincroniza os Posts coleção (que se chama posts no banco de dados) usando a publicação chamada postsPub .
Várias coleções em uma publicação . Você pode enviar vários cursores para uma única publicação, usando uma matriz.

No cliente e no servidor:
```
Posts = new Meteor.Collection("posts");
Comments = new Meteor.Collection("comments");
```
Apenas no servidor:
```
Meteor.publish("postsAndComments", function() { 
    return [ 
        Posts.find(), 
        Comments.find() 
    ]; 
});
```
Somente no cliente:
```
Meteor.subscribe("postsAndComments");
```
Isso sincroniza os Posts coleção, bem como os Comments coleção usando uma única publicação chamada postsAndComments . Esse tipo de publicação é adequado para dados relacionais; por exemplo, onde você deseja publicar apenas determinadas postagens e os comentários associados apenas a essas postagens. Veja um pacote que pode construir esses cursores automaticamente .
Várias publicações para uma única coleção . Você pode usar várias publicações para enviar diferentes fatias de dados para uma única coleção que são mescladas pelo Meteor automaticamente.

No servidor e no cliente:
```
Posts = new Meteor.Collection("posts");
```
Apenas no servidor:
```
Meteor.publish("top10Posts", function() { 
    return Posts.find({}, {
        sort: {comments: -1}, 
        limit: 10
    });
});        
Meteor.publish("newest10Posts", function() { 
    return Posts.find({}, {
        sort: {timestamp: -1},
        limit: 10
    }); 
});
```
Somente no cliente:
```
Meteor.subscribe("top10Posts");
Meteor.subscribe("newest10Posts");
```
Isso envia as 10 postagens com mais comentários e as 10 postagens mais recentes no site para o usuário, que vê os dois conjuntos de dados mesclados em um único Posts coleção. Se uma das postagens mais recentes também for uma postagem com mais comentários ou vice-versa, as Posts coleção conterá menos de 20 itens. Este é um exemplo de como o modelo de dados no Meteor permite que você faça operações poderosas de mesclagem de dados sem implementar os detalhes por conta própria.
Várias assinaturas por publicação. Você pode obter vários conjuntos de dados da mesma publicação usando argumentos diferentes.

No servidor e no cliente:
```
Posts = new Meteor.Collection("posts");
```
Apenas no servidor:
```
Meteor.publish("postsByUser", function(user) { 
    return Posts.find({
        userId: user
    });
});        
```
Somente no cliente:
```
Meteor.subscribe("postsByUser", "fooUser");
Meteor.subscribe("postsByUser", "barUser");
```
Isso faz com que as postagens de fooUser e barUser para que ambos apareçam nos posts coleção. Esse modelo é conveniente quando você tem vários cálculos diferentes que analisam diferentes fatias de seus dados e podem ser atualizados dinamicamente. Observe que quando você se inscreve dentro de um Deps.autorun(...) , Meteor chama stop() em qualquer identificador de assinatura anterior com o mesmo nome automaticamente, mas se você estiver usando essas assinaturas fora de um autorun você precisará detê-los você mesmo. A partir de agora, você não pode fazer duas assinaturas com o mesmo nome dentro de um autorun computação, porque o Meteor não pode diferenciá-los.
Enviando dados arbitrários em uma publicação. Você pode personalizar completamente as publicações para não exigir os mesmos nomes de coleção no servidor e no cliente. Na verdade, o servidor pode publicar dados que não são suportados por uma coleção. Para fazer isso, você pode usar a API para as funções de publicação .

Apenas no servidor:
```
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();
    })    
});
```
Somente no cliente:
```
NewPosts = new Meteor.Collection("newposts");

Meteor.subscribe("newPostsPub");
```
Isso sincroniza as 10 postagens mais recentes do Posts coleção no servidor (chamada posts no banco de dados) para o NewPosts coleção no cliente (chamada newposts no minimongo) usando a publicação/assinatura chamada newPostsPub . Observe que observeChanges difere de observe , que pode fazer várias outras coisas.

O código parece complicado, mas quando você retorna um cursor dentro de uma função de publicação, este é basicamente o código que o Meteor está gerando nos bastidores. Escrever publicações dessa forma oferece muito mais controle sobre o que é e o que não é enviado ao cliente. Tenha cuidado, pois você deve desativar manualmente observe manipula e marca quando a assinatura está pronta. Para obter mais informações, consulte a descrição de Matt Debergalis desse processo (no entanto, esse post está desatualizado). Claro, você pode combinar isso com as outras peças acima para potencialmente obter publicações muito sutis e complicadas.

Desculpe pelo ensaio :-) mas muitas pessoas ficam confusas sobre isso e eu pensei que seria útil descrever todos os casos.