La lliçó anterior va acabar amb un diagnòstic precís: els callbacks funcionen, però no retornen res. Com que el resultat futur no és un valor, no es pot guardar en una variable, ni passar a una funció, ni combinar, ni encadenar sense imbricar, i els errors deixen de propagar-se sols així que es travessa la frontera asíncrona. La solució del llenguatge va ser fer que aquell resultat futur sí que sigui un valor: un objecte anomenat promesa que representa «alguna cosa que encara no hi és, però hi serà». En aquesta lliçó aprendràs a crear-les, consumir-les i encadenar-les; veuràs com la piràmide del 05-05 s'aplana en una llista de passos; coneixeràs els quatre combinadors que resolen en una línia el que abans exigia comptadors manuals; i arribaràs a async/await, la sintaxi que fa que el codi asíncron es llegeixi exactament igual que el síncron, amb el seu try/catch funcionant per fi.

1. Què és una promesa: els tres estats
2. Crear una promesa amb new Promise
3. Prometificar llegirBacklogSimulat
4. Consumir: .then, .catch, .finally
5. Encadenar: com s'aplana la piràmide
6. Com es propaguen els errors per la cadena
7. Promise.resolve i Promise.reject
8. Els quatre combinadors
9. async i await
10. try/catch que per fi funciona
11. await en bucles davant de Promise.all
12. for await...of i await a nivell de mòdul
13. Els paranys d'async/await
14. Exemple integrador: carregarTauler()
15. La taula comparativa dels tres estils
16. Errors Habituals i Consells
17. Exercicis
18. Conclusió

Una promesa (Promise) és un objecte que representa el resultat d'una operació asíncrona. Existeix des de l'instant en què l'operació comença, molt abans que hi hagi resultat, i per això es pot guardar, passar i combinar com qualsevol altre valor.

A cada moment està en un de tres estats:

Dues propietats que defineixen tot el seu comportament:

• La transició és única i irreversible. Una promesa passa de pendent a complerta o a rebutjada, una sola vegada, i allà es queda. Un cop decidida, es diu que està saldada (settled). Això elimina d'una tacada el problema de la doble crida del 05-05: per molt que el codi cridi resolve cinc vegades, només compta la primera.
• El resultat es conserva. Si et subscrius a una promesa que ja està complerta, en reps el valor igualment. No cal «arribar a temps», al contrari que amb un esdeveniment.

Una diferència de vocabulari que evita confusions: una promesa rebutjada és un resultat normal i previst (el servidor ha retornat un 503), mentre que un error no gestionat és una fallada del programa. Totes dues coses fan servir objectes Error, però conceptualment són diferents.

El constructor rep una funció —anomenada executor— amb dos paràmetres: resolve i reject.

Punts clau de l'executor:

• S'executa immediatament, en el moment de crear la promesa. El que és asíncron és quan es crida resolve/reject, no quan comença la feina.
• resolve i reject són funcions normals; els seus noms són convenció, no obligació.
• Només compta la primera crida. Les següents s'ignoren en silenci.
• reject ha de rebre un Error, no un string. Només així conserves el missatge, el nom i la traça de 03-05.
• Una excepció llançada dins de l'executor rebutja la promesa automàticament. És el primer senyal que la propagació d'errors torna a funcionar.

Regla pràctica: new Promise només es fa servir per embolcallar alguna cosa que encara no parla en promeses —un setTimeout, una API antiga de callbacks—. Si ja tens una promesa, no l'emboliquis en una altra: és un antipatró tan comú que té nom, el constructor promesa explícit.

Convertir una funció de callbacks en una que retorni una promesa s'anomena prometificar, i és l'operació frontissa entre els dos mons.

Compara-la amb la versió de callbacks del 05-05. La diferència essencial és a la primera línia del cos: hi ha un return. La funció retorna alguna cosa, i aquella cosa és un valor de primera classe:

Cap d'aquelles tres línies era possible amb callbacks. I també existeix una recepta genèrica, útil quan prometifiques moltes funcions error-first:

És la mateixa idea de les funcions d'ordre superior de 03-06: una funció que rep una funció i retorna una altra funció.

Una promesa es consumeix registrant què fer quan se saldi.

.finally és l'equivalent del finally de 02-05 i serveix per al mateix: la neteja que cal fer passi el que passi —amagar un indicador de càrrega, tancar una connexió, reactivar un botó—. No rep arguments precisament perquè no ha de dependre del resultat, i no consumeix el valor: el deixa passar als .then següents.

Encara que .then(enComplir, enFallar) existeix, la forma recomanada és .then(...).catch(...), i hi ha un motiu tècnic: amb dos arguments, el gestor d'error no captura les fallades del mateix enComplir, perquè tots dos es registren sobre la mateixa promesa.

Aquí hi ha la propietat que ho canvia tot:

.then() retorna una promesa nova, complerta amb el que retorni el seu callback.

Això permet posar un .then darrere d'un altre en lloc d'imbricar-los. I hi ha una regla addicional que fa la màgia completa: si el callback retorna una promesa, la cadena espera que aquella se saldi i continua amb el seu valor, en lloc de passar la promesa mateixa.

Amb aquella eina, la piràmide de l'apartat 9 de 05-05 es converteix en una llista. Primer prometifiquem els altres dos mòduls simulats:

I ara l'informe setmanal de la Marta, el mateix del 05-05, sense ni una imbricació:

Tres millores respecte a la versió amb callbacks, i cap no és cosmètica:

1. La sagnia és plana. Els passos es llegeixen de dalt a baix, en l'ordre en què passen.
2. Hi ha un únic .catch. Si falla la càrrega, la consulta de l'equip o el desat, l'error acaba a la mateixa línia. Els tres blocs if (error) { … return; } repetits han desaparegut.
3. El flux és explícit. Cada return diu què es passa al pas següent.

Queda un defecte honest: aquella variable carrega fora de la cadena, necessària perquè el tercer .then necessita una dada que es va calcular al primer. És exactament el mateix problema d'estat compartit que ja va aparèixer en «aplanar amb funcions anomenades» a 05-05, i les promeses per si soles no el resolen del tot. Guarda la incomoditat: async/await la fa desaparèixer, perquè allà les variables són simplement variables locals.

Quan un pas falla, la cadena salta tots els .then següents fins al primer .catch. És el comportament de la pila síncrona de 02-05, recuperat.

Un error dins d'un .then provoca el mateix, encara que no sigui una operació asíncrona:

I —això és clau— la cadena es pot recuperar després d'un .catch, perquè .catch també retorna una promesa:

D'aquí una regla de col·locació important: el .catch captura el que passa per sobre d'ell a la cadena, no per sota. Si el poses al mig i vols que també protegeixi els passos següents, en necessites un altre al final. L'habitual és un sol .catch al final de tot.

Amb errors propis, el patró es combina amb la jerarquia de 05-02:

Dues dreceres per crear promeses ja saldades.

El seu ús més valuós és normalitzar: fer que una funció retorni sempre una promesa, hagi de treballar de debò o no.

Sense aquell Promise.resolve, la funció retornaria un array unes vegades i una promesa unes altres, i qui la fes servir ho hauria de comprovar. És la memoïtzació de 03-06, ara aplicada a operacions asíncrones.

Promise.resolve té a més una propietat molt pràctica: si li passes una promesa, la retorna tal qual, sense embolicar-la una altra vegada.

Aquí hi ha la resposta al «problema 4» del 05-05: combinar operacions asíncrones. Quatre mètodes estàtics, cadascun amb una semàntica diferent.

Promise.all — espera que totes es compleixin. Si una falla, falla el conjunt immediatament.

Dues coses que cal interioritzar. L'ordre de l'array de resultats és el d'entrada, no el d'arribada: encara que la Lucía respongui primer, el seu resultat continua a la tercera posició. I les tres peticions corren alhora: el total triga 500 ms —el que la més lenta—, no 1000 ms.

Promise.allSettled — espera que totes se saldin, complertes o rebutjades, i no falla mai.

Cada element és un objecte { status: 'fulfilled', value } o { status: 'rejected', reason }. És el que vols quan una fallada parcial és acceptable: prefereixes l'informe de dues persones a cap informe.

Promise.race — se salda amb la primera que acabi, tant si es compleix com si es rebutja. El seu ús canònic és imposar un temps màxim:

Un avís honest: el setTimeout intern no cancel·la l'operació lenta, que continua corrent encara que el seu resultat s'ignori. La cancel·lació de debò necessita AbortController, que arriba a 07-03.

Promise.any — es compleix amb la primera que es compleixi, ignorant els rebuigs. Només falla si fallen totes, amb un AggregateError.

La taula de decisió:

Tots quatre accepten qualsevol iterable i retornen una promesa. Compara mentalment aquestes quatre línies amb les vint de comptadors i banderes de l'apartat 10 de 05-05: això és el que significa que el resultat futur sigui un valor.

Les promeses van arreglar el flux, però el codi continua ple de .then((x) => …). Des d'ES2017 existeix una sintaxi que elimina fins i tot això.

async davant d'una funció fa que retorni sempre una promesa.

await davant d'una promesa n'espera el resultat i el retorna com si fos un valor normal. Només es pot fer servir dins d'una funció async (o al nivell superior d'un mòdul, apartat 12).

Que aquell await no bloqueja res és l'essencial i el que més costa de creure al principi. El que fa és suspendre aquesta funció en aquell punt i tornar el control al programa; quan la promesa se salda, la funció es reprèn just on s'havia quedat. El fil, mentrestant, està lliure per a tota la resta. El mecanisme exacte que ho permet és el tema de 05-07.

La mateixa cadena de l'apartat 5, reescrita:

Compara-ho amb la piràmide original de 05-05. És el mateix programa: tres operacions asíncrones encadenades, cadascuna dependent de l'anterior. I es llegeix exactament com es llegiria si tot fos síncron. La variable carrega ha tornat a ser una variable local, sense necessitat de treure-la a fora. No hi ha callbacks, no hi ha .then, no hi ha sagnia.

Un apunt de sintaxi: async funciona amb qualsevol forma de funció, incloses les fletxa de 03-02 i els mètodes de classe de 05-02.

A 02-05 vas aprendre try/catch, i a 05-05 vas descobrir que no servia per al que és asíncron. Amb await, torna a servir.

El motiu pel qual ara sí que funciona és precís: await converteix un rebuig en una excepció llançada en aquella mateixa línia. Com que el throw passa dins del try, a la mateixa pila, el catch el captura igual que capturaria un TypeError. Tota la maquinària de 02-05 torna a estar disponible: finally, instanceof per distingir tipus, rellançar el que no saps gestionar, la jerarquia ErrorDeValidacio/ErrorDeDades de 05-02.

I hi ha una simetria que convé tenir present:

Són la mateixa porta en els dos sentits, i per això els errors travessen sense problema la frontera entre funcions async i cadenes de promeses.

També pots barrejar estils quan convingui. Un patró útil és capturar només un await concret sense embolcallar mitja funció:

Aquest és l'error de rendiment més comú de tot async/await, i mereix un apartat propi.

Nou-cents mil·lisegons davant de tres-cents, amb tres elements. Amb trenta responsables serien nou segons davant de tres-cents mil·lisegons. La causa és que await dins d'un bucle atura el bucle: la segona petició ni tan sols s'envia fins que arriba la primera.

La clau de l'arranjament és en un detall que convé subratllar: una promesa comença a treballar en el moment en què es crea, no quan se li fa await. El .map() crea les tres promeses de cop —i les tres peticions surten alhora—; l'await Promise.all(...) només espera que totes acabin.

Ara bé: seqüencial no sempre està malament. És el correcte quan cada pas necessita el resultat de l'anterior, o quan vols limitar deliberadament la càrrega sobre el servidor.

I un advertiment sobre forEach, que és un parany clàssic:

forEach (04-04) descarta el valor de retorn del callback, així que les tres promeses queden soltes i ningú no les espera. Si necessites esperar, fes servir for...of amb await (seqüencial) o map + Promise.all (paral·lel). Mai forEach.

Quan el que tens és un array de promeses i vols processar-les a mesura que arriben, existeix una variant del bucle:

Les tres peticions arrenquen alhora (el map ja les va crear), i el bucle les va desembolicant en ordre d'array. El seu potencial de debò és recórrer fonts de dades asíncrones de longitud desconeguda —pàgines de resultats, fitxers que es llegeixen per trossos—, i per a això calen els iteradors asíncrons, que s'estudien a 05-08. Per ara n'hi ha prou amb reconèixer la sintaxi.

L'altre afegit és l'await a nivell de mòdul, que ja va aparèixer de passada a 05-04:

Tot mòdul que importi aquest esperarà que aquell await acabi abans d'executar-se. És còmode per a configuració imprescindible, però endarrereix l'arrencada de tota l'aplicació, així que convé fer-lo servir amb moderació i només a la capa de dades.

Quatre errors que cometràs alguna vegada. Convé reconèixer-los pel seu símptoma.

Parany 1: oblidar l'await. El símptoma és un Promise { <pending> } on esperaves una dada.

Parany 2: oblidar el return. La funció async es compleix amb undefined i ningú no se n'assabenta.

Un cas especialment insidiós és oblidar l'await dins d'un try:

Sense await, la funció retorna la promesa abans que es rebutgi, i el catch no veu res. La regla és return await quan el return és dins d'un try; fora d'un try, return promesa és equivalent i una mica més eficient.

Parany 3: rebuigs sense gestionar. Una promesa que es rebutja i no té cap .catch ni try/catch produeix un UnhandledPromiseRejection. Al navegador apareix com un error a la consola; a Node modern, acaba el procés.

Especialment traïdores són les promeses «òrfenes» que es llancen sense esperar (fire and forget). Si de debò no t'interessa el resultat, posa-li un .catch igualment, encara que només registri la fallada.

Parany 4: async en un constructor. No existeix: un constructor no pot ser async perquè ha de retornar l'objecte, no una promesa. El patró correcte és una fàbrica estàtica de les que vas aprendre a 05-02:

Reunim-ho tot a la funció que a partir d'ara serà l'arrencada de Nómada Tasques: carregar el backlog, validar-lo, construir el tauler i produir el resum, amb reserva local si el servidor falla i temps màxim d'espera.

I el punt d'entrada, que queda notablement curt:

Fixa't en el .catch de l'última línia: iniciar() és una funció async, retorna una promesa, i si alguna cosa s'escapa de tots els gestors interns aquell .catch és la xarxa de seguretat que evita un rebuig sense gestionar. Tota funció async que s'invoca des del nivell superior necessita aquell tancament.

La conclusió operativa: escriu async/await per defecte, fes servir .then/.catch quan encaixi millor —una transformació solta, un .catch de reserva en una línia—, recorre als combinadors per a tot el que sigui paral·lel, i reserva new Promise per embolcallar APIs antigues de callbacks. I no oblidis que els tres estils són el mateix mecanisme: async/await és sintaxi sobre promeses, i una promesa se salda gràcies a callbacks registrats per dins.

• Oblidar await. El símptoma és Promise { <pending> }, undefined en una propietat o un TypeError dient que un mètode no és una funció. És la primera hipòtesi quan alguna cosa asíncrona dona resultats estranys.
• Oblidar await dins d'un try. El rebuig s'escapa del bloc i el catch no se n'assabenta. Fes servir return await quan el return sigui dins d'un try.
• await dins d'un bucle sobre operacions independents. Multiplica el temps total pel nombre d'elements. Fes servir map + Promise.all.
• forEach amb un callback async. No espera res. Fes servir for...of o map + Promise.all.
• Promeses sense .catch. Un rebuig sense gestionar és un error al navegador i pot tombar el procés a Node. Tota cadena acaba en .catch, i tota funció async cridada des del nivell superior també.
• Embolcallar una promesa en new Promise. Si ja tens una promesa, encadena-la. new Promise és només per embolcallar el que encara no ho és.
• reject('text') amb un string. Perds nom i traça. Rebutja sempre amb un Error o una subclasse de les de 05-02.
• Promise.all quan toleres fallades parcials. Un sol rebuig tira tot el conjunt. Si prefereixes resultats parcials, allSettled.
• Creure que Promise.race cancel·la. No cancel·la res: l'operació perdedora continua corrent. La cancel·lació real és AbortController (07-03).
• Constructors async. No existeixen. Fes servir una fàbrica estàtica (static async carregar()).
• Consell: anomena les variables que contenen promeses de manera que es noti (promesaBacklog, pendents). Una variable anomenada tasques que en realitat és una promesa és una font inesgotable de despistes.

Exercici 1 — De callbacks a async/await. Reescriu la funció ambReintents de l'exercici 3 de 05-05 com a ambReintents(operacio, intents, esperaMs) on operacio retorna una promesa. Ha de reintentar fins a esgotar els intents, esperar entre ells i llançar l'últim error si tots fallen. Compta les línies i compara-les amb la versió de callbacks.

Exercici 2 — Informe paral·lel amb tolerància a fallades. Escriu informeDeCarrega(noms) que consulti les hores de diverses persones en paral·lel, inclogui a l'informe qui respongui i llisti a part qui falli, sense que una fallada tombi el conjunt. Prova-la amb ['Iván', 'Marta', 'Ningú', 'Lucía'] i verifica que les 45 h obertes continuen quadrant entre els tres reals.

Exercici 3 — Predir la sortida. Sense executar-lo, indica què imprimeix i en quin ordre, i explica cada línia. (Nota: aquí només es demana el resultat; el perquè exacte de l'ordre entre el que és síncron i el que és asíncron és el tema de 05-07.)

Exercici 1

Dotze línies de funció davant de les vint de la versió amb callbacks, i la comparació qualitativa és més eloqüent que el recompte: aquí tota la lògica és lògica. Un for normal compta els intents, un try/catch normal captura la fallada, un await normal espera entre reintents. Ha desaparegut la funció interna que existia només per poder repetir-se, han desaparegut els return de guarda després de cada crida al callback, i ha desaparegut la fragilitat de la doble crida: una promesa se salda una sola vegada per construcció. Fixa't també en el return await operacio() dins del try: aquí l'await és imprescindible, perquè sense ell el rebuig s'escaparia del bloc i no hi hauria reintent (parany 2 de l'apartat 13).

Exercici 2

Les 45 h canòniques quadren: 25 de l'Iván, 6 de la Marta i 14 de la Lucía. Tres decisions que mereixen comentari. L'elecció d'allSettled en lloc d'all és el cor de l'exercici: amb all, la fallada de 'Ningú' hauria tirat l'informe complet i no n'hauries vist ni una línia. El resultats.entries() és necessari perquè allSettled no diu a quina entrada correspon cada resultat; l'únic garantit és que l'ordre es conserva, i per això l'índex serveix per recuperar el nom. I les quatre consultes es llancen alhora al map, així que l'informe triga el que la més lenta, no la suma de les quatre.

Exercici 3

Línia per línia:

• A i B són síncrones dins de principal. Entremig es creen p1 i p2: pas és async, i el seu cos s'executa fins al primer await, així que els dos temporitzadors arrenquen immediatament i en paral·lel. Cap dels dos no imprimeix res encara.
• F surt després de B perquè principal() se suspèn al seu primer await i torna el control al nivell superior, que encara tenia aquell console.log pendent.
• D dos ha fallat: als 100 ms p2 es rebutja. Promise.all es rebutja a l'instant amb la primera fallada, sense esperar p1. Per això no s'imprimeix C.
• Mai no apareix fi dos (va llançar abans d'arribar al console.log), però sí que apareixeria fi un als 200 ms: p1 continua el seu curs encara que Promise.all ja l'hagi ignorada —recorda que res no es cancel·la—. El seu fi un es cola entre D i E.
• E [ 'fulfilled', 'rejected' ]: allSettled espera totes dues i no es rebutja mai; 'tres' imprimeix el seu fi tres i 'quatre' falla sense imprimir.

Amb fi un inclòs, la sortida completa és: A, B, F, D dos ha fallat, fi un, fi tres, E [...]. La lliçó que cal endur-se és doble: Promise.all falla ràpid però no cancel·la res, i una funció async cedeix el control al seu primer await, que és exactament el mecanisme que es dissecciona a la lliçó següent.

Has resolt els quatre problemes que va deixar la lliçó anterior, i tots amb la mateixa idea: fer que el resultat futur sigui un valor. Una promesa és un objecte amb tres estats —pendent, complerta, rebutjada—, amb una transició única i irreversible que fa impossible la doble crida, i amb el resultat conservat per a qui s'hi subscrigui més tard. Saps crear-la amb new Promise((resolve, reject) => …) —recordant que l'executor s'executa immediatament, que només compta la primera crida i que cal rebutjar amb Error—, i saps prometificar una API de callbacks, que és l'operació frontissa entre els dos mons i la que va convertir llegirBacklogSimulat en llegirBacklog.

Domines el consum. .then per al valor, .catch per a la fallada, .finally per a la neteja; i sobretot l'encadenament, perquè cada .then retorna una promesa nova i, si el seu callback en retorna una altra, la cadena l'espera. Això va aplanar la piràmide de l'informe setmanal en una llista de passos amb un sol .catch al final, i va restaurar la propagació automàtica d'errors que s'havia perdut en travessar la frontera asíncrona: una fallada en qualsevol baula salta fins al primer gestor, i un .catch intermedi pot fins i tot recuperar la cadena retornant un valor de reserva. Amb Promise.resolve normalitzes funcions que de vegades treballen i de vegades responen de memòria cau, i amb els quatre combinadors resols en una línia el que exigia comptadors manuals: all quan ho necessites tot, allSettled quan toleres fallades parcials, race per a temps màxims i any per a diverses fonts equivalents.

I has arribat a async/await, que és sintaxi sobre tot l'anterior. Una funció async retorna sempre una promesa —es compleix amb el return, es rebutja amb el throw—, i await suspèn aquella funció sense bloquejar el fil fins que la promesa se salda, lliurant el valor com si fos normal. Amb això, el try/catch torna a funcionar, perquè await converteix un rebuig en una excepció llançada en aquella mateixa línia, i amb ell tornen finally, l'instanceof per distingir ErrorDeValidacio d'ErrorDeDades, i el fail-fast de rellançar el que no saps gestionar. Coneixes l'error de rendiment clàssic —await dins d'un bucle sobre operacions independents, 900 ms en lloc de 300— i el seu arranjament amb map + Promise.all, recolzat en el detall que una promesa comença a treballar en crear-se, no en esperar-la; saps que forEach amb un callback async no espera res; i reconeixes for await...of i l'await a nivell de mòdul. Els quatre paranys —oblidar l'await, oblidar el return dins d'un try, deixar rebuigs sense gestionar, intentar un constructor async— estan identificats pel seu símptoma. I carregarTauler() ho reuneix tot: càrrega amb temps màxim, valida els invariants del backlog, cau a dades locals si el servidor falla i retorna el resum canònic de sempre —48 h, 45 obertes, 1 vençuda, esforç 124— en una funció que es llegeix de dalt a baix.

Queda una pregunta que hem anat esquivant expressament. Saps què fa await, però no per què l'ordre de la sortida és el que és: per què 'F' surt abans que el resultat d'una promesa ja complerta, per què un setTimeout(f, 0) s'executa després d'un .then registrat més tard, i per què un bucle pesat congela la interfície encara que hi hagi await pel mig. Tot això ho decideix una maquinària amb nom propi —la pila de crides, les APIs de l'entorn, la cua de macrotasques, la cua de microtasques i el bucle que les coordina— i és el tema d'El Bucle d'Esdeveniments i la Cua de Microtasques.