Pourquoi une nouvelle promesse est-elle résolue plus tôt avec p.then (résoudre) qu'avec resolution (p)?

Une promesse est dans l'un de ces états:

-pending: état initial, ni rempli ni rejeté.
-fulfilled: signifie que l'opération s'est terminée avec succès.
-rejected: signifie que l'opération a échoué.

Une promesse en attente peut être remplie avec une valeur ou rejetée avec une raison (erreur). Lorsque l'une de ces options se produit, les gestionnaires associés mis en file d'attente par la méthode then d'une promesse sont appelés. Consultez ceci pour plus de détails

Maintenant, dans votre cas particulier, vous utilisez "Promise.resolve ()" probablement pour créer un nouvel objet de promesse mais ce qu'il fait, c'est qu'il crée une promesse déjà résolue sans valeur. Ainsi, votre objet de promesse "p" est résolu lors de sa création et le reste du code où vous le résolvez n'a littéralement aucun effet autre que de placer le "after: wait" dans une file d'attente de gestionnaire. Veuillez vous reporter à la Boucle d'événement avec zéro retard . La sortie des deux codes est différente en fonction du moment où le "console.log" est placé dans la pile d'appels et non de la manière dont vous l'écrivez.

La bonne façon de procéder peut être :

var promise1 = new Promise(function(resolve, reject) {
 setTimeout(function() {
  resolve('foo');
 }, 300);
});

promise1.then(function(value) {
 console.log(value);// expected output: "foo"
});

console.log(promise1);// expected output: [object Promise]

Dans vos deux réponses, la chaîne de promesse1 et la chaîne de promesse2 peuvent être entrelacées différemment. Mais, tick: a, tick: b, tick: c seront affichés dans cet ordre, tick: a avant tick: b, et tick: b avant tick: c. after: await peut être affiché n'importe où entre les deux.

Pour ce que fait votre code.

const p = Promise.resolve();

new Promise((resolve) => {
    // Here you are calling then which if promise p has been fulfilled
    // will call the callback you passed as an argument, which then
    // will eventually cause the outer promise to enter a state of
    // fulfilled triggering a call to the next 'then' provided in the part of the chain. 
    p.then(()=>resolve());
}).then(() => {
    console.log('after:await');
});


p.then(() => console.log('tick:a'))
    .then(() => console.log('tick:b'))
    .then(() => console.log('tick:c'));

// Returns a resolved promise object
// Which is equivalent to const p = new Promise(resolve => resolve());
const p = Promise.resolve();

// For Reference Call This Promise Chain 1

new Promise((resolve) => {
    // Fulfills the promise with the promise object p 
    resolve(p);  // (1)
}).then(() => {
    console.log('after:await');
});

For Reference Promise Chain 2
p.then(() => console.log('tick:a'))
    .then(() => console.log('tick:b'))
    .then(() => console.log('tick:c'));

La méthode Promise.resolve() renvoie un objet Promise qui est résolu avec une valeur donnée. Si la valeur est une promesse, cette promesse est retournée; si la valeur est un thenable (c'est-à-dire a une méthode "then" ), la promesse retournée "suivra" cette table alors en adoptant son état éventuel; sinon, la promesse retournée sera remplie avec la valeur. Cette fonction aplatit les couches imbriquées d'objets de type promesse (par exemple, une promesse qui se résout en une promesse qui se résout en quelque chose) en une seule couche.

Veuillez vous référer ici pour plus d'informations sur Promise.resolve ().

La différence dans la sortie de vos deux codes est due au fait que les gestionnaires puis sont appelés de manière asynchrone.

Lors de l'utilisation d'une promesse résolue, le bloc «alors» sera déclenché instantanément, mais ses gestionnaires seront déclenchés de manière asynchrone.

Veuillez vous référer ici pour plus d'informations sur le comportement des gestionnaires puis .

C'est en fait une question très intéressante, car les Promise / A + specs permettraient à la première version du code de produire le même résultat que la deuxième version du code.

On pourrait rejeter la question en disant que l'implémentation de Promise ne dit rien sur la façon dont résoudre (p) serait implémenté. Ceci est une déclaration vraie lorsque l'on regarde la spécification Promise / A +, citant sa préface:

la spécification principale Promises / A + ne traite pas de la façon de créer, de remplir ou de rejeter des promesses, ...

Mais la spécification EcmaScript pour Promises (section 25.4 ) est bien plus détaillée que la spécification Promise / A + et exige que des" travaux "soient ajoutés à l'arrière de la file d'attente des travaux correspondante - ce qui pour les règlements de promesse est le PromiseJobs file d'attente ( 25.4.1.3.2 et 8.4 ): cela détermine un ordre spécifique:

Files d'attente de travaux requises

[...]
PromiseJobs : Emplois qui sont des réponses au règlement d'une promesse

[...]

Les enregistrements PendingJob d'une seule file d'attente de travaux sont toujours lancés dans l'ordre FIFO

Il définit également que résoudre (p) - lorsque p est une table alors - mettra d'abord une tâche sur la file d'attente qui effectuera l'appel interne nécessaire de la méthode p. puis . Ceci n'est pas effectué immédiatement. Pour citer la note dans les spécifications EcmaScript à 25.4.2.2 a >:

Ce processus doit avoir lieu en tant que Job pour garantir que l'évaluation de la méthode then se produit après l'évaluation de tout code environnant.

Cette instruction est illustrée par l'ordre de sortie dans l'extrait suivant:

const p1 = Promise.resolve();
const p2 = new Promise((resolve) => resolve(p1));
const p3 = p2.then(() => console.log('after:await'));
const p4 = p1.then(() => console.log('tick:a'));
const p5 = p4.then(() => console.log('tick:b'))
const p6 = p5.then(() => console.log('tick:c'));

Lorsque nous utilisons l'appel de méthode p1.then (résoudre) au lieu de resolution (p1) , nous obtenons l'ordre inverse:

const p1 = Promise.resolve();

// Wrap the `p1.then` method, so we can log something to the console:
const origThen = p1.then;
p1.then = function(...args) {
    console.log("The p1.then method is called synchronously now");
    origThen.call(this, ...args);
};
const p2 = new Promise(resolve => {
    p1.then(resolve);
    console.log("Code that follows is executed synchronously, after p1.then is");
});

Votre code

Ce qui précède explique vraiment les différents ordres de sortie que vous obtenez. Voici comment la première version de code séquence les actions. Tout d'abord, permettez-moi de réécrire un peu ceci afin que la plupart des promesses impliquées aient un nom:

const p1 = Promise.resolve();

// Wrap the `p1.then` method, so we can log something to the console:
const origThen = p1.then;
p1.then = function(...args) {
    console.log("The p1.then method is called asynchronously when triggered by resolve(p1)");
    origThen.call(this, ...args);
};
const p2 = new Promise(resolve => {
    resolve(p1);
    console.log("Code that follows is executed synchronously, before p1.then is");
});

Maintenant, une fois le code principal synchrone exécuté jusqu'à la fin, seul p1 a un état résolu, et deux travaux sont présents dans la file d'attente des travaux (file d'attente des micro-tâches), un suite à résoudre (p1) et une seconde à cause de p1. puis:

1. Selon 25.4.2.2 , la méthode puis de p1 est appelée en lui passant la fonction interne [[résoudre]] liée à p2 . Les internes de p1.then savent que p1 est résolu et mettent encore un autre travail dans la file d'attente pour résoudre réellement p2 !

2. Le rappel avec "tick: a" est exécuté et la promesse p4 est marquée comme remplie, ajoutant un nouveau travail dans la file d'attente des travaux. Il y a maintenant 2 nouveaux travaux dans la file d'attente, qui sont traités dans l'ordre:

3. Le travail de l'étape 1 est exécuté: p2 est maintenant résolu. Cela signifie qu'un nouveau travail est mis en file d'attente pour appeler le ou les rappels puis correspondants

4. Le job de l'étape 2 est exécuté: le callback avec "tick: b" est exécuté

Ce n'est que plus tard que le job ajouté à l'étape 3 sera exécuté, ce qui appellera le callback avec "after: await".

Donc, en conclusion. Dans EcmaScript, un résoudre (p) , où p est un thenable implique un travail asynchrone, qui lui-même déclenche un autre travail asynchrone pour notifier l'exécution.

Le rappel puis , qui différencie la deuxième version de code, n'aura besoin que d'un un travail asynchrone pour être appelé, et ainsi il se produit avant la sortie de "tick: b".