javascript - node - meteor schema
Estrategias de publicación/suscripción de Meteor para colecciones únicas del lado del cliente (3)
Usando Meteor, me pregunto cómo manejar mejor las diferentes colecciones del lado del cliente que comparten la misma colección de bases de datos del lado del servidor. Considere el siguiente ejemplo: Tengo una colección de User , y en mi lado del cliente tengo una lista de usuarios que son amigos y tengo una función de búsqueda que realiza una consulta en toda la base de datos de usuarios, devolviendo una lista de nombres de usuario que coinciden con el consulta .
En el método Publicar del lado del servidor, tengo dos consultas contra la misma colección que devuelven diferentes conjuntos de documentos. ¿Deberían estos datos entrar en dos colecciones separadas en el lado del cliente? ¿O deberían todos los documentos del Usuario que coinciden con ambas consultas terminar en la misma colección? En este último caso, ¿podría duplicar el código utilizado tanto para la consulta del lado del servidor como para la del lado del cliente?
En el servidor:
Meteor.publish(''searchResults'', function(query){
var re = new RegExp(query, ''i'')
return Users.find({ ''name'' : {$regex: re}})
})
En el cliente:
Session.set(''searchQuery'', null)
Meteor.autosubscribe(function(){
Meteor.subscribe(''searchResults'', Session.get(''searchQuery''))
})
Template.search.events = {
''keyup #user-search'' : function(e){
Session.set(''searchQuery'', e.target.value)
}
}
_.extend(Template.search, {
searchResults: function() {
var re = new RegExp(Session.get(''searchQuery''), ''i'')
return Users.find({ ''name'' : {$regex: re}})
}
})
Esto parece una solución plausible, pero no óptima. ¿Qué ocurre si quiero crear una nueva colección del lado del cliente que consista en resultados de búsqueda de varias colecciones del lado del servidor?
En un área compartida:
function getSearchUsers(query) {
var re = new RegExp(query, "i");
return Users.find({name: {$regex: re}});
}
function getFriendUsers() {
return Users.find({friend: true}); // or however you want this to work
}
En el servidor:
Meteor.publish("searchUsers", getSearchUsers);
Meteor.publish("friendUsers", getFriendUsers);
En el cliente:
Template.search.onCreated(function () {
var self = this;
self.autorun(function () {
self.subscribe("searchUsers", Session.get("searchQuery"));
});
});
Template.friends.onCreated(function () {
this.subscribe("friendUsers");
});
Template.search.helpers({
searchResults: function () {
return getSearchUsers(Session.get("searchQuery"));
}
});
Template.friends.helpers({
results: function () {
return getFriendUsers();
}
});
El punto clave de esto es que lo que ocurre detrás de escena cuando los datos se transfieren por cable no es obvio. Meteor parece combinar los registros que se emparejaron en las diversas consultas en el servidor y enviarlo al cliente. Luego, el cliente debe ejecutar la misma consulta para separarlos.
Por ejemplo, supongamos que tiene 20 registros en una colección del lado del servidor. A continuación, tiene dos publicaciones: la primera coincide con 5 registros, la segunda coincide con 6, de los cuales 2 son iguales. Meteor enviará 9 registros. En el cliente, luego ejecuta exactamente las mismas consultas que realizó en el servidor y debe terminar con 5 y 6 registros respectivamente.
Llego un poco tarde a la fiesta, pero hay una forma de tener colecciones separadas en el cliente para subconjuntos de una colección de servidores. En este ejemplo, tengo una colección de servidores llamada entities que contiene información sobre polygons y rectangles .
Código compartido (carpeta lib):
// main collection (in this example only needed on the server
Entities = new Meteor.Collection(''entities'');
// partial collections
RectEntities = new Mongo.Collection(''rectEntities'');
PolyEntities = new Mongo.Collection(''polyEntities'');
Codigo del cliente:
// this will fill your collections with entries from the Entities collection
Meteor.subscribe(''rectEntities'');
Meteor.subscribe(''polyEntities'');
Recuerde que el nombre de la suscripción debe coincidir con el nombre de la publicación (pero no el nombre de la colección en sí)
Código del servidor:
Meteor.publish(''rectEntities'', function(){
Mongo.Collection._publishCursor( Entities.find({shapeType: ''rectangle''}), this, ''rectEntities'');
this.ready();
});
Meteor.publish(''polyEntities'', function(){
Mongo.Collection._publishCursor( Entities.find({shapeType: ''polygon''}), this, ''polyEntities'');
this.ready();
});
¡Gracias a user728291 por la solución mucho más simple usando _publishCursor() !
El tercer argumento de la función _publishCursor() es el nombre de su nueva colección.
Fuente: http://docs.meteor.com/#/full/publish_added
usar el paquete publish-composite
// main collection
Entities = new Meteor.Collection(''entities'');
// partial collections only client side
RectEntities = new Mongo.Collection(''rectEntities'');
PolyEntities = new Mongo.Collection(''polyEntities'');
// server publish
Meteor.publishComposite("rectEntities", function(someParameter) {
return {
collectionName:''rectEntities'',
find: function() {
return Entities.find({shapeType: ''rectangle''});
},
children: []
}
});
Meteor.publishComposite("polyEntities", {
collectionName:''polyEntities'',
find: function() {
return Entities.find({shapeType: ''polygon''});
},
children: []
});