1

Scénario:Appel Meteor.call() et attendre à l'intérieur `avant: insert` crochet

Je suis en train d'insérer un Appointment pour un client en utilisant autoform uniquement lorsque les dates ne se heurtent pas. ci-dessous est le code pour obtenir une idée brève.

{{#autoForm id='insertAppointmentForm' collection=appointment type="insert" 
       doc=this validation="browser"}} 
    <fieldset> 
     <!-- All fields here --> 
    </fieldset> 
    <button type="submit" class="btnn"> Create </button> 
{{/autoForm}} 

J'ajoute crochet au-dessus du code AutoForm insert comme ci-dessous,

var hooksObject = { 
    before: { 
    insert: function(doc) { 
     console.log(doc); 
     Meteor.call('checkAppointmentClash', doc, function(error, response){ 
      if(error){ } else { } 
     }); 
     return doc; // I want to wait here 
    } 
    }, 
    onSuccess: function(formType, result) {}, 
    onError: function(formType, error) {} 
}; 

AutoForm.addHooks(['insertAppointmentForm'], hooksObject, true); 

Problème:

Le problème ici est que la forme se soumis, même si error retourné de Meteor.call() et inserts le document à la base de données. Je sais que le Meteor.call() est un appel asynchrone, mais comment puis-je attendre le résultat? seulement alors je veux continuer à soumettre si aucune erreur.

Répondre

2

Les hameçons peuvent fonctionner de manière asynchrone. À partir de documentation:

Ces fonctions peuvent effectuer des tâches asynchrones si nécessaire. Si l'asynchronicité n'est pas nécessaire, renvoyez simplement le document ou le modificateur, ou renvoyez false pour annuler la soumission. Si vous ne renvoyez rien, vous devez appeler le this.result() et lui transmettre le document ou le modificateur, ou false pour annuler la soumission.

Ainsi, le code pourrait ressembler à ceci:

insert: function(doc) { 
    // note using() => {} to bind `this` context 
    Meteor.call('checkAppointmentClash', doc, (error, response) => { 
    if(error) { 
     this.result(false); 
    } else { 
     this.result(doc); 
    } 
    }); 
    // return nothing 
} 

Bien que, je vous suggère de repenser votre flux. Il est faux de vérifier pour "clash" dans un crochet. Vous devriez le faire sur l'étape "Données entrées par l'utilisateur" et désactiver/activer le bouton "Soumettre" en conséquence.

+0

La vérification du conflit sur les "données entrées par l'utilisateur" n'est pas une solution réalisable en termes de performances (même si j'utilise '_.debounce' pour contrôler les requêtes). Le vérifier au crochet fait juste un appel au serveur et il correspond à mes besoins d'application. –

+0

@AnkurSoni Je ne voulais pas dire "vérifier en continu", une seule fois, lorsque l'utilisateur a déjà entré des données sur le terrain. Bien sûr, cela n'aurait pas de sens, si vous avez besoin de champs _all_ pour vérifier le conflit :) – Styx