Verwendung von Promises

Verkettung

Ein hufiges Bedrfnis ist es, zwei oder mehr asynchrone Operationen hintereinander auszufhren, wobei jede nachfolgende Operation startet, wenn die vorherige erfolgreich ist, mit dem Ergebnis aus dem vorherigen Schritt. In der Vergangenheit fhrte die Durchfhrung mehrerer asynchroner Operationen hintereinander zum klassischen Callback-Hell:

doSomething(function (result) {
  doSomethingElse(result, function (newResult) {
    doThirdThing(newResult, function (finalResult) {
      console.log(`Got the final result: ${finalResult}`);
    }, failureCallback);
  }, failureCallback);
}, failureCallback);

Mit Promises erreichen wir dies, indem wir eine Promise-Kette erstellen. Das API-Design von Promises macht dies groartig, weil die Callbacks an das zurckgegebene Promise-Objekt angehngt werden, anstatt in eine Funktion bergeben zu werden.

Hier ist das Besondere: Die Funktion then() gibt ein neues Promise zurck, das sich vom ursprnglichen unterscheidet:

const promise = doSomething();
const promise2 = promise.then(successCallback, failureCallback);

Dieses zweite Promise (promise2) reprsentiert den Abschluss nicht nur von doSomething(), sondern auch von dem an successCallback oder failureCallback bergebenen Callback welche andere asynchrone Funktionen sein knnen, die ein Promise zurckgeben. Wenn dies der Fall ist, werden alle an promise2 hinzugefgten Callbacks hinter das Promise in die Warteschlange eingereiht, das von entweder successCallback oder failureCallback zurckgegeben wird.

function doSomething() {
  return new Promise((resolve) => {
    setTimeout(() => {
      // Andere Dinge, die vor dem Abschluss des Promises erledigt werden mssen
      console.log("Did something");
      // Der Erfllungswert des Promises
      resolve("https://example.com/");
    }, 200);
  });
}

Mit diesem Muster knnen Sie lngere Verarbeitungsreihen erstellen, bei denen jedes Promise den Abschluss eines asynchronen Schrittes in der Kette darstellt. Darber hinaus sind die Argumente zu then optional, und catch(failureCallback) ist kurz fr then(null, failureCallback) wenn also Ihr Fehlerbehandlungscode fr alle Schritte gleich ist, knnen Sie ihn am Ende der Kette anhngen:

doSomething()
  .then(function (result) {
    return doSomethingElse(result);
  })
  .then(function (newResult) {
    return doThirdThing(newResult);
  })
  .then(function (finalResult) {
    console.log(`Got the final result: ${finalResult}`);
  })
  .catch(failureCallback);

Sie knnten dies mit Pfeilfunktionen ausgedrckt sehen:

doSomething()
  .then((result) => doSomethingElse(result))
  .then((newResult) => doThirdThing(newResult))
  .then((finalResult) => {
    console.log(`Got the final result: ${finalResult}`);
  })
  .catch(failureCallback);

doSomethingElse und doThirdThing knnen jeden Wert zurckgeben wenn sie Promises zurckgeben, wird das Promise zuerst gewartet, bis es sich erfllt, und der nchste Callback erhlt den Erfllungswert, nicht das Promise selbst. Es ist wichtig, immer Promises von then-Callbacks zurckzugeben, selbst wenn das Promise immer undefined auflst. Wenn der vorherige Handler ein Promise gestartet hat, es aber nicht zurckgegeben hat, gibt es keine Mglichkeit, seine Behebung weiter zu verfolgen, und das Promise wird als "schwebend" angesehen.

doSomething()
  .then((url) => {
    // Missing `return` keyword in front of fetch(url).
    fetch(url);
  })
  .then((result) => {
    // result is undefined, because nothing is returned from the previous
    // handler. There's no way to know the return value of the fetch()
    // call anymore, or whether it succeeded at all.
  });

Indem wir das Ergebnis des fetch-Aufrufs (ein Promise) zurckgeben, knnen wir sowohl dessen Abschluss verfolgen als auch dessen Wert erhalten, wenn er abgeschlossen ist.

doSomething()
  .then((url) => {
    // `return` keyword added
    return fetch(url);
  })
  .then((result) => {
    // result is a Response object
  });

Schwebende Promises knnten schlimmer sein, wenn Sie Rennbedingungen haben wenn das Promise vom letzten Handler nicht zurckgegeben wird, wird der nchste then-Handler frhzeitig aufgerufen, und jeder Wert, den er liest, knnte unvollstndig sein.

const listOfIngredients = [];

doSomething()
  .then((url) => {
    // Missing `return` keyword in front of fetch(url).
    fetch(url)
      .then((res) => res.json())
      .then((data) => {
        listOfIngredients.push(data);
      });
  })
  .then(() => {
    console.log(listOfIngredients);
    // listOfIngredients will always be [], because the fetch request hasn't completed yet.
  });

Daher, als Daumenregel, wann immer Ihre Operation auf ein Promise trifft, geben Sie es zurck und berlassen Sie seine Behandlung dem nchsten then-Handler.

const listOfIngredients = [];

doSomething()
  .then((url) => {
    // `return` keyword now included in front of fetch call.
    return fetch(url)
      .then((res) => res.json())
      .then((data) => {
        listOfIngredients.push(data);
      });
  })
  .then(() => {
    console.log(listOfIngredients);
    // listOfIngredients will now contain data from fetch call.
  });

Noch besser ist es, die geschachtelte Kette in eine einzige Kette zu gltten, was einfacher ist und die Fehlerbehandlung erleichtert. Die Details werden im Abschnitt Schachtelung unten besprochen.

doSomething()
  .then((url) => fetch(url))
  .then((res) => res.json())
  .then((data) => {
    listOfIngredients.push(data);
  })
  .then(() => {
    console.log(listOfIngredients);
  });

Die Verwendung von async/await kann Ihnen helfen, Code zu schreiben, der intuitiver ist und synchronem Code hnelt. Unten ist dasselbe Beispiel mit async/await:

async function logIngredients() {
  const url = await doSomething();
  const res = await fetch(url);
  const data = await res.json();
  listOfIngredients.push(data);
  console.log(listOfIngredients);
}

Beachten Sie, wie der Code genau wie synchroner Code aussieht, auer fr die await-Schlsselwrter vor Promises. Eines der wenigen Kompromisse ist, dass es leicht sein kann, das await-Schlsselwort zu vergessen, das nur behoben werden kann, wenn ein Typ-Mismatch auftritt (z. B. der Versuch, ein Promise als Wert zu verwenden).

async/await baut auf Promises auf zum Beispiel ist doSomething() dieselbe Funktion wie zuvor, sodass nur minimales Refactoring erforderlich ist, um von Promises zu async/await zu wechseln. Sie knnen mehr ber die async/await-Syntax in den Referenzen zu asynchronen Funktionen und await lesen.

Fehlerbehandlung

Sie erinnern sich vielleicht, dass failureCallback dreimal in der Pyramide des Schreckens vorgekommen ist, verglichen mit nur einmal am Ende der Promise-Kette:

doSomething()
  .then((result) => doSomethingElse(result))
  .then((newResult) => doThirdThing(newResult))
  .then((finalResult) => console.log(`Got the final result: ${finalResult}`))
  .catch(failureCallback);

Wenn eine Ausnahme auftritt, sucht der Browser die Kette nach .catch()-Handlern oder onRejected ab. Dies ist stark nach dem Modell, wie synchroner Code funktioniert:

try {
  const result = syncDoSomething();
  const newResult = syncDoSomethingElse(result);
  const finalResult = syncDoThirdThing(newResult);
  console.log(`Got the final result: ${finalResult}`);
} catch (error) {
  failureCallback(error);
}

Diese Symmetrie mit asynchronem Code gipfelt in der async/await-Syntax:

async function foo() {
  try {
    const result = await doSomething();
    const newResult = await doSomethingElse(result);
    const finalResult = await doThirdThing(newResult);
    console.log(`Got the final result: ${finalResult}`);
  } catch (error) {
    failureCallback(error);
  }
}

Promises lsen einen grundlegenden Fehler mit der Callback-Pyramide des Schreckens, indem sie alle Fehler abfangen, sogar geworfene Ausnahmen und Programmierfehler. Dies ist essentiell fr die funktionale Komposition asynchroner Operationen. Alle Fehler werden jetzt von der catch()-Methode am Ende der Kette behandelt, und man sollte fast nie try/catch verwenden mssen, ohne async/await zu verwenden.

Schachtelung

In den obigen Beispielen mit listOfIngredients hat das erste einen in den Rckgabewert eines anderen then()-Handlers geschachtelten Promise-Strang, whrend das zweite eine vllig flache Kette verwendet. Einfache Promise-Ketten sollten flach gehalten werden, ohne Schachtelung, da Schachtelung das Ergebnis unvorsichtiger Komposition sein kann.

Schachtelung ist eine Kontrollstruktur, um den Geltungsbereich von catch-Anweisungen zu begrenzen. Konkret fngt ein geschachteltes catch nur Fehler in seinem Geltungsbereich und darunter ab, nicht aber Fehler, die hher in der Kette auerhalb des geschachtelten Bereichs liegen. Wenn dies richtig verwendet wird, bietet es eine grere Przision bei der Fehlerbehebung:

doSomethingCritical()
  .then((result) =>
    doSomethingOptional(result)
      .then((optionalResult) => doSomethingExtraNice(optionalResult))
      .catch((e) => {}),
  ) // Ignore if optional stuff fails; proceed.
  .then(() => moreCriticalStuff())
  .catch((e) => console.error(`Critical failure: ${e.message}`));

Beachten Sie, dass die optionalen Schritte hier geschachtelt sind die Schachtelung wird nicht durch die Einrckung, sondern durch die Platzierung der ueren ( und ) Klammern um die Schritte herum verursacht.

Der innere Fehlerunterdrckung-catch-Handler fngt nur Fehler von doSomethingOptional() und doSomethingExtraNice() ab, danach wird der Code mit moreCriticalStuff() fortgesetzt. Wichtig ist, dass, wenn doSomethingCritical() fehlschlgt, sein Fehler nur vom finalen (ueren) catch gefangen wird und nicht vom inneren catch-Handler unterdrckt wird.

In async/await sieht dieser Code so aus:

async function main() {
  try {
    const result = await doSomethingCritical();
    try {
      const optionalResult = await doSomethingOptional(result);
      await doSomethingExtraNice(optionalResult);
    } catch (e) {
      // Ignore failures in optional steps and proceed.
    }
    await moreCriticalStuff();
  } catch (e) {
    console.error(`Critical failure: ${e.message}`);
  }
}

Chaining nach einem Catch

Es ist mglich, nach einem Fehler, d.h. einem catch zu verketteten, was ntzlich ist, um nach einem fehlgeschlagenen Vorgang in der Kette neue Aktionen durchzufhren. Lesen Sie das folgende Beispiel:

doSomething()
  .then(() => {
    throw new Error("Something failed");

    console.log("Do this");
  })
  .catch(() => {
    console.error("Do that");
  })
  .then(() => {
    console.log("Do this, no matter what happened before");
  });

Dies gibt den folgenden Text aus:

Do that
Do this, no matter what happened before

In async/await sieht dieser Code so aus:

async function main() {
  try {
    await doSomething();
    throw new Error("Something failed");
    console.log("Do this");
  } catch (e) {
    console.error("Do that");
  }
  console.log("Do this, no matter what happened before");
}

Promise-Ablehnungsereignisse

Wenn ein Promise-Ablehnungsereignis von keinem Handler abgefangen wird, wird es bis zum oberen Ende des Aufrufstapels weitergegeben, und der Host muss es anzeigen. Im Web, wann immer ein Promise abgelehnt wird, wird eines von zwei Ereignissen an den globalen Bereich gesendet (in der Regel ist dies entweder das window oder, wenn es in einem Web Worker verwendet wird, das Worker oder eine andere arbeitnehmerbasierte Schnittstelle). Die beiden Ereignisse sind:

unhandledrejection

Wird gesendet, wenn ein Promise abgelehnt wird, aber kein Ablehnungshandler verfgbar ist.

rejectionhandled

Wird gesendet, wenn ein Handler an ein abgelehntes Promise angehngt wird, das bereits ein unhandledrejection-Ereignis verursacht hat.

In beiden Fllen hat das Ereignis (vom Typ PromiseRejectionEvent) als Mitglieder eine promise-Eigenschaft, die das abgelehnte Promise anzeigt, und eine reason-Eigenschaft, die den Grund angibt, warum das Promise abgelehnt wurde.

Diese ermglichen es, eine alternative Fehlerbehandlung fr Promises anzubieten und helfen dabei, Probleme mit Ihrem Promise-Management zu debuggen. Diese Handler sind global pro Kontext, sodass alle Fehler an dieselben Ereignis-Handler gehen, unabhngig von der Quelle.

In Node.js ist die Behandlung von Promise-Ablehnungen etwas anders. Sie erfassen unbehandelte Ablehnungen, indem Sie einen Handler fr das Node.js-unhandledRejection-Ereignis hinzufgen (achten Sie auf die Gro- und Kleinschreibung des Namens), so:

process.on("unhandledRejection", (reason, promise) => {
  // Add code here to examine the "promise" and "reason" values
});

Fr Node.js, um zu verhindern, dass der Fehler in die Konsole geloggt wird (die Standardaktion, die sonst erfolgen wrde), reicht es aus, diesen process.on()-Listener hinzuzufgen; es besteht keine Notwendigkeit fr ein quivalent zur preventDefault()-Methode der Browserlaufzeit.

Wenn Sie jedoch diesen process.on-Listener hinzufgen, aber keine Logik darin haben, um abgelehnte Promises zu behandeln, werden sie einfach ignoriert. Idealerweise sollten Sie daher Code innerhalb dieses Listeners hinzufgen, um jedes abgelehnte Promise zu untersuchen und sicherzustellen, dass es nicht durch einen tatschlichen Programmierfehler verursacht wurde.

Zusammensetzung

Es gibt vier Zusammensetzungstools fr die gleichzeitige Ausfhrung von asynchronen Operationen: Promise.all(), Promise.allSettled(), Promise.any(), und Promise.race().

Wir knnen Operationen gleichzeitig starten und warten, bis sie alle beendet sind, wie folgt:

Promise.all([func1(), func2(), func3()]).then(([result1, result2, result3]) => {
  // use result1, result2 and result3
});

Wenn eines der Promises im Array abgelehnt wird, lehnt Promise.all() sofort das zurckgegebene Promise ab. Die anderen Operationen laufen weiter, aber ihre Ergebnisse sind nicht ber den Rckgabewert von Promise.all() verfgbar. Dies kann zu unerwartetem Verhalten fhren. Promise.allSettled() ist ein weiteres Zusammensetzungstool, das sicherstellt, dass alle Operationen abgeschlossen sind, bevor es aufgelst wird.

Diese Methoden fhren alle Promises gleichzeitig aus eine Folge von Promises wird gleichzeitig gestartet und wartet nicht aufeinander. Sequenzielle Zusammensetzung ist mit einigem cleveren JavaScript mglich:

[func1, func2, func3]
  .reduce((p, f) => p.then(f), Promise.resolve())
  .then((result3) => {
    /* use result3 */
  });

In diesem Beispiel reduzieren wir ein Array von asynchronen Funktionen zu einer Promise-Kette. Der obige Code entspricht:

Promise.resolve()
  .then(func1)
  .then(func2)
  .then(func3)
  .then((result3) => {
    /* use result3 */
  });

Dies kann zu einer wiederverwendbaren Compose-Funktion gemacht werden, die in der funktionalen Programmierung blich ist:

const applyAsync = (acc, val) => acc.then(val);
const composeAsync =
  (...funcs) =>
  (x) =>
    funcs.reduce(applyAsync, Promise.resolve(x));

Die composeAsync()-Funktion akzeptiert beliebig viele Funktionen als Argumente und gibt eine neue Funktion zurck, die einen Anfangswert akzeptiert, der durch die Kompositionspipeline geleitet wird:

const transformData = composeAsync(func1, func2, func3);
const result3 = transformData(data);

Sequentielle Zusammensetzung kann auch prgnanter mit async/await durchgefhrt werden:

let result;
for (const f of [func1, func2, func3]) {
  result = await f(result);
}
/* use last result (i.e. result3) */

Bevor Sie jedoch Promises sequentiell zusammensetzen, berlegen Sie, ob es wirklich notwendig ist es ist immer besser, Promises gleichzeitig auszufhren, sodass sie sich nicht unntig blockieren, es sei denn, die Ausfhrung eines Promises hngt von dem Ergebnis eines anderen ab.

Abbruch

Promise selbst verfgt ber kein erstklassiges Protokoll fr den Abbruch, aber es ist mglich, die zugrunde liegende asynchrone Operation direkt abzubrechen, typischerweise mit AbortController.

Erstellen eines Promises um eine alte Callback-API

Ein Promise kann von Grund auf neu mit seinem Konstruktor erstellt werden. Dies sollte nur bentigt werden, um alte APIs zu umschlieen.

In einer idealen Welt wrden alle asynchronen Funktionen bereits Promises zurckgeben. Leider erwarten einige APIs immer noch, dass Erfolgs- und/oder Fehler-Callbacks auf die alte Weise bergeben werden. Das offensichtlichste Beispiel ist die setTimeout()-Funktion:

setTimeout(() => saySomething("10 seconds passed"), 10 * 1000);

Das Mischen von Rckrufen im alten Stil und Promises ist problematisch. Wenn saySomething() fehlschlgt oder einen Programmierfehler enthlt, fngt nichts dies ab. Dies ist intrinsisch zum Design von setTimeout().

Glcklicherweise knnen wir setTimeout() in ein Promise verpacken. Die beste Praxis besteht darin, die rckrufannehmenden Funktionen so niedrig wie mglich zu umschlieen und sie dann nie wieder direkt aufzurufen:

const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

wait(10 * 1000)
  .then(() => saySomething("10 seconds"))
  .catch(failureCallback);

Der Promise-Konstruktor akzeptiert eine Ausfhrungsfunktion, die es uns ermglicht, ein Promise manuell aufzulsen oder abzulehnen. Da setTimeout() nicht wirklich fehlschlgt, haben wir reject in diesem Fall weggelassen. Weitere Informationen darber, wie die Ausfhrungsfunktion funktioniert, finden Sie in der Promise()-Referenz.

Timing

Zum Schluss schauen wir uns noch die technischen Details an, wann die registrierten Callbacks aufgerufen werden.

Garantien

In der rckrufbasierten API hngt es vom API-Implementierer ab, wann und wie der Rckruf aufgerufen wird. Zum Beispiel knnte der Rckruf synchron oder asynchron aufgerufen werden:

function doSomething(callback) {
  if (Math.random() > 0.5) {
    callback();
  } else {
    setTimeout(() => callback(), 1000);
  }
}

Das obige Design wird stark abgeraten, da es zum sogenannten "Zalgo-Zustand" fhrt. Im Kontext des Entwerfens asynchroner APIs bedeutet dies, dass ein Rckruf in einigen Fllen synchron, in anderen Fllen jedoch asynchron aufgerufen wird und so Ambiguitten fr den Anrufer entstehen. Weitere Hintergrundinformationen finden Sie im Artikel Designing APIs for Asynchrony, wo der Begriff erstmals formell vorgestellt wurde. Dieses API-Design macht Nebeneffekte schwer analysierbar:

let value = 1;
doSomething(() => {
  value = 2;
});
console.log(value); // 1 or 2?

Auf der anderen Seite sind Promises eine Form der umgekehrten Kontrolle der API-Implementierer kontrolliert nicht, wann der Rckruf aufgerufen wird. Stattdessen wird die Verwaltung der Rckrufwarteschlange und die Entscheidung, wann die Rckrufe aufgerufen werden, an die Promise-Implementierung delegiert, und sowohl der API-Anwender als auch der API-Entwickler erhalten automatisch starke semantische Garantien, einschlielich:

• Rckrufe, die mit then() hinzugefgt werden, werden niemals vor dem Abschluss des aktuellen Laufs der JavaScript-Ereignisschleife aufgerufen.
• Diese Rckrufe werden aufgerufen, auch wenn sie nach dem Erfolg oder Misserfolg der asynchronen Operation, die das Promise darstellt, hinzugefgt wurden.
• Mehrere Rckrufe knnen hinzugefgt werden, indem then() mehrmals aufgerufen wird. Sie werden nacheinander in der Reihenfolge aufgerufen, in der sie eingefgt wurden.

Um berraschungen zu vermeiden, werden Funktionen, die an then() bergeben werden, niemals synchron aufgerufen, auch nicht bei einem bereits gelsten Promise:

Promise.resolve().then(() => console.log(2));
console.log(1);
// Logs: 1, 2

Anstatt sofort zu laufen, wird die bergebene Funktion in eine Microtask-Warteschlange gestellt, was bedeutet, dass sie spter ausgefhrt wird (nur nachdem die Funktion, die sie erstellt hat, beendet ist und wenn der JavaScript-Ausfhrungsstack leer ist), gerade bevor die Kontrolle an die Ereignisschleife zurckgegeben wird; d.h. ziemlich bald:

const wait = (ms) => new Promise((resolve) => setTimeout(resolve, ms));

wait(0).then(() => console.log(4));
Promise.resolve()
  .then(() => console.log(2))
  .then(() => console.log(3));
console.log(1); // 1, 2, 3, 4

Aufgabenwarteschlangen vs. Microtasks

Promise-Callbacks werden als Microtask behandelt, wohingegen setTimeout()-Callbacks als Aufgabenwarteschlangen behandelt werden.

const promise = new Promise((resolve, reject) => {
  console.log("Promise callback");
  resolve();
}).then((result) => {
  console.log("Promise callback (.then)");
});

setTimeout(() => {
  console.log("event-loop cycle: Promise (fulfilled)", promise);
}, 0);

console.log("Promise (pending)", promise);

Der obige Code gibt Folgendes aus:

Promise callback
Promise (pending) Promise {<pending>}
Promise callback (.then)
event-loop cycle: Promise (fulfilled) Promise {<fulfilled>}

Weitere Details finden Sie unter Aufgaben vs. Microtasks.

Wenn Promises und Aufgaben kollidieren

Wenn Sie auf Situationen stoen, in denen Sie Promises und Aufgaben (wie Ereignisse oder Rckrufe) haben, die in unvorhersehbaren Reihenfolgen ausgelst werden, ist es mglich, dass Sie von der Verwendung eines Microtasks profitieren knnten, um den Status zu berprfen oder Ihre Promises auszugleichen, wenn Promises bedingt erstellt werden.

Wenn Sie glauben, dass Microtasks zur Lsung dieses Problems beitragen knnen, lesen Sie den Microtask-Leitfaden, um mehr darber zu erfahren, wie Sie queueMicrotask() verwenden, um eine Funktion als Microtask in die Warteschlange einzureihen.

Siehe auch

• Promise
• async function
• await
• Promises/A+ specification
• We have a problem with promises auf pouchdb.com (2015)

• Zurck
• Weiter