Standalone & Style Guide

Angular — Standalone & Style Guide

0:00 Im vorigen Modul ging es um die Voreinstellungen des Frameworks. Jetzt geht es um etwas anderes: um die Art, wie Angular-Code heute geschrieben wird. Das klingt nach Geschmack, ist aber handfester, als man denkt. Wer in ein fremdes Angular-Projekt kommt, verbringt die ersten Tage vor allem damit, sich zu orientieren. Jede Abweichung von der üblichen Form kostet dabei Zeit — nicht viel auf einmal, aber ständig.

0:25 Standalone Components, die neue Template-Syntax und der offizielle Style Guide haben alle dasselbe Ziel: Code, den andere auf Anhieb wiedererkennen. Darum geht es in diesem Modul.

Standalone Components & Style Guide

0:36 Wir gehen vom Groben ins Feine. Zuerst die Standalone Components — die Frage, wie eine Komponente überhaupt an ihre Abhängigkeiten kommt, und wie man eine gewachsene Anwendung dorthin bringt, ohne alles auf einmal umzubauen. Danach die neue Control-Flow-Syntax im Template. Und zum Schluss zweimal Style Guide: einmal für Dateinamen und Projektstruktur, einmal für Komponenten, Direktiven und Services.

1:00 Der letzte Teil ist eine ganze Reihe kleiner Regeln. Keine davon ist für sich genommen dramatisch — zusammen entscheiden sie darüber, ob Ihr Projekt vertraut oder eigenwillig wirkt.

Standalone Components

1:11 Fangen wir mit dem Baustein an, aus dem alles besteht. Über Jahre brauchte eine Angular-Komponente ein Modul, das sie kannte und bekannt machte. Diese Schicht ist inzwischen optional — und für neuen Code ausdrücklich nicht mehr vorgesehen. Was das praktisch bedeutet und wie man eine bestehende Anwendung schrittweise umstellt, schauen wir uns jetzt an.

1:31 Und die Frage ist praktischer, als sie klingt: Sie entscheidet darüber, wie viele Dateien Sie öffnen müssen, um eine Komponente zu verstehen. Eine Standalone Component importiert ihre Abhängigkeiten selbst. Der Unterschied lässt sich mit einer Küche erklären: Früher gab es eine zentrale Vorratskammer, das NgModule, in der alles lag, was irgendwer brauchen könnte — und jede Komponente durfte sich daraus bedienen, ohne zu sagen, was sie eigentlich nutzt.

1:57 Heute schreibt jede Komponente ihre Zutatenliste selbst an die Tür. Das ist ein paar Zeilen mehr Schreibarbeit und dafür deutlich mehr Klarheit: Sie sehen einer Komponente an, wovon sie abhängt, ohne eine zweite Datei aufschlagen zu müssen. Bei neuen Projekten ist das inzwischen die Voreinstellung. Der offensichtliche Gewinn ist weniger Boilerplate — kein Deklarieren, kein Exportieren, keine dritte Stelle, an der man etwas vergessen kann.

2:22 Wichtiger finde ich aber den zweiten Punkt: Eine Komponente wird für sich lesbar. Wer sie verstehen will, muss nicht mehr rekonstruieren, welches Modul ihr was zur Verfügung stellt. Und dann gibt es noch einen praktischen Aspekt, der oft untergeht: Sie müssen sich nicht entscheiden. Module und Standalone Components funktionieren nebeneinander in derselben Anwendung.

2:43 Eine Migration ist deshalb kein Projekt mit Stichtag, sondern etwas, das man nebenher erledigen kann. Zwei Dinge sind hier bemerkenswert, und beide sind unscheinbar. Erstens: Es steht nirgends „standalone: true". Das ist mittlerweile die Voreinstellung — die Zeile brauchen Sie nur noch, wenn Sie das Gegenteil wollen. Zweitens: die imports-Liste. Das ist die erwähnte Zutatenliste.

3:08 Was das Template benutzt, steht dort — Pipes, Direktiven, Kindkomponenten. Und genau daran entzündet sich später die Migration: Eine Komponente kann nur importieren, was selbst schon standalone ist. Merken Sie sich diesen Satz, er erklärt gleich, warum die Reihenfolge beim Umbauen so wichtig ist. Der rote Faden dieser fünf Schritte ist eine einzige Richtung: von unten nach oben.

3:33 Suchen Sie sich die Komponente, die am wenigsten benutzt wird und selbst keine Kinder hat — ein Blatt im Baum. Die stellen Sie um, samt ihrer Importe, und entfernen sie aus dem Modul. Und dann kommt der Teil, den man einplanen muss: Alle Komponenten, die dieses Blatt verwenden, müssen mit umgestellt werden. Das ist keine Panne, sondern die Mechanik.

3:54 Deshalb fängt man klein an — je weiter unten Sie ansetzen, desto weniger zieht sich mit. Der erste Punkt ist die häufigste teure Fehlentscheidung: oben anzufangen. Wer sich die Hauptkomponente vornimmt, zieht sämtliche Kinder mit, und die ziehen ihre eigenen Eltern mit — aus einem Nachmittag wird eine Woche. Der zweite Punkt erklärt, warum das so ist: Die Grenze zwischen beiden Welten ist in beide Richtungen dicht. Der dritte ist der Fehler, den der Compiler Ihnen freundlich sagt.

4:22 Und der vierte ist der stille: Das Modul hat CommonModule bereitgestellt, die Komponente hat es nie selbst importiert — und merkt das erst, wenn sie alleine dasteht. Diese Aufgabe ist klein und lehrt trotzdem das Entscheidende. Nehmen Sie sich eine Komponente ganz unten im Baum vor und machen Sie sie standalone. Geschafft haben Sie es, wenn die Anwendung kompiliert und das Modul die Komponente nicht mehr deklariert.

4:46 Der Hinweis ist der eigentliche Lerninhalt: Schreiben Sie vorher auf, welche Eltern mitgezogen werden müssen. Wer das einmal gemacht hat, schätzt den Aufwand einer Standalone-Migration danach realistisch ein — und das ist im Gespräch mit dem Team mehr wert als jede Faustregel aus einem Blogartikel.

Moderne Control-Flow-Syntax

5:03 Vom Aufbau einer Komponente zu ihrem Template. Auch hier hat Angular etwas ersetzt, das jahrelang selbstverständlich war: die Strukturdirektiven mit dem Sternchen davor. Der Nachfolger sieht anders aus, und er ist mehr als eine kosmetische Änderung. Es geht um die Frage, wie man Bedingungen und Schleifen im Template ausdrückt — und darum, warum die neue Schreibweise nicht nur besser aussieht, sondern dem Compiler tatsächlich mehr erlaubt.

5:29 Der entscheidende Satz steht in der Mitte: Die neuen Blöcke sind Teil der Template-Sprache, nicht mehr Direktiven, die obendrauf gelegt wurden. Das klingt nach einer Feinheit für Compilerbauer, hat aber ganz praktische Folgen. Eine Direktive war für Angular jahrelang eine Art Fremdkörper im Template — sie funktionierte, aber der Compiler konnte nur begrenzt darüber nachdenken.

5:49 Jetzt kennt er die Verzweigung selbst. Man kann sich das vorstellen wie den Unterschied zwischen einem angeklebten Zusatzknopf und einem, der von Anfang an im Gerät vorgesehen war. Der erste Punkt ist der, den man sofort merkt: Templates lesen sich wie gewöhnlicher Programmcode. Das Umschalten im Kopf zwischen TypeScript-Datei und Template entfällt weitgehend.

6:10 Der zweite Punkt betrifft alle, die je einen else-Zweig gebraucht haben — früher hieß das entweder, die Bedingung ein zweites Mal negiert hinzuschreiben, oder mit einer Template-Variablen zu hantieren. Beides ging, beides war umständlich. Und der letzte Punkt ist der, der auf lange Sicht am meisten bringt: Weil der Compiler die Konstrukte versteht, sind die Typprüfung und die Fehlermeldungen deutlich besser.

6:33 Achten Sie hier nicht auf die Syntax, sondern auf das, was oben verschwindet. Die alte Fassung braucht ein ng-template-Element mit einem Namen, obwohl dieses Element auf der Seite nie erscheint — es existiert nur, weil man einen Aufhänger für den else-Zweig brauchte. Unten steht schlicht, was gemeint ist. Ein Detail sollten Sie im Kopf behalten: Die neue Schleife verlangt zwingend eine track-Angabe.

6:56 Das ist die Nachfolgerin der früheren trackBy-Funktion, nur dass sie jetzt Pflicht ist statt guter Stil. Angular zwingt Sie damit zu einer Entscheidung, die vorher gerne vergessen wurde. Diese Aufgabe hat eine angenehme Eigenschaft: Der Großteil der Arbeit lässt sich automatisieren. Angular bringt eine Migration mit, die die Strukturdirektiven in Blöcke überführt.

7:17 Geschafft haben Sie es, wenn das Template die neue Syntax nutzt und die Seite unverändert rendert. Genau dieses „unverändert" ist der Prüfstein — schauen Sie danach wirklich in den Browser, nicht nur auf den Build. Und werfen Sie einen Blick auf das Ergebnis der Migration: Bei verschachtelten Bedingungen findet man danach oft Stellen, die sich noch einmal deutlich vereinfachen lassen.

Style Guide — Namen und Projektstruktur

7:39 Jetzt wird es auf den ersten Blick unspektakulär: Dateinamen und Ordner. Ich finde das trotzdem einen der wertvollsten Teile, weil er über etwas entscheidet, das man selten misst — wie schnell sich jemand Neues in Ihrem Projekt zurechtfindet. Und die gute Nachricht vorweg: Das meiste davon bekommen Sie geschenkt. Denn Konventionen wirken erst, wenn man sie nicht mehr bemerkt — und dahin kommt man nur, wenn alle dieselben nehmen.

8:04 Der Style Guide ist eine offizielle Sammlung von Konventionen — für Benennung, Struktur und Codierpraxis. Sein Wert liegt nicht darin, dass die Regeln besonders klug wären. Er liegt darin, dass alle dieselben nehmen. Man kann das mit Verkehrsregeln vergleichen: Ob rechts oder links gefahren wird, ist technisch beliebig — dass sich alle für dasselbe entscheiden, ist es nicht.

8:27 Genau so funktioniert der Style Guide. Wer sich daran hält, produziert Code, den andere Angular-Entwicklerinnen und -Entwickler sofort einordnen können. Das ist die ganze Idee. Hinter diesen vier Regeln steckt ein einziges Prinzip: Der Dateiname soll die Frage beantworten, was drinsteht, ohne dass man die Datei öffnet. Bindestriche statt Großbuchstaben, weil Dateisysteme unterschiedlich mit Groß- und Kleinschreibung umgehen.

8:53 Gleiche Namen für alle Dateien einer Komponente, damit sie im Editor beieinanderstehen. Die spec-Endung, damit sofort klar ist, was ein Test ist. Und die letzte Regel schließt den Kreis: Der Dateiname passt zum exportierten Namen. Das Beste daran — wer die Kommandozeile zum Generieren benutzt, muss sich keine einzige dieser Regeln merken.

9:14 Der Kern dieser fünf Schritte steckt im dritten und vierten. Gliedern Sie nach Fachbereichen, nicht nach Dateityp. Der Unterschied klingt akademisch, entscheidet aber darüber, wie sich Arbeit anfühlt: Wenn Sie am Warenkorb etwas ändern, wollen Sie in einem Ordner arbeiten — und nicht zwischen einem Komponentenordner, einem Style-Ordner und einem Service-Ordner hin- und herspringen.

9:34 Die Gliederung nach Dateityp sieht auf dem Papier ordentlich aus und arbeitet im Alltag gegen Sie. Und der letzte Schritt ist die einfachste Prüffrage überhaupt: Trägt diese Datei genau eine Verantwortung? Der erste Punkt ist der, den man am häufigsten sieht, und er entsteht meist mit den besten Absichten — es sieht ja aufgeräumt aus.

9:54 Der Preis fällt erst später an, wenn eine Änderung fünf Ordner betrifft. Der zweite Punkt ist die kleine Bequemlichkeit, die sich einschleicht: zwei Komponenten in einer Datei, weil die zweite so klein ist. Der Style Guide erlaubt das sogar in engen Grenzen, aber es wächst erfahrungsgemäß. Und der dritte Punkt ist die Ursache für vieles davon: Dateien von Hand anlegen.

10:15 Wer generiert, driftet gar nicht erst ab.

Style Guide — Komponenten, Direktiven, Services

10:18 Das letzte Kapitel dieses Moduls ist zugleich das dichteste. Es geht um Selektoren, um Ein- und Ausgaben, um Klassenmember und um die Frage, wie man heute Abhängigkeiten hineinreicht. Viele kleine Regeln — ich hebe die hervor, die im Alltag wirklich einen Unterschied machen. Vieles davon ist in fünf Minuten übernommen und wirkt über Jahre, weil es die Reibung an den Stellen wegnimmt, an denen man sonst jedes Mal kurz nachdenken muss.

10:44 Diese Regeln haben alle denselben Zweck: Kollisionen zu vermeiden. Ihre Komponenten leben in demselben Namensraum wie das HTML des Browsers und wie jede Bibliothek, die Sie einbinden. Ohne Konventionen ist es nur eine Frage der Zeit, bis zwei Dinge denselben Namen beanspruchen — und solche Fehler sind unangenehm zu finden, weil nichts kaputt aussieht, sondern nur das Falsche passiert.

11:06 Die Regeln auf der nächsten Folie sind deshalb weniger Stilfragen als Vorsichtsmaßnahmen. Drei Gedanken tragen diese Tabelle. Erstens: ein eigenes Präfix, damit Ihre Komponenten sich nicht mit fremden beißen — und niemals ng, das gehört Angular selbst. Zweitens der Unterschied zwischen Komponenten und Attribut-Direktiven. Komponenten werden zu HTML-Elementen, deshalb Bindestrich-Schreibweise wie im HTML-Standard.

11:32 Attribut-Direktiven werden oft zugleich zur Eingabe-Eigenschaft — und dort spart die Höckerschreibweise ein umständliches Umbenennen. Drittens: Finger weg von Namen, die es im DOM schon gibt. Ein eigenes „title" oder „style" sorgt für Verwirrung, die niemand sucht, weil beides ja irgendwie funktioniert. Hier steckt eine Entwurfsidee drin, die über Angular hinausgeht. Der übliche Reflex, wenn man einen Knopf mit Symbol braucht, ist eine eigene Komponente, die einen Knopf enthält.

12:03 Das Problem: Damit versteckt sie ihn. Alles, was ein richtiger Knopf kann — Klick-Ereignisse, deaktiviert sein, Tastaturbedienung — müssen Sie einzeln wieder nach außen durchreichen. Der Attribut-Selektor dreht das um. Die Komponente hängt sich an ein echtes Knopf-Element, statt eines zu verstecken. Der Aufrufer behält damit alles, was der Browser mitbringt.

12:25 Ein kleiner Kniff mit erstaunlich großer Wirkung. Diese vier Regeln lassen sich auf einen Satz bringen: Machen Sie sichtbar, was gemeint ist. Angular-spezifische Eigenschaften nach oben, damit man die Abhängigkeiten einer Komponente auf einen Blick sieht. Nur für das Template gedachte Member auf „protected", damit sie nicht versehentlich zur öffentlichen Schnittstelle werden.

12:47 Nur-lesbar für alles, was Angular selbst befüllt — das schützt vor Zuweisungen, die ohnehin nie funktionieren würden. Und die letzte Regel ist meine liebste: Nennen Sie Handler nach ihrer Wirkung. „addToCart" sagt Ihnen in einem halben Jahr etwas. „onClick" sagt Ihnen nur, dass geklickt wurde. Jahrelang war der Konstruktor der Ort, an dem Abhängigkeiten hereinkamen. Die Empfehlung hat gewechselt, und zwar nicht aus Mode.

13:12 Die inject-Funktion kommt mit weniger Zeremonie aus, sie funktioniert auch an Stellen, an denen es keinen Konstruktor gibt, und sie liefert die bessere Typinferenz. Was Sie dabei nicht verlieren: Es ist dieselbe Dependency Injection wie vorher, nur anders notiert. Für bestehenden Code heißt das ausdrücklich nicht, dass Sie jetzt jeden Konstruktor umschreiben müssen. Es heißt: Neues schreiben Sie so.

13:36 Diese Aufgabe schließt das Modul ab, und sie ist bewusst eine Prüfung, keine Neuentwicklung. Nehmen Sie eine bestehende Komponente und gehen Sie mit der Tabelle von vorhin durch: Selektor, Präfix, Namen der Ein- und Ausgaben, Sichtbarkeiten, Art der Injektion. Geschafft haben Sie es, wenn alle fünf Punkte sitzen. Die Kür ist die interessanteste: einen Event-Handler nach seiner Wirkung umbenennen.

13:59 Es ist erstaunlich, wie oft man dabei merkt, dass die Methode eigentlich zwei Dinge tut — der Name lässt sich nämlich nur dann sauber vergeben, wenn die Verantwortung sauber ist. Vier Punkte, ein gemeinsamer Nenner. Bei der Standalone-Migration entscheidet die Richtung über den Aufwand: von den Blättern nach oben, und Module bleiben dabei ausdrücklich erlaubt — es gibt keinen Stichtag.

14:21 Die neuen Control-Flow- Blöcke sind Teil der Sprache und deshalb mehr als eine schönere Schreibweise. Beim Projektaufbau gliedern Sie nach Fachbereichen, nicht nach Dateityp. Und die kleinen Regeln — eigenes Präfix, inject statt Konstruktor, Namen nach Wirkung — kosten einzeln nichts und machen zusammen den Unterschied zwischen einem Projekt, das vertraut wirkt, und einem, das man sich erarbeiten muss.

Fragen & Weiterarbeiten

14:45 Damit sind die Bausteine beisammen. Im nächsten Modul wechseln wir die Flughöhe: Es geht nicht mehr um einzelne Komponenten, sondern um die Struktur der ganzen Anwendung — emergente Architektur als Grundhaltung, das Feature-Shell-Muster und ein Werkzeug namens Sheriff, das Architekturabsprachen zur Bauzeit prüft. Was den Style Guide angeht: Er ändert sich gelegentlich, und es lohnt sich, ihn einmal im Jahr durchzublättern.

15:08 Man findet dabei zuverlässig zwei, drei Dinge, die man seit Jahren anders macht als der Rest der Welt.