Templates, Kontrollfluss und Wiederverwendung

Templates, Kontrollfluss und Wiederverwendung

0:00 Templates sind der Teil von Angular, der sich in den letzten Jahren am sichtbarsten verändert hat. Wer vor fünf Jahren aufgehört hat hinzuschauen, kennt noch die Schreibweise mit Sternchen vor den Direktiven. Die gibt es weiterhin, aber der Kontrollfluss steckt inzwischen im Compiler und liest sich wie JavaScript. Das ist mehr als Kosmetik: Der Compiler versteht diese Blöcke, er kann sie prüfen und optimieren.

0:23 In diesem Modul bauen wir damit die Auftragsübersicht — mit Filter, mit Leerfall und mit einem kleinen Übergang.

Angular verstehen und eine Anwendung aufbauen

0:30 Das ist das letzte Modul des ersten Tages. Am Ende haben Sie ein lauffähiges Projekt mit einem sichtbaren Ergebnis: einer Liste, die sich filtern lässt und die auch dann noch etwas Vernünftiges sagt, wenn kein Treffer übrig bleibt. Morgen kümmern wir uns darum, wo der Zustand dahinter eigentlich wohnt.

Bindung, Ereignisse und Pipes

0:47 Fangen wir mit den Grundlagen an — und vor allem mit der Frage, was in ein Template gehört und was nicht. Denn das ist die Entscheidung, die über die Testbarkeit Ihrer ganzen Anwendung mitbestimmt. Die Schreibweisen sind schnell erzählt: geschweifte Klammern für Werte, eckige für Eigenschaften, runde für Ereignisse. Pipes formatieren für die Anzeige.

1:08 Interessanter ist die Regel des Style Guide dazu: Komplexe Logik gehört aus dem Template heraus in die Klasse, bevorzugt als Ableitung. Und: direkte Klassen- und Stilbindungen statt der älteren Direktiven. Denken Sie an ein Template wie an ein Schaufenster. Es zeigt, was da ist, und es nimmt entgegen, wenn jemand klopft. Es entscheidet nicht, was verkauft wird.

1:31 Achten Sie auf die mittlere Zeile — die Klassenbindung. Dort steht kein Vergleich, keine Bedingung, sondern der Aufruf einer Ableitung. Die Regel „ist dieser Auftrag dringend" steht in der Klasse und ist damit prüfbar, ohne etwas zu rendern. Hätte ich sie ins Template geschrieben, wäre sie nur durch eine gerenderte Ansicht zu testen — und liefe außerdem bei jedem Durchlauf neu.

1:53 Darunter die Pipe für das Datum: Das ist reine Anzeige und gehört genau dorthin. Die Trennlinie verläuft zwischen Formatierung und Entscheidung. Vier Dinge, und sie haben dieselbe Begründung: Im Template ist nichts davon sichtbar und nichts davon messbar. Berechnungen laufen bei jedem Durchlauf, ohne dass irgendwo steht, was sie kosten. Fachliche Regeln lassen sich nur mit Browser prüfen.

2:17 Verschachtelte Bedingungen sind nur im gerenderten Zustand lesbar — also nicht beim Lesen des Codes. Und Methodenaufrufe verbergen ihre Kosten vollständig. Nichts davon ist verboten, alles funktioniert. Es verschiebt nur die Kosten von der Entwicklung in den Betrieb, und dort sind sie teurer. Der erste Punkt ist der teuerste und der unauffälligste: Eine Methode im Template wird bei jedem Durchlauf aufgerufen. Bei zehn Zeilen merkt das niemand, bei tausend schon.

2:45 Der zweite geht in die andere Richtung und ist eher ein Schönheitsfehler: Formatierung wandert in die Klasse, obwohl eine Pipe genügt hätte. Und der dritte klingt nach Kleinigkeit, ist aber beim Lesen ein echter Unterschied: Ereignis-Methoden heißen nach dem Klick statt nach der Absicht. Wer „handleClick" liest, weiß nichts. Wer „auftragOeffnen" liest, weiß alles.

Kontrollfluss mit @if, @for und @switch

3:07 Jetzt zum Teil, der neu ist — jedenfalls für alle, die Angular vor Version siebzehn zuletzt angeschaut haben. Und zu einer Pflichtangabe, die es vorher nicht gab. Der eingebaute Kontrollfluss kennt Bedingungen mit mehreren Zweigen, Schleifen mit einem Leerfall und eine Verzweigung mit strengem Vergleich. Die wichtigste Neuerung steckt in der Schleife: Die Angabe, woran Angular einen Datensatz wiedererkennt, ist Pflicht. Früher war sie eine Optimierung, die man vergessen konnte.

3:37 Heute muss sie da sein. Dazu kommen Variablen für Index, Anzahl, erste und letzte Zeile. Und die Verzweigung fällt nicht durch — wer das aus anderen Sprachen anders kennt, sollte kurz innehalten. Zwei Dinge sind hier bemerkenswert, und beide betreffen die Ränder. Erstens die Angabe hinter „track": Sie verbindet Datensatz und DOM-Knoten.

3:57 Ohne einen stabilen Schlüssel baut Angular Zeilen neu auf, statt sie zu verschieben — sichtbar als Flackern beim Sortieren. Zweitens der Leerfall direkt daneben. Er gehört zur Schleife und steht deshalb dort, wo man ihn beim Lesen erwartet. Eine leere Liste ist kein Sonderfall, den man später ergänzt — sie ist der Normalfall am ersten Tag und nach jedem zu engen Filter.

4:20 Diese Variablen stehen Ihnen zur Verfügung, ohne dass Sie etwas tun müssen — und genau darin liegt eine Versuchung. Der Index ist verfügbar, also nimmt man ihn gern für „track". Tun Sie das nicht. Der Index sagt, an welcher Stelle etwas gerade steht, nicht, was es ist. Sortieren Sie die Liste, und derselbe Index zeigt auf einen anderen Datensatz.

4:42 Wofür die Variablen dagegen gut sind: für Darstellung. Die erste Zeile anders gestalten, jede zweite einfärben, die Anzahl anzeigen. Also überall dort, wo die Position wirklich die Information ist. Der erste Punkt ist der, vor dem ich gerade gewarnt habe, und er ist so häufig, dass ich ihn zweimal nenne: „track" bekommt den Index, obwohl sich die Reihenfolge ändert.

5:05 Der zweite: Der Leerfall fehlt, und die Liste wirkt beim Filtern defekt — der Benutzer sieht eine weiße Fläche und weiß nicht, ob er etwas falsch gemacht hat oder die Anwendung. Und der dritte ist eine Überraschung für Umsteiger: Die Verzweigung wird mit lockerem Vergleich erwartet und trifft nicht, weil sie streng vergleicht.

Direktiven und Content Projection

5:23 Kommen wir zur Wiederverwendung — und zu zwei Mitteln, die oft übersehen werden, weil die Komponente so naheliegt. Eine Direktive fügt einem vorhandenen Element Verhalten hinzu, ohne selbst etwas darzustellen. Content Projection geht andersherum: Eine Komponente lässt eine Lücke, und der Aufrufer füllt sie. Stellen Sie sich einen Bilderrahmen vor.

5:44 Der Rahmen bringt Form und Aufhängung mit, aber er schreibt nicht vor, welches Bild hineinkommt. Genau das ist Content Projection. Und eine Direktive wäre dann die Aufhängung allein — brauchbar an jedem Rahmen, ohne selbst einer zu sein. Das Muster ist klein und trägt weit. Das Panel bringt Rahmen, Kopf und Fuß mit, kennt aber seinen Inhalt nicht.

6:05 Der Aufrufer setzt ein, was er braucht — hier über einen benannten Bereich für den Titel und einen allgemeinen für den Rest. Worauf es ankommt: Dieses Panel muss nie geändert werden, wenn ein neuer Aufrufer etwas anderes hineinsetzen will. Die Alternative wäre eine Eingabe je Variante gewesen, und die Liste dieser Eingaben wächst mit jedem neuen Fall.

6:27 Vier Anzeichen, und wenn zwei davon zutreffen, ist die Direktive die bessere Wahl. Das Verhalten gilt für viele verschiedene Elemente — dann wäre eine Komponente eine Zwangsjacke. Es gibt nichts zu rendern, nur etwas zu tun. Eine zusätzliche Komponente würde nur eine Hülle erzeugen, also ein Element mehr im DOM ohne eigenen Zweck.

6:46 Und der vierte ist der strategische: Der Baustein soll offen bleiben, statt jede Variante als Eingabe zu kennen. Das ist derselbe Gedanke wie bei der Content Projection, nur von der anderen Seite. Der erste Punkt beschreibt, wie Bausteine sterben: Für jede Abweichung kommt eine weitere Eingabe hinzu, statt Inhalt zu projizieren.

7:06 Nach zehn Eingaben versteht niemand mehr, welche Kombination erlaubt ist. Der zweite ist ein stiller: Ein benannter Bereich wird im Aufruf vergessen und bleibt einfach leer — keine Warnung, keine Meldung, nur eine Lücke, die niemand bemerkt. Und der dritte hebt den Nutzen wieder auf: Eine Direktive greift auf Interna der Komponente zu und koppelt sich damit fest an genau die, von der sie unabhängig sein sollte.

Animationen mit animate.enter und animate.leave

7:30 Zum Abschluss noch etwas, das neu ist und das viele angenehm überrascht: Bewegung, ohne dafür ein zusätzliches Paket einzubinden. Zwei Attribute, mehr ist es nicht. Eines setzt beim Einfügen eines Elements eine CSS-Klasse, das andere beim Entfernen — und Angular nimmt sie nach der längsten Animation wieder weg. Das Praktische daran: Beides ist in den Compiler eingebaut. Sie brauchen kein zusätzliches Paket, keine Deklarationen, keinen eigenen Baustein.

7:59 Wichtig ist eine Einschränkung: Das ältere Animationspaket lässt sich in derselben Komponente nicht daneben verwenden. Es ist also ein Ersatz, kein Zusatz. Worauf es hier ankommt, ist die Arbeitsteilung. Angular kümmert sich um den Zeitpunkt — wann die Klasse kommt, wann sie wieder geht. Wie die Animation aussieht, steht vollständig in Ihrem CSS.

8:21 Sie schreiben also normales CSS, und Angular sorgt dafür, dass das Element beim Verschwinden lange genug im DOM bleibt, damit man es überhaupt verschwinden sieht. Das war früher der aufwendige Teil. Behalten Sie im Kopf, dass es eine Variante mit Rückruf für JavaScript-Animationen gibt — dort müssen Sie das Ende selbst melden.

8:41 Der erste Punkt ist eine harte Grenze: altes und neues Animationsmodell in derselben Komponente — das geht nicht. Der zweite betrifft die Rückruf-Variante: Wer das Ende nicht meldet, wartet in eine Zeitgrenze hinein, und die Oberfläche fühlt sich träge an. Der dritte ist einer, der in der Barrierefreiheit wiederkommt: Bewegung wird gesetzt, ohne die Systemeinstellung für reduzierte Bewegung zu beachten.

9:05 Für manche Menschen ist das nicht Geschmack, sondern Übelkeit. Und der vierte: Kindkomponenten werden nicht automatisch mitanimiert.

Übung

9:13 Bauen wir die Übersicht. Sie ist die Ansicht, an der wir die nächsten Tage immer wieder weiterarbeiten — insofern lohnt es sich, sie gleich ordentlich zu machen. Die Übersicht zeigt alle offenen Reparaturaufträge eines Standorts, mit einem Filter für Status und Fahrzeugklasse. Der interessante Teil ist der Rand: Was passiert, wenn kein Treffer übrig bleibt? In der ersten Fassung bei Falkenhorst stand dort nichts — eine weiße Fläche.

9:39 Die Meisterinnen haben daraufhin regelmäßig die Seite neu geladen, weil sie dachten, etwas sei kaputt. Ein Leerfall ist kein Detail für später. Er ist die Ansicht, die Ihre Benutzer am häufigsten sehen, wenn sie suchen. Das Lernziel nennt den Anspruch: Die Anzeige soll auch an den Rändern verständlich bleiben. Das Erfolgskriterium hat drei Teile, und alle drei sind beobachtbar.

10:03 Ohne Flackern filtern — das ist die Frage nach dem Schlüssel. Bei null Treffern erklären, was los ist — das ist der Leerfall. Und beim Sortieren keine Zeilen unnötig neu aufbauen — auch das hängt am Schlüssel. Wer früh fertig ist, ergänzt einen Übergang und prüft ihn bei reduzierter Bewegung. Das ist kein Zusatz, sondern die Probe, ob der Übergang sauber gebaut ist.

10:26 Fünf Schritte mit einer klaren Dramaturgie: erst die Liste, dann die Ränder, dann die Sauberkeit. Der dritte Schritt ist der wichtigste — den Filterzustand als Ableitung in die Klasse holen. Damit ist er testbar und läuft nicht bei jedem Durchlauf. Der vierte zeigt die Verzweigung für den Status, und dabei bitte den Standardfall belegen; ein unbekannter Status soll etwas anzeigen und nicht nichts.

10:49 Und der fünfte ist die Probe aufs Exempel: Sortierung ändern und schauen, ob die Zeilen erhalten bleiben. Die drei Fallen sind genau die, gegen die wir gerade gearbeitet haben. Der Schlüssel steht auf dem Index, und die Sortierung baut die Liste komplett neu auf. Der Filter rechnet im Template und läuft bei jedem Durchlauf erneut. Und der Leerfall zeigt eine leere Fläche ohne Hinweis auf den Filter.

11:13 Damit endet der erste Tag: Sie haben ein Projekt, einen Baustein und eine Ansicht. Morgen stellen wir die Frage, die wir heute umgangen haben — wo wohnt der Zustand eigentlich, und wer darf ihn ändern?