javascript promise es6-promise

javascript - ¿La devolución de llamada del constructor Promise se ejecuta de forma asincrónica?



es6-promise (2)

Supongamos que tengo este código

function y(resolve, reject) { console.log("Result"); resolve(); } var promise = new Promise(y);

Lo que quiero saber es si la función y se ejecutará de forma asincrónica o no.


Depende de la implementación de la promesa. Si verificamos las especificaciones . Puede encontrar la especificación final here : dado que esta respuesta se escribió originalmente, se ha finalizado.

Aquí está el extracto relevante (puede encontrar la fuente original aquí )

  1. Que la finalización sea Call (ejecutor, indefinido, «resolvingFunctions. [[Resolve]], resolvingFunctions. [[Reject]]»).
  2. Si la finalización es abrupta, entonces
    • Deje que el estado sea Llamada (resolvingFunctions. [[Rechazar]], indefinido, «finalización. [[Valor]]»).
    • ReturnIfAbrupt (estado).

El estándar ES6 indica que el cumplimiento de una promesa siempre es asíncrono (consulte la sección 25.4.5.3, Promise.prototype.then y la sección adjunta 25.4.5.3.1, PerformPromiseThen ). He colocado el material relevante a continuación.

Realizar Promesa Luego

  1. De lo contrario, si el valor de la ranura interna [[PromiseState]] de la promesa se "cumple",
    • Deje que el valor sea el valor de la ranura interna [[PromiseResult]] de la promesa.
    • Realice EnqueueJob ("PromiseJobs", PromiseReactionJob, «satisfReaction, value»).
  2. De lo contrario, si el valor de la ranura interna [[PromiseState]] de la promesa se "rechaza",
    • Deje que la razón sea el valor de la ranura interna de [[PromiseResult]] de promesa.
    • Realice EnqueueJob ("PromiseJobs", PromiseReactionJob, «acceptReaction, reason»).

TLDR : la función pasada a la promesa se ejecuta sincrónicamente, pero las llamadas posteriores siempre se ejecutan de forma asincrónica.


La otra respuesta prueba esto, pero déjenme hablar sobre el razonamiento:

Constructor de promesas

La devolución de llamada del constructor de promesa (como se especifica en la especificación ES6 o en la implementación de las bibliotecas de especificaciones del constructor) siempre se ejecutará de forma síncrona; esto es para extraer una forma diferida (construcción de promesa anterior) en caso de que necesite tener acceso para resolve devolución de llamada:

var r; var p new Promise(function(resolve, reject){ r = resolve; }); // use r here, for example arr.push(r);

then devoluciones de llamada

then siempre se ejecutará de forma asíncrona, prácticamente todas las implementaciones de promesa convencionales (Native, bluebird, $ q, Q, when, rsvp, promise, jQuery (a partir de 3.0), etc.) así como las promesas nativas implementan (o implementan un superconjunto de, con más restricciones) Promesas / A + .

Esta es exactamente la razón por la que Promises / A + se creó a partir de Promises / A. Se conservarán las garantías asincrónicas y no se lanzará Zalgo. (También vea esta publicación ).

El hecho de que esto suceda (garantía asincrónica) es completamente intencional y evita activamente las condiciones de carrera . El código dentro y fuera de then siempre se ejecutará en el mismo orden.

Aquí está la cita relevante:

onFulfilled u onRejected no se debe onRejected hasta que la pila de contexto de ejecución contenga solo código de plataforma. [3.1]