Promesas de JavaScript: introducción

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

Jake Archibald

Prepárense, desarrolladores, para un momento crucial en la historia del desarrollo web.

[Comienza el redoble de tambores]

¡Las promesas llegaron a JavaScript!

[Explotan fuegos artificiales, cae papel brillante desde arriba, el público se vuelve loco]

En este punto, te encuentras en una de las siguientes categorías:

• Las personas te vitorean, pero no sabes por qué. Quizás ni siquiera sepas qué es una "promesa". Te encogerías de hombros, pero el peso del papel brillante te oprime los hombros. Si es así, no te preocupes, me llevó mucho tiempo entender por qué debería preocuparme por estas cosas. Probablemente quieras comenzar por el principio.
• ¡Golpeas el aire! Ya era hora, ¿verdad? Ya usaste estas cosas de Promise antes, pero te molesta que todas las implementaciones tengan una API ligeramente diferente. ¿Cuál es la API para la versión oficial de JavaScript? Probablemente quieras comenzar con la terminología.
• Ya lo sabías y te burlas de quienes saltan de alegría como si fuera una novedad. Tómate un momento para disfrutar de tu propia superioridad y, luego, ve 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 bien para agregar promesas a otros navegadores y a Node.js, consulta el polyfill (2 KB comprimido con gzip).

¿De qué se trata todo este alboroto?

JavaScript es de un solo subproceso, lo que significa que dos fragmentos de secuencia de comandos no pueden ejecutarse al mismo tiempo, sino que deben ejecutarse uno después del 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 estilos y el control de las acciones del usuario (como destacar texto y la interacción con los controles de formularios). La actividad en uno de estos elementos retrasa los demás.

Como ser humano, eres multihilo. 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 conduces y tratas de mantener una conversación. No quieres escribir código que sea estornudable.

Probablemente hayas usado eventos y devoluciones de llamada para solucionar 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 me da alergia. 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 comenzáramos a escucharlos, por lo que debemos solucionar ese 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 detecta las imágenes que generaron un error antes de que tuviéramos la oportunidad de escucharlas. Lamentablemente, el DOM no nos brinda una forma de hacerlo. Además, esto carga una imagen. Las cosas se complican aún más si queremos saber cuándo se cargó un conjunto de imágenes.

Los eventos no siempre son la mejor manera

Los eventos son ideales para situaciones que pueden ocurrir varias veces en el mismo objeto (keyup, touchstart, etcétera). Con esos eventos, no te importa lo que sucedió antes de que adjuntaras el objeto de escucha. Pero cuando se trata de éxito o falla asíncronos, 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 mejores nombres. 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 completarse correctamente o fallar una vez. No puede tener éxito o fallar dos veces, ni puede cambiar de éxito a falla o viceversa.
• Si una promesa se completó correctamente o falló y, más adelante, agregas una devolución de llamada de éxito o error, se llamará a la devolución de llamada correcta, aunque el evento haya tenido lugar antes.

Esto es muy útil para el éxito o el error asíncronos, 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 corrigió la primera versión de este artículo y me calificó con una "F" por la terminología. Me castigó, me obligó a copiar Estados y destinos 100 veces y les escribió una carta preocupada a mis padres. A pesar de eso, todavía confundo muchos términos, pero aquí tienes los conceptos básicos:

Una promesa puede ser lo siguiente:

• fulfilled: La acción relacionada con la promesa se completó correctamente.
• rejected: La acción relacionada con la promesa falló.
• pendiente: Aún no se cumplió o rechazó.
• settled: Se cumplió 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 exentrenador de la selección inglesa de fútbol Terry Venables, por lo que lo usaré lo menos posible.

¡Las promesas llegan a JavaScript!

Las promesas existen desde hace un tiempo en forma de bibliotecas, como las siguientes:

• P
• Cuándo
• WinJS
• RSVP.js

Las promesas anteriores y las de JavaScript comparten un comportamiento estandarizado común llamado Promises/A+. Si eres usuario de jQuery, tienen algo similar llamado Deferreds. Sin embargo, los objetos Deferred no cumplen con Promise/A+, lo que los hace ligeramente diferentes y menos útiles, así que ten cuidado. jQuery también tiene un tipo Promise, pero este es solo un subconjunto de Deferred y tiene los mismos problemas.

Si bien las implementaciones de promesas siguen un comportamiento estandarizado, sus APIs generales difieren. Las promesas de JavaScript son similares en la API a RSVP.js. Sigue estos pasos para 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 la promesa toma un argumento, una devolución de llamada con dos parámetros, resolve y reject. Haz algo dentro de la devolución de llamada, tal vez de forma asíncrona, y, luego, llama a resolve si todo funcionó o, de lo contrario, llama a reject.

Al igual que throw en JavaScript simple, es habitual, 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.

Así es como usas 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 de éxito y otra para el caso de falla. Ambos son opcionales, por lo que puedes agregar una devolución de llamada solo para el caso de éxito o de falla.

Las promesas de JavaScript comenzaron en el DOM como "Futures", se renombraron como "Promises" y, finalmente, se trasladaron a JavaScript. Tenerlos en JavaScript en lugar del DOM es genial porque estarán disponibles en contextos de JS que no son del navegador, como Node.js (si los usan en sus APIs principales es otra cuestión).

Aunque son una función de JavaScript, el DOM no teme usarlos. De hecho, todas las APIs del DOM nuevas con métodos asíncronos de éxito o error usarán promesas. Esto ya sucede con Quota Management, Font Load Events, ServiceWorker, Web MIDI, Streams y muchos más.

Compatibilidad con otras bibliotecas

La API de promesas de JavaScript tratará cualquier elemento con un método then() como similar a una promesa (o thenable en el lenguaje de promesas suspiro), por lo que, si usas una biblioteca que devuelve una promesa de Q, no habrá problemas, ya que funcionará bien con las nuevas promesas de JavaScript.

Aunque, como mencioné, los objetos Deferred de jQuery son un poco… inútiles. Afortunadamente, puedes convertir estos objetos en promesas estándar, lo que vale la pena hacer lo antes posible:

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

Aquí, $.ajax de jQuery devuelve un objeto Deferred. Como tiene un método then(), Promise.resolve() puede convertirlo en una promesa de JavaScript. Sin embargo, a veces, los objetos 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) {
  // ...
})

Mientras que las promesas de JS ignoran todas, excepto la primera:

jsPromise.then(function(response) {
  // ...
}, function(xhrObj) {
  // ...
})

Afortunadamente, esto suele ser 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 simplificado

Bien, codifiquemos algunas cosas. Supongamos que queremos hacer lo siguiente:

1. Inicia un spinner para indicar la carga
2. Recupera algo de JSON para un cuento, lo que nos da el título y las URLs de cada capítulo.
3. Agrega un título a la página
4. Recupera cada capítulo
5. Agrega la historia a la página
6. Detén el spinner

… pero también infórmale al usuario si algo salió mal en el proceso. También deberemos detener el spinner en ese punto, ya que, de lo contrario, seguirá girando, se mareará y chocará con otra IU.

Por supuesto, no usarías JavaScript para entregar una historia, ya que servir como HTML es más rápido, pero este patrón es bastante común cuando se trabaja con APIs: se recuperan varios datos y, luego, se hace algo cuando todo está listo.

Para comenzar, veamos cómo recuperar datos de la red:

Cómo convertir XMLHttpRequest en una promesa

Las APIs antiguas se actualizarán para usar promesas, si es posible de forma retrocompatible. XMLHttpRequest es un candidato principal, pero, mientras tanto, escribamos 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 el exasperante uso de mayúsculas y minúsculas de XMLHttpRequest, más feliz será mi vida.

Encadenamiento

then() no es el final de la historia, puedes encadenar thens para transformar valores o ejecutar acciones asíncronas adicionales una tras otra.

Transformación de valores

Puedes transformar valores simplemente devolviendo 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:

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

La respuesta es JSON, pero actualmente la recibimos como texto sin formato. Podríamos modificar nuestra función get para usar el responseType de JSON, pero también podríamos resolverlo en la tierra 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 devuelve 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 devuelve una promesa, una que recupera una URL y, luego, analiza la respuesta como JSON.

Cómo poner en cola acciones asíncronas

También puedes encadenar thens 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á al siguiente then() con ese valor. Sin embargo, si devuelves algo similar a una promesa, el siguiente then() espera a que se resuelva y solo se llama cuando se resuelve esa promesa (se completa correctamente 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í hacemos una solicitud asíncrona a story.json, que nos proporciona un conjunto de URLs para solicitar, y luego solicitamos la primera de ellas. Es aquí cuando las promesas realmente comienzan a destacarse de los patrones de devolución de llamada simples.

Incluso podrías 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 llama a getChapter, pero la próxima vez 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 para el éxito y otro para el error (o fulfill y reject, 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, solo es 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 extremadamente útil. Los rechazos de promesas se adelantan 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 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 bloque try/catch normal de JavaScript. Los errores que ocurren dentro de un "try" van inmediatamente al bloque catch(). Este es el diagrama 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 una promesa se rechaza de forma explícita, pero también de forma implícita si se arroja 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 nuestros 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., error HTTP 500 o el usuario está sin conexión), se omitirán todas las devoluciones de llamada de éxito posteriores, 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 cambio, pasa a la devolución de llamada catch. Como resultado, se agregará el mensaje "No se pudo mostrar el capítulo" a la página si falló alguna de las acciones anteriores.

Al igual que con try/catch de JavaScript, se detecta el error y continúa el código posterior, por lo que el spinner siempre está oculto, 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 desees catch() simplemente para registrar el error, sin recuperarte de él. Para ello, solo vuelve a arrojar 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. Hagamos que eso suceda.

Paralelismo y secuenciación: cómo obtener lo mejor de ambos

Pensar de forma asíncrona no es fácil. Si tienes dificultades para comenzar, 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'

¡Funciona! Pero se sincroniza y bloquea el navegador mientras se descarga el contenido. 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 iterar a través de 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 operaciones asíncronas, por lo que nuestros capítulos aparecerían en el orden en que se descarguen, que es básicamente cómo se escribió Pulp Fiction. Esto no es Pulp Fiction, así que vamos a corregirlo.

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 en cualquier valor que le des. Si le pasas una instancia de Promise, simplemente la devolverá (nota: Este es un cambio en la especificación que algunas implementaciones aún no siguen). Si le pasas algo similar a una promesa (tiene un método then()), crea un Promise genuino que se cumple 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 ningún valor, como se muestra arriba, se completará con "undefined".

También existe Promise.reject(val), que crea una promesa que se rechaza con el valor que le das (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())

Esto hace lo mismo que el ejemplo anterior, pero no necesita la variable "sequence" 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 devolvimos en la llamada anterior. array.reduce es muy útil para reducir un array a un solo valor, que, en este caso, es una promesa.

Combinemos 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í lo tenemos, una versión completamente asíncrona de la versión síncrona. Pero podemos hacerlo mejor. Por el momento, nuestra página se descarga de la siguiente manera:

Los navegadores son bastante buenos para descargar varias cosas a la vez, por lo que perdemos rendimiento al descargar capítulos uno tras otro. Lo que queremos hacer es descargarlos todos al mismo tiempo y, luego, procesarlos cuando hayan llegado todos. 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 correctamente. Obtienes un array de resultados (lo que las promesas cumplieron) 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 los elementos 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 capítulo uno, debemos agregarlo a la página. Esto permite que el usuario comience a leer antes de que lleguen el resto de los capítulos. Cuando llegue el capítulo tres, no lo agregaríamos a la página porque es posible que el usuario no se dé cuenta de que falta el capítulo dos. Cuando llegue el capítulo dos, podemos agregar los capítulos dos y tres, y así sucesivamente.

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 listo, lo mejor de ambos mundos. Se 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 casi 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 devoluciones de llamada o eventos al estilo de Node.js requiere el doble de código, pero, lo que es más importante, no es tan fácil de seguir. Sin embargo, esta no es la última palabra sobre 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 Promises se expandió considerablemente. Desde Chrome 55, las funciones async permiten escribir código basado en promesas como si fuera síncrono, pero sin bloquear el subproceso principal. Puedes obtener más información sobre eso en mi artículo sobre funciones asíncronas. Los principales navegadores admiten de forma generalizada tanto las promesas como las funciones asíncronas. Puedes encontrar los detalles en las referencias de Promise y async function de MDN.

Muchas gracias a Anne van Kesteren, Domenic Denicola, Tom Ashworth, Remy Sharp, Addy Osmani, Arthur Evans y Yutaka Hirano, quienes revisaron este documento y realizaron correcciones y recomendaciones.

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