Si je veux obtenir le résultat d'une promesse depuis ma console de test de nœuds, comment puis-je le faire?
Par exemple.
let promise = new Promise(() => {
console.log('my promise');
}
promise.then(() => { console.log('resolved') })
// returns a Promise {<pending>}
await promise.then(() => { console.log('resolved') })
// still returns just a Promise
(async () => {
await promise
})()
// still returns ... just a Promise
En fin de compte, je suis en essayant de tester les résultats des promesses (requêtes de base de données) à partir de ma console de nœud à un point d'arrêt, et je ne cesse de recevoir des promesses.
MISE À JOUR - Je suppose que c'est plus compliqué que je pensais. Parce que je sais qu'on a su répondre.
Je comprends comment obtenir les résultats d'une promesse dans un environnement régulier. Je parle d'obtenir des résultats à un point d'arrêt lors du débogage d'une application Node. Pour vous connecter à la console dont je parle, veuillez suivre ces instructions: https://medium.com/@paul_irish/ debugging-node-js-nightlies-with-chrome-devtools-7c4a1b95ae27
Depuis la console de DevTools, les promesses continuent de renvoyer Promise {}. Je ne sais pas s'il est possible d'obtenir la valeur de la promesse, mais si quelqu'un sait l'un ou l'autre, faites-le moi savoir.
3 Réponses :
lorsque vous créez un objet de promesse, vous devez utiliser cette syntaxe
promise.then(value => console.log(value))
l'exécuteur est une fonction avec cette signature
let promise = new Promise( resolve => {
resolve("my promise")
})
Lorsque nous revenez à votre exemple spécifique, vous pouvez le définir comme
function(resolutionFunc, rejectionFunc){
// typically, some asynchronous operation.
}
Remarque Je n'ai pas ajouté la fonction de rejet
alors vous peut faire
var promiseObj = new Promise(executor);
vous pouvez trouver une description détaillée ici
votre explication est correcte car la promesse est résolue immédiatement dans ce cas, mais il y a un comportement différent sur la console du nœud et la console du navigateur. La console du nœud indique toujours que la promesse est en attente tandis que la console du navigateur indique qu'elle est résolue.
^ merci. Je comprends exactement que la promesse fonctionnerait correctement si je l'utilisais dans une application ou dans la console du navigateur. Mais pas dans la console lors du débogage d'une application (c'est-à-dire à un point d'arrêt) montre ici comment se connecter: medium.com/@paul_irish/...
La position de vos points d'arrêt est importante, et le comportement sera le même dans le débogueur Node.js et le débogueur du navigateur.
Dans ce qui suit, j'utilise des étiquettes comme
let p1 = new Promise((resolve) => resolve('result 1'))
const p2 = p1.then(() => 'result 2')
p2.then(() => {
// here `p2` === `Promise {<resolved>: "result 2"}`
console.log(p2)
})
À p1 ne sera pas déclaré car la fonction exécuteur s'exécute de manière synchrone, et le le processus de déclaration de variable n'est pas encore terminé.
À p1 sera une promesse tenue ( Promise {), résolu avec la valeur 'result 1' car la résolution a été appelée dans la fonction exécuteur.
Le prochain point d'arrêt à être l'appel sera
À , p2 sera une promesse en attente ( Promise {) car la promesse a été configurée avec un .puis qui n'a pas encore eu l'occasion de s'exécuter. .then les rappels sont exécutés sur des microtâches asynchrones pour donner au programmeur la possibilité de configurer une chaîne de promesse avant son exécution. Après tout, les promesses sont conçues pour être utilisées avec un comportement asynchrone.
Lors de la prochaine microtâche disponible, . puis le rappel est exécuté. À p1 et p2 restent inchangées. p1 a été rempli plus tôt et ne changera pas. L'état de p2 est inchangé car le .then avec lequel il a été configuré n'a pas encore terminé son exécution.
Afin d'observer p2 dans son état rempli, vous devez ajouter un point d'arrêt à une extension de la chaîne de promesse.
1. const p1 = new Promise((resolve) => <b1> resolve('result 1'))
2. <b2>
3. const p2 = p1.then(() => <b3> 'result 2')
4. <b4>
Comme je l'ai déjà expliqué. Je comprends que c'est ainsi que les promesses fonctionneraient dans un environnement régulier. Là où j'essaie d'obtenir les résultats d'une promesse se trouvent à un point d'arrêt lors du débogage de mon application Node. Donc, la console dans laquelle je serais en train de courir serait là si vous suivez cet environnement: medium.com/@paul_irish/... Je viens d'essayer votre code, et une fois de plus il renvoie "Promise {pending}"
Que vous exécutiez dans le débogueur de nœud ou dans le navigateur, le comportement sera le même. Le positionnement de vos points d'arrêt est important. Comme je l'ai dit ci-dessus: " notez comment vous devez toujours garder votre code dans la chaîne des fonctions de rappel. C'est parce que le flux de contrôle asynchrone traverse ces rappels. "
D'après les commentaires, je suppose qu'il est impossible d'obtenir des résultats d'appels asynchrones à un point d'arrêt en JavaScript.
Si quelqu'un vient ici et veut un moyen de pouvoir effectuer des requêtes DB à partir de la console Node (REPL) comme je le recherchais, je vous recommande d'aller ici:
https://medium.com/ @ vemarav / build-rails-like-console-in-nodejs-repl-2459fb5d387b
Celui avec
awaitnon encapsulé dans une fonction asynchrone supplémentaire n'aurait pas dû vous donner de promesse. Cela aurait dû être la valeur ou une erreur de syntaxe. Pouvez-vous en montrer une capture d'écran? (Aussi, attribuer une variable aveclet x; promise.then (y => {x = y;})ou se connecter avecpromise.then (console.log)sont bons à la rigueur.)(Tout cela suppose que votre vraie promesse jamais se résout. Votre exemple ne le fait pas.)
J'ai changé la promesse d'avoir "résoudre ('ma promesse')" et elle renvoie toujours juste "Promise {}"
Qu'est-ce que " ma console de test de nœuds "? Utilisez-vous le nœud REPL?
@Bergi si vous suivez ici, cela vous montre ce que je veux dire: medium.com/@paul_irish/...
< / i> alors je doute que vous puissiez jamais récupérer le résultat asynchrone, car la boucle d'événements est mise en pause et ne peut pas passer au tick suivant. Mais de toute façon, vous ne devriez pas appeler du code asynchrone à partir d'un point d'arrêt - pourquoi feriez-vous cela?
Ah je vois ça a du sens. J'essaie juste de faire des requêtes DB pendant les tests. J'ai trouvé une solution de contournement où j'ai une console asynchrone en utilisant le drapeau de Node ("--experimental-repl-await") où je peux faire des requêtes DB. Mais merci pour l'aide!