Gruppieren, Iterieren und Datenfluss

JavaScript — Gruppieren und Iterieren

0:00 Daten liegen selten still. Sie werden sortiert, gebündelt, durchlaufen, gefiltert — und irgendwann verlassen sie den Speicher und gehen in eine Datei, an eine Schnittstelle oder in eine Datenbank. Genau diese Bewegung ist das Thema dieses Moduls. Wir sehen uns an, wie man Listen nach einem Merkmal gruppiert, wie man verschiedene Strukturen sauber durchläuft und wie Werte durch eine Verarbeitungskette fließen können, ohne dass bei jedem Schritt eine neue Zwischenliste entsteht.

0:26 Das letzte Kapitel ist bewusst ein Ausblick — es spannt den roten Faden zu den Modulen, die noch kommen.

Datenfluss

0:32 Fünf Kapitel. Zuerst das Gruppieren, wo JavaScript in den letzten Jahren erfreulich nachgelegt hat — was früher Handarbeit war, ist heute ein Aufruf. Dann das Durchlaufen der Strukturen, die wir im letzten Modul kennengelernt haben, und ein Beispiel, in dem zum ersten Mal alles ineinandergreift, was wir bisher gelernt haben.

0:51 Danach ein fortgeschrittenes Thema: Iteratoren und ihre Helfer. Praktisch wird es beim Lesen von Kommandozeilen-Argumenten, und zum Abschluss der Ausblick auf das, was passiert, wenn ein Programm endet.

Daten gruppieren

1:03 Beginnen wir mit einer Aufgabe, die in fast jeder Anwendung vorkommt: eine Liste nach einem Merkmal bündeln. Umsätze nach Monat, Nutzer nach Rolle, Beete nach Art. Bis vor Kurzem hat man das von Hand gebaut. Heute geht es in einer Zeile. Gruppieren heißt: Sie haben eine flache Liste und wollen sie nach einem Merkmal in Fächer sortieren. Der Mechanismus ist dabei erfreulich einfach zu erklären.

1:28 Sie übergeben die Liste und eine kleine Funktion, die für jeden Eintrag sagt, in welches Fach er gehört — sie liefert den Schlüssel. Das Ergebnis enthält dann je Schlüssel ein Array mit allen passenden Einträgen. Stellen Sie sich einen Briefsortierer vor: Jeder Brief wird angeschaut, die Postleitzahl entscheidet über das Fach, und am Ende liegt in jedem Fach ein Stapel.

1:49 Genau das passiert hier, nur schneller. Zwei Varianten derselben Idee. Die kleine Funktion in der Klammer ist die Fachauswahl — sie sagt für jedes Beet: Deine Art ist dein Fach. Der Unterschied zwischen beiden Aufrufen liegt im Ergebnistyp. Die erste liefert ein Objekt, deshalb greifen Sie mit der Punktschreibweise zu. Die zweite liefert eine Map, und dort brauchen Sie die Hol-Methode — genau die Unterscheidung aus dem letzten Modul, jetzt in der Praxis.

2:16 Beachten Sie außerdem, dass in jedem Fach ein Array liegt, auch wenn nur ein Eintrag darin ist. Deshalb steht in der letzten Zeile der Index vor dem Namenszugriff. Die Entscheidungslogik ist kurz. Sind Ihre Schlüssel Zeichenketten — und das ist der Normalfall —, reicht die Objekt-Variante. Sobald die Schlüssel andere Typen haben, brauchen Sie die Map-Variante, denn ein Objekt wandelt jeden Schlüssel stillschweigend in Text um.

2:41 Der dritte Eintrag ist ein Argument, das man leicht übersieht: Eine Map hat eine verlässliche Durchlaufreihenfolge, ein Objekt nicht in gleichem Maße. Und die letzte Zeile ist die Rückfallebene für ältere Umgebungen — dort baut man die Gruppen weiterhin selbst zusammen. Was das an Code bedeutet, sehen Sie in der Aufgabe gleich selbst.

3:01 Bilden Sie je Art eine Gruppe und geben Sie die Anzahl je Gruppe aus. Das ist mit der neuen Methode schnell erledigt. Der eigentliche Auftrag steckt im Hinweis: Lösen Sie dieselbe Aufgabe zusätzlich mit der klassischen Reduzier-Methode und vergleichen Sie den Umfang. Sie werden sehen, dass aus einer Zeile etwa fünf werden — mit einer Merkvariablen, einer Prüfung, ob das Fach schon existiert, und dem Anlegen des Fachs.

3:25 Nichts davon ist schwierig, alles davon ist Gelegenheit für Fehler. Genau deshalb ist der Zugewinn hier so deutlich. Bei der Map-Variante mit Punktschreibweise zuzugreifen, ist der Fehler aus dem letzten Modul in neuem Gewand — und weil es keinen Fehler auslöst, sondern undefined liefert, fällt es spät auf. Der zweite Punkt ist verwandt: Eine Gruppe anzusprechen, die es im Datenbestand gar nicht gibt, liefert ebenfalls undefined.

3:50 Wer darauf eine Länge abfragt, bekommt einen echten Fehler. Der dritte ist der Verfügbarkeitshinweis, denn das sind neuere Methoden. Und der vierte ist besonders praxisnah: Nach einem Wert zu gruppieren, der undefined sein kann, erzeugt eine Gruppe mit dem Namen „undefined". Meistens ist das ein Datenproblem, kein Codeproblem.

Datenstrukturen durchlaufen

4:10 Jetzt gehen wir die Strukturen aus dem letzten Modul der Reihe nach durch — jede mit der Schleifenform, die zu ihr passt. Und am Ende dieses Kapitels steht ein Beispiel, in dem zum ersten Mal alles zusammenkommt, was wir seit Modul vier gelernt haben. Iteration heißt schlicht: Werte einzeln nacheinander bearbeiten. Die Frage ist nur, welche Schleifenform dafür die richtige ist, und die Antwort hängt an drei Kriterien.

4:35 Brauche ich einen Index — also die Position? Liegt eine iterierbare Sammlung vor? Oder sind es Objektschlüssel, die mich interessieren? Diese drei Fragen führen Sie zuverlässig zur passenden Form. Der Grundgedanke ist derselbe wie bei der Strukturauswahl im letzten Modul: Die richtige Wahl macht den Code nicht nur schöner, sie schließt ganze Fehlerklassen von vornherein aus.

4:57 Fünf Zeilen, fünf Situationen. Ganz oben ein nützlicher Trick: Die Einträge-Methode liefert Index und Wert als Paar, sodass Sie beides bekommen, ohne selbst zu zählen. Darunter eine Zeichenkette — auch die ist iterierbar, Zeichen für Zeichen. Dann die Map mit ihren Paaren und der Destrukturierung, die wir schon kennen. Das Set verhält sich so einfach wie erhofft.

5:19 Und die letzte Zeile ist die Ausnahme, die man sich merken muss: Beim Durchlaufen eines Objekts bekommen Sie den Schlüssel, nicht den Wert. Den Wert holen Sie sich über die Klammerschreibweise dazu. Das ist der Moment, an dem dieser Kurs zum ersten Mal wie echter Code aussieht. Schauen Sie, was hier alles zusammenkommt: eine Schleife über eine Sammlung, zwei Bedingungen, eine Negation, ein Objektzugriff, ein Anhängen an eine Ergebnisliste.

5:45 Jedes einzelne Element haben wir behandelt; hier greifen sie zum ersten Mal vollständig ineinander. Und beachten Sie die Bauweise: Beide Bedingungen steigen früh aus, statt den eigentlichen Fall einzurücken. Das ist die Guard-Clause-Idee aus Modul vier, angewandt auf eine Schleife. Der Rumpf bleibt dadurch flach und liest sich als das, was er ist — die Behandlung des Normalfalls.

6:08 Filtern Sie aus einer Liste nur die aktiven Kräuterbeete heraus. Wichtig ist der Zusatz im Erfolgskriterium: Prüfen Sie an einem Bestand, der mindestens ein Gegenbeispiel enthält. Ein Filter, der bei lauter passenden Einträgen funktioniert, beweist gar nichts — erst der Eintrag, der nicht durchkommen darf, zeigt, ob die Logik stimmt.

6:27 Diese Denkweise werden wir im Testmodul wieder aufgreifen. Und halten Sie den Rumpf flach, mit frühem Überspringen statt Verschachtelung. Der Unterschied ist bei zwei Bedingungen noch klein und bei fünf entscheidend. Die Objektschleife auf ein Array anzuwenden, ist der Dauerbrenner — Sie bekommen Indizes, und zwar als Text, nicht als Zahlen.

6:47 Bei Map-Paaren die Destrukturierung zu vergessen, führt zu einer Ausgabe, die aussieht wie ein Array mit zwei Einträgen, weil sie genau das ist. Der dritte Punkt ist der gefährlichste und in der Praxis am schwersten zu debuggen: die Sammlung zu verändern, über die man gerade läuft. Je nach Struktur überspringen Sie dann Einträge oder laufen ins Endlose. Sammeln Sie stattdessen die Änderungen und führen Sie sie nach der Schleife aus.

7:12 Und der letzte Punkt ist der überflüssige Index, den wir schon kennen.

Iteratoren und Iterator-Helfer

7:16 Jetzt ein fortgeschrittenes Thema, und das sage ich bewusst dazu: Verständnis genügt hier, Beherrschung ist für den Alltag nicht nötig. Es geht darum, wie Werte durch eine Verarbeitungskette fließen können, ohne dass unterwegs jedes Mal eine komplette Zwischenliste entsteht. Wir vertiefen jetzt die beiden Begriffe aus dem letzten Modul. Iterierbar ist der Wert, über den sich laufen lässt.

7:39 Der Iterator ist das Objekt, das die Arbeit macht — und es hat eine überraschend schlichte Schnittstelle: eine einzige Methode, die den nächsten Wert liefert, zusammen mit der Auskunft, ob es noch weitergeht. Mehr steckt technisch nicht dahinter. Das Neue sind die Helfer: Methoden, die auf solchen Iteratoren arbeiten und dabei träge sind.

7:59 Träge heißt, sie tun nichts, bis jemand den nächsten Wert anfordert. Genau daraus entsteht der Vorteil, den wir gleich sehen. Die ersten beiden Zeilen öffnen die Motorhaube: So sieht ein Iterator von innen aus, mit Wert und Fertig-Kennzeichen. Das brauchen Sie im Alltag nie, aber es entzaubert das Konzept. Der interessante Teil ist die Kette darunter.

8:20 Filtern, umwandeln, die ersten beiden nehmen — und erst der letzte Aufruf sammelt das Ergebnis tatsächlich in ein Array. Der Clou: Weil nach zwei Treffern Schluss ist, wird der Rest der Liste gar nicht erst angefasst. Die Kette arbeitet auf Zuruf, nicht auf Vorrat. Bei drei Beeten ist das egal, bei drei Millionen Datensätzen ist es der Unterschied zwischen Sekunden und Minuten.

8:43 Die Abwägung ist ehrlich zweiseitig. Die klassischen Array-Methoden erzeugen bei jedem Schritt ein neues Array — filtern Sie eine Million Einträge und wandeln sie dann um, entstehen zwei Zwischenlisten mit jeweils Hunderttausenden Einträgen. Die Iterator-Helfer reichen jeden Wert einzeln durch die ganze Kette, ohne diese Stufen zu materialisieren.

9:02 Aber — und das ist der entscheidende dritte Punkt — bei kleinen Listen sind die Array-Methoden einfacher, vertrauter und völlig ausreichend. Der Gewinn zeigt sich erst bei großen Mengen oder wenn Sie ohnehin nur einen Teil brauchen. Wählen Sie also nach der Datenmenge, nicht nach der Modernität. Bauen Sie eine Kette, die aus einer längeren Liste genau zwei Ergebnisse liefert — und benennen Sie dann, welche Zwischenlisten dabei nicht entstanden sind.

9:27 Diese Benennung ist der Kern der Aufgabe. Wer sagen kann, was nicht passiert ist, hat die Trägheit verstanden. Ein praktischer Hinweis, der Ihnen Verwirrung erspart: Ohne den abschließenden Sammel-Aufruf bleibt das Ergebnis ein Iterator. Auf der Konsole sehen Sie dann etwas, das aussieht wie ein leeres Objekt — und denken, die Kette hätte nichts gefunden. Sie hat nur noch nicht angefangen.

9:50 Der vergessene Sammel-Aufruf ist genau der eben beschriebene Fall — die Ausgabe verwirrt, obwohl alles korrekt ist. Der zweite Punkt ist eine Eigenschaft, die man kennen muss: Ein Iterator ist nach dem ersten Durchlauf erschöpft. Er ist keine Sammlung, sondern ein Durchgang. Wollen Sie zweimal darüber, brauchen Sie ihn zweimal.

10:09 Der dritte Punkt ist der Angemessenheitshinweis, den ich schon gegeben habe — für ein Array mit fünf Einträgen kaufen Sie hier Komplexität ohne Gewinn. Und der letzte ist der Verfügbarkeitscheck, denn die Helfer sind neu.

Kommandozeilen-Argumente lesen

10:23 Jetzt wird es wieder handfest. Bisher liefen unsere Programme mit fest verdrahteten Werten. Sobald sie Argumente entgegennehmen, werden aus Skripten kleine Werkzeuge — und genau so entsteht der größte Teil der Automatisierung, mit der Entwickler täglich arbeiten. Node stellt Ihnen die Aufrufargumente in einem Array bereit, und dieses Array hat eine Eigenheit, die man einmal wissen muss.

10:46 Die ersten beiden Einträge sind nicht das, was der Nutzer getippt hat — es sind der Pfad zum Node-Programm und der Pfad zu Ihrem Skript. Erst ab der dritten Position, also ab Index zwei, kommt das, was der Aufrufer wirklich übergeben hat. Das wirkt zunächst wie eine Merkwürdigkeit, ist aber konsequent: Das Array bildet den kompletten Aufruf ab, so wie das Betriebssystem ihn gesehen hat.

11:08 Die erste Zeile schneidet die beiden Pfade weg — deshalb die Zwei. Die zweite nutzt die Array-Destrukturierung aus Modul drei, um die ersten beiden Werte in benannte Variablen zu holen. Das ist deutlich lesbarer als ein Zugriff über Positionen. Der Block darunter ist die Prüfung, und hier gilt genau das, was wir im Eingabemodul besprochen haben: Argumente sind Nutzereingaben. Der Fußtext sagt es deutlich.

11:32 Niemand garantiert Ihnen, dass die richtige Anzahl kommt oder dass die Werte sinnvoll sind. Beachten Sie auch die Meldung — sie zeigt den korrekten Aufruf, statt nur zu sagen, dass etwas fehlt. Das ist der eigentliche Fortschritt gegenüber dem Zählen von Positionen. Sie beschreiben, welche Optionen es gibt, welchen Typ sie haben und ob es eine Kurzform gibt — und bekommen ein fertig ausgewertetes Objekt zurück.

11:57 Der Vorteil zeigt sich, sobald sich etwas ändert. Eine zusätzliche Option ergänzen Sie in der Beschreibung, und alles andere bleibt, wie es ist. Bei Positionen müssten Sie überlegen, an welche Stelle sie gehört, und alle bestehenden Aufrufe prüfen. Dazu kommt: Benannte Optionen sind für den Nutzer selbsterklärend. Niemand muss sich merken, dass an dritter Stelle die Fläche steht.

12:20 Bauen Sie ein Werkzeug, das ein Beet über benannte Optionen anlegt — und bei einem fehlenden Pflichtwert eine verständliche Meldung ausgibt statt eines Absturzes. Damit verbinden Sie die Argumentauswertung mit der Prüflogik aus Modul fünf. Der Hinweis stellt eine gute Entwurfsfrage: Vergleichen Sie die Fassung mit Positionen und die mit benannten Optionen, und überlegen Sie, welche eine zusätzliche Option besser verträgt.

12:43 Diese Frage — was passiert, wenn sich etwas ändert — ist eine der nützlichsten überhaupt, wenn man zwischen zwei Lösungen wählt. Das vergessene Abschneiden der ersten beiden Einträge führt dazu, dass Sie den Node-Pfad als Befehl verarbeiten — die Fehlermeldung ist dann besonders rätselhaft. Positionen zu zählen statt benannter Optionen funktioniert bei zwei Argumenten und wird ab vier zur Qual.

13:06 Der dritte Punkt ist eine Haltungsfrage, die ich gern wiederhole: Argumente sind nicht deshalb geprüft, weil sie vom Aufrufer kommen — im Gegenteil. Und der letzte schlägt die Brücke zum Typkapitel: Alles, was von der Kommandozeile kommt, ist Text. Auch die Zahl. Ohne Umwandlung rechnen Sie mit Zeichenketten, und das Plus verkettet dann munter.

Ausblick: Daten über Grenzen bewegen

13:26 Zum Abschluss ein reiner Ausblick. Wir implementieren hier nichts — wir spannen den roten Faden zu den Modulen, die noch kommen. Denn eine Frage haben wir bisher konsequent ausgeklammert: Was passiert eigentlich, wenn das Programm endet? Die Antwort ist ernüchternd: Dann ist alles weg. Solange ein Programm läuft, liegen seine Daten im Arbeitsspeicher, und der wird beim Beenden freigegeben.

13:50 Alles, was darüber hinaus bestehen soll — oder ein anderes System erreichen —, muss vorher in ein Format überführt werden, das dieses System versteht. Das ist der Moment, in dem aus einem Objekt im Speicher etwas anderes wird: Text in einer Datei, JSON auf der Leitung, eine Zeile in einer Tabelle. Diese Übersetzung ist keine Nebensache; sie ist einer der Hauptteile jeder echten Anwendung.

14:13 Drei Wege, ein gemeinsames Muster: An jeder Grenze findet eine Übersetzung statt. Bei der Datei wird aus dem Objekt Text und beim Einlesen wieder ein Objekt — das kennen Sie aus dem JSON-Kapitel. Bei einer Schnittstelle geht dasselbe hin und her, mit dem Zusatz, dass die Gegenseite fremd ist und man ihren Daten misstrauen sollte.

14:32 Und bei der Datenbank werden Zeilen zu Objekten und mehrere Zeilen zu einem Array — die Struktur, die wir als Standardmuster kennengelernt haben. Diese drei Wege bauen die kommenden Module aus. Was Sie jetzt schon mitnehmen können, ist das Muster dahinter. Hier schließt sich der Kreis zum letzten Modul. Die Struktur im Speicher wählen Sie nach der Aufgabe: ein Array für Reihenfolge, ein Objekt für den einzelnen Datensatz, eine Map fürs schnelle Nachschlagen.

14:59 Aber — und das ist der dritte Punkt — JSON kennt weder Map noch Set noch Funktionen noch undefined. Was über die Grenze soll, muss vorher in eine übertragbare Form gebracht werden. Das ist keine lästige Pflicht, sondern eine bewusste Entscheidung: Die Form im Speicher dient der Verarbeitung, die Form beim Transport der Übertragbarkeit.

15:18 Beides darf verschieden sein — es muss nur jemand die Übersetzung schreiben. Diese Aufgabe erzeugt keinen Code, sondern eine Entscheidung. Benennen Sie für einen Datenbestand dreierlei: die Struktur im Programm, die Form beim Speichern und die Stelle, an der umgewandelt werden muss. Besonders der dritte Punkt lohnt sich, denn er wird in Projekten gern vergessen und landet dann verstreut an fünf Stellen.

15:41 Der Hinweis nimmt Ihnen eine mögliche Verunsicherung: Eine Map beim Nachschlagen und ein Array beim Schreiben — beides ist gleichzeitig richtig. Es ist kein Widerspruch, sondern die Trennung von Verarbeitungsform und Transportform. Eine Map direkt in JSON schreiben zu wollen, liefert ein leeres Objekt — ohne Fehler, ohne Warnung.

16:00 Das ist ein besonders unangenehmer Fall, weil das Programm scheinbar funktioniert und die Datei am Ende leer ist. Der zweite Punkt ist die Grundannahme dieses Kapitels: Im Speicher gehaltene Daten überleben das Programmende nicht. Der dritte betrifft die Reihenfolge der Entscheidungen — die Struktur erst beim Speichern zu wählen, ist zu spät.

16:19 Und der letzte ist die Haltung gegenüber fremden Daten, die uns durch das ganze Seminar begleitet: Gehen Sie beim Einlesen nie davon aus, dass die Gegenseite Gültiges liefert.

Daten fließen jetzt

16:30 Drei Punkte zum Mitnehmen. Erstens: Die eingebauten Gruppier-Methoden ersetzen den Aufbau von Gruppen per Hand — eine Zeile statt fünf, und deutlich weniger Gelegenheit für Fehler. Zweitens die Merkregel beim Durchlaufen: for-of für Werte, for-in für Schlüssel, und bei Map-Paaren wird destrukturiert. Drittens die Abwägung bei den Iterator-Helfern — sie lohnen bei großen Mengen und Teilergebnissen, nicht als Selbstzweck.

16:54 Im nächsten Modul geht es an das Werkzeug, mit dem all das strukturiert wird: Funktionen, Gültigkeitsbereiche und Closures.