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í )
- Que la finalización sea Call (ejecutor, indefinido, «resolvingFunctions. [[Resolve]], resolvingFunctions. [[Reject]]»).
-
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
-
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»).
-
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
uonRejected
no se debeonRejected
hasta que la pila de contexto de ejecución contenga solo código de plataforma. [3.1]