javascript - learn - meteor java script

Cuándo usar Meteor.methods y utilizar stubs

Question

Usando Meteor, intento entender cuándo usar los Meteor.methods() lado del Meteor.methods() mientras sigo conservando las actualizaciones de UI instantáneas.

Del tutorial introductorio de Andrew Scala, afirma que Meteor.methods() debe usar cuando desee actualizar y modificar sus documentos de base de datos:

La idea es que defina todas las funciones del servidor que hacen cosas peligrosas, como modificar y actualizar datos, y luego permita que el cliente llame a esas funciones y obtenga valores devueltos, como las funciones normales. El cliente nunca ve la implementación y no modifica personalmente los datos. El servidor hace todo el trabajo.

Y siguiendo este consejo, implementé esto en mi código:

Lado del servidor:

Meteor.methods({
addMovie: function(data) {
var movie = Movies.insert({name: data});
return movie;
},
...

Lado del cliente:

Template.movies.events = ({
''click #add-movie'': function(e) {
var name = document.getElementById(''movie-name'').value;
Meteor.call(''addMovie'', name);
return false;
},
...

Esto funciona, pero es lento. La interfaz de usuario no se actualiza al instante como lo haría si Movies.insert() en el lado del cliente. Los docs indican que, para rectificar el problema, puedes crear stubs en el lado del cliente:

Los métodos de llamada en el cliente definen funciones de código auxiliar asociadas con los métodos del servidor del mismo nombre. No es necesario que defina un código auxiliar para su método si no lo desea. En ese caso, las llamadas a métodos son como las llamadas a procedimientos remotos en otros sistemas, y tendrá que esperar los resultados del servidor.

Pero, ¿cómo deberían ser estos talones? ¿Debería básicamente tener el mismo aspecto que el método del lado del servidor? Si es así, ¿cuál es el punto? Estoy buscando una explicación más completa del uso y el propósito de Meteor.methods() , el punto / uso de stubs, y su implementación.

EDITAR: David Greenspan ha ayudado a aclarar el uso de Meteor.methods () y trozos de meteor-talk .

Answer 1

Como dijo Daniel, puede definir un método en un archivo que no está en los directorios del cliente o del servidor y está disponible en ambos lados. También puede usar isSimulation boolean value para realizar comprobaciones adicionales. Por ejemplo, puede verse algo como esto:

Meteor.methods({
addMovie: function (movieData) {
if (!this.isSimulation) {
check(movieData, someAdditionaCheckinFunc);
}
Movies.insert(movieData);
}
})

Por lo tanto, el código en la rama condicional se ejecutará solo en el servidor.

Answer 2

En breve :

Defina algunos métodos (Meteor.methods) en los archivos enviados al servidor que harán el trabajo real en el servidor, defina algunos métodos (Meteor.methods) en los archivos enviados al cliente para obtener un comportamiento ''instantáneo'' en el cliente ( como un indicador de carga) hasta que el servidor devuelve los cambios resultantes al cliente

Aquí está la publicación original de David:

Hola Ben,

En principio, un método puede realizar acciones completamente diferentes en el cliente y el servidor, por ejemplo, mostrar un indicador de carga en el cliente y hablar con una API remota en el servidor. Las llamadas a Meteor.methods en el cliente definen el comportamiento del cliente, y las llamadas a Meteor.methods en el servidor definen el comportamiento del servidor.

Para los métodos que operan en la base de datos, a menudo la misma implementación servirá para ambos. La versión del cliente afecta a la base de datos del lado del cliente (la "memoria caché" del lado del navegador de los documentos suscritos) y la versión del lado del servidor afecta a la base de datos real. Cuando el cliente escucha, se "ajusta" al resultado de las mutaciones del lado del servidor; las mutaciones de la base de datos del lado del cliente se descartan (o deshacen, dependiendo de cómo piense al respecto). Si un método del lado del cliente llama a otros métodos, estas llamadas secundarias no están remotas al servidor. La versión del lado del servidor llamará a los mismos métodos en el servidor, o no, según lo crea conveniente.

Por lo tanto, cualquier método del lado del cliente que usted proporcione es simplemente una "simulación" y no tiene que ser preciso (puede no serlo). La esperanza es que normalmente obtenga la impl de simulación de forma gratuita porque es lo mismo que la impl del servidor.

¿Responde esto a tu pregunta?

- David

Answer 3

Si define un método en un archivo compartido por el cliente / servidor como /collections ¿no sería accesible para ambos y se sincronizaría automáticamente?

Asi que:

/collections/houses.js

Meteor.methods({
callHouse: function () {
if (currentGame.isInProgress) {
currentGame.winner = this.userId;
currentGame.end();
}
}
});

Esto estará disponible tanto para el cliente como para el servidor. Si no pasa, el servidor rechazará automáticamente la actualización / revertir del cliente.

Answer 4

aquí hay otro ejemplo.

diga que está escribiendo un juego de bingo y que hace clic en el botón para llamar a "casa". En el evento de clic puede llamar a un método, por ejemplo

Method.call("callHouse");

esto invocará el método del servidor:

// on the server
Meteor.methods({
callHouse: function () {
if (currentGame.isInProgress) {
currentGame.winner = this.userId;
currentGame.end();
}
}
});

si eres el primero en llamar "casa", el método te marcará como ganador. Sin embargo, imaginemos que el método es extremadamente lento y tu aplicación cliente está esperando ... estás 99% seguro de que el servidor confirmará que eres el ganador: solo desea actualizar la pantalla del usuario sin esperar ... en este caso, implemente un talón del lado del cliente:

// on the client
Meteor.methods({
callHouse: function () {
currentGame.winner = Meteor.userId();
// add any other side-effects you expect to occur here
}
});

cuando el resultado del servidor retorna, si los datos devueltos son diferentes a los establecidos en el código auxiliar, lo corregirá y actualizará la pantalla en consecuencia.