Las promesas simplifican los cálculos diferidos y asíncronos. Una promesa representa una operación que aún no se completó.
Desarrolladores, prepárense para un momento clave en la historia del desarrollo web.
[Drumroll begins]
¡Llegaron las promesas a JavaScript!
[Fireworks explode, glittery paper rains from above, the crowd goes wild]
En este momento, te encuentras en una de estas categorías:
- Las personas te aplauden, pero no sabes cuál es el motivo de tanto entusiasmo. Tal vez ni siquiera sepas qué es una “promesa”. Te encogerías de hombros, pero el peso del papel con brillantina te abruma. Si es así, no te preocupes. Me llevó mucho tiempo descubrir por qué debería preocuparme por esto. Lo mejor es comenzar desde el principio.
- Golpea el aire. Ya era hora, ¿no? Ya usaste estas promesas antes, pero te molesta que todas las implementaciones tengan una API ligeramente diferente. ¿Cuál es la API de la versión oficial de JavaScript? Te recomendamos que comiences con la terminología.
- Ya lo sabías y te burlas de quienes saltan como si fuera una novedad. Tómate un momento para disfrutar de tu superioridad y, luego, dirígete directamente a la referencia de la API.
Compatibilidad con navegadores y polyfill
Para que los navegadores que no tienen una implementación completa de promesas cumplan con las especificaciones o agreguen promesas a otros navegadores y Node.js, consulta el polyfill (2 K comprimidos con gzip).
¿Por qué tanto alboroto?
JavaScript es de un solo subproceso, lo que significa que dos fragmentos de secuencia de comandos no se pueden ejecutar al mismo tiempo, sino uno tras otro. En los navegadores, JavaScript comparte un subproceso con una gran cantidad de otros elementos que difieren de un navegador a otro. Sin embargo, por lo general, JavaScript se encuentra en la misma cola que la pintura, la actualización de los estilos y el control de las acciones del usuario (como destacar texto y, también, interactuar con los controles de formulario). La actividad en uno de estos elementos retrasa a los demás.
Como ser humano, tienes varios subprocesos. Puedes escribir con varios dedos, conducir y mantener una conversación al mismo tiempo. La única función de bloqueo con la que tenemos que lidiar es el estornudo, en el que se debe suspender toda la actividad actual durante el estornudo. Eso es bastante molesto, sobre todo cuando estás conduciendo y tratando de mantener una conversación. No querrás escribir código que sea inestable.
Es probable que hayas usado eventos y devoluciones de llamada para evitar este problema. Estos son los eventos:
var img1 = document.querySelector('.img-1');
img1.addEventListener('load', function() {
// woo yey image loaded
});
img1.addEventListener('error', function() {
// argh everything's broken
});
No hace estornudar en absoluto. Obtenemos la imagen, agregamos un par de objetos de escucha y, luego, JavaScript puede dejar de ejecutarse hasta que se llame a uno de esos objetos de escucha.
Lamentablemente, en el ejemplo anterior, es posible que los eventos hayan ocurrido antes de que comencemos a escucharlos, por lo que debemos solucionarlo con la propiedad "complete" de las imágenes:
var img1 = document.querySelector('.img-1');
function loaded() {
// woo yey image loaded
}
if (img1.complete) {
loaded();
}
else {
img1.addEventListener('load', loaded);
}
img1.addEventListener('error', function() {
// argh everything's broken
});
Esto no detecta las imágenes que tuvieron errores antes de que tuviéramos la oportunidad de escucharlas. Lamentablemente, el DOM no nos brinda una forma de hacerlo. Además, se carga una sola imagen. La situación se vuelve aún más compleja si queremos saber cuándo se cargó un conjunto de imágenes.
Los eventos no siempre son la mejor opción
Los eventos son excelentes para acciones que pueden ocurrir varias veces en el mismo
objeto: keyup
, touchstart
, etcétera. Con esos eventos, no te importa
lo que sucedió antes de conectar el objeto de escucha. Sin embargo, cuando se trata de
éxito o error asíncrono, lo ideal es que quieras algo como lo siguiente:
img1.callThisIfLoadedOrWhenLoaded(function() {
// loaded
}).orIfFailedCallThis(function() {
// failed
});
// and…
whenAllTheseHaveLoaded([img1, img2]).callThis(function() {
// all loaded
}).orIfSomeFailedCallThis(function() {
// one or more failed
});
Esto es lo que hacen las promesas, pero con un nombre mejor. Si los elementos de imagen HTML tuvieran un método “listo” que devolviera una promesa, podríamos hacer lo siguiente:
img1.ready()
.then(function() {
// loaded
}, function() {
// failed
});
// and…
Promise.all([img1.ready(), img2.ready()])
.then(function() {
// all loaded
}, function() {
// one or more failed
});
En su forma más básica, las promesas son un poco como los objetos de escucha de eventos, excepto por lo siguiente:
- Una promesa solo puede tener éxito o fallar una vez. No puede tener éxito o fallar dos veces, ni cambiar de éxito a error o viceversa.
- Si una promesa se realiza correctamente o falla y, luego, agregas una devolución de llamada de éxito o error, se llamará a la devolución de llamada correcta, aunque el evento haya ocurrido antes.
Esto es muy útil para el éxito o el error asíncrono, ya que te interesa menos el momento exacto en que algo estuvo disponible y más reaccionar al resultado.
Terminología de promesas
Domenic Denicola revisó el primer borrador de este artículo y me puso una calificación de “F” en terminología. Me puso en detención, me obligó a copiar Estados y destinos 100 veces y les escribió una carta preocupada a mis padres. A pesar de eso, todavía se me mezcla mucho la terminología, pero estos son los conceptos básicos:
Una promesa puede ser:
- fulfilled: La acción relacionada con la promesa se realizó correctamente.
- rechazada: La acción relacionada con la promesa falló.
- pendiente: Aún no se cumple ni se rechaza.
- settled: Se completó o rechazó.
La especificación también usa el término thenable para describir un objeto similar a una promesa, ya que tiene un método then
. Este término me recuerda al exdirector técnico de la selección de fútbol de Inglaterra, Terry Venables, por lo que lo usaré lo menos posible.
¡Llegaron las promesas a JavaScript!
Las promesas existen desde hace tiempo en forma de bibliotecas, como las siguientes:
Las promesas anteriores y las de JavaScript comparten un comportamiento común y estandarizado llamado Promises/A+. Si eres usuario de jQuery, tienen algo similar llamado Deferreds. Sin embargo, los objetos diferidos no cumplen con Promise/A+, lo que los hace ligeramente diferentes y menos útiles, así que ten cuidado. jQuery también tiene un tipo de promesa, pero es solo un subconjunto de Deferred y tiene los mismos problemas.
Aunque las implementaciones de promesas siguen un comportamiento estandarizado, sus APIs generales difieren. Las promesas de JavaScript son similares en la API a RSVP.js. A continuación, se muestra cómo crear una promesa:
var promise = new Promise(function(resolve, reject) {
// do a thing, possibly async, then…
if (/* everything turned out fine */) {
resolve("Stuff worked!");
}
else {
reject(Error("It broke"));
}
});
El constructor de promesas toma un argumento, una devolución de llamada con dos parámetros, resolver y rechazar. Haz algo dentro de la devolución de llamada, quizás asíncrono, y, luego, llama a resolver si todo funcionó, de lo contrario, llama a rechazar.
Al igual que throw
en JavaScript puro, es costumbre, pero no obligatorio, rechazar con un objeto Error. El beneficio de los objetos Error es que capturan un seguimiento de pila, lo que hace que las herramientas de depuración sean más útiles.
A continuación, te mostramos cómo usar esa promesa:
promise.then(function(result) {
console.log(result); // "Stuff worked!"
}, function(err) {
console.log(err); // Error: "It broke"
});
then()
toma dos argumentos, una devolución de llamada para un caso exitoso y otra para el caso de falla. Ambas son opcionales, por lo que puedes agregar una devolución de llamada solo para el caso de éxito o error.
Las promesas de JavaScript comenzaron en el DOM como "Futures", cambiaron su nombre a "Promises" y, finalmente, se trasladaron a JavaScript. Tenerlos en JavaScript en lugar del DOM es excelente porque estarán disponibles en contextos de JS que no sean de navegadores, como Node.js (si los usan en sus APIs principales es otra cuestión).
Aunque son una función de JavaScript, el DOM no tiene miedo de usarlas. De hecho, todas las APIs de DOM nuevas con métodos de éxito o error asíncronos usarán promesas. Esto ya sucede con la Administración de cuotas, los Eventos de carga de fuentes, ServiceWorker, Web MIDI, flujos y mucho más.
Compatibilidad con otras bibliotecas
La API de promesas de JavaScript tratará cualquier elemento con un método then()
como una promesa (o thenable
en el lenguaje de promesas sigh), por lo que, si usas una biblioteca que muestra una promesa de Q, está bien, funcionará bien con las nuevas promesas de JavaScript.
Sin embargo, como mencioné, los objetos diferidos de jQuery son un poco… poco útiles. Afortunadamente, puedes transmitirlas a promesas estándar, lo que vale la pena hacer cuanto antes:
var jsPromise = Promise.resolve($.ajax('/whatever.json'))
Aquí, $.ajax
de jQuery muestra un elemento Deferred. Como tiene un método then()
, Promise.resolve()
puede convertirlo en una promesa de JavaScript. Sin embargo, a veces, los diferidos pasan varios argumentos a sus devoluciones de llamada, por ejemplo:
var jqDeferred = $.ajax('/whatever.json');
jqDeferred.then(function(response, statusText, xhrObj) {
// ...
}, function(xhrObj, textStatus, err) {
// ...
})
Mientras que las promesas de JS ignoran todo excepto la primera:
jsPromise.then(function(response) {
// ...
}, function(xhrObj) {
// ...
})
Por lo general, esto es lo que quieres o, al menos, te da acceso a lo que quieres. Además, ten en cuenta que jQuery no sigue la convención de pasar objetos Error a los rechazos.
Código asíncrono complejo más fácil
Bien, comencemos a programar. Digamos que queremos hacer lo siguiente:
- Inicia un ícono giratorio para indicar la carga
- Recuperar algunos JSON de una historia, que nos proporciona el título y las URLs de cada capítulo
- Agrega un título a la página
- Cómo recuperar cada capítulo
- Agrega la historia a la página
- Detén el ícono giratorio
… pero también infórmale al usuario si algo salió mal en el proceso. También querremos detener el ícono giratorio en ese punto, de lo contrario, seguirá girando, se mareará y fallará en otra IU.
Por supuesto, no usarías JavaScript para entregar una historia, ya que publicar como HTML es más rápido, pero este patrón es bastante común cuando se trata de APIs: varias recuperaciones de datos y, luego, hacer algo cuando todo está listo.
Para empezar, veamos cómo recuperar datos de la red:
Conversión de XMLHttpRequest a promesa
Las APIs anteriores se actualizarán para usar promesas, si es posible de manera retrocompatible. XMLHttpRequest
es un candidato principal, pero, mientras tanto, vamos a escribir una función simple para realizar una solicitud GET:
function get(url) {
// Return a new promise.
return new Promise(function(resolve, reject) {
// Do the usual XHR stuff
var req = new XMLHttpRequest();
req.open('GET', url);
req.onload = function() {
// This is called even on 404 etc
// so check the status
if (req.status == 200) {
// Resolve the promise with the response text
resolve(req.response);
}
else {
// Otherwise reject with the status text
// which will hopefully be a meaningful error
reject(Error(req.statusText));
}
};
// Handle network errors
req.onerror = function() {
reject(Error("Network Error"));
};
// Make the request
req.send();
});
}
Ahora, usémoslo:
get('story.json').then(function(response) {
console.log("Success!", response);
}, function(error) {
console.error("Failed!", error);
})
Ahora podemos realizar solicitudes HTTP sin escribir XMLHttpRequest
de forma manual, lo cual es genial, ya que cuanto menos tenga que ver la mayúscula y minúscula intercalada de XMLHttpRequest
, más feliz será mi vida.
Encadenamiento
then()
no es el final de la historia, puedes encadenar then
para transformar valores o ejecutar acciones asíncronas adicionales una tras otra.
Transformación de valores
Para transformar valores, simplemente muestra el valor nuevo:
var promise = new Promise(function(resolve, reject) {
resolve(1);
});
promise.then(function(val) {
console.log(val); // 1
return val + 2;
}).then(function(val) {
console.log(val); // 3
})
Como ejemplo práctico, volvamos a lo siguiente:
get('story.json').then(function(response) {
console.log("Success!", response);
})
La respuesta es JSON, pero actualmente la recibimos como texto sin formato. Podríamos alterar nuestra función get para usar el objeto JSON responseType
, pero también podríamos resolverlo en el mundo de las promesas:
get('story.json').then(function(response) {
return JSON.parse(response);
}).then(function(response) {
console.log("Yey JSON!", response);
})
Dado que JSON.parse()
toma un solo argumento y muestra un valor transformado, podemos crear un atajo:
get('story.json').then(JSON.parse).then(function(response) {
console.log("Yey JSON!", response);
})
De hecho, podríamos crear una función getJSON()
con mucha facilidad:
function getJSON(url) {
return get(url).then(JSON.parse);
}
getJSON()
aún muestra una promesa, que recupera una URL y, luego, analiza la respuesta como JSON.
Cómo poner en cola acciones asíncronas
También puedes encadenar then
para ejecutar acciones asíncronas en secuencia.
Cuando devuelves algo desde una devolución de llamada then()
, es un poco mágico.
Si devuelves un valor, se llamará a la siguiente then()
con ese valor. Sin embargo, si muestra algo similar a una promesa, el siguiente then()
la espera y solo se le llama cuando esa promesa se resuelve (tiene éxito o falla). Por ejemplo:
getJSON('story.json').then(function(story) {
return getJSON(story.chapterUrls[0]);
}).then(function(chapter1) {
console.log("Got chapter 1!", chapter1);
})
Aquí, realizamos una solicitud asíncrona a story.json
, que nos proporciona un conjunto de URLs para solicitar y, luego, solicitamos la primera de ellas. Aquí es cuando las promesas realmente comienzan a destacarse de los patrones de devolución de llamada simples.
Incluso puedes crear un método de acceso directo para obtener capítulos:
var storyPromise;
function getChapter(i) {
storyPromise = storyPromise || getJSON('story.json');
return storyPromise.then(function(story) {
return getJSON(story.chapterUrls[i]);
})
}
// and using it is simple:
getChapter(0).then(function(chapter) {
console.log(chapter);
return getChapter(1);
}).then(function(chapter) {
console.log(chapter);
})
No descargamos story.json
hasta que se llame a getChapter
, pero las próximas veces que se llame a getChapter
, volveremos a usar la promesa de la historia, por lo que story.json
solo se recuperará una vez. ¡Felicidades, Promises!
Manejo de errores
Como vimos antes, then()
toma dos argumentos, uno para el éxito y uno para el error (o para entregar y rechazar, en términos de promesas):
get('story.json').then(function(response) {
console.log("Success!", response);
}, function(error) {
console.log("Failed!", error);
})
También puedes usar catch()
:
get('story.json').then(function(response) {
console.log("Success!", response);
}).catch(function(error) {
console.log("Failed!", error);
})
catch()
no tiene nada de especial, es solo azúcar para then(undefined, func)
, pero es más legible. Ten en cuenta que los dos ejemplos de código anteriores no se comportan de la misma manera, el último es equivalente a lo siguiente:
get('story.json').then(function(response) {
console.log("Success!", response);
}).then(undefined, function(error) {
console.log("Failed!", error);
})
La diferencia es sutil, pero muy útil. Los rechazos de promesas omiten
el siguiente then()
con una devolución de llamada de rechazo (o catch()
, ya que
es equivalente). Con then(func1, func2)
, se llamará a func1
o func2
, nunca a ambos. Sin embargo, con then(func1).catch(func2)
, se llamará a ambos si func1
rechaza, ya que son pasos separados en la cadena. Ten en cuenta lo siguiente:
asyncThing1().then(function() {
return asyncThing2();
}).then(function() {
return asyncThing3();
}).catch(function(err) {
return asyncRecovery1();
}).then(function() {
return asyncThing4();
}, function(err) {
return asyncRecovery2();
}).catch(function(err) {
console.log("Don't worry about it");
}).then(function() {
console.log("All done!");
})
El flujo anterior es muy similar al try/catch normal de JavaScript. Los errores que se producen dentro de un “try” van inmediatamente al bloque catch()
. A continuación, se muestra lo anterior como un diagrama de flujo (porque me encantan los diagramas de flujo):
Sigue las líneas azules para las promesas que se cumplen o las rojas para las que se rechazan.
Excepciones y promesas de JavaScript
Los rechazos se producen cuando se rechaza una promesa de forma explícita, pero también de forma implícita si se genera un error en la devolución de llamada del constructor:
var jsonPromise = new Promise(function(resolve, reject) {
// JSON.parse throws an error if you feed it some
// invalid JSON, so this implicitly rejects:
resolve(JSON.parse("This ain't JSON"));
});
jsonPromise.then(function(data) {
// This never happens:
console.log("It worked!", data);
}).catch(function(err) {
// Instead, this happens:
console.log("It failed!", err);
})
Esto significa que es útil hacer todo el trabajo relacionado con las promesas dentro de la devolución de llamada del constructor de promesas, de modo que los errores se detecten automáticamente y se conviertan en rechazos.
Lo mismo sucede con los errores que se arrojan en las devoluciones de llamada de then()
.
get('/').then(JSON.parse).then(function() {
// This never happens, '/' is an HTML page, not JSON
// so JSON.parse throws
console.log("It worked!", data);
}).catch(function(err) {
// Instead, this happens:
console.log("It failed!", err);
})
Manejo de errores en la práctica
Con nuestra historia y capítulos, podemos usar catch para mostrar un error al usuario:
getJSON('story.json').then(function(story) {
return getJSON(story.chapterUrls[0]);
}).then(function(chapter1) {
addHtmlToPage(chapter1.html);
}).catch(function() {
addTextToPage("Failed to show chapter");
}).then(function() {
document.querySelector('.spinner').style.display = 'none';
})
Si la recuperación de story.chapterUrls[0]
falla (p.ej., http 500 o el usuario no tiene conexión), se omitirán todas las siguientes devoluciones de llamada de éxito, incluida la de getJSON()
que intenta analizar la respuesta como JSON y también se omitirá la devolución de llamada que agrega chapter1.html a la página. En su lugar, pasa a la devolución de llamada de captura. Como resultado, se agregará a la página el mensaje "No se pudo mostrar el capítulo" si
alguna de las acciones anteriores falló.
Al igual que try/catch de JavaScript, se detecta el error y se continúa con el código posterior, por lo que la lista de opciones siempre está oculta, que es lo que queremos. Lo anterior se convierte en una versión asíncrona no bloqueante de lo siguiente:
try {
var story = getJSONSync('story.json');
var chapter1 = getJSONSync(story.chapterUrls[0]);
addHtmlToPage(chapter1.html);
}
catch (e) {
addTextToPage("Failed to show chapter");
}
document.querySelector('.spinner').style.display = 'none'
Es posible que quieras usar catch()
solo con fines de registro, sin recuperar del error. Para ello, vuelve a lanzar el error. Podríamos hacerlo en
nuestro método getJSON()
:
function getJSON(url) {
return get(url).then(JSON.parse).catch(function(err) {
console.log("getJSON failed for", url, err);
throw err;
});
}
Logramos recuperar un capítulo, pero queremos todos. Hagámoslo posible.
Paralelismo y secuenciación: aprovecha lo mejor de ambos
Pensar de forma asíncrona no es fácil. Si tienes dificultades para comenzar, prueba escribir el código como si fuera síncrono. En este caso, ocurre lo siguiente:
try {
var story = getJSONSync('story.json');
addHtmlToPage(story.heading);
story.chapterUrls.forEach(function(chapterUrl) {
var chapter = getJSONSync(chapterUrl);
addHtmlToPage(chapter.html);
});
addTextToPage("All done");
}
catch (err) {
addTextToPage("Argh, broken: " + err.message);
}
document.querySelector('.spinner').style.display = 'none'
¡Funciona! Sin embargo, se sincroniza y bloquea el navegador mientras se descargan los elementos. Para que esto funcione de forma asíncrona, usamos then()
para que las acciones sucedan una tras otra.
getJSON('story.json').then(function(story) {
addHtmlToPage(story.heading);
// TODO: for each url in story.chapterUrls, fetch & display
}).then(function() {
// And we're all done!
addTextToPage("All done");
}).catch(function(err) {
// Catch any error that happened along the way
addTextToPage("Argh, broken: " + err.message);
}).then(function() {
// Always hide the spinner
document.querySelector('.spinner').style.display = 'none';
})
Pero ¿cómo podemos recorrer las URLs de los capítulos y recuperarlas en orden? Esto no funciona:
story.chapterUrls.forEach(function(chapterUrl) {
// Fetch chapter
getJSON(chapterUrl).then(function(chapter) {
// and add it to the page
addHtmlToPage(chapter.html);
});
})
forEach
no es compatible con la operación asíncrona, por lo que nuestros capítulos aparecerían en cualquier orden en el que se descarguen, que es básicamente como se escribió Pulp Fiction. Esto no es Pulp Fiction, así que vamos a solucionarlo.
Cómo crear una secuencia
Queremos convertir nuestro array chapterUrls
en una secuencia de promesas. Para ello, podemos usar then()
:
// Start off with a promise that always resolves
var sequence = Promise.resolve();
// Loop through our chapter urls
story.chapterUrls.forEach(function(chapterUrl) {
// Add these actions to the end of the sequence
sequence = sequence.then(function() {
return getJSON(chapterUrl);
}).then(function(chapter) {
addHtmlToPage(chapter.html);
});
})
Esta es la primera vez que vemos Promise.resolve()
, que crea una promesa que se resuelve en cualquier valor que le des. Si le pasas una instancia de Promise
, simplemente la mostrará (nota: este es un cambio en la especificación que aún no siguen algunas implementaciones). Si le pasas algo similar a una promesa (tiene un método then()
), se crea un Promise
genuino que se entrega o rechaza de la misma manera. Si pasas cualquier otro valor, p.ej., Promise.resolve('Hello')
, crea una promesa que se cumple con ese valor. Si lo llamas sin un valor, como se indicó anteriormente, se completa con "undefined".
También está Promise.reject(val)
, que crea una promesa que se rechaza con el valor que le proporcionas (o indefinido).
Podemos ordenar el código anterior con array.reduce
:
// Loop through our chapter urls
story.chapterUrls.reduce(function(sequence, chapterUrl) {
// Add these actions to the end of the sequence
return sequence.then(function() {
return getJSON(chapterUrl);
}).then(function(chapter) {
addHtmlToPage(chapter.html);
});
}, Promise.resolve())
Esto hace lo mismo que el ejemplo anterior, pero no necesita la variable "secuencia" separada. Se llama a nuestra devolución de llamada de reducción para cada elemento del array.
“sequence” es Promise.resolve()
la primera vez, pero para el resto de las llamadas, “sequence” es lo que mostramos de la llamada anterior. array.reduce
es muy útil para reducir un array a un solo valor, que en este caso es una promesa.
Resumamos todo:
getJSON('story.json').then(function(story) {
addHtmlToPage(story.heading);
return story.chapterUrls.reduce(function(sequence, chapterUrl) {
// Once the last chapter's promise is done…
return sequence.then(function() {
// …fetch the next chapter
return getJSON(chapterUrl);
}).then(function(chapter) {
// and add it to the page
addHtmlToPage(chapter.html);
});
}, Promise.resolve());
}).then(function() {
// And we're all done!
addTextToPage("All done");
}).catch(function(err) {
// Catch any error that happened along the way
addTextToPage("Argh, broken: " + err.message);
}).then(function() {
// Always hide the spinner
document.querySelector('.spinner').style.display = 'none';
})
Y aquí está, una versión completamente asíncrona de la versión síncrona. Pero podemos hacerlo mejor. En este momento, nuestra página se descarga de la siguiente manera:
Los navegadores son bastante buenos para descargar varios elementos a la vez, por lo que perdemos rendimiento cuando descargamos capítulos uno tras otro. Lo que queremos hacer es descargarlos todos al mismo tiempo y, luego, procesarlos cuando lleguen. Afortunadamente, hay una API para esto:
Promise.all(arrayOfPromises).then(function(arrayOfResults) {
//...
})
Promise.all
toma un array de promesas y crea una promesa que se cumple cuando todas se completan correctamente. Obtienes un array de resultados (cualquiera que sea la promesa que se cumpla) en el mismo orden que las promesas que pasaste.
getJSON('story.json').then(function(story) {
addHtmlToPage(story.heading);
// Take an array of promises and wait on them all
return Promise.all(
// Map our array of chapter urls to
// an array of chapter json promises
story.chapterUrls.map(getJSON)
);
}).then(function(chapters) {
// Now we have the chapters jsons in order! Loop through…
chapters.forEach(function(chapter) {
// …and add to the page
addHtmlToPage(chapter.html);
});
addTextToPage("All done");
}).catch(function(err) {
// catch any error that happened so far
addTextToPage("Argh, broken: " + err.message);
}).then(function() {
document.querySelector('.spinner').style.display = 'none';
})
Según la conexión, esto puede ser segundos más rápido que cargar uno por uno, y es menos código que nuestro primer intento. Los capítulos se pueden descargar en cualquier orden, pero aparecen en la pantalla en el orden correcto.
Sin embargo, aún podemos mejorar el rendimiento percibido. Cuando llegue el primer capítulo, deberíamos agregarlo a la página. Esto permite que el usuario comience a leer antes de que llegue el resto de los capítulos. Cuando llegue el tercer capítulo, no lo agregaríamos a la página porque es posible que el usuario no se dé cuenta de que falta el segundo. Cuando llegue el capítulo dos, podremos agregar los capítulos dos y tres, etcétera.
Para ello, recuperamos el JSON de todos nuestros capítulos al mismo tiempo y, luego, creamos una secuencia para agregarlos al documento:
getJSON('story.json')
.then(function(story) {
addHtmlToPage(story.heading);
// Map our array of chapter urls to
// an array of chapter json promises.
// This makes sure they all download in parallel.
return story.chapterUrls.map(getJSON)
.reduce(function(sequence, chapterPromise) {
// Use reduce to chain the promises together,
// adding content to the page for each chapter
return sequence
.then(function() {
// Wait for everything in the sequence so far,
// then wait for this chapter to arrive.
return chapterPromise;
}).then(function(chapter) {
addHtmlToPage(chapter.html);
});
}, Promise.resolve());
}).then(function() {
addTextToPage("All done");
}).catch(function(err) {
// catch any error that happened along the way
addTextToPage("Argh, broken: " + err.message);
}).then(function() {
document.querySelector('.spinner').style.display = 'none';
})
Y aquí tienes lo mejor de ambos. Tarda la misma cantidad de tiempo en entregar todo el contenido, pero el usuario recibe el primer fragmento de contenido antes.
En este ejemplo trivial, todos los capítulos llegan aproximadamente al mismo tiempo, pero el beneficio de mostrar uno a la vez se exagerará con más capítulos más grandes.
Hacer lo anterior con callbacks o eventos de estilo Node.js es aproximadamente el doble del código, pero lo más importante es que no es tan fácil de seguir. Sin embargo, esto no es el final de la historia de las promesas, ya que, cuando se combinan con otras funciones de ES6, se vuelven aún más fáciles.
Ronda adicional: funciones ampliadas
Desde que escribí este artículo originalmente, la capacidad de usar promesas se expandió mucho. Desde Chrome 55, las funciones asíncronas permitieron que el código basado en promesas se escriba como si fuera síncrono, pero sin bloquear el subproceso principal. Puedes obtener más información sobre esto en mi artículo sobre funciones asíncronas. Existe una compatibilidad generalizada con las promesas y las funciones asíncronas en los navegadores principales. Puedes encontrar los detalles en la referencia de Promise y función asíncrona de MDN.
Muchas gracias a Anne van Kesteren, Domenic Denicola, Tom Ashworth, Remy Sharp, Addy Osmani, Arthur Evans y Yutaka Hirano, quienes revisaron este texto y realizaron correcciones y recomendaciones.
También, gracias a Mathias Bynens por actualizar varias partes del artículo.