Comment faire attendre une fonction jusqu'à ce qu'un callback ait été appelé en utilisant node.js

Question

J'ai une fonction simplifiée qui ressemble à ceci :

function(query) {
  myApi.exec('SomeCommand', function(response) {
    return response;
  });
}

En gros, je veux qu'il appelle myApi.exec et renvoie la réponse qui est donnée dans le lambda de rappel. Cependant, le code ci-dessus ne fonctionne pas et renvoie simplement immédiatement.

Pour une tentative très artisanale, j'ai essayé ce qui suit qui n'a pas fonctionné, mais au moins vous avez l'idée de ce que j'essaie de faire :

function(query) {
  var r;
  myApi.exec('SomeCommand', function(response) {
    r = response;
  });
  while (!r) {}
  return r;
}

En gros, quelle est la meilleure façon de procéder pour un nœud.js/événement ? Je veux que ma fonction attende que le callback soit appelé, puis retourne la valeur qui lui a été passée.

Answer 1

La "bonne méthode node.js/event driven" pour faire cela est de ne pas attendre .

Comme presque tout lorsque vous travaillez avec des systèmes événementiels comme node, votre fonction doit accepter un paramètre de rappel qui sera invoqué lorsque le calcul sera terminé. L'appelant ne doit pas attendre que la valeur soit "retournée" au sens normal, mais plutôt envoyer la routine qui traitera la valeur résultante :

function(query, callback) {
  myApi.exec('SomeCommand', function(response) {
    // other stuff here...
    // bla bla..
    callback(response); // this will "return" your value to the original caller
  });
}

Donc tu ne l'utilises pas comme ça :

var returnValue = myFunction(query);

Mais comme ça :

myFunction(query, function(returnValue) {
  // use the return value here instead of like a regular (non-evented) return value
});

Answer 2

Vérifiez ça : https://github.com/luciotato/waitfor-ES6

votre code avec wait.for : (nécessite des générateurs, drapeau --harmony)

function* (query) {
  var r = yield wait.for( myApi.exec, 'SomeCommand');
  return r;
}

Answer 3

Note : Cette réponse ne devrait probablement pas être utilisée dans un code de production. C'est un hack et vous devez connaître les implications.

Il y a le uvrun (mis à jour pour les nouvelles versions de Nodejs) aquí ) où vous pouvez exécuter un tour de boucle unique de la boucle d'événement principale de la libuv (qui est la boucle principale de Nodejs).

Votre code ressemblerait à ceci :

function(query) {
  var r;
  myApi.exec('SomeCommand', function(response) {
    r = response;
  });
  var uvrun = require("uvrun");
  while (!r)
    uvrun.runOnce();
  return r;
}

(Vous pouvez aussi utiliser uvrun.runNoWait() . Cela pourrait éviter certains problèmes de blocage, mais prend 100% du CPU).

Notez que cette approche invalide en quelque sorte l'objectif de Nodejs, à savoir que tout soit asynchrone et non bloquant. De plus, cela pourrait augmenter considérablement la profondeur de votre pile d'appels, et vous pourriez vous retrouver avec des débordements de pile. Si vous exécutez une telle fonction de manière récursive, vous aurez certainement des problèmes.

Voir les autres réponses sur la façon de reconcevoir votre code pour le faire "correctement".

Cette solution n'est probablement utile que lorsque vous effectuez des tests et que vous voulez surtout avoir un code synchronisé et sériel.

Answer 4

Supposons que vous ayez une fonction :

var fetchPage(page, callback) {
   ....
   request(uri, function (error, response, body) {
        ....
        if (something_good) {
          callback(true, page+1);
        } else {
          callback(false);
        }
        .....
   });

};

vous pouvez utiliser des callbacks comme ceci :

fetchPage(1, x = function(next, page) {
if (next) {
    console.log("^^^ CALLBACK -->  fetchPage: " + page);
    fetchPage(page, x);
}
});

Answer 5

Cela va à l'encontre du but de l'IO non-bloquante -- vous la bloquez alors qu'elle n'a pas besoin d'être bloquée. :)

Vous devriez imbriquer vos callbacks au lieu de forcer node.js à attendre, ou appeler un autre callback à l'intérieur du callback où vous avez besoin du résultat de r .

Il y a de fortes chances que si vous devez forcer le blocage, c'est que vous pensez mal à votre architecture.