Komponenten und ihre Verträge

Komponenten und ihre Verträge

0:00 Jetzt bauen wir den ersten echten Baustein. Und ich möchte gleich zu Anfang den Begriff einführen, um den sich dieses Modul dreht: Vertrag. Eine Komponente ist nämlich nicht einfach ein Stück Oberfläche, sondern ein Versprechen — das geht hinein, das kommt heraus, alles andere ist meine Sache. Wenn dieses Versprechen klar ist, kann jemand die Komponente benutzen, ohne hineinzuschauen.

0:22 Und wenn es unklar ist, schaut jeder hinein, und dann ist es keine Komponente mehr, sondern ein Stück Code mit einem eigenen Ordner.

Angular verstehen und eine Anwendung aufbauen

0:31 Wir sind in der zweiten Hälfte des ersten Tages. Das Gerüst steht, jetzt entstehen die Bausteine. In diesem Modul die Auftragskarte — der Baustein, den später drei verschiedene Ansichten benutzen werden. Genau deshalb lohnt es sich, über seinen Vertrag nachzudenken, bevor man ihn schreibt.

Aufbau einer Komponente

0:49 Beginnen wir mit dem, was eine Komponente überhaupt ausmacht — und mit ein paar Konventionen, die aus dem Style Guide kommen und die Ihnen viel Diskussion ersparen. Eine Komponente ist eine Klasse, ein Template und optionale Styles — drei Dateien, die zusammengehören und denselben Namen tragen. Der Selector bestimmt, wie sie im HTML erscheint.

1:09 Neu gegenüber früher ist, dass Komponenten heute standalone sind: Sie nennen ihre Abhängigkeiten selbst, direkt in der Komponente, ohne den Umweg über ein NgModule. Das klingt nach einer Kleinigkeit und ändert in der Praxis erstaunlich viel — man sieht beim Lesen einer Komponente sofort, was sie braucht, statt in einer zentralen Datei nachschlagen zu müssen.

1:30 Was Sie hier sehen, ist die Grundform, und zwei Details daran sind wichtiger, als sie aussehen. Erstens die Sichtbarkeit: „protected" für alles, was nur das Template liest. Damit wird aus einem Feld, das zufällig öffentlich war, keine Schnittstelle, auf die sich jemand verlässt. Zweitens „readonly" für alles, was Angular selbst setzt — Eingaben, Ausgaben, Abfragen.

1:52 Beides sind Empfehlungen des Style Guide, beides kostet nichts, und beides verhindert genau die Art von Kopplung, die man später nur schwer wieder loswird. Vier Regeln, die auf denselben Gedanken hinauslaufen: Eine Komponente zeigt an. Fachlogik gehört in einen Service — dazu kommen wir in Modul acht ausführlich. Komplexe Ausdrücke gehören als Ableitung in die Klasse, wo sie testbar sind, statt ins Template, wo sie es nicht sind.

2:19 Lebenszyklus-Methoden bleiben kurz und rufen benannte Methoden auf. Und Ereignis-Methoden heißen nach der Absicht, nicht nach dem Ereignis — also „auftragOeffnen" und nicht „handleClick". Das ist keine Kosmetik: Beim Lesen sieht man den Unterschied zwischen einer Komponente, die weiß, was sie tut, und einer, die nur reagiert.

2:40 Der erste Punkt beschreibt, wie es tatsächlich passiert: Die Komponente wächst zur Fachschicht, weil der Service noch fehlt. Niemand entscheidet das — es ergibt sich, weil der Code ja irgendwo hin muss und die Komponente schon da ist. Der zweite: Öffentliche Felder werden zur unbeabsichtigten Schnittstelle. Jemand greift von außen darauf zu, und ab dann können Sie sie nicht mehr umbenennen.

3:01 Und der dritte ist schnell behoben, wenn man ihn kennt: Ein Selector ohne Präfix kollidiert früher oder später mit einem Baustein aus einer Bibliothek.

Eingaben mit input() und required

3:10 Jetzt zum ersten Teil des Vertrags — dem, was hineingeht. Hier hat sich gegenüber älteren Angular-Versionen am meisten geändert, und die Änderung ist eine Verbesserung. Eine Eingabe wird heute als Funktion erklärt, und das Ergebnis ist ein Signal — also ein Wert, der seine Leser benachrichtigt, wenn er sich ändert. Ein Standardwert leitet den Typ gleich mit ab, was Ihnen eine Typangabe erspart.

3:35 Für Pflichtfelder gibt es eine eigene Variante, und die wird beim Bauen geprüft — wer die Bindung vergisst, erfährt es nicht zur Laufzeit, sondern im Build. Dazu zwei Optionen: einen Alias für den Namen im Template und eine Umwandlungsfunktion für den eingehenden Wert. Gelesen wird die Eingabe wie jedes Signal: durch Aufruf.

3:55 Drei Eingaben, drei verschiedene Aufgaben — darauf kommt es hier an. Die erste ist Pflicht und nimmt ein fachliches Objekt entgegen, nicht seine Einzelfelder. Die zweite zeigt die Umwandlung: Angular bringt fertige Funktionen mit, die aus einem Attribut ohne Wert ein „wahr" machen — damit können Sie den Baustein schreiben wie ein natives HTML-Element.

4:15 Die dritte zeigt den Alias. Und beachten Sie, was nirgends steht: keine Typangabe bei der zweiten und dritten, weil der Standardwert sie liefert. Diese Gegenüberstellung brauchen Sie vor allem beim Lesen fremden Codes. Links die Schreibweise, die Sie in praktisch jedem älteren Beispiel finden, rechts die heutige. Die interessanteste Zeile ist die unterste: Früher hat man auf Änderungen einer Eingabe über eine Lebenszyklus-Methode reagiert — eine Methode, die bei jeder Änderung irgendeiner Eingabe lief und in der man selbst herausfinden musste, welche es war.

4:47 Heute ist es eine Ableitung. Das ist nicht nur kürzer, es ist ein anderer Denkansatz: Sie beschreiben, was gilt, statt zu behandeln, was passiert ist. Der erste Punkt ist der, den Umsteiger am häufigsten machen: Die Eingabe wird in der Klasse geschrieben statt gelesen. Eine Eingabe gehört dem Aufrufer; wer sie verändert, bricht den Vertrag.

5:08 Der zweite ist heimtückisch: Ein Pflichtfeld bekommt einen Standardwert — und damit ist es kein Pflichtfeld mehr. Die Prüfung beim Bauen fällt weg, und niemand merkt es, weil ja ein Wert da ist. Und der dritte: Ein Alias verdeckt den Feldnamen. Wer im Code nach dem Namen aus dem Template sucht, findet nichts.

Ausgaben und Zwei-Wege-Bindung

5:27 Der zweite Teil des Vertrags: das, was herauskommt. Und dabei gleich die Frage, an der sich die Architektur entscheidet — melden oder teilen? Eine Ausgabe ist ein eigenes Ereignis, das die Komponente auslöst. Drei Eigenschaften sind wichtig: Angular-Ereignisse steigen nicht im DOM auf, sie unterscheiden Groß- und Kleinschreibung, und sie tragen eine typisierte Nutzlast.

5:49 Daneben gibt es die Zwei-Wege-Bindung: Ein Wert, den die Komponente selbst ändern darf und dessen Änderung automatisch nach außen gemeldet wird. Das Muster kennen Sie von einem Lichtschalter mit Rückmeldung — Sie schalten, und der Schalter zeigt auch an, wenn jemand anders geschaltet hat. Hier stehen beide Varianten nebeneinander, und der Vergleich ist der eigentliche Inhalt.

6:11 Oben die Ausgabe: Die Karte meldet, dass jemand einen Auftrag öffnen will — was daraus folgt, entscheidet der Aufrufer. Darunter die Zwei-Wege-Bindung fürs Merken: Das ändert die Karte selbst, also darf sie es auch halten. Die Faustregel dahinter: Wenn die Komponente den Wert selbst verändert, ist eine Zwei-Wege-Bindung richtig. Wenn sie nur mitteilt, dass etwas passiert ist, ist es eine Ausgabe.

6:35 Wer das vertauscht, führt den Zustand doppelt. Der entscheidende Satz ist der erste: Die Komponente bleibt frei von der Frage, wer den Zustand hält. Das klingt abstrakt, ist aber sehr praktisch. Unsere Auftragskarte wird von drei Stellen benutzt — der Übersicht, der Suche und später der Detailansicht. Jede davon geht anders mit der Auswahl um.

6:56 Würde die Karte die Auswahl selbst speichern, müsste sie alle drei Fälle kennen. So meldet sie nur, und der Aufrufer entscheidet, ob er reagiert, speichert oder ignoriert. Zwei-Wege-Bindung lohnt sich deshalb nur für Werte, die die Komponente wirklich selbst ändert. Der erste Punkt ist der wichtigste: Ein geteiltes Objekt ersetzt das Ereignis. Das ist bequem — beide Seiten schauen auf dasselbe — und koppelt sie fest aneinander.

7:23 Ab dann können Sie keine der beiden mehr allein ändern. Der zweite ist ein Ärgernis, kein Fehler: Groß- und Kleinschreibung der Ausgabe weicht von der Bindung ab, und es passiert einfach nichts. Keine Fehlermeldung, kein Hinweis. Und der dritte: Zwei-Wege-Bindung wird dort verwendet, wo eine Ausgabe genügt hätte — mehr Vertrag als nötig.

CSS-Kapselung und Darstellung

7:44 Bleibt der dritte Teil: das Aussehen. Angular macht hier etwas, das vielen zuerst im Weg steht und sich später als Geschenk herausstellt. Angular kapselt die Styles einer Komponente. Was Sie dort schreiben, gilt für diese Komponente und sonst nirgends. Für Umsteiger aus der Welt globaler Stylesheets ist das zuerst ungewohnt — man schreibt eine Regel, und sie wirkt nicht dort, wo man es erwartet.

8:09 Dazu kommt das Host-Element: das Element, auf das der Selector passt. Es trägt Layout und äußere Abstände. Merken Sie sich die Arbeitsteilung: Was drinnen aussieht, entscheidet die Komponente. Wie viel Platz sie nach außen braucht, entscheidet ebenfalls sie — aber am Host, nicht in ihren Kindern. Der Gewinn ist derselbe wie bei Modulen in anderen Sprachen: lokale Änderungen bleiben lokal. Ein Stil aus einem Feature verändert kein anderes.

8:36 Eine Klasse umbenennen ist eine Änderung an einer Stelle, nicht eine Suche über das ganze Projekt. Dazu zwei praktische Punkte: Der Style Guide bevorzugt direkte Klassen- und Stilbindungen gegenüber den älteren Direktiven — kürzer und ohne zusätzlichen Import. Und der Abstand nach außen gehört ans Host-Element. Steht er im Kind, wiederholt er sich an jeder Einbaustelle, und irgendwann stimmt er an einer nicht mehr.

9:01 Der erste Punkt ist die typische erste Reaktion auf Kapselung: Sie wird abgeschaltet, um einen einzelnen Stil durchzureichen. Danach ist sie für die ganze Komponente weg, wegen einer Zeile. Der zweite ist der, den ich in fast jedem Projekt sehe: Äußere Abstände stehen im Kind und wiederholen sich. Und der dritte ist der ärgerlichste in der Fehlersuche — globale Stile überschreiben Komponentenstile, und weil sie ganz woanders stehen, findet niemand die Stelle.

9:28 Wenn ein Stil sich unerklärlich verhält: Schauen Sie zuerst nach, ob er von außen kommt.

Übung

9:33 Machen wir aus der Theorie einen Vertrag. Und zwar einen, den drei verschiedene Aufrufer benutzen können, ohne sich gegenseitig im Weg zu stehen. Die Auftragskarte zeigt Auftragsnummer, Fahrzeug, Standort und Status. Interessant ist nicht die Karte, sondern dass sie an drei Stellen gebraucht wird: in der Übersicht mit allem, in der Suche kompakter, und später in der Detailansicht ohne die Notiz, weil die dort ausführlich darunter steht.

9:59 Drei Stellen mit unterschiedlichem Bedarf — das ist genau die Situation, in der ein Vertrag entweder gut gedacht ist oder anfängt zu wuchern. Das Lernziel bringt die Reihenfolge auf den Punkt: aus dem Bedarf der Aufrufer herleiten, nicht aus dem, was die Karte zufällig anzuzeigen hat. Das Erfolgskriterium nennt konkrete Zahlen — eine Pflichteingabe, zwei optionale, eine Ausgabe — und einen Satz, der wichtiger ist als die Zahlen: Sie soll sich einbauen lassen, ohne ihr Innenleben zu kennen.

10:28 Das ist die Probe. Wenn jemand beim Einbauen fragen muss, was eine Eingabe eigentlich bewirkt, ist der Vertrag noch nicht fertig. Der Ablauf dreht die übliche Reihenfolge um. Sie schreiben nicht zuerst die Komponente und leiten dann ab, was sie braucht — Sie befragen zuerst die drei Einbaustellen. Daraus ergibt sich, was Pflicht ist und was Wahl. Dann erst kommen die Eingaben, mit abgeleiteten Typen statt ausgeschriebenen. Die Auswahl wird gemeldet, nicht gespeichert.

10:56 Und der letzte Schritt ist der, den ich am nützlichsten finde: den Vertrag in fünf Zeilen aufschreiben und im Review vorlesen. Wenn sich das vorlesen lässt, ohne dass jemand nachfragt, stimmt er. Der erste Punkt ist die häufigste Fehlform: Die Karte bekommt eine Eingabe je Textfeld — Nummer, Kennzeichen, Modell, Status — statt eines fachlichen Objekts.

11:18 Das funktioniert und ist bei jeder Erweiterung eine Änderung an allen drei Einbaustellen. Der zweite: Die Auswahl wird in der Karte gespeichert und ist dort von außen nicht abfragbar. Und der dritte ist die Krankheit, an der Verträge sterben: Er wächst um Felder, die nur eine der drei Stellen braucht. Im nächsten Modul setzen wir die Karte in eine Liste — und kümmern uns um Templates.