Promesas de JavaScript: introducción

Las promesas simplifican cómputos diferidos y asíncronos. Una promesa representa una operación que aún no se completó.

Jake Archibald

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 ante una de estas situaciones:

• Las personas te aplauden, pero no sabes por qué. Tal vez ni siquiera sepas qué es una “promesa”. Te encoges de hombros, pero el peso de la lluvia de papeles se siente. Si este es el caso, no te preocupes. Me tomó años descubrir por qué todo esto debería importarme. Probablemente te convenga empezar por el principio.
• Te embarga la alegría. Ya era hora, ¿no es así? Ya usaste estas promesas, pero te molesta que todas las implementaciones usen API con pequeñas diferencias. ¿Cuál es la API para la versión oficial de JavaScript? Probablemente te convenga empezar con la terminología.
• Ya sabías todo esto y te burlas de los que están saltando de felicidad porque recién se enteran. 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

Navegadores compatibles

• 32
• 12
• 29
• 8

Origen

Consulta el polyfill (archivo gzip de 2 KB) si deseas que los navegadores sin implementaciones completas de promesas cumplan con las especificaciones, o si quieres agregar promesas a otros navegadores y Node.js.

¿Por qué tanto alboroto?

JavaScript es de un solo subproceso, es decir, dos porciones de secuencia de comandos no se pueden ejecutar al mismo tiempo, tienen que ejecutarse una después de la otra. En navegadores, JavaScript comparte un subproceso con una carga de otras cosas que difiere de navegador en navegador. Pero, generalmente, JavaScript se encuentra en la misma cola que la pintura, la actualización de estilos y el control de acciones de usuario (como destacar texto e interactuar con controles de formulario). La actividad en uno de estos elementos retrasa los otros.

Como ser humano, tienes la capacidad de procesar varias tareas. Puedes escribir con varios dedos, conducir y hablar al mismo tiempo. La única función que nos bloquea es el estornudo: toda actividad en desarrollo se debe suspender durante un estornudo. Esto es bastante molesto, en especial cuando conduces y tratas de llevar una conversación. No te convendrá escribir código que produzca estornudos.

Es probable que hayas usado eventos y devoluciones de llamadas para evitarlo. Estos son algunos 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 de receptores. JavaScript puede detenerse hasta que se llame a alguno de estos receptores.

Por desgracia, en el ejemplo anterior, es posible que los eventos hayan ocurrido antes de que comenzáramos a escucharlos. Por eso, debemos solucionar este problema usando 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 que generaron un error antes de que pudiéramos escucharlas. Lamentablemente, el DOM no nos brinda una forma de hacerlo. Además, se carga una imagen. La complejidad aumenta aún más cuando deseamos saber cuándo se cargó un conjunto de imágenes.

Los eventos no siempre son la mejor solución

Los eventos son ideales para sucesos que pueden ocurrir varias veces en el mismo objeto: keyup, touchstart, etc. Con esos eventos, no interesa saber realmente lo que ocurrió antes de adjuntar el objeto de escucha. Pero, si se trata de éxito/fallo asincrónico, idealmente, querrás algo así:

img1.callThisIfLoadedOrWhenLoaded(function() {
  // loaded
}).orIfFailedCallThis(function() {
  // failed
});

// and…
whenAllTheseHaveLoaded([img1, img2]).callThis(function() {
  // all loaded
}).orIfSomeFailedCallThis(function() {
  // one or more failed
});

Las promesas hacen eso, aunque 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
});

Fundamentalmente, las promesas se parecen un poco 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 exitoso a fallido ni viceversa.
• Si una promesa se completó correctamente o falló, y luego agregas un callback de éxito o falla, se llamará al callback correcto, a pesar de que el evento haya tenido lugar antes.

Esto es extremadamente útil para el éxito o fracaso de procesos asincrónicos porque es menos importante el momento exacto de la disponibilidad que la reacción ante el resultado.

Terminología de Promise

Domenic Denicola corrigió el primer borrador de este artículo y obtuve un “Desaprobado” en terminología. Me puso en penitencia, me obligó a copiar Estados y destinos cien veces y escribió una carta preocupada a mis padres. A pesar de todo esto, sigo confundiendo la terminología, pero estos son los conceptos básicos:

Una promesa puede ser de estas clases:

• fulfilled: La acción relacionada con la promesa se completó con éxito.
• rejected: La acción relacionada con la promesa no se completó correctamente.
• pendiente: Aún no se completa ni se rechaza.
• settled: Se completó o se rechazó.

En las especificaciones, 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!

Hace tiempo que las promesas existen en forma de bibliotecas. Estos son algunos ejemplos:

• Q
• cuando
• WinJS
• RSVP.js

Las promesas anteriores y las de JavaScript comparten un comportamiento estandarizado común llamado Promises/A+. Si usas jQuery, encontrarás algo similar llamado Deferreds. Sin embargo, Deferred no cumple con Promise/A+, por lo cual es un tanto diferente y menos útil, así que ten cuidado. jQuery también tiene un tipo de Promise, pero solo se trata de un subconjunto de Deferred y tiene los mismos problemas.

Si bien las implementaciones de las promesas siguen un comportamiento estandarizado, las APIs generales son diferentes. Las promesas de JavaScript son similares en la API a RSVP.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: un callback con dos parámetros (resolve y reject). A continuación, se hace algo con el callback (tal vez un proceso asíncrono) y se llama a resolve si todo funciona bien o a reject si esto no sucede.

Como en throw del JavaScript que todos conocemos, es costumbre (aunque no obligación) aplicar reject con un objeto Error. La ventaja 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í se usa esta promesa:

promise.then(function(result) {
  console.log(result); // "Stuff worked!"
}, function(err) {
  console.log(err); // Error: "It broke"
});

then() recibe dos argumentos: un callback para cuando se tiene éxito y otro para cuando sucede lo contrario. Ambos son opcionales, por lo que puedes agregar una devolución de llamada solo para cuando se tiene éxito o se produce una falla.

Las promesas de JavaScript empezaron en DOM como “Future”, se les cambió el nombre a “Promise” y, finalmente, se trasladaron a JavaScript. Es fabuloso contar con ellas en lugar del DOM en JavaScript, porque 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 asincrónicos usan promesas. Esto ya ocurre en la administración de cuotas, los eventos de carga de fuentes, ServiceWorker, Web MIDI, Streams y mucho más.

Compatibilidad con otras bibliotecas

La API de promesas de JavaScript tratará a todos los elementos con un método then() como una promesa (o thenable en el idioma_ de las promesas), por lo que, si usas una biblioteca que muestra una promesa Q, no habrá problema, ya que funcionará bien con las nuevas promesas de JavaScript.

Sin embargo, como mencioné, los Deferreds de jQuery son un poco… inútiles. Afortunadamente, puedes transmitirlos a las promesas convencionales. Vale la pena hacerlo lo más pronto posible:

var jsPromise = Promise.resolve($.ajax('/whatever.json'))

En este caso, $.ajax de jQuery muestra un elemento Deferred. Ya 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 callbacks, por ejemplo:

var jqDeferred = $.ajax('/whatever.json');

jqDeferred.then(function(response, statusText, xhrObj) {
  // ...
}, function(xhrObj, textStatus, err) {
  // ...
})

En cambio, las promesas de JS ignoran todos 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 quieres. 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 simple

Bien, comencemos a escribir algo de código. Supongamos que queremos hacer lo siguiente:

1. Inicia un indicador de carga para indicar que esta se encuentra en curso
2. Obtener algunos JSON para una historia, que nos proporciona el título y las URLs de cada capítulo
3. Agrega un título a la página
4. Cómo obtener cada capítulo
5. Agrega la historia a la página
6. Detén el indicador de carga

…pero también decirle al usuario si algo salió mal en el camino. También deberemos detener el indicador de carga en ese momento. De lo contrario, seguirá girando, experimentará errores y finalmente fallará en otra IU.

Por supuesto que no usarías JavaScript para proporcionar una historia, considerando que el lenguaje HTML es más rápido, pero este patrón es bastante común cuando se trabaja con diferentes APIs: varias recuperaciones de datos y, luego, hacer algo cuando todo esté listo.

Para comenzar, analicemos la obtención de datos desde la red:

Promesas en XMLHttpRequest

Las APIs anteriores se actualizarán para usar promesas y si es posible, se hará de forma que sean compatibles con versiones anteriores. XMLHttpRequest es una gran candidata. 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émosla:

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. Esto es fabuloso, porque mientras menos tenga que ver la exasperante tipografía de XMLHttpRequest, más feliz seré.

Encadenamiento

then() no es el final del camino. Puedes encadenar varios then para transformar valores o ejecutar acciones asincrónicas adicionales una tras otra.

Transformación de valores

Puedes transformar valores mostrando simplemente el nuevo valor:

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
})

A modo de ejemplo práctico, volvamos al código anterior:

get('story.json').then(function(response) {
  console.log("Success!", response);
})

La respuesta es un JSON, pero lo recibimos como texto sin formato. Podríamos alterar nuestra función get para que use el responseType de JSON, 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() recibe un solo argumento y muestra un valor transformado, podemos crear un método abreviado:

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() sigue mostrando una promesa; se trata de una promesa que obtiene una URL y, a continuación, analiza la respuesta como un JSON.

Cómo poner en cola acciones asíncronas

También puedes encadenar then para ejecutar acciones asíncronas en secuencia.

Cuando muestras algo de una devolución de llamada then(), sucede algo mágico. Si muestras un valor, se llamará a la siguiente then() con ese valor. Sin embargo, si muestras algo parecido a una promesa, el siguiente then() lo espera, y solo se lo llama cuando esa promesa se detiene (se completa con éxito/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, se realiza una solicitud asíncrona a story.json, que nos proporciona un conjunto de URLs que podemos solicitar. A continuación, se solicita la primera URL. En este momento, las promesas realmente comienzan a destacarse frente a los patrones de callbacks 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 descargamos 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 cual story.json solo se obtendrá una sola vez. ¡Vivan las promesas!

Manejo de errores

Como vimos antes, then() toma dos argumentos: uno por éxito y uno por falla (o cumplimiento y rechazo, 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 un recubrimiento 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 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. Considera 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 suceden dentro de un “try” van inmediatamente al bloque catch(). A continuación, explico 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 se producen cuando se rechaza una promesa de forma explícita, pero también de forma implícita si aparece un error en el callback 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 del callback del constructor de la promesa para 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

En nuestro ejemplo de 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 falla la recuperación de story.chapterUrls[0] (p.ej., HTTP 500 o el usuario está sin conexión), se saltearán todos los siguientes callbacks de éxito, lo que incluye el de getJSON() que intenta analizar la respuesta como JSON, y también se salteará el callback que agrega chapter1.html a la página. Como alternativa, se trasladará al callback de catch. Como resultado, se agregará “Failed to show chapter” (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 continúa el código siguiente; el indicador de carga está siempre oculto. Esto es lo que deseamos. Lo anterior se convierte en una versión asíncrona y 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 para el registro, sin recuperar del error. Para ello, solo debes volver a lanzar el error. Podríamos hacer esto 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 obtener un capítulo, pero queremos tenerlos a todos. Hagámoslo.

Paralelismo y secuencia: cómo aprovechar lo mejor de ambos

No es fácil aplicar un razonamiento asincrónico. Si tienes problemas para dar el primer paso, intenta escribir el código como si fuera sincrónico. 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! Pero es sincrónico y bloquea el navegador durante las descargas. Para que esto funcione de forma asíncrona, 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';
})

Sin embargo, ¿cómo podemos recorrer todas las URLs de los capítulos y obtenerlas 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 procesos asíncronos, por lo que nuestros capítulos aparecerían en el orden en que se descargaron, que es básicamente la forma en que se escribió Pulp Fiction. Esto no es Pulp Fiction, así que solucionémoslo.

Cómo crear 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 proporcionado. Si le pasas una instancia de Promise, simplemente se mostrará (nota: se trata de un cambio en las especificaciones que aún no aplican algunas implementaciones). Si le pasas algo similar a una promesa (tiene un método then()), crea una Promise genuina que se cumple o rechaza de la misma forma. Si le pasas otro valor, p.ej., Promise.resolve('Hello'), crea una promesa que se cumple con ese valor. Si la llamas sin ningún valor, como lo hicimos antes, se cumple con “undefined”.

También existe Promise.reject(val), que crea una promesa que se rechaza con el valor proporcionado (o “undefined”).

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 “sequence”. Llamamos al callback “reduce” para cada elemento del array. “sequence” es Promise.resolve() la primera vez, pero en el resto de las llamadas, “sequence” es lo que hayamos mostrado en la llamada anterior. array.reduce es realmente útil para reducir una matriz 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 aquí la tenemos, una versión completamente asincrónica de la versión sincrónica. 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 al mismo tiempo. Si descargamos los capítulos uno tras otro, significa que estamos perdiendo rendimiento. Lo ideal es descargarlos al mismo tiempo y procesarlos cuando todos hayan terminado de descargarse. Afortunadamente, existe una API para esto:

Promise.all(arrayOfPromises).then(function(arrayOfResults) {
  //...
})

Promise.all recibe una matriz de promesas y crea una promesa que se cumple cuando todas se completan con éxito. Se obtiene una matriz 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 algunos segundos más rápido que cargar uno por uno, y tiene menos código que nuestro primer intento. Los capítulos se pueden descargar en cualquier orden, pero aparecen en la pantalla en el orden adecuado.

Sin embargo, podemos mejorar aún más el rendimiento percibido. Cuando llega el capítulo uno, debemos agregarlo a la página. De esta forma, el usuario puede 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, se pueden agregar el capítulo dos, tres, etc.

Para poder hacerlo, se obtiene el JSON de todos los capítulos al mismo tiempo. Después, se crea 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 ahí lo tenemos, ¡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 potenciará cuando haya más cantidad de capítulos o estos sean más extensos.

Si hacemos lo mismo con eventos o callbacks al estilo Node.js, necesitaremos casi el doble de código y, lo que es más importante, no será 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: 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. Hay compatibilidad generalizada con promesas y 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 editaron este artículo, y realizaron correcciones y recomendaciones.

También, gracias a Mathias Bynens por actualizar varias partes del artículo.