JavaScript-Generators durch die Array-Linse betrachtet

Veröffentlicht am 30. März 2020

JavaScript-Arrays in wenigen Worten abschließend zu beschreiben ist fast unmöglich, denn sie sind so vielseitig! Je nach Einsatzszenario fungieren sie als Stack (Methoden push() und pop()), als Tuple (mit fester Länge und gemischtem Inhalt) oder als das, was in anderen Programmiersprachen als „Array“ oder „List“ bezeichnet wird. Außerdem implementieren sie das Iterationsprotokoll, sind also kompatibel zu for-of-Schleifen und vielen anderen nativen Sprachkonstrukten. Wenn wir nicht zu genau hinschauen und keine unangenehmen Fragen stellen, können wir uns vielleicht mit der Umschreibung „iterierbare Liste von Werten“ zufriedengeben.

Genau das Gleiche lässt sich über JavaScript-Generators sagen. Sie sind vergleichsweise neu, vergleichsweise selten und, genau wie Arrays, extrem vielseitig. Wenn wir nicht zu genau hinschauen und keine unangenehmen Fragen stellen, können wir uns auch für Generators mit der Umschreibung „iterierbare Liste von Werten“ zufriedengeben. Sobald wir uns auf diese Sichtweise einlassen, werden Generators zu einem schönen Werkzeug für den Alltag!

Generators sind Objekte, die Generator Functions entspringen, fast normalen function-Functions mit einem Sternchen dahinter. In Generator Functions ist das yield-Keyword verfügbar. Dieses fungiert ein wenig wie ein return-Statement und gibt den Wert auf seiner rechten Seite heraus. Damit lässt sich eine Sequenz bzw. eine Liste formulieren, die in der Benutzung einem Array nicht unähnlich ist:

// Generator Function
function * genFn () {
  yield 0;
  yield 1;
  yield 2;
}

// Generator
const numberGenerator = genFn();

// Generator wie ein Array verwenden
for (const number of numberGenerator) {
  console.log(number); // 0, 1, 2
}

Ein Generator Function ist im Prinzip ein Template für eine Sequenz bzw. Liste. Die Schritte der Sequenz sind die Ausdrücke auf der rechten Seite der yield-Statements, und die Liste ergibt sich, wenn die Schleife die Sequenz durchgeht und der Reihe nach 0, 1 und 2 generiert werden.

Das sieht auf den ersten Blick etwas exotisch aus, aber vergleichen wir das Ganze doch mal mit dem folgenden Code:

// Fast eine Generator Function
function genFn () {
  const values = [];
  values.push(0);
  values.push(1);
  values.push(2);
  return values;
}

// Quasi ein Generator
const numbers = genFn();

// Array wie einen Generator verwenden
for (const number of numbers) {
  console.log(number); // 0, 1, 2
}

Unter der JavaScript-Haube geht hier zwar etwas ganz anderes ab, als mit Generators, aber nicht vergessen: heute schauen wir nicht allzu genau hin und stellen keine unangenehmen Fragen. Wir erreichen mit beiden Codeschnipseln das gleiche Ziel einer Liste von Zahlen, wobei der Ansatz mit Generators einige Vorteile (oder zumindest interessante Tradeoffs) bietet.

Ein erster Vorteil ist, dass ein Generator immer eine Liste von Werten abbildet, zumindest bei unserer vereinfachten Betrachtungsweise. Das bedeutet, dass eine leere Liste besonders einfach zu bauen ist: wir machen einfach gar kein yield:

// Nur Werte liefern, wenn "someCondition" true ist

function createArray () {
  const values = [];
  if (someCondition) {
    values.push(0);
    values.push(1);
    values.push(2);
  }
  return values;
}

function * createGenerator () {
  if (someCondition) {
    yield 0;
    yield 1;
    yield 2;
  }
}

Die Vereinfachung ist offensichtlich und selbsterklärend: wenn ein Generator implizit immer eine Liste liefert, brauchen wir, anders als bei der Array-Funktion, keine zu erstellen und zurückzugeben. Ein weiterer Bonus liegt darin, dass es, ausgehend von der Beschreibung des Problems im Kommentar, nur einen Weg gibt, createGenerator() zu schreiben: wenn Bedingung, dann yield Werte. Über die Formulierung von createArray() könnte man hingegen streiten. Vielleicht wäre ein Early Return besser? Oder undefined statt eines leeren Arrays? Bei Generators stellt sich diese Frage praktischerweise gar nicht.

Sollte ein Early Return gewünscht sein, geht der Vorteil des Generators dahin:

// Wenn "someCondition" true ist, Early Return durchführen

function createArray () {
  if (someCondition) {
    return [ 42 ]; // Ausgabe + Ende der Funktion
  }
  const values = [];
  values.push(0);
  values.push(1);
  values.push(2);
  return values;
}

function * createGenerator () {
  if (someCondition) {
    yield 42; // Ausgabe
    return;   // Ende der Funktion
  }
  yield 0;
  yield 1;
  yield 2;
}

Einerseits ist es bei createArray() nötig, die zurückgegebene 42 händisch in ein Array zu verpacken, was beim Generator entfällt. Dieser benötigt dafür ein yield und ein return-Statement; return 42 ist zwar im Prinzip erlaubt, liefert aber die 42 nicht in der erzeugten Liste, sondern irgendwo im Nirvana ab.

Wiederum für Generators spricht, dass es neben dem normalen yield noch eine Art Super-Yield gibt, das den Inhalt anderer Generators herausgibt:

function * createStrings () {
  yield "A";
  yield "B";
  yield "C";
}

function * createValues () {
  yield 0;
  yield 1;
  yield 2;
  yield* createStrings();
}

for (const value of createValues()) {
  console.log(value)
}
// > 0, 1, 2, "A", "B", "C"

Das yield* in der Zeile yield* createStrings() gibt anders als das normale yield nicht einfach den Wert auf seiner rechten Seite (den Generator) aus, sondern das, was der Generator erzeugt! Und das klappt auch mit anderen iterierbaren Objekten, nicht nur mit Generatoren:

function * createValues () {
  yield 0;
  yield 1;
  yield 2;
  yield* [ "A", "B", "C" ]; // klappt auch mit Arrays!
}

for (const value of createValues()) {
  console.log(value)
}
// > 0, 1, 2, "A", "B", "C"

yield* fungiert also eine Art implizites flatMap() für alles mögliche an listen-artigen Datenstrukturen, nicht nur für Generators. Das ist ein ziemlich mächtiges Feature! Die Bedingung hierfür ist allerdings, dass yield* auch verwendet werden kann, was ausschließlich direkt in Generator Functions möglich ist. Callbacks sind also ein syntaktisches Problem:

function * createValues () {
  yield 0;
  setTimeout( () => {
    yield 1; // > SyntaxError
  }, 1000);
  yield 2;
}

Mit Arrays würde der Code zwar nicht mit einem Error abbrechen, sondern „funktionieren“ …

function createValues () {
  const values = [];
  values.push(0);
  setTimeout( () => {
    values.push(1);
  }, 1000);
  values.push(2);
  return values;
}

…aber trotzdem ein großes Problem darstellen! Immerhin wird hier ein Array aus der Funktion ausgegeben, in das nach seiner Ausgabe noch zusätzliche Werte hinterlegt werden – ein sicheres Rezept für Bugs und Verwirrung. An sich ist aber das Konzept einer Liste, in der sich erst nach und nach Werte einfinden, durchaus sinnvoll und wird z.B. durch die Observables in RxJS umgesetzt. Mit Arrays lässt sich dieses Konzept, wie wir gesehen haben, nicht wirklich abbilden und ein Timeout-Callback in einem Generator ist, wie wir ebenfalls gesehen haben, syntaktisch nicht mit yield kombinierbar. Das bedeutet aber nicht, dass Generators und setTimeout() nicht wunderbar zusammenpassen würden – der Timeout darf sich nur nicht im Generator befinden, sondern muss nach außen verfrachtet werden.

Wir können Generators unter gewissen Bedingungen mit Arrays vergleichen, aber es gibt einen wichtigen Unterschied: Generators sind lazy und liefern nur dann Werte, wenn Werte angefordert werden. Dies geschieht mit der Generator-Methode next():

function * createGenerator () {
  yield 0; // landet in a
  yield 1; // landet in b
  yield 2; // wird nie angefordert
}

const generator = createGenerator();
const a = generator.next(); // { value: 0, done: false }
const b = generator.next(); // { value: 1, done: false }

Jeder Aufruf von next() liefert ein Objekt, in dem das Feld value den Wert rechts des letzten yield-Statements enthält und in dem done nur true ist, wenn der Generator abgearbeitet wurde bzw. ein return-Statement erreicht wurde. In obigen Beispiel finden nur zwei Aufrufe von next() statt, was bedeutet, dass das yield 2 in der Generator Function nie erreicht wird und nie eine 2 in die Welt gesetzt wird. Bei einer Funktion, die ein Array liefert, sähe das anders aus:

function createArray () {
  const values = [];
  values.push(0); // landet in a
  values.push(1); // landet in b
  values.push(2); // braucht niemand, ist trotzdem im Array
  return values;
}

const list = createArray();
const a = list[0]; // 0
const b = list[1]; // 1

Auch wenn der dritte Wert nie verwendet wird, so landet er doch im Array, unmittelbar beim Aufruf der Funktion. Es ist erwähnenswert, dass Arrays zwar ganz anders funktionieren als Generators, aber auch eine Generators entsprechende API anbieten:

const gen = function * () {
  yield 23;
  yield 42;
}();

gen.next(); // > { value: 23, done: false }
gen.next(); // > { value: 42, done: false }

const arr = [ 23, 42 ];

const arrIter = arr[Symbol.iterator]();
arrIter.next(); // > { value: 23, done: false }
arrIter.next(); // > { value: 42, done: false }

Im speziellen Feld Symbol.iterator verstecken Arrays eine Funktion, die einen Iterator für das betroffene Array bereitstellt. Dieser Iterator unterstützt ebenso wie ein Generator die next()-Methode, weswegen for-of-Schleifen beide Objekt-Typen gleich unterstützen. Der Unterschied bleibt aber bestehen: während der Generator Werte erst generiert, sind sie beim Array von Anfang an vorhanden und binden entsprechend Ressourcen.

Wir halten fest: sowohl Arrays als auch Generators bilden Listen von Werten ab und beide unterstützen das Iterator-Protokoll mit der next()-Methode. Dank des Iterator-Protokolls können Arrays wie Generators von for-of-Schleifen konsumiert werden, von Array.from() in (neue) Arrays überführt werden oder manuell via next() iteriert werden. Der große Unterschied ist zwischen Arrays und Generator ist, dass letztere lazy sind und daher immer nur den Code bis zum nächsten yield ausführen. Der Unterschied zwischen for-of bzw. Array.from() und der next()-Methode ist, dass letztere (da sie ja nur eine Funktion ist) in Callbacks gesteckt und damit asynchron verarbeitet werden kann. Daraus folgt: setTimeout() und Generators können sehr wohl zusammen verwendet werden, der Timeout muss nur außerhalb der Funktion stattfinden:

function * createGenerator () {
  yield 0;
  yield 1;
  yield 2;
}

const generator = createGenerator();

setTimeout( function consumeValue () {
  const next = generator.next();
  if (!next.done) {
    console.log(next.value);
    setTimeout(consumeValue, 1000);
  }
}, 1000);

Dieser Aufruf schreibt nicht nur mit einer Sekunde Abstand Abstand 0, 1 und 2 in die Konsole, sondern erzeugt die Werte auch jeweils erst nach einer Sekunde. Dadurch haben wir die eigentliche Erzeugung der Werte vom Timing für die Erzeugung der Werte entkoppelt und Interleaving etabliert. Zwischen der Erzeugung der einzelnen Werte erhält die JS-Engine dank setTimeout() eine Atempause, um andere Aufgaben abzuwickeln, Frames zu rendern und sonstige dringende Angelegenheiten zu erledigen. Da wir unsere Werte in einem Generator erzeugen, brauchen wir die Generator Function selbst hierfür nicht zu verbiegen, sondern überlassem die Timing-Frage denen, die den Generator nutzen. Jeder Konsument eines Generators kann selbst über das genehme Timing entscheiden:

function * createGenerator () {
  yield 0;
  yield 1;
  yield 2;
}

// Zeitgesteuert?
const gen1 = createGenerator();
setTimeout( function consumeValue () {
  const next = gen1.next();
  if (!next.done) {
    console.log(next.value);
    setTimeout(consumeValue, 1000);
  }
}, 1000); // 0, 1 und 2 nach je einer Sekunde


// Abhängig von der Framerate?
const gen2 = createGenerator();
requestAnimationFrame( function consumeValue () {
  const next = gen1.next();
  if (!next.done) {
    console.log(next.value);
    requestAnimationFrame(consumeValue);
  }
}); // 0, 1 und 2 nach je einem Frame

// Alles auf einmal, ohne Pausen?
for (const value of createGenerator()) {
  console.log(value);
}

// Oder noch einfacher
const allValues = Array.from(createGenerator());

Es gibt mehrere Gründe dafür, Timing-Fragen von der eigentlichen Logik zu entkoppeln. Zum einen ist es oft wünschenswert, lang laufende und komplexe JS-Funktionen durch Timeout-Atempausen für Browser besser verdaulich zu machen. Wer (aus welchen Gründen auch immer) 1000 Reflows zu triggern gedenkt, ist gut damit beraten, diese nicht auf einmal durchzuführen, sondern zeitgesteuert zu batchen. Somit hat der Browser zwischen den Rechenaufgaben Zeit die Webseite zu rendern und die Framerate bleibt im grünen Bereich. Allerdings ist es bei ohnehin schon komplizierten Funktionen aus Entwicklersicht wünschenswert, wenn diese Funktionen nicht auch noch durch Timeout-Callbacks weiter verkompliziert würden. Generator Functions sind hier die beste Lösung: einfach zunächst die (Generator-) Funktion schreiben, als gäbe es die Timeout-Überlegungen gar nicht und hinterher ein setTimeout() anflanschen – so bleibt sowohl die Erzeugung der Werte als auch das Timing der Erzeugung übersichtlich und beherrschbar, bei gleichzeitig flotter Framerate.

Aber brauchen wir wirklich immer eine flotte Framerate? Für einen Unit Test ist das eher unwichtig, denn hier kommt es nur auf die Ergebnisse an. Zum Glück ist es den Konsumenten von Generators selbst überlassen, wie sie einen Generator zu konsumieren gedenken. Für einen Test könnte das synchron erfolgen, für Production mit framerate-schonenden Timeout-Päuschen:

function * createGenerator () {
  yield 0;
  yield 1;
  yield 2;
}

// Für Production: mit Timeout-Interleaving und Callbacks
consume(createGenerator(), (values) => {
  // values = 0, 1, 2
});


// Für den Test: alles auf einmal bitte!
expect(Array.from(createGenerator())).toBe([ 0, 1, 2 ]);

Ob lang laufende und komplexe JS-Funktionen wirklich Timeout-Atempausen brauchen, kommt oft mehr auf den Kontext des Aufrufs an als auf die Funktion selbst.

Ein drittes schönes Feature von Generators ist der eingebaute Abbruch-Mechanismus. Normale JavaScript-Funktionen laufen nach ihrem Aufruf bis zum Ende durch, falls nicht Exceptions dazwischenfunken. Ein Abbrechen einer laufenden Operation von Außen gibt es eigentlich gar nicht … abgesehen von Generator Functions! Die Operationen in einem Generator finden nur statt, solange Werte angefordert werden. Wird nichts mehr angefordert, passiert nichts mehr; die Funktion ist effektiv gestoppt.

const createGenerator = function * () {
  let i = 0;
  while (true) {
    yield i++;
  }
};

let stop = false;

const gen = createGenerator();
setTimeout( function consumeValue () {
  const next = gen.next();
  if (!stop) {
    console.log(next.value);
    setTimeout(consumeValue, 1000);
  }
}, 1000); // jede Sekunde eine Zahl bis "stop" true ist

stopButton.addEventListener("click", () =>{
  stop = true;
}, { once: true });

Durch das hin- und herschalten zwischen verschiedenen Generators lassen sich auch Konzepte wie Restarts recht bequem umsetzen.

Ich schraube gerade an der Tester-Library von Warhol, die die Aufgabe hat, Designfehler auf Websites zu finden. Diese Library wird in unserer Browser-Extension verwendet, aber auch in unseren automatisierten Services, die mit ferngesteuerten Browsern automatisch ganze Domains nach Fehlern abgrasen. Dank der Vielfalt der Einsatzgebiete findet sich die Library mit zahlreichen konkurrierenden Ansprüchen konfrontiert:

  1. Die Tests müssen funktionieren und weder falsch positive noch falsch negative Ergebnisse sind akzeptabel. Also haben wir hunderte von automatisierten Tests und es werden stetig mehr. Diese müssen so schnell laufen wie möglich, denn Entwickler-Zeit ist kostbar.
  2. Innerhalb der Browser-Extension müssen die Tests vor den Augen eines ungeduldigen Menschen durchgeführt werden. „Dank“ moderner Webentwicklungs-Praktiken wir es hierbei oft mit absurd großen DOM-Bäumen zu tun, die rekursiv nach Fehlern abgegrast werden müssen. Ein Fortschrittsbaken könnte die wahrgenommene Performance stark verbessern und ein Stopp-Button, den die Nutzer nach den ersten 9000 gefundenen Fehlern drücken können, trägt auch zum Erhalt der Laune bei.
  3. Die gleichen Tests in automatisierten Services brauchen keine ungeduldigen Nutzer zu bedenken, sondern müssen einfach nur so schnell sein wie möglich. Jedes bisschen Cloud-Zeit kostet schließlich!
  4. Die Tester-Library ist ein ausgesprochen kompliziertes Stück TypeScript-Hexerei und darf nicht unübersichtlicher werden als absolut nötig.

Ursprünglich war die Tester-Library ungefähr wie folgt aufgebaut:

// Alte Vesion (extrem vereinfachte Darstellung)
const test = (element: Element): TestResult[] => {
  return [
    testElement(element),
    ...element.children.map( (child) => test(child) ),
  ];
};

Der ganze DOM-Tree wurde durchgetestet und am Ende gibt es ein Array mit Ergebnissen. Es gab kein Interleaving, keine Abbruch-Möglichkeit und in der Realität stellte sich das Handling der Ergebnis-Arrays oft weniger einfach dar wie hier gezeigt. Oft gibt es Early Returns, im Voraus bekannte Ergebnisse und viele weitere Komplikationen. Mit Warhols zunehmenden Fähigkeiten und den immer komplexeren Enterprise-Webseiten, auf denen Warhol meist zum Einsatz kommt, wurde die Performance-Frage akut. Und was haben wir getan?

// Neue Version (extrem vereinfachte Darstellung)
const test = (element: Element): Generator<TestResult, void, void> => {
  yield testElement(element);
  for (const child of element.children) {
    yield * test(child);
  }
};

Wir haben eigentlich fast gar nichts getan! Die array-produzierenden Funktionen mussten zu Generator Functions umgemodelt werden (was bei 90% der Funktionen komplett ohne Nachdenken ging) und schon sind alle Anforderungen bedient:

  1. Automatische Tests konsumieren die Generators synchron und sind damit so schnell wie eh und je.
  2. In der Browser-Extension macht Interleaving mit requestAnimationFrame() der Rendern einer Lade-Animation möglich und ein Abbruch-Button war trivial zu implementieren.
  3. In der Cloud verzichten wir auf Interleaving und blockieren einfach mit den Tests das UI komplett, denn es gibt ja keinen Menschen, der sich daran stört.
  4. Der Code für die Tester-Library ist praktisch gleich geblieben, Arrays wurde fast überall 1:1 mit Generators ersetzt.

Generators in JavaScript sind sehr seltsame, sehr vielseitige Objekte. Arrays und normale JS-Objekte sind auch sehr vielseitig, aber so konkret, dass man als Entwickler recht schnell etwas damit anzufangen weiß. Die Vielseitigkeit von Generators ist anderer Natur: sie sind so vielseitig, weil sie unglaublich allgemein sind, aber das macht auch schwer, sie überhaupt als etwas zu erkennen, das eine Lösung für ein konkretes Problem sein kann. In solchen Fällen ist es wichtig, Dinge durch bestimmte Linsen zu betrachten – in meinem Fall mit dem Warhol-Tester war es die Listen-Linse, aber durch andere Linsen sind Generators genau das richtige Mittel um Message Passing oder Async/Await zu implementieren. Für das initiale Verständnis ist es dabei immer gut, nicht zu genau hinzuschauen, keine unangenehmen Fragen zu stellen und sich nicht zu sehr im Abstrakten zu verlieren.

Fragen zu HTML5 und Co beantwortet 26 - Globale IDs, Offline-Modus bei PWA, fortgeschrittenes TypeScript, Methoden-Syntax

Veröffentlicht am 3. Dezember 2019

Alle Jahre wieder sammeln sich in meiner Inbox genug Fragen zu Webtechnologien an, um einen Blogpost zu rechtfertigen. Dass es dieses Mal fast ausschließlich Fragen zu JavaScript und TypeScript sind, muss nicht sein – wenn ihr mir zu anderen Themen (oder eben diesen Themen) Fragen mailt oder mich auf Twitter anquatscht, werde ich sie beantworten und vielleicht eines Tages auch in einem Post wie diesem veröffentlichen!

Jens fragt: Bitte was? HTML-IDs legen globale JavaScript-Variablen an?!

Wenn ich einem HTML-Element eine ID gebe, kann ich das Element ohne document.getElementById() ansprechen? Einfach so, als globale Variable? Ist das Teil des Standards?

Ja, das ist Teil des HTML/DOM-Standards! Es handelt sich um den sogenannten named access on the Window object, der im Übrigen nicht nur mit IDs funktioniert. Dezent vereinfacht können als globale Variable verwendet werden:

  1. iframe-, embed-, form-, frameset-, img- und object-Elemente mit einem name-Attribut, dessen Wert als Variablenname fungiert
  2. Alle sonstigen Elemente mit einem id-Attribut, dessen Wert als Variablenname fungiert

Gibt es mehrere Kandidaten für einen Variablennamen (z.B. ein Iframe mit name="foo" und ein Div mit id="foo"), gilt folgende Rangfolge:

  1. Ist einer der Kandidaten ein Iframe mit passendem name, belegt es den Variablennamen; bei mehreren Iframe-Kandidaten belegt das erste Element im DOM den Namen
  2. Gibt es keinen passenden Iframe, kommen die Kandidaten aus Kategorie embed/form/frameset/img/object zum Zuge, wobei auch hier gilt, dass bei mehreren Kandidaten mit passendem name-Wert der Erste Kandidat im DOM verwendet wird
  3. Zuletzt kommen Kandidaten mit id-Attribut (bzw. der erste solche Kandidat im DOM) an Reihe.

Dass in einer Welt, die Funktionen wie document.querySelector() bietet, niemand dieses ausgesprochen fragwürdige „Feature“ verwenden sollte, versteht sich von selbst. Was macht es dann im HTML-Standard? Meine historischen Ausgrabungen legen nahe, dass es sich um ein altes Feature aus dem Internet Explorer handelt. Anderer Browser mussten, um alte IE-only-Seiten zu unterstützen, das Feature unter erheblichem Zähneknirschen auch implementieren und zack – fertig ist der Webstandard.

Es ist wichtig anzumerken, dass dieses „Feature“ keine Gefahr für andere globale Variablen darstellt. Ein window.foo = 42 wird nicht durch ein Iframe mit name="foo" überschrieben und dem eingebauten window.navigator droht keine Gefahr durch <div id="navigator">. Es handelt sich eher um eine Kuriosität als ein Problem.

Boris und Reinhard fragen: Wie einen Offline-Modus für eine PWA bauen?

Unsere Anwendung soll als Progressive Web App offline funktionieren. Das Laden der App funktioniert dank eines Service Worker auch schon problemlos. Aber wie können wir herausfinden ob der Nutzer on- oder offline ist, um zu entscheiden, ob Daten lokal oder auf dem Server gespeichert werden sollten?

Ob ein Nutzer online oder offline ist, kann man gar nicht herausfinden bzw. die Begriffe „online“ und „offline“ sind hier nicht besonders hilfreich. Landläufig versteht man unter „online“ eine Verbindung zum Internet, aber als Nutzer einer App interessiert mich das Internet™ an sich nicht; was ich eigentlich möchte, ist durch das Internet eine Verbindung zu einem bestimmten Endpunkt aufbauen und mit diesem Endpunkt einen spezifischen Satz Daten austauschen. Nicht nur braucht also die PWA eine Internetverbindung, sondern auch der Ziel-Server muss funktionsfähig und verbunden sein. Und zu allem Überfluss muss die Verbindung auch dergestalt sein, dass der Datenaustausch auch stattfinden kann, darf also z.B. nicht zu langsam sein.

Im Angesicht eines Web-Requests lautet die eigentliche Frage also nicht „bin ich online?“, sondern vielmehr „klappt dieser Request zu diesem Zeitpunkt?“. Und diese Frage lässt sich nur beantworten, indem man versucht, den fraglichen Request (und nicht etwa einen Ping-Request) sofort (und nicht etwa nach einem Ping) durchzuführen.

Ich würde für meine PWA ein Offline-First-Datenspeichern bauen. Wann immer der Nutzer in der App Daten abzuspeichern versucht, würde ich diese zuerst im lokalen Speicher ablegen und danach einfach versuchen, sie zum Server zu senden. Wenn das klappt, können die lokalen Daten bei Bedarf gelöscht werden. Und wenn nicht, dann probiert man es später einfach nochmal.

Mathias fragt: Wie kann man fortgeschrittenes TypeScript verständlich halten?

Kennst du Strategien, um TypeScript möglichst lesbar und verständlich zu halten, wenn man fortgeschrittene Features wie Mapped Types und Generics verwendet?

Es stimmt, dass fortgeschrittene TypeScript-Features für Uneingeweihte ziemlich kryptisch daherkommen können und dass unsachgemäßer Eingriff viel kaputt machen kann … aber das gilt eigentlich für alle möglichen fortgeschrittenen Features in allen möglichen Programmiersprachen. Und dass fortgeschrittene Features für nichtfortgeschrittene Nutzer ein Problem darstellen, ist etwas, um das wir grundsätzlich nicht herumkommen. Entsprechend denke ich, dass sich hier „nur“ die üblichen Software-Entwicklungs-Maßnahmen für den Umgang mit Komplexität ergreifen lassen:

  1. YAGNI: ich versenke gelegentlich Zeit in die ausgefeilt-generische Typ-Formulierung von Dingen, die am Ende in der Codebase in genau einer Form zum Einsatz kommen. Das ist dumm und ich sollte das nicht tun. Und auch sonst niemand. Fortgeschrittene Features sind weniger häufig wirklich nötig, als man glaubt.
  2. Automatisierung: die Typinferenz vom TypeScript hilft sehr beim Einsatz von Generics. Intelligent ausgelegte Funktionen machen nicht nur ihren Job, sondern sind auch benutzerfreundlich und bei TypeScript ist hierbei die Typinferenz von Generics als ein zusätzliches Kriterium neben Funktionalität und Lesbarkeit zu berücksichtigen. Wenn das mal nicht klappt, weil die Typinferenz eine bestimmte Konstruktion einfach nicht versteht, hilft vielleicht Abstraktion weiter: vor einen mit Generics gespickten Funktionsaufruf könnte man 2-3 nicht-generische Fassaden stellen, die für alle tatsächlichen Use Cases ausreichen (siehe YAGNI).
  3. Abstraktion: eine gute Typ-Transformation ist wie eine gute Funktion, also generisch, gut getestet und dem UNIX-Prinzip folgend. Und wie eine gute Funktion muss eine gute Typ-Transformation, wenn einmal geschrieben, auch von jenen verwendet werden, die nicht in der Lage wären, die Funktion/Transformation zu schreiben. Sie können als Black Boxes einfach benutzt werden und stören im Arbeitsalltag nicht, vor allem nicht, wenn sie gut dokumentiert in einem eigenen Modul wohnen. Stichwort Modul …
  4. Modularisierung: es lohnt sich, eine Library von TypeScript-Transformationen aufzubauen, die auch Nichtnerds einfach benutzen können – quasi ein Lo-Dash für Typen. Mit type-zoo und typelevel-ts gibt es solche Libraries von Dritten, aber es spricht nichts dagegen, auch einen eigenen Typ-Werkzeugkoffer zusammenzustellen und ihn versioniert und dokumentiert griffbereit, aber aus dem Weg zu halten.

Meine persönliche TypeScript-Philosophie ist, dass ich fortgeschrittene Features nur dann verwende, wenn sie mir wirklich viel Arbeit ersparen oder signifikante Sicherheitszuwächse bieten. Und das ist nur gegeben, wenn die entsprechenden Codeschnipsel nicht im Weg herumstehen und dabei die Typinferenz aufmotzen. Abgefahrenes TypeScript sollte man nur schreiben, wenn man als direkte Folge weniger abgefahrenes (oder mühsames) TypeScript schreiben kann.

Daniel fragt: ist die Methoden-Syntax für Objekt-Literale gut oder böse?

Ich habe deinen Artikel gelesen, in dem es darüber ging, dass man function-Funktionen nicht nutzen sollten und finde ihn super! Aber wie sieht es bei Funktionen in Objekt-Literalen aus? Arrow Functions, Methoden-Syntax oder doch function-Keyword?

Für Unterbringung von Funktionen im Objekt-Literal gibt es drei Möglichkeiten:

const obj = {
  foo () { return 42; },
  bar: () => { return 42; },
  baz: function () { return 42; },
}

Von diesen drei Kandidaten würde ich die Arrow-Function-Variante bar zuallererst verwerfen. Funktionen auf Objekten sollten im Normalfall schon als Methoden nutzbar sein und das klappt nicht mit dem lexikalischen this der Arrow Functions. Die verbleibenden Kandidaten foo () {} und baz: function () {} führen, wie der Babel-Output zeigt, zum gleichen Ergebnis, beide sind in letztendlich normale function-Funktionen (und müssen das auch sein).

Und was nimmt man nun? Ich persönlich greife zur Methoden-Syntax foo () {} weil sie einfach kürzer als das function-Keyword und in vielen Fällen weniger falsch als die Arrow-Function-Variante ist. Die Methoden-Syntax erlaubt außerdem die vollumfängliche Verbannung des function-Keyword aus meinem Code, was im Sinne der Code-Konsistenz vielleicht noch das stärkste Argument ist.

Weitere Fragen?

Habt ihr auch dringende Fragen zu Frontend-Technologien? Nur her damit! Alle Fragen in diesem Post wurden mir per E-Mail oder Twitter gestellt und ihr könnt das genau so machen! Einfach über einen der genannten Kanäle anschreiben oder gleich das komplette Erklärbären-Paket kommen lassen.

Hallo Welt, Warhol!

Veröffentlicht am 22. Oktober 2019

Seit ziemlich genau einem Jahr schrauben Hans und meine Wenigkeit an Warhol herum und so langsam ist es an der Zeit, auch an dieser Stelle einmal auf das Projekt hinzuweisen und ein paar Takte dazu zu erzählen. Falls Pattern Libraries und konsistentes Design am Herzen liegen, ist Warhol genau das Richtige für euch!

Was ist Warhol?

Warhol verwandelt Pattern Libraries in Tests. Eine Pattern Library (oft auch Styleguide genannt) in Warhols Sinn ist eine HTML/CSS-Seite, die Komponenten, Farbpaletten und Typografie vorgibt. Im Idealfall halten sich alle Entwickler bei der Umsetzung eines Web-Projekts an diese Vorgaben, tatsächlich passiert das nur selten. Das liegt zum einen daran, dass es schwer nachzuvollziehen ist, ob die Implementierung einer Komponente wirklich alle Vorgaben erfüllt, zum anderen sind die Vorgaben selbst nicht selten unvollständig oder widerspüchlich – z.B. verwenden Komponenten in einer Pattern Library oft Farben, die gar nicht in der Farbpalette vorgesehen sind. Warhols Ziel ist, Pattern Libraries aus der Rolle der groben Absichtserklärung zu befreien und sie in Unit Tests für Design zu verwandeln.

Mit nur wenig Konfigurationsaufwand extrahiert Warhol aus einer ganz normalen Pattern Library die Kernkonzepte (wie Farbpaletten und Komponenten) und stellt sicher, dass diese im echten Projekt genau so umgesetzt werden, wie es vorgesehen ist. Fehlerhaft implementierte Komponenten werden als Fehler gemeldet, ebenso nicht erlaubte Farben oder von der Pattern Library nicht abgedeckte Kombinationen von Schriftart, -farbe, und -schnitt. Wichtig dabei: anders als andere Tools arbeitet Warhol nicht mit Screenshots, sondern vergleicht HTML und CSS. Die mit Blindtext gefüllten Komponenten in der Pattern Library sind damit als Vorlage für die mit echtem Content gefüllten Production-Seiten problemlos zu gebrauchen.

Wie benutzt man Warhol?

Der erste Schritt ist das Anlegen einer Pattern Library. Wie genau diese umgesetzt ist, ist fast egal. Solange der Output eine HTML-Seite ist, kommt Warhol damit klar. Die Pattern Library muss dabei keinesfalls vollständig sein, auch wenn es nur eine Farbpalette gibt und nur eine einzige Komponente definiert wurde (oder gerne auch gar keine), funktioniert Warhol und testet immer nur das ab, was vorgegeben und konfiguriert wurde.

Als Zweites muss die Pattern Library für Warhol konfiguriert und zugänglich gemacht werden. Die Konfiguration erfolgt im Moment über eine simple JSON-Datei, die in etwa wie folgt aussieht:

{
  "patternLibUrl": "https://warhol.io/components",
  "breakpoints": [800, 1000],
  "theme": {
    "colors": {
      "sources": ".color-swatch"
    },
    "typography": {
      "sources": ".typography"
    }
  },
  "components": [
    { "name": "Navigation", "source": ".navigation" },
    { "name": "Button", "source": ".button" },
    { "name": "Button - Primary", "source": ".button.button--primary" },
    { "name": "Button - Secondary", "source": ".button.button--secondary" },
    { "name": "Teaser", "source": ".teaser" },
    { "name": "Teaser - Left", "source": ".teaser.teaser--align-left" },
    { "name": "Teaser - Post", "source": ".teaser.teaser--align-left.post" },
    { "name": "Author",  "source": ".author" }
  ]
}

Die Konfiguration besteht im Wesentlichen daraus, dass Warhol die öffentliche URL der Pattern Library, die Breakpoints und die CSS-Selektoren für verschiedene Konzepte der Pattern Library mitgeteilt werden. Ein Web-Interface zur Konfiguration von Pattern Libraries, Teams, API-Keys und allem was dazu gehört, gibt es selbstverständlich auch:

Als Nächstes kommt Warhols Crawler zu Besuch und verwandelt eure Pattern Library in Daten. In der ersten Version passiert das ausschließlich auf dem Rücken von Chrome, aber zumindest vom Prinzip her funktioniert auch der Firefox-Support schon. Der Browser schaut sich eure Pattern Library in den verschiedenen Breakpoint-Größen an, während Warhol das HTML und CSS eurer Komponenten und Farbpaletten mitschneidet. Die Daten landen in Warhols Backend und können dann verwendet werden, um Webseiten auf Konformität mit der Pattern Library zu testen.

In der ersten Version steht hierfür eine Browser-Erweiterung zur Verfügung. Ihr loggt euch einfach mit eurem Warhol-Account ein, ladet die Test-Daten für euer Projekt und schon seht ihr, wo ein Web-UI überall von der Pattern Library abweicht:

Wie der Screenshot zeigt, sind die Fehlermeldungen präzise und gnadenlos. Die Pattern Library im Beispiel enthält kein Weiß in der Farbpalette und erlaubt auch nirgends fetten Text, so dass die Browser-Extension sich über diese beiden Inkonsistenzen beklagt. Beides sind wohl eher Probleme in der Pattern Library als in der Webseite, aber auch solche Probleme müssen erst einmal gefunden werden. Mithilfe der Browser-Extension lassen sich Fehler in Production wie auch in der Pattern Library schnell diagnostizieren und reparieren.

Warhol kann Tests natürlich auch völlig autark ausführen und braucht keinen menschlichen Aufpasser oder Browser-Bediener. Ein Test-Crawler, der binnen weniger Minuten ganze Webauftritte oder Online-Shops nach Fehlern in allen Bildschirmgrößen in verschiedensten Browsern durchkämmt, ist in Arbeit.

Wann kann ich Warhol benutzen?

Bis zum öffentlichen Release wird noch etwas Zeit vergehen, aber die Alpha-Phase ist nah! Wir suchen deshalb mutige Tester, die sich in einem ersten Schritt Warhol demonstrieren lassen und bei dann weiter bestehendem Interesse Alpha-Tester werden wollen. Meldet euch hierzu einfach bei mir! Weitere Updates zu Warhol gibt es bei @wearewarhol und im Warhol-Newsletter, den ihr auf warhol.io abonnieren könnt.

Fragen zu HTML5 und Co beantwortet 25 - lange Klassen, Input-Labels, rekursive TypeScript-Typen, HTML-Attribute

Veröffentlicht am 22. August 2019

Im Laufe der Wochen hat sich mein Postfach wieder mit vielen Webtech-Fragen gefüllt, die per E-Mail schon beantwortet wurden und deren Veröffentlichung hiermit nachgeholt wird. Habt ihr auch Fragen zu HTML, CSS, JS, TypeScript oder anderen Frontend-Themen? Meldet euch bei mir per E-Mail oder auf Twitter!

Wie organisiere ich am besten exorbitant große TypeScript-Klassen?

In unserem Projekt haben wir eine Klasse namens „Document“, die von sich aus schon über 1000 TypeScript-Zeilen lang ist. Damit die Klassen nicht noch größer wird, versuchen wir Code in Mixins auszulagern, die wir mittels Object.assign() auf Document.prototype anwenden. Das funktioniert zur Laufzeit, aber im Editor gibts keine Hilfe, Autovervollständigung oder Typeahead für den via Object.assign() eingebundenen TS-Mixin-Code. Wie können wir den Code so aufbauen, dass er sowohl in JavaScript zur Laufzeit als auch in TypeScript zur Entwicklungs-Zeit vernünftig funktioniert? Brauchen wir eine riesige Vererbungs-Kette? Die würden wir eigentlich gerne vermeiden …

Mit einer gewaltigen Vererbungs-Kaskade würde Autovervollständigung wieder funktionieren, aber nur für Autovervollständigung lohnt sich der Umbau sicher nicht. Wir können auch nichts daran ändern, dass TypeScript die Object.assign()-Operation, die den Klassen-Prototypen mutiert, nicht so wirklich versteht. Prototype-Patchen ist etwas, das zur Entwicklungszeit (d.h. vor der Ausführung) für das Typsystem aufgrund der großen Dynamik des ganzen Vorgangs einfach nicht zu durchschauen ist.

Ein denkbarer Ausweg bestünde darin, dass wir das, was TypeScript von selbst nicht schafft, manuell herstellen. Parallel zum Patchen des Prototyps können wir einen Typ konstruieren, der den gepatchten Prototyp mit all seinen Mixins darstellt:

type PatchedClass <Base extends new (...args: any) => any, Mixin1, Mixin2> =
  Base extends new (...args: infer Args) => infer BaseInstance
    ? new (...args: Args) => BaseInstance & Mixin1 & Mixin2
    : never;

Dieser Utility-Typ konstruiert, vereinfacht gesagt, aus einer dem Typ einer Klasse und den Typen zweiter Mixins einen Typ, der aus der Constructor-Signatur des Typs der Input-Klasse plus den Feldern des Input-Klassen-Typs und der beiden Mixins besteht. Das Ganze ließe sich bei Bedarf auch für N statt 2 Mixin-Typen auslegen.

Am Ende behaupten wir dann einfach per Type Assertion, die gepatchte Klasse sei vom manuell konstruierten Typ. Dazu brauchen wir eine temporäre Klasse, die wir z.B. in einer IIFE verstecken können:

import FooMixin from "./moduleFoo";
import BarMixin from "./moduleBar";

class BaseClass { /* Klassen-Funktionalität */ }

const Document = ( () => {
  class __TempClass extends BaseClass { /* Klassen-Funktionalität */ }
  Object.assign(__TempClass.prototype, FooMixin, BarMixin);
  return __TempClass as PatchedClass<typeof __TempClass, typeof FooMixin, typeof BarMixin>;
})();

const myDocument = new Document();
// "myDocument" kennt foo() und bar() aus den Mixin-Modulen!

Funktioniert und ist dabei sogar gar nicht mal so schön!

Ich würde das als eine clevere Lösung bezeichnen, aber in Programmierfragen gilt: „clever“ ist das genaue Gegenteil von „intelligent“! Ich persönlich schreibe in solchen Fällen einfach immer eine exorbitant große Klasse mit zigtausend Zeilen, eine monströs große Funktion oder ein Modul mit laut „Best Practices“ viel zu vielen Zeilen. Die gezeigte TypeScript-Hexerei erlaubt es zwar, die Klasse in Einzelteile zu zerlegen, aber warum genau zerlegt man große Klassen oder lange Module? Das Ziel sollte immer sein, größere Programmteile konzeptuell aufzugliedern, um die einzelnen Basis-Bestandteile besser überschaubar, testbar und portierbar zu machen. Das geht aber nur dann, wenn der zu zerteilende Programmteil selbst kein Basis-Baustein ist, der ein fundamentales Konzept des Gesamtprogramms implementiert. Versucht man einen konzeptionell nicht weiter zu untergliedernden Basis-Baustein zu zerteilen, wird dieser nicht modularisiert, sondern lediglich auf viele verschiedene Module verteilt. Und davon sollte man dringend Abstand nehmen! Eine Klasse wird ja de facto nicht kürzer, indem man sie verteilt, nur noch schwerer zu überblicken. Der Name der Klasse in dieser Frage („Document“) und das Problem (viele Methoden) legen nahe, dass es sich hier nicht um etwas handelt, das sich sinnvoll aufgliedern lässt. Ein Dokument ist eben ein zentrales, wichtiges Konzept und es kann viel. Dann ist die Klasse eben lang und die Methoden zahlreich. Damit kann und sollte man sich arrangieren.

Programmierer haben heutzutage viel zu viel Angst vor langen Klassen und Funktionen. Wir sind drauf konditioniert, Code schön zu modularisieren und aufzuteilen, aber nicht jedes Real-World-Problem lässt sich schön modularisieren und aufteilen. Manches ist einfach inhärent komplex und lang und haarig. Das bedeutet nicht, dass man sich nicht an Modularisierung und knackig-kurzen Klassen und Funktionen versuchen sollte, aber wer versucht, unteilbares zu zerhacken, schafft es bestenfalls Komplexität zu verschleiern. Und das ist ebenso wenig wie eine bestimmte Maximallänge von Klassen und Modulen ein Ziel, das ein Entwickler haben sollte.

Wenn sich ein Programmierproblem nicht rein ästhetisch nicht zufriedenstellend lösen lässt, dann besteht die richtige Lösung darin, über die rein ästhetisch nicht zufriedenstellende Lösung einen erklärenden Kommentar zu schreiben und sie genau so zu lassen wie sie ist. Und dann hat die Klasse eben ein paar tausend Zeilen. Besser als das TypeScript-Gehacke oder eine konzeptionell keinen Sinn ergebende Vererbungskette ist das allemal.

Inputs und Labels verknüpfen: for-Attribut oder Verschachtelung?

Man kann ein Label einem Formularfeld per for-Attribut zuordnen oder indem man das Input-Element als Kind-Element in das Label steckt. Was ist besser?

Wenn es nach dem HTML-Standard geht, ist keins von beidem „besser“. Beide Verfahren haben den Effekt, das das Input-Element als labeled control mit dem Label-Element assoziiert wird und dann z.B. Klicks auf das Label ein Input-Element fokussieren. Das for-Attribut hat im Zweifelsfall Vorrang, aber wenn kein for-Attribut gesetzt ist, assoziiert sich das Label mit dem ersten Input-Element in seinen Kind- und sonstigen Nachfahren-Elementen.

Ich persönlich verwende, wann immer möglich, die Variante ohne for-Attribut. Dann müssen nämlich keine IDs jongliert und abgeglichen werden (IDs sind sowieso immer zu vermeiden) und ich habe weniger Arbeit und mache weniger Fehler.

Wie baue ich einen rekursiven TypeScript-Typ?

Ich möchte in TypeScript einen Array-Typ konstruieren, der entweder einen Wert oder sich selbst enthält, quasi Foo | Array<Foo> | Array<Array<Foo>> | ... bis zur Unendlichkeit. Wie geht das? Ich bin kurz davor ein @ts-ignore einzubauen!

Die Lösung besteht darin, einen Typ per type und einen per interface zu definieren:

interface RecursiveArray extends Array<Recursive> {}
type Recursive = number | RecursiveArray;

const a: Recursive = 23;
const b: Recursive = [ 23 ];
const c: Recursive = [ [ 23 ] ];
const d: Recursive = [ [ [ 23 ] ] ];
const e: Recursive = [ [ [ [ 23 ] ] ] ];

Grundsätzlich kann man in TypeScript in fast allen Fällen auf interface verzichten und stattdessen type verwenden, da type alles und mehr kann als interface … mit zwei Ausnahmen. Zum einen gibt es bei Interfaces (und nur bei Interfaces) Declaration Merging. Das bedeutet, dass die Deklarationen interface A { x: number } interface A { y: string } zum Typ A { x: number, y: string } zusammengefügt werden, was praktisch ist wenn globale Objekte wie z.B. Window gepatcht werden müssen. Zum anderen werden type-Deklarationen eager, interface-Deklarationen hingegen lazy ausgewertet. Um einen rekursiven Typ wie in der Frage zu beschreiben braucht man beides: das interface für die Selbstreferenz und den type für den mit | geschriebenen Union Type.

Darf ich mir einfach so HTML-Attribute ausdenken?

Ich verwende ein task-Attribut auf <button>-Elementen. Das funktioniert mit meinem JavaScript auch ganz gut, aber mein Kollege sagt, dass solche Attribute nicht unterstützt werden. Wer hat recht?

Die Antwort auf diese Frage hängt davon ab, was mit „Unterstützung“ des Attributs genau gemeint ist. Prinzipiell dürfen HTML-Elemente nur die Attribute haben, die sie laut Spezifikationen haben dürfen. „Unterstützt“ werden nicht-standardkonforme Attribute aber dennoch insofern, als der Browser sie parsen und über die meisten erwartenden APIs (z.B. in JS durch myButton.getAttribute("task") oder als CSS-Selektor myButton[task]) nutzbar macht. Ernsthaft problematisch sind bei frei erfundenen Attributen nur zwei Aspekte:

  • DOM-Getter und -Setter funktionieren nicht. Das bedeutet, dass z.B. Attribut-Updates nur per myButton.setAttribute("task", "42") funktionieren, über myButton.task = "42" hingegen nicht.
  • Sie sind nicht standardkonform und daher nicht zukunftssicher. Nichts hält die Browser der Zukunft davon ab, selbst eines Tages selbst ein task-Attribut einzuführen, dessen Funktionalität mit der hinzuerfundenen Funktionalität kollidiert.

Die beiden Aspekte sind in der Praxis nicht wirklich problematisch, aber es gibt auch einen Weg, selbsterfundene Attribute richtig zu machen: sie einfach durch ein vorangestelltes data- zu „namespacen“. Aus dem Attribut task wird data-task und schon gibt es keine Probleme mehr mit zukünftigen Browser-Updates. Durch die Dataset-API gibt es sogar bequeme DOM-Getter und -Setter!

Die Nachteile, die selbsterfundene Attribute ohne data-Prefix mit sich bringen, sind überschaubar. Aber da es nahezu null Aufwand bedeutet, dieses Prefix einzubauen, würde ich dazu raten. Es ist ein wenig richtiger und verursacht nur minimale Mehrarbeit. Das ist doch ein Deal!

Weitere Fragen?

Habt ihr auch dringende Fragen zu HTML, CSS, JavaScript oder TypeScript? Nur her damit! Alle Fragen in diesem Post wurden mir per E-Mail oder Twitter gestellt und ihr könnt das genau so machen! Einfach über einen der genannten Kanäle anschreiben oder gleich für einen Workshop das komplette Erklärbär-Paket bestellen.