Meteor.méthodes renvoie undefined

C'est un comportement parfaitement normal: serveur d'appels de méthode dans le Météore sont documenté asynchrone :

Sur le client, si vous ne passez pas un rappel, et vous n'êtes pas à l'intérieur d'un tampon, l'appel sera de retour indéfini, et vous n'aurez aucun moyen d'obtenir la valeur de retour de la méthode.

Cela signifie que lorsque vous demandez une Meteor.call méthode à exécuter à distance sur le serveur, les locaux de l'appel de méthode est non bloquant et retourne undefined immédiatement.
Lorsque la méthode a été appelée sur le serveur, il envoie le résultat de manière asynchrone pour le client, de sorte que vous devez le récupérer à l'aide de la fonction de rappel du motif :

Meteor.call("myMethod", arguments..., function(error, result){
  if(error){
    console.log(error.reason);
    return;
  }
  //do something with result
});

Anonyme fonction de rappel est appelée sur le client dès que le serveur de méthode résultat est envoyé au client.

Il y a un autre subtile fonctionnalité dans le Météore invalider ce que je viens de dire : la compensation de latence et de méthodes de talons.
Dans le cas où le serveur d'appel de méthode peut être SIMULÉ correctement dans le client et donc exécutée immédiatement, sans un aller-retour vers le serveur, vous pouvez définir ce qu'on appelle une méthode de stub (ou simulation).

Une utilisation de ce comportement est d'insérer immédiatement dans le local (côté client réplication sous-ensemble) de la base de données de l'utilisateur le contenu affiché (un commentaire sous un article de blog par exemple) : les données et la logique est disponible et il est logique de simuler côté serveur d'insertion.
Ce qui se passe ensuite est ce que l'utilisateur voit la page web de mises à jour dès qu'il a soumis son contenu, même si le serveur n'a pas pris connaissance de ces changements. (ceci est un exemple de la façon dont la compensation de latence est mis en œuvre dans le Météore).

Bien sûr, le serveur qui a le dernier mots sur ce qui est finalement inséré dans la base de données, cela signifie que lorsque le côté serveur twin exécution de la méthode, ses actions auront préséance et de remplacer ce qui a été inséré dans la base de données locale.

Pour définir une telle méthode stub, vous avez juste à définir le même serveur, le nom de la méthode sur le code client.
Si la déclaration de la méthode est définie dans le code partagé (disponible à la fois pour le client et le serveur), vous pouvez tester si l'appel de méthode est en fait une simulation en cochant la isSimulation propriété :

Meteor.methods({
    myMethod: function(arguments...){
        if(this.isSimulation){
            //called from the client
        }
    }
});

Mise à JOUR 26/11/2014 : @steph643 commenté sur la façon dont la dernière partie de ma réponse précédente a été fait, le problème, ici, c'est une correction.

Noter que sur le serveur d'appels de méthode peut toujours être invoquée à l'aide de la machine synchrone syntaxe parce que l'environnement de serveur fournit suffisamment de mécanisme de blocage (fibres).

Sur le client, cependant, si vous retourner quelque chose à partir d'une méthode de stub, elle peut être exécutée de manière synchrone seulement si vous êtes à l'intérieur d'un autre stub et vous pouvez récupérer le résultat dans une façon synchrone, c'est à dire

Meteor.methods({
  intermediateMethod: function(){
    return " WORLD";
  },
  method: function(){
    var result = "HELLO";
    result += intermediateResult;
    var intermediateResult = Meteor.call("intermediateMethod");
    return result;
  }
});

Ce comportement est un peu bizarre, considérant que Mongo les opérations de collecte (insert/update/delete) sont mis en œuvre comme Meteor méthodes et leurs clients sont les versions de la mise en œuvre valide talons (modification de l'minimongo répliqué locale de la base de données sous-ensemble) qui peut être exécuté de façon synchrone.