Der JavaScript-Event-Loop: Sag die Ausgabe voraus

Ein Spinner, der lügt

Ein typischer Bug. Stell dir ein Formular mit einem Button „Alle speichern“ vor. Du klickst. Der Spinner blinkt kurz auf, dann erscheint die Erfolgsmeldung. Gespeichert ist aber noch nichts. Drei Requests sind noch unterwegs.

Der Code nach der Schleife hat nicht auf sie gewartet. Er lief zuerst. Die nächste Ansicht liest die Daten, und die Daten sind nicht da.

Um zu verstehen, warum, spielen wir ein bisschen. Jedes Rätsel zeigt Code. Klick die Konsolenzeilen in der Reihenfolge an, die du erwartest, und prüf dann. Erst aus dem Bauch heraus. Ein falscher Tipp bringt dir mehr als ein richtiger.

Rätsel 1: Was loggt das?

console.log('1')setTimeout(() => console.log('2'), 0)Promise.resolve().then(() => console.log('3'))console.log('4')

Was ist da passiert?

Geh es Schritt für Schritt durch. Drück auf Weiter oder nutz die Pfeiltasten und sieh dir an, wie sich die Listen ändern.

console.log('1')setTimeout(() => console.log('2'), 0)Promise.resolve().then(() => console.log('3'))console.log('4')

Drei Dinge sind wichtig:

• Der Call Stack enthält die Funktion, die gerade läuft. JavaScript führt immer nur eine Sache aus, und eine laufende Funktion wird nie unterbrochen.
• Die Microtask-Queue enthält Promise-Callbacks (.then und den Code nach await) sowie alles, was du an queueMicrotask übergibst.
• Die Task-Queue enthält Callbacks wie Timer und Events.

Hier ist die Regel. Wenn der aktuelle Code fertig und der Call Stack leer ist, führt der Browser alle Microtasks aus. Erst danach nimmt er den nächsten Task.

Darum verliert setTimeout(fn, 0) gegen .then. Nicht weil es langsam ist, sondern weil es in einer anderen Queue wartet.

Rätsel 2: async und await

Gleiches Spiel, jetzt mit async und await. Vorsicht: Der Funktionsrumpf läuft nicht am Stück.

async function load() {console.log('A')await nullconsole.log('B')}console.log('C')load()console.log('D')

async function load() {  console.log('A')  await null  console.log('B')}console.log('C')load()console.log('D')

Eine async-Funktion läuft bis zum ersten await wie eine normale Funktion. Am await pausiert sie, und der Aufrufer macht weiter. Der Rest der Funktion wird als Microtask eingeplant. Deshalb kommt B zuletzt.

Merk dir diesen Satz: Der Code nach await ist ein Microtask.

Rätsel 3: Microtasks, die Microtasks anlegen

Noch eins. Achte auf die Reihenfolge der Microtasks und darauf, was mit dem passiert, der in einem anderen angelegt wird.

setTimeout(() => console.log('timeout'), 0)queueMicrotask(() => console.log('micro 1'))Promise.resolve().then(() => {console.log('micro 2')queueMicrotask(() => console.log('micro 3'))})console.log('sync')

Der Browser nimmt den nächsten Task erst, wenn die Microtask-Queue leer ist. Das gilt auch für Microtasks, die andere Microtasks angelegt haben.

Das hat einen Preis. Ein Microtask, der ständig neue Microtasks anlegt, sorgt dafür, dass die Queue nie leer wird. Der Browser kommt nie zum nächsten Task und kann den Bildschirm nicht aktualisieren. Die Seite friert ein, und im Code steht nirgends eine lange Schleife.

Zurück zum Spinner

Hier ist der Bug vom Anfang.

async function saveAll(items: Item[]) {
  setSaving(true)

  items.forEach(async item => {
    await save(item)
  })

  setSaving(false)
  showToast('Saved')
}

forEach ruft deinen async-Callback für jedes Element auf. Jeder Aufruf läuft bis zum ersten await und gibt ein Promise zurück. forEach schaut sich diese Promises nicht an. Es wartet nicht auf sie. Die Zeilen danach laufen also sofort.

Probier es auf drei Arten aus. Die Speichervorgänge sind fake: Timer mit 400, 700 und 300 ms. Die Zahlen werden auf deinem Rechner gemessen, ein paar Millisekunden Rauschen sind normal.

forEach schaltet den Spinner nach etwa 0 ms aus, während die Speichervorgänge noch laufen. for...of mit await wartet auf jeden Vorgang nacheinander und braucht deshalb etwa 1400 ms. Promise.all startet alle drei gleichzeitig und braucht ungefähr so lange wie der langsamste, etwa 700 ms.

Zwei Wege zur Lösung:

   setSaving(true)

-  items.forEach(async item => {
-    await save(item)
-  })
+  // Fix A: one after the other
+  for (const item of items) {
+    await save(item)
+  }
+
+  // Fix B: all at once (use A or B, not both)
+  await Promise.all(items.map(item => save(item)))

   setSaving(false)
   showToast('Saved')

Nimm for...of, wenn die Reihenfolge zählt oder ein Vorgang das Ergebnis des vorherigen braucht. Nimm Promise.all, wenn die Vorgänge unabhängig sind. Das ist schneller. Beachte, dass es abgelehnt wird, sobald ein Vorgang fehlschlägt.

Den Main Thread spüren

Der Zähler unten zählt Animations-Frames. Er hängt an requestAnimationFrame, das deinen Callback vor dem nächsten Repaint ausführt. Solange er tickt, lebt die Seite.

Drück den ersten Button. Eine lange Schleife ist ein langer Task. Der Browser kann den Bildschirm nur zwischen zwei Tasks aktualisieren, also friert der Zähler ein.

Drück den zweiten Button. Es ist dieselbe Arbeit, nur in kleine Häppchen geschnitten. Nach jedem Häppchen gibt der Code den Thread mit scheduler.yield() zurück, oder mit setTimeout(fn, 0), wenn der Browser das nicht kennt. Zwischen den Häppchen kann der Browser zeichnen, und der Zähler läuft weiter.

Prüf dich selbst

Drei Fragen. Ohne Punkte, aber mit einer Erklärung zu jeder.

Spickzettel

1. Die Reihenfolge: synchroner Code, dann alle Microtasks, dann der nächste Task.
2. Microtasks: Promise.then, catch und finally, der Code nach await, queueMicrotask.
3. Tasks: setTimeout, setInterval und Events wie Klicks.
4. In Schleifen: for...of wartet auf jedes await, Promise.all führt sie zusammen aus, forEach wartet gar nicht.