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 crucial en la historia del desarrollo web.
[Redoble de tambores]
Llegaron las promesas a JavaScript.
[Fuegos artificiales, lluvia de papeles y exaltación de la multitud]
En este momento, te encuentras en una de estas categorías:
- Hay personas que te animan, pero no sabes por qué tanto alboroto. Tal vez no sepas qué es una "promesa". Te encogerías de hombros, pero el peso del papel brillante se siente. Si es así, no te preocupes. Me tomó años descubrir por qué todo esto debería importarme. Es probable que te convenga comenzar por el principio.
- Te embarga la alegría. Ya era hora, ¿verdad? Ya usaste estas promesas, pero te molesta que todas las implementaciones tengan una API ligeramente diferente. ¿Cuál es la API de la versión oficial de JavaScript? Es probable que te convenga empezar con la terminología.
- Ya sabías todo esto y te burlas de los que están saltando de arriba abajo como si fuera una noticia para ellos. Tómate un momento para disfrutar de tu propia superioridad y, luego, dirígete a la referencia de la API.
Compatibilidad con navegadores y polyfill
Consulta el polyfill (2,000 comprimidos) para adaptar los navegadores que no tienen una implementación completa de promesas al cumplimiento de las especificaciones o agregar promesas a otros navegadores y Node.js.
¿Por qué tanto escándalo?
JavaScript tiene un solo subproceso, lo que significa que dos fragmentos de secuencia de comandos no se pueden ejecutar al mismo tiempo, sino que deben ejecutarse uno después del otro. En navegadores, JavaScript comparte un subproceso con una carga de otras cosas que difiere de un navegador a otro. Sin embargo, por lo general, JavaScript está en la misma cola que la pintura, la actualización de diseños y el control de las acciones del usuario (como destacar texto e interactuar con los controles de formularios). La actividad en uno de estos elementos retrasa los demás.
Como ser humano, tienes varios subprocesos. Puedes escribir con varios dedos o conducir y mantener una conversación al mismo tiempo. La única función que nos bloquea es el estornudo, que consiste en suspender toda la actividad actual durante un estornudo. Eso es muy molesto, en especial cuando conduces y tratas de mantener una conversación. No quieres escribir código que produzca estornudos.
Probablemente hayas usado eventos y devoluciones de llamada para evitar esto. 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 hay estornudos. Obtenemos la imagen y agregamos algunos objetos de escucha. 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 solucionar este problema 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 captura imágenes con errores antes de que pudiéramos escucharlas. Lamentablemente, el DOM no nos brinda una forma de hacerlo. Esto también implica cargar una imagen. El proceso se vuelve aún más complejo si queremos saber cuándo se cargó un conjunto de imágenes.
Los eventos no siempre son la mejor manera
Los eventos son excelentes para eventos que pueden suceder varias veces en el mismo objeto, keyup, touchstart, etc. Con esos eventos, no te interesa lo que sucedió antes de adjuntar el objeto de escucha. Sin embargo, cuando se trata de éxito o fracaso de procesos asincrónicos, lo ideal sería lograr 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 una mejor nomenclatura. Si los elementos de imagen HTML tuviesen un método "listo" que mostrara 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
});
Básicamente, las promesas se parecen a los objetos de escucha de eventos, a excepción de lo siguiente:
- Una promesa solo puede completarse con éxito o fallar una vez. No puede completarse con éxito o fallar dos veces, ni puede pasar de exitosa a con errores o viceversa.
- Si una promesa se completó correctamente o falló y luego agregas una devolución de llamada de éxito o fracaso, se llamará a la devolución de llamada correcta, aunque el evento haya ocurrido antes.
Esto es muy útil para el éxito o fracaso de procesos asíncronos, porque te interesa menos el momento exacto en el que algo estuvo disponible que reaccionar al resultado.
Terminología de las promesas
Domenic Denicola leyó el primer borrador de este artículo y obtuve un "Desaprobado" en terminología. Me puso en detención, me obligó a copiar Estados y destinos 100 veces y escribió una carta preocupada a mis padres. A pesar de eso, sigo confundiendo la terminología, pero estos son los conceptos básicos:
Una promesa puede ser:
- fulfill: la acción relacionada con la promesa se realizó correctamente
- rejected: No se pudo realizar la acción relacionada con la promesa.
- pending: Aún no se completa ni se rechaza.
- liquidado: Se completó o se rechazó.
En la especificación, también se usa el término thenable para describir un objeto parecido a una promesa, ya que tiene un método then. Este término me recuerda a Terry Venables, un ex entrenador de fútbol de Inglaterra, así 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 de JavaScript anteriores y las de JavaScript comparten un comportamiento estandarizado común denominado Promises/A+. Si usas jQuery, pueden usar algo similar llamado Deferred. Sin embargo, diferidos no cumplen con Promise/A+, lo que los hace un tanto diferentes y menos útiles, así que ten cuidado. jQuery también tiene un tipo de Promise, pero solo es un subconjunto de Deferred y tiene los mismos problemas.
Si bien las implementaciones de las promesas siguen un comportamiento estandarizado, sus APIs generales difieren. En cuanto a la API, las promesas de JavaScript son similares a las de confirmación de asistencia.js. Así se crea 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 la promesa recibe un argumento: una devolución de llamada con dos parámetros: resolver y rechazar. Realiza alguna acción dentro de la devolución de llamada, quizás de manera asíncrona, y, luego, llama a resolve si todo funcionó, de lo contrario, llama a rescindir.
Al igual que throw en el JavaScript que todos conocemos, es costumbre (aunque no obligación) rechazarlo 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.
Así es como se usa esa promesa:
promise.then(function(result) {
console.log(result); // "Stuff worked!"
}, function(err) {
console.log(err); // Error: "It broke"
});
then() recibe dos argumentos: una devolución de llamada para casos de éxito y otro para casos de falla. Ambos son opcionales, por lo que puedes agregar una devolución de llamada solo para el caso de éxito o fracaso.
Las promesas de JavaScript empezaron en DOM como "Future", se les cambió el nombre a "Promise" y, finalmente, se trasladaron a JavaScript. Tenerlos en JavaScript en lugar del DOM es genial, ya que estarán disponibles en contextos de JS sin navegador, como Node.js (si se usan en sus APIs principales, es otra cuestión).
Si bien son una función de JavaScript, el DOM no tiene miedo de usarlas. De hecho, todas las nuevas APIs de DOM con métodos de éxito o falla asíncronos usarán promesas. Esto ya sucede con la administración de cuotas, los eventos de carga de fuentes, ServiceWorker, Web MIDI y transmisiones y mucho más.
Compatibilidad con otras bibliotecas
La API de las promesas de JavaScript tratará todo lo que tenga un método then() como si fuera una promesa (o thenable en suspiro de promesas). Por lo tanto, si usas una biblioteca que muestra una promesa Q, no hay problema, funcionará bien con las nuevas promesas de JavaScript.
Sin embargo, como mencioné, los elementos Deferred de jQuery son un poco... inútiles. Por suerte, puedes transmitirlos a las promesas estándar, lo que vale la pena hacerlo lo antes posible:
var jsPromise = Promise.resolve($.ajax('/whatever.json'))
Aquí, $.ajax de jQuery muestra un elemento Deferred. Dado que tiene un método then(),
Promise.resolve() puede convertirlo en una promesa de JavaScript. Sin embargo, a veces los elementos deferred 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) {
// ...
})
En cambio, las promesas de JS ignoran todo menos el primero:
jsPromise.then(function(response) {
// ...
}, function(xhrObj) {
// ...
})
Afortunadamente, esto suele ser lo que quieres o, al menos, te brinda acceso a lo que deseas. Además, ten en cuenta que jQuery no sigue la convención de pasar objetos Error a rechazos.
Código asíncrono complejo más fácil
Bueno, codifiquemos algunas cosas. Supongamos que queremos hacer lo siguiente:
- Inicia un ícono giratorio para indicar que se está cargando
- Recuperar algunos archivos JSON para una historia, que nos proporciona el título y las URL de cada capítulo
- Agrega un título a la página
- Obtener cada capítulo
- Agrega la historia a la página
- Detener el ícono giratorio
... pero también decirle al usuario si algo salió mal en el camino. También deberemos detener el ícono giratorio en ese momento, ya que, de lo contrario, seguirá girando, se mareará y fallará con 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 trabajas con APIs: varias recuperaciones de datos y, luego, haz algo cuando todo esté listo.
Para comenzar, analicemos la recuperación de datos de la red:
Promesas en XMLHttpRequest
Las APIs anteriores se actualizarán para usar promesas y si es posible, de una manera retrocompatible. XMLHttpRequest es una gran candidata, pero, mientras tanto, escribamos una función simple para hacer 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 lo usaremos:
get('story.json').then(function(response) {
console.log("Success!", response);
}, function(error) {
console.error("Failed!", error);
})
Ahora podemos hacer solicitudes HTTP sin escribir XMLHttpRequest de forma manual, lo cual es genial, ya que mientras menos tenga que ver la exasperante tipografía de XMLHttpRequest, más feliz será mi vida.
Encadenamiento
then() no es el final de la historia. Puedes encadenar las then para transformar valores o ejecutar acciones asíncronas adicionales una tras otra.
Cómo transformar valores
Puedes transformar valores con solo mostrar 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 la recibimos como texto sin formato. Podríamos modificar la función get para usar el JSON responseType, pero también podríamos resolverlo en el ámbito 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 hacer una función getJSON() con mucha facilidad:
function getJSON(url) {
return get(url).then(JSON.parse);
}
getJSON() aún muestra una promesa, una que recupera una URL y, luego, analiza la respuesta como JSON.
Pon en cola acciones asíncronas
También puedes encadenar objetos then para ejecutar acciones asíncronas en secuencia.
Cuando muestras algo de una devolución de llamada de then(), ocurre algo mágico.
Si muestras un valor, se llama al siguiente then() con ese valor. Sin embargo, si muestras algo parecido a una promesa, el siguiente then() lo espera y solo se llama cuando esa promesa se termina (se completa con é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);
})
En este ejemplo, realizamos una solicitud asíncrona a story.json, que nos proporciona un conjunto de
URLs para solicitar; luego, solicitamos la primera de ellas. En este momento, las promesas realmente comienzan a destacarse frente a los patrones de devolución de llamada simples.
Incluso puedes crear un método abreviado 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 descargaremos story.json hasta que se llame a getChapter, pero las próximas veces que se llame a getChapter, reutilizaremos la promesa de la historia, por lo que story.json solo se recuperará una vez. ¡Viva las promesas!
Manejo de errores
Como vimos antes, then() toma dos argumentos: uno por éxito y uno por falla (o completado y rechazado, hablando 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 simplemente azúcar sintáctico 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; este último equivale 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 extremadamente útil. Los rechazos de promesas avanzan al 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 se rechaza func1, ya que son pasos separados de la cadena. Supongamos 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 de JavaScript normal; los errores que ocurren dentro de un "try" van inmediatamente al bloque catch(). Esto es lo anterior en un diagrama de flujo (porque me encantan estos diagramas):
Sigue las líneas azules para las promesas que se cumplan o las rojas para las que se rechacen.
Excepciones y promesas de JavaScript
Los rechazos ocurren cuando se rechaza una promesa de forma explícita, pero también de forma implícita si se produce 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 resulta útil realizar todo el trabajo relacionado con las promesas dentro de la devolución de llamada del constructor de la promesa para que los errores se detecten automáticamente y se conviertan en rechazos.
Lo mismo ocurre con los errores arrojados en 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 los 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 falla la recuperación de story.chapterUrls[0] (p.ej., http 500 o el usuario está sin conexión), se omitirán todas las siguientes devoluciones de llamada exitosas, incluidas la de getJSON() que intenta analizar la respuesta en formato JSON, y también omitirá la devolución de llamada que agrega capítulo1.html a la página. En su lugar, se trasladará a la devolución de llamada de catch. Como resultado, se agregará "No se pudo mostrar el capítulo" a la página si falla alguna de las acciones anteriores.
Como try/catch de JavaScript, se detecta el error y el código posterior continúa, por lo que el ícono giratorio siempre está oculto, que es lo que queremos. Lo anterior se convierte en una versión asíncrona sin bloqueo 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 recuperarte del error. Para ello, simplemente arroja 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;
});
}
Hemos podido obtener un capítulo, pero los queremos a todos. Hagamos que eso suceda.
Paralelismo y secuencia: cómo aprovechar lo mejor de ambos
No es fácil pensar como asincrónico. Si tienes problemas para dar el primer paso, intenta 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'
Sí, funciona. Sin embargo, es sincrónico y bloquea el navegador mientras se descargan las cosas. Para que este trabajo sea asíncrono, usamos then() para que las cosas 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 asíncrono, por lo que nuestros capítulos aparecerían en el orden en que se descargaron, que es básicamente la forma en que se redactó el trabajo de Pulp espere. Esto no es Pulp Fantasy, así que solucionémoslo.
Crea una secuencia
Queremos convertir nuestro array chapterUrls en una secuencia de promesas. Podemos hacerlo con 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 al valor que le proporciones. Si le pasas una instancia de Promise, simplemente se la mostrará (Nota: Se trata de un cambio en la especificación que aún no siguen algunas implementaciones). Si le pasas algo parecido a una promesa (tiene un método then()), crea un Promise genuino que se cumple/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 la llamas sin ningún valor, como se muestra más arriba, se cumple con "undefined".
También existe Promise.reject(val), que crea una promesa que se rechaza con
el valor que le asignas (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())
Cumple la misma función que el ejemplo anterior, pero no requiere la otra variable “secuencia”. Llamamos a la devolución de llamada "reduce" para cada elemento de la matriz.
"secuencia" es Promise.resolve() la primera vez, pero, en el resto de las llamadas, es el que mostramos en la llamada anterior. array.reduce es muy útil para reducir un array a un solo valor, que en este caso es una promesa.
Juntemos 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 ahí la tenemos, una versión completamente asincrónica de la versión síncrona. Pero podemos hacerlo mejor. En este momento, nuestra página realiza descargas de la siguiente forma:
Los navegadores son bastante buenos para descargar varias cosas a la vez, por lo que si descargamos los capítulos uno tras otro, significa que estamos perdiendo rendimiento. Lo que queremos hacer es descargarlos todos al mismo tiempo y procesarlos cuando todos hayan terminado. Afortunadamente, existe 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 de forma correcta. Se obtiene un array de resultados (independientemente de lo que se usó para cumplir con la promesa) 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 llega el capítulo uno, debemos agregarlo a la página. Esto le permite al usuario comenzar a leer antes de que llegue el resto de los capítulos. Cuando llega el capítulo tres, no lo agregamos a la página porque es posible que el usuario no se dé cuenta de que falta el capítulo dos. Cuando llega el capítulo dos, podemos agregar el capítulo dos, tres, etc.
Para ello, recuperamos el archivo JSON de todos los 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';
})
Aquí vamos, lo mejor de ambos. Se tarda lo mismo en entregar todo el contenido, pero el usuario obtiene la primera parte de este antes.
En este ejemplo trivial, todos los capítulos llegan casi al mismo tiempo, pero el beneficio de mostrar uno a la vez se exagera con la cantidad de capítulos más grandes.
Hacer lo anterior con devoluciones de llamada o eventos de estilo Node.js implica casi el doble del código, pero lo que es más importante, no es tan fácil de seguir. Sin embargo, este no es el fin 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: capacidades expandidas
Desde que escribí este artículo originalmente, la capacidad de usar promesas se ha expandido enormemente. A partir de Chrome 55, las funciones asíncronas permiten 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 al respecto en my async functions article. Los principales navegadores admiten tanto las promesas como las funciones asíncronas. 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, que editaron este texto y realizaron correcciones y recomendaciones.
Además, gracias a Mathias Bynens por actualizar varias partes del artículo.