ECMAScript 6: Generators

Achtung: dieser Beitrag ist alt! Es kann gut sein, dass seine Inhalte nicht mehr aktuell sind.

Generators sind eins der Features von ECMAScript 6, die erhebliche Auswirkungen auf die tägliche JS-Programmierpraxis haben werden. So werden durch Generators vor allem asynchrone Operationen zum Kinderspiel; also genau jene Teile des JS-Alltags, die heutzutage im besten Fall nur mit lästiger Fummelei verbunden sind und im schlimmsten Fall mit dem Abgleiten in die callback hell enden. Da mittlerweile die ersten Browser und auch Node.js Generators implementieren, lohnt sich ein gründlicher Blick auf dieses neue Werkzeug bereits heute, denn wie gesagt: asynchrone Programmierung wird durch Generators extrem vereinfacht. Alles, was vorher in einer ünübersichtlichen Callback-Verschachtelung endete, kann mit dem neuen ES6-Feature und einem altbekannten JS-Pattern in übersichtlichen Sequenzen ausgedrückt werden. Klingt sehr kompliziert, ist es aber eigentlich gar nicht.

Was ist ein Generator?

Das ECMAScript-Wiki beschreibt Generators wie folgt:

First-class coroutines, represented as objects encapsulating suspended execution contexts (i.e., function activations).

In irdischer Sprache formuliert handelt es sich um pausierbare Funktionen. Diese Funktionen (bzw. die aus ihnen erstellten Objekte) können eine Anzahl von Werten ausgeben und ihrerseits mit neuen Werten gefüttert werden. Jede Ausgabe eines Werts pausiert die Funktion, jede Fortsetzung der Funktion bietet die Möglichkeit, einen neuen Wert in die Funktion einzugeben.

Ein Generator ist das Produkt einer generator function, einer JS-Funktion mit einer speziellen Syntax:

// Generator Function
var genFn = function*(){
};

// Generator
var gen = genFn();

Hier ist genFn die generator function und gen der Generator. Eine generator function also ist eine Vorlage, die einen Generator produziert. Sie unterscheidet sich durch zwei Merkmale von einer herkömmlichen Funktion; neben dem * hinter function kann in ihr yield anstelle bzw. als Ergänzung zu return verwendet werden.

Aus dem Generator …

Wird auf einem Generator-Objekt die next()-Methode aufgerufen, wird der Code der erstellenden generator function ausgeführt, bis das erste yield erreicht wird. Dieses neue Schlüsselwort ist wie return, in dem Sinne dass es einen Wert zurückgibt. Allerdings ist mit dem ersten yield die Funktion nicht beendet, sondern nur an exakt dieser Stelle pausiert. Am besten versteht man das an einem super-simplen (und entsprechend nutzlosen) Beispiel:

// Generator Function
var genFn = function*(){
  yield 1;
  yield 2;
  yield 3;
};

// Generator
var gen = genFn();

Ein Aufruf von gen.next() führt dazu, dass die generator function ausgeführt wird, allerdings nur bis zum ersten yield. Das yield gibt vergleichbar mit return einen Wert zurück. Im Unterschied zu return beendet yield allerdings die weitere Ausführung der Funktion nur vorläufig. Die Funktion merkt sich, an welcher Position im Code das yield stattgefunden hat und beim nächsten Aufruf von next() macht sie an genau dieser Stelle weiter. Man kann also gen.next() drei mal aufrufen und bekommt jedes mal einen anderen Wert, weil der Reihe nach alle drei yield drankommen:

var genFn = function*(){
  yield 1;
  yield 2;
  yield 3;
};
var gen = genFn();

gen.next(); // > { value: 1, done: false }
gen.next(); // > { value: 2, done: false }
gen.next(); // > { value: 3, done: false }
gen.next(); // > { value: undefined, done: true }
gen.next(); // > Exception: Generator has already finished

Der Wert, den next() zurückgibt, ist ein Objekt, dass nebem dem Wert in der Eigenschaft value auch ein done-Flag enthält, das angibt, ob der Generator komplett abgearbeitet wurde. Nach drei Aufrufen von next() sind alle yield drangekommen und entsprechend gibt es keinen Wert mehr, sondern nur noch undefined mit dem Hinweis done: true. Ein weiterer Aufruf next() wird mit einer Exception quittiert.

Mit Generatoren lassen sich allerlei Dinge anstellen, die man anders in JavaScript nicht auf die Reihe bekommt. Eine endlose (wirklich endlose) Zahlenreihe zu repräsentieren ist mit ihnen zum Beispiel ein Kinderspiel:

var genFn = function*(){
  var i = 0;
  while(true){
    yield i++;
  }
};
var gen = genFn();

Hier kann man gen.next() aufrufen bis man grün wird, die Zahlenreihe endet nie. Gleichmaßen führt die Generator-Funktion selbst nicht zu einer Browser-Blockade, da die while-Schleife nach jedem Durchlauf mit yield verlassen und erst bei gen.next() wieder betreten wird. Somit ist auch klar, warum wir hier von generators sprechen – die generator function beschreibt eine Sequenz und jedes Mal wenn wir das aus ihr produzierte Objekt anstoßen, wird ein entsprechender Wert generiert.

Für Dinge wie endlose Zahlenreihen brauchen wir auch nicht mehr zum Thema Generator zu wissen. Wer aber jenseits der Fibonacci-Zahlen noch Use Cases für den Browser-Alltag sucht, sollte aber wissen, dass man sich ein Generator auch gerne mit neuen Inputs füttern lässt.

… in den Generator

Was yield von return unterscheidet ist neben der eingebauten Hier-Gleich-Weitermachen-Funktionalität auch, dass man von außen an die Stelle von yield einen Wert in den Generator hineinwerfen kann. Im folgenden Codebeispiel sorgt der erste Aufruf von next() dafür, dass die Funktion bis zum ersten yield kommt, wo 23 zurückgegeben wird. Der nächste next()-Aufruf erhält mit 42 einen Wert, und da die Funktion direkt nach dem vorherigen yield fortgesetzt wird, wird dieser Wert an die Stelle des vorher zurückgebenen gesetzt; im Prinzip steht dann dort die Zeile i = 42. Entsprechend ist das, was schließlich mit return zurückgegeben wird, der Wert 42.

var genFn = function*(){
  var i = yield 23;
  return i;
};
var gen = genFn();

// Ausführung bis zum yield; 23 wird durch yield ausgegeben
gen.next();   // > { value: 23, done: false }

// Fortsetzung ab dem yield; 42 wird an die Stelle des yield eingegeben
gen.next(42); // > { value: 42, done: true }

Ein Generator kann also nicht nur einen Wert zurückgeben und dann pausieren, wir können auch bestimmen mit welchem Wert der Generator weitermacht. Dieses Feature erlaubt es, aus einem Generator einen Wert auszuwerfen, den Wert zu transformieren und ihn dann wieder in den Generator hineinzustecken, der dann mit dem transformierten Wert fortfährt. Man könnte zum Beispiel einen Generator Objekte auswerfen lassen, die von der Außenwelt auf einen Wert reduziert und wieder in den Generator hineingeworfen werden:

var genFn = function*(){
  var sum = yield [1, 2, 3];
  var factor = 2;
  return sum * factor;
};

var gen = genFn();

var arr = gen.next().value;
var sum = arr.reduce(function(x, y){
  return x + y;
});
var result = gen.next(sum).value; // > 12

Der Generator wirft ein Array aus, das außerhalb des Generators zu einer einzigen Zahl reduziert und wieder in Generator hineingesteckt wird. Da dieses Hineinstecken genau an der Stelle des yield passiert, könnte man sagen dass sich der Ausdruck sum = yield [1, 2, 3] in sum = neuerWert verwandet; so erhält sum als Wert die Zahl, die außerhalb des Generators aus dem Arrays errechnet wurde. Durch diese Zuweisung an sum kann der Generator den außen errechneten Wert dann weiterverwerten, ihn mit dem factor multiplizieren und das finale Endergebnis ausgeben.

Besonders sinnvoll mag dieses Beispiel nicht erscheinen, was aber vor allem daran liegt, dass es eine ganz wesentliche Eigenschaft von Generators gar nicht benutzt; die Pause-Funktion! Das Reduzieren des Arrays könnte ja theoretisch auch eine lang dauernde, asynchrone Operation sein. Wenn dies der Fall wäre, würde das aber den Code der generator function gar nicht berühren:

var genFn = function*(){
  var sum = yield [1, 2, 3];
  var factor = 2;
  return sum * factor;
};

var gen = genFn();

var arr = gen.next().value;

// Asynchrones errechnen des Wertes aus dem Array
setTimeout(function(){
  var sum = arr.reduce(function(x, y){
    return x + y;
  });
  var result = gen.next(sum).value; // > 12
}, 1000);

Die durch die generator function beschriebene Sequenz bleibt, wie sie ist; dass anderswo asynchrone Operationen passiert, ist egal, denn nach dem yield ist der Generator schließlich pausiert. Er wartet auf das nächste next(), bevor er seine Berechnung zum Ende bringt. Wenn man das zuende denkt, könnte man Code formulieren, der eine generator function so verarbeitet, dass der Code der Funktion lediglich eine Abfolge von asynchronen Operationen darstellt und die Aufrufe von next() automatisch passieren. In unserer täglichen Arbeit schreiben wir also nur noch so etwas …

async(function*(){
  var wert1 = yield macheWasAsynchrones();
  var wert2 = yield macheWasAnderesAsynchrones();
  whatever(wert1 + wert2);
});

… und die async()-Funktion kümmert sich um den Rest. Wir können uns damit von der callback hell für immer verabschieden und es ist noch nicht mal schwer: wir müssen nur das bisher über Generators gelernte mit althergebrachten Promises kombinieren.

Rein-Raus-Ajax via Generator

Startet man einen Ajax-Request mit jQuerys $.get() so gibt diese Funktion ein Objekt zurück, das die asynchrone Operation kapselt. An dieses Objekt lassen sich Callbacks hängen, die feuern sobald die Ajax-Operation abgeschlossen ist.

var operation = $.get('/api/foo');
operation.then(function erfolgCallback(data){
  console.log('Yay!', data);
}, function failCallback(){
  console.log('Ups!');
});

Diese Objekte gibt es nicht nur bei Ajax-Requests und nicht nur in jQuery, sondern sehr viele JS-Libraries können derartiges liefern. Diese promises genannten Objekte abstrahieren alle Arten von asynchrone Operationen hinter einer immergleichen API; sie alle produzieren Objekte mit einer then()-Methode und triggern Callbacks wenn die hinter den Kulissen ablaufende Operationen beendet werden. Objekte und asynchrone Operationen? Das klingt nach einem Job für einem Generator! Die generator function müsste einfach Promises auswerfen …

var genFn = function*(){
  $('#Alpha').text(yield $.get('/api/alpha'));
  $('#Beta').text(yield $.get('/api/beta'));
  $('#Gamma').text(yield $.get('/api/gamma'));
};

… die durch externen Code aufgelöst und deren Resultate zurück in den Generator gegeben werden:

function async(genFn){
  var gen = genFn();
  var resume = function(promise){
    return promise.done(function(text){
      var next = gen.next(text);
      if(!next.done){
        return resume(next.value);
      }
    });
  };
  return resume(gen.next().value);
}

Fertig! (funktioniert Stand Ende 2013 in Chrome mit aktiviertem Experimentelles-JS-Flag und Firefox-Vorabversionen)

Die async()-Funktion nimmt eine generator function und erstellt aus ihr den Generator gen. Die resume()-Funktion nimmt ein Promise (bezogen aus gen.next().value) und hängt dort mittels done() einen Callback an. Feuert der Callback, wird dessen erster Parameter in den Generator hereingesteckt und sofern der Generator nicht schon sein letztes yield hinter sich hatte das nächste Promise in resume() gesteckt. So fertigt async() Schritt für Schritt die Generator-Sequenz ab, ganz ohne dass der Autor der Sequenz auch nur einen Moment lang über Callbacks nachdenken müsste, vorausgesetzt die yields im Generator geben immer Promises zurück.

In ihrer jetzigen Form ist die async()-Funktion freilich noch ausbaufähig; zum Beispiel hat sie noch keine Zeile für den Fall, dass eine der Async-Operationen fehlschlägt. Fehlerbehandlung nachzurüsten ist aber kein Problem, denn die Generator-API hat neben next() noch ein paar weitere nützliche Funktionen.

Weitere Generator-Funktionen

Neben next() bieten Generators auch eine throw()-Methode. Diese erlaubt es, einen Wert in den Generator zu werten, an der Stelle des letzten yield eine Exception auslöst. So kann man problemlos Fehler, die in asynchronen Operationen außerhalb des Generators passieren an die das Problem auslösende Stelle im Generator zurückführen: und schon funktioniert try-catch mit asynchronem Code!

var genFn = function*(){
  $('#Alpha').text(yield $.get('/api/alpha'));
  $('#Beta').text(yield $.get('/gibt/es/nicht/404')); // Exception tritt hier auf
  $('#Gamma').text(yield $.get('/api/gamma'));
};

function async(genFn){
  var gen = genFn();
  var resume = function(promise){
    return promise.done(function(text){
      var next = gen.next(text);
      if(!next.done){
        return resume(next.value);
      }
    }).fail(function(err){
      gen.throw(err.status);
    });
  };
  return resume(gen.next().value);
}

try {
  async(genFn);
} catch(e){
  console.log(e);
}

Außerdem können Generators mit den in ES6 ebenfalls neuen neuen for-of-Schleifen benutzt werden (Demo):

var genFn = function*(){
  var i = 0;
  while(i < 100){
    yield i++;
  }
};

var gen = genFn();

for(var num of gen){
  console.log(num);
}

Die for-of-Schleife ist ein universeller Iterationsmechanismus, mit dem in ES6-JS nicht nur Generators, sondern alle möglichen Sorten von Objekten verarbeitet werden können. Das Iterator-Konzept ist allerdings ein eigenes Thema für einen späteren Zeitpunkt – spannender dürfte aktuell die Frage sein, wie es denn um die Implementierung von Generators in heutigen JavaScript-Engines bestellt ist.

Unterstützung für Generators

Native und weitgehend standardkonforme Unterstützung für Generators findet sich Stand Ende 2013 in Chrome (vorausgesetzt der Exterminelles-JavaScript-Flag wurde in den Einstellungen aktivieren), in Firefox-Vorabversionen und in mit dem Parameter --harmony gestartenen Node-Umgebungen. Außerdem kann die Generator-Syntax nebst allen APIs vom Traceur-Compiler in JavaScript übersetzt werden, das jeder heutige Browser versteht. Erwartungsgemäß vervielfacht sich durch den Übersetzungsprozess die Code-Menge aber im Prinzip gilt: Generators funktionieren!

Kommentare (5)

  1. Robert Agthe

    5. Dezember 2013, 21:36 Uhr

    Also ich würde das ganze ehrlich gesagt aktuell nie für Callbacks nutzen. Anstatt jetzt Callbacks und die Logik an ort und stelle zu haben, habe ich eine zentrale methode die jetzt meine diversen anderen Methoden, die wiederum ansynchrone funktionen enthalten zeitgesteuert ausführen? Und ausserdem muss der ajax response exakt gleich sein, da ich bei Abweichungen ja WIEDER callbacks einführen muss (oder ein anderen Konstrukt)? Ausserdem kann ich nun methoden nicht mehr direkt aufrufen sondern muss das mit einer hässlichen async() methode tun, was am ende ja eh wiedern callback ist? Also glaube das kanns wohl noch nicht so sein, jedenfalls die erhoffte Lösung ;)

  2. Peter Kröner

    5. Dezember 2013, 22:47 Uhr

    Also ich würde das ganze ehrlich gesagt aktuell nie für Callbacks nutzen. Anstatt jetzt Callbacks und die Logik an ort und stelle zu haben, habe ich eine zentrale methode die jetzt meine diversen anderen Methoden, die wiederum ansynchrone funktionen enthalten zeitgesteuert ausführen? Und ausserdem muss der ajax response exakt gleich sein, da ich bei Abweichungen ja WIEDER callbacks einführen muss (oder ein anderen Konstrukt)?

    Die Generators werden ja auch nicht mit Callbacks genutzt (jedenfalls nicht in diesem Beispiel) sondern mit Promises. Da gibt es keine Abweichungen. Und es ist ja auch nicht gesagt, dass jeder asynchrone Code in einer großen Generator Function stehen muss. Nur wirklich zusammengehörige Sequenzen gehören da zusammengefasst.

    Ausserdem kann ich nun methoden nicht mehr direkt aufrufen sondern muss das mit einer hässlichen async() methode tun, was am ende ja eh wiedern callback ist?

    Das ist kein Callback, denn der Generator selbst wird ja nicht asynchron erzeugt. Der Aufruf von async(fn) ist halt der einzig sinnvolle Weg um den Code der Generator Function fn abzuarbeiten. Aber selbst wenn: diese eine Funktionsverschachtelung in async() ist die einzige die wir je schreiben müssen, selbst bei komplexeren Sequenzen. Das hier läuft zwar z.Z. nur im Firefox Nightly, weil ich da Destructuring verwende, aber da wäre es kein Problem, in die loadAndDisplay()-Sequenz weitere asynchrone Operationen einzubauen, einfach indem man sie unter alle anderen Operationen anbaut. Das ist sehr viel bequemer als Callback-Verkettungen.

  3. Robert Agthe

    6. Dezember 2013, 09:43 Uhr

    Dein Beispiel ist da recht einfach. Wenn man allerdings mehrere, unterschiedliche abfolgen von promises (das sind für mich halt anders geschriebene callbacks) hat, braucht man für jede kombination eben so ein async(fn) teil. Das finde ich halt extrem unelegeant. Dein Fiddle würde ich zb. so lieber lösen:

    
    // daten holen usw.
    getData = function() {
        return $.post('/echo/html/', { html: 'Neue Nachricht', delay: 2 });
    }
    // kram ins dom dingsen, promise zurückgeben
    changeDomMessage = function(newMessage) {
        return $('.message').text(newMessage).promise();
    } 
    
    // nachricht ausfaden, promise zurückgeben
    hideMessage = function(){
        return $('.message').hide('slow').promise();
    }
    
    // nachricht anzeigen, promise zurückgeben
    showMessage = function(){
        return $('.message').show('slow').promise()
    }
    
    // jegliche erdenkliche asynchrone abfolge erstellen
    hideMessage().then(getData).then(changeDomMessage).then(showMessage)
    
    // oder einfach nur nachricht laden & tauschen ohne den fade scheiss
    getData.then(changeDomMessage)
    
    // usw.
    

    fiddle gucken

    liest sich gut, schreibt sich gut, geht in jedem browser. Um quasi das mit yield umzusetzen, bräuchte ich eine helper methode (async(fn) ) und müsste jede kombination an asynchronen funktionen in eine methode wrappen. Ist halt anders, aber empfinde ich nicht als besser oder hilfreicher. Empfinde es wie gesagt als sehr unhübsch. Und bei großen Projekten wirds ja immer schnell unübersichtlich. Nicht das ich yield schlecht reden möchte, versuche es nur zu begreifen, für was es gut sein soll. bzw es sinnvoll in mein universum zu integrieren.

  4. Peter Kröner

    31. Dezember 2013, 14:30 Uhr

    liest sich gut, schreibt sich gut, geht in jedem browser.

    Nur sieht dein Code so doch realistischerweise nicht aus, denn die ganzen then() brauchen schließlich noch Fehler-Callbacks. Mit Generators mache ich einfach ein Try-Catch um den Funktionsaufruf und bin fertig. Ist jetzt in diesem Simpel-Beispiel mangels Fehlerquellen nicht so drastisch, aber bei komplizierteren Sequenzen wo mehr schiefgehen kann, macht das einen Unterschied.

    Und dass man mit async() eine zusätzliche Funktion braucht, ist nur solange wahr, bis etwas derartiges in den ganzen Promise-Libraries selbst (inkl. jQuery) gelandet ist. Da gehört‘s nämlich rein, genau so wie es da ja auch $.when() etc. gibt.

  5. Robert Agthe

    9. Januar 2014, 17:04 Uhr

    Noch der Vollständigkeit halber. diese "then()" aktzeptieren auch mehrere Parameter:

    .then( doneFilter [, failFilter ] [, progressFilter ] )

    Man kann also durchaus noch eine allgemeine Fail Methode basteln (throwError) und die immer mitgeben:

    // jegliche erdenkliche asynchrone abfolge erstellen
    hideMessage()
    .then(getData, throwError)
    .then(changeDomMessage,  throwError)
    .then(showMessage)
    

    Oder, was auch geht. einfach ein fail() anhängen. Der catcht dann alles:

    // jegliche erdenkliche asynchrone abfolge erstellen
    hideMessage()
    .then(getData)
    .then(changeDomMessage)
    .then(showMessage)
    .fail(throwError)
    

    Das ganze mit "yield" zu lösen sehe ich ein. Ist eben eine weitere Möglichkeit, finde es nur nicht so "Bahnbrechend". Vielleicht verstehe ich auch noch nicht die komplette Eleganz :D

Die Kommentarfunktion ist seit Juli 2014 deaktiviert, weil sie zu sehr von Suchmaschinenoptimierern für manuellen Spam mißbraucht wurde. Wenn du Anmerkungen oder Fragen zum Artikel hast, schreib mir eine E-Mail oder melde dich via Twitter.

Folgt mir!

Kauft mein Zeug!

Cover der HTML5-DVD
Infos auf html5-dvd.de, kaufen bei Amazon

Cover des HTML5-Buchs
Infos auf html5-buch.de, kaufen bei Amazon

Cover des CSS3-Buchs
Infos auf css3-buch.de, kaufen bei Amazon