Le rappel d'une promesse peut-il être retardé ?

Question

Lorsque nous concevons une fonction qui renvoie une promesse, comme ceci :

function getAsyncResult() {

    // synchronous code 1

    return new Promise(function (resolve, reject) {

        // synchronous code 2

        // asynchronous code

    });
}

Cela fait-il une différence que nous placions notre code synchrone avant de créer la promesse résultante ou au début du callback ?

En d'autres termes, est-il possible qu'il y ait un décalage entre new Promise(...) et l'appel à sa fonction de rappel ?

Pour reformuler la question, est-il possible que synchronous code 2 s'exécute toujours avec un certain retard, et non pas immédiatement après synchronous code 1 ?

P.S. Je suis surtout intéressé par cette question en ce qui concerne ES6 Promise et Bluebird, bien qu'il serait intéressant de savoir si d'autres bibliothèques majeures le font différemment.

Answer 1

Selon la Spécification ES6 Ce qu'il appelle l'"exécuteur" (le rappel passé au constructeur) est exécuté immédiatement. Par conséquent, une implémentation qui ne se comporterait pas de cette manière ne serait pas conforme, et vous pouvez compter sur elle.

Par conséquent, vous pouvez placer votre code soit avant d'appeler le constructeur, soit dans l'exécuteur, et cela ne devrait pas faire de différence en termes de temps d'exécution (bien que, comme une autre réponse l'a souligné, il y aura des différences en termes de ce qui se passe si le code se lance).

D'autres implémentations peuvent varier, et certaines peuvent même ne pas fournir le constructeur de promesses de style ES6, choisissant de construire les promesses d'une autre manière.

Answer 2

Avec ES6/compliant Promise, synchronous code 1 y synchronous code 2 s'exécuteront (sauf erreur non corrigée) dans cet ordre, dans le même tour d'événement. Cependant, il y a une différence :

• code synchrone 1 : Une erreur non prise sera affichée (dans la console) de la manière habituelle.
• code synchrone 2 : Une erreur non corrigée entraînera le rejet de la promesse.

asynchronous code n'existe pas vraiment, du moins pas à ce niveau ; seules les fonctions internes peuvent être exécutées ultérieurement. Vous pouvez appeler une fonction qui renvoie une promesse. Une telle promesse, p peut être utilisé pour résoudre/rejeter la promesse extérieure (celle qui est en cours de construction), sans utiliser la fonction .then() en utilisant la syntaxe resolve(p) de la même manière que vous écririez resolve(value) .

Avec un resolve(p) en place, si p devait rejeter, alors la Promesse extérieure rejetterait également, même si sa propre révélation de l'existence de la reject n'est pas appelée explicitement par le code utilisateur.

Answer 3

Promise est inventé pour éviter le phénomène connu sous le nom de "callback hell". Ce n'est rien d'autre qu'un système structuré dans lequel vous pouvez enregistrer vos callbacks plus proprement qu'en créant un nexus en plein milieu de votre code. A part cela, il n'y a pas de magie asynchrone qui se passe dans Promise .

Voyons cela

return new Promise(function (resolve, reject) {

        // synchronous code 2

        // asynchronous code

    });

Vous renvoyez une promesse qui permet d'accrocher deux fonctions (resolve et reject) qui seront appelées (par vous) après une opération asynchrone. qui sera également initiée par vous à l'intérieur de la fonction de promesse.

Il peut s'agir d'une entrée de l'utilisateur, d'une requête ajax, etc., dont on ne sait pas vraiment quand elle va se produire.

L'exécution du code à l'intérieur de votre constructeur de promesses se produit immédiatement, ce qui vous permet de démarrer votre processus asynchrone ( synchronous code 2 ) avant d'atteindre toute autre ligne de code.

Si vous avez vraiment besoin de séparer l'exécution linéaire de synchronous code 2 y asynchronous code Vous pouvez probablement placer ce dernier à l'intérieur d'un setTimeout fonction. De cette manière, elle est exécutée lorsque le navigateur obtient le prochain espace de respiration. Mais ce type de pratique est un peu biaisé face au concept de Promise .

Answer 4

Il n'y aura absolument aucun retard : le code sera exécuté dans la même pile, de manière synchrone.

A titre de preuve, vous pouvez exécuter cet extrait :

console.log('sync code before promise');

new Promise(function (resolve, reject) {
  console.log('sync code in promise');
});

console.log('sync code after promise');

Le résultat est avant -> en -> après