Komponentenbasierte Entwicklung

Komponentenbasierte Entwicklung

0:00 Im ersten Modul haben Sie eine einzelne Komponente gebaut. Heute wird daraus ein ganzes Gebäude. Komponenten sind der Grund, warum moderne Oberflächen überhaupt noch beherrschbar sind — sie sind die Antwort auf ein Problem, das jeder kennt, der einmal eine gewachsene HTML-Seite gepflegt hat. Wir sehen uns an, wie man eine Oberfläche sinnvoll zerlegt, woran man einen guten Schnitt erkennt und wie die Bausteine miteinander in Beziehung stehen.

0:24 Das ist weniger Technik als Entwurf — und genau deshalb der Teil, der über die Lebensdauer eines Projekts entscheidet.

Konzept der komponentenbasierten Architektur

0:32 Fangen wir mit der Grundidee an. Warum überhaupt Komponenten, und warum bündelt Vue Struktur, Verhalten und Aussehen in einer einzigen Datei, wo man doch jahrelang gelernt hat, HTML, CSS und JavaScript sauber zu trennen? Diese Frage ist berechtigt, und die Antwort darauf erklärt ziemlich genau, was sich im Frontend in den letzten fünfzehn Jahren verschoben hat.

0:52 Nehmen wir uns kurz Zeit dafür — es zahlt sich in jeder Entwurfsentscheidung aus, die Sie später treffen. Stellen Sie sich ein Haus vor. Sie könnten es beschreiben, indem Sie alle Leitungen an einem Ort auflisten, alle Wände an einem zweiten und alle Fenster an einem dritten. Technisch sauber getrennt — und völlig unbrauchbar, wenn Sie ein Zimmer umbauen wollen. Genau das war die alte Aufteilung nach HTML, CSS und JavaScript.

1:18 Eine Komponente ist stattdessen das Zimmer: Alles, was dazugehört, liegt beieinander. Sie hat ihren eigenen Zustand, ihr eigenes Aussehen und ihre eigene Lebensdauer. Und eine Anwendung ist dann kein Stapel Dateien mehr, sondern ein Baum aus solchen Zimmern. Der entscheidende Punkt ist der zweite: Sie können einen Baustein verstehen, ohne die ganze Anwendung zu kennen. Das klingt selbstverständlich, ist es aber nicht.

1:43 In einer gewachsenen Seite müssen Sie vor jeder Änderung wissen, welches Stylesheet sie treffen könnte und welcher Handler noch daran hängt. Bei einer Komponente ist die Antwort: nur das, was in dieser Datei steht. Das senkt die Einstiegshürde für neue Kolleginnen erheblich, und es senkt das Risiko jeder Änderung. Der vierte Punkt ist der eigentliche Gewinn: Eine Korrektur wirkt überall dort, wo der Baustein verwendet wird.

2:08 Diese drei Blöcke sind das Grundmuster jeder Vue-Datei, und interessant ist, was in der rechten Spalte steht: Zwei von dreien sind optional. Eine Komponente ohne Skript ist völlig legitim — sie zeigt einfach nur Struktur an. Eine Komponente ohne eigene Stile ebenso. Was Sie fast immer haben, ist das Template. Die Reihenfolge der Blöcke steht Ihnen frei, aber halten Sie sich im Projekt an eine: Wer in zwanzig Dateien blättert, will nicht jedes Mal suchen, wo das Skript anfängt.

2:37 Die übliche Reihenfolge ist Skript, Template, Stil. Der zweite Punkt ist der wichtigste, weil er sich schleichend einstellt. Eine Komponente wird selten sofort zu groß — sie wächst über Wochen um jeweils zehn Zeilen. Irgendwann sitzt jemand vor einer Datei mit vierhundert Zeilen und weiß nicht mehr, wo er anfangen soll. Mein Rat: Wenn Sie beim Lesen einer Komponente scrollen müssen, um den Zusammenhang zu behalten, ist das ein Signal.

3:02 Und zum letzten Punkt eine Entwarnung: Eine Komponente ohne eigenen Zustand ist kein Konstruktionsfehler. Solche reinen Anzeigebausteine sind sogar die am besten wiederverwendbaren.

Erstellung eigener Vue-Komponenten

3:13 Jetzt zum Handwerk. Eine Komponente anzulegen dauert etwa zwanzig Sekunden, und trotzdem gibt es dabei ein paar Konventionen, die man kennen sollte — vor allem bei der Benennung. Wir sehen uns den vollständigen Ablauf an, von der leeren Datei bis zur eingebundenen Komponente, und ich zeige Ihnen dabei, welche Schritte Vue Ihnen abnimmt und welche Sie selbst gehen müssen.

3:34 Es lohnt sich, das einmal bewusst zu machen, denn danach läuft es automatisch. Der Satz, auf den es hier ankommt, ist der letzte: Alles, was im Skript auf oberster Ebene steht, ist im Template verfügbar. Keine Anmeldung, kein Export, keine Rückgabe. Wenn Sie aus anderen Frameworks kommen, ist das ungewohnt — dort muss man meist ausdrücklich sagen, was nach außen sichtbar wird.

3:56 Vue nimmt Ihnen das ab, weil der Compiler beim Übersetzen ohnehin sieht, was da steht. Das gilt übrigens auch für Importe: Eine importierte Hilfsfunktion können Sie direkt im Template aufrufen, ohne sie irgendwo durchzureichen. Hier sehen Sie beides zusammen: einen Wert, der sich ändern kann, und eine Funktion, die ihn ändert.

4:16 Beide stehen auf oberster Ebene, beide sind im Template ohne weiteres Zutun verwendbar. Achten Sie auf einen Unterschied, der Sie noch beschäftigen wird: Im Skript sprechen wir den Wert mit einem Zusatz an, im Template ohne. Das ist kein Fehler in den Folien, das ist Absicht — warum, klären wir ausführlich in Modul 5. Für den Moment reicht die Beobachtung, dass Vue Ihnen im Template diese Schreibarbeit abnimmt.

4:41 Fünf Schritte, und der rote Faden ist: erst die Struktur, dann das Verhalten, dann die Einbindung. Das klingt banal, hat aber einen praktischen Grund. Wenn Sie mit dem Template anfangen, denken Sie über die Oberfläche nach — und die bestimmt, welchen Zustand Sie überhaupt brauchen. Fangen Sie umgekehrt an, neigen Sie dazu, Zustand vorzuhalten, den nie jemand anzeigt. Der wichtige Hinweis steht unten: Der Dateiname ist zugleich der Tagname.

5:08 Wenn Sie die Datei gut benennen, benennen Sie die Komponente gleich mit. Diese Aufgabe übt genau die Fähigkeit, die Sie im Alltag am häufigsten brauchen — nicht das Anlegen auf der grünen Wiese, sondern das Herauslösen aus etwas Bestehendem. Nehmen Sie einen zusammenhängenden Teil Ihrer Seite und machen Sie eine Komponente daraus.

5:27 Der Nachweis ist bewusst streng formuliert: Die Seite muss hinterher unverändert aussehen. Wer beim Herausschneiden gleich noch etwas verbessert, weiß am Ende nicht mehr, ob ein Unterschied vom Umbau kommt oder von der Verbesserung. Refaktorieren und Ändern sind zwei Vorgänge. Der dritte Punkt verdient eine Einordnung. Seit Vue 3 darf eine Komponente mehrere Wurzelelemente haben, und das ist eine echte Erleichterung — man muss nicht mehr alles in ein überflüssiges div wickeln.

5:55 Es hat aber eine Folge, die erst später auffällt: Wenn von außen ein Attribut oder eine Klasse an die Komponente gegeben wird, weiß Vue nicht mehr, an welches der Wurzelelemente es gehört. Merken Sie sich das für Modul 6 und 7. Und der letzte Punkt: Ohne den Setup-Zusatz am Skript ist wirklich keine Variable im Template sichtbar.

Unterschied zwischen lokalen und globalen Komponenten

6:15 Ein kleines Kapitel mit einer klaren Empfehlung. Es gibt zwei Wege, eine Komponente bekannt zu machen, und einer davon ist im Alltag praktisch immer der richtige. Trotzdem sollten Sie beide kennen — nicht zuletzt, weil Ihnen der zweite in fremdem Code begegnen wird und Sie dann verstehen wollen, warum ein Tag funktioniert, für das nirgends ein Import steht.

6:34 Genau dieser Moment kostet sonst eine halbe Stunde Suche in einem fremden Projekt. Der Unterschied ist schnell erzählt: Lokal heißt, die Komponente wird dort importiert, wo sie gebraucht wird. Global heißt, sie wird einmal zentral angemeldet und ist danach überall verfügbar. Global klingt bequemer, und genau deshalb ist die Empfehlung wichtig: Lokal ist der Normalfall.

6:56 Der Grund liegt nicht in der Technik, sondern in der Lesbarkeit und im Bauprozess — dazu gleich mehr. Ein Detail vorweg, das oft überrascht: Eine lokal importierte Komponente steht in den Kindkomponenten ausdrücklich nicht zur Verfügung. Jede Datei braucht ihren eigenen Import. Falls Sie doch einmal global anmelden — so sieht es aus. Die Verkettung ist Komfort, mehr nicht.

7:19 Der wichtige Teil steht in der Fußzeile: Die Registrierung muss vor dem Einhängen der Anwendung stehen. Das ist dieselbe Regel wie bei allem anderen, was anwendungsweit gilt, und sie scheitert leise: Wer eine Komponente nach dem Einhängen anmeldet, bekommt keine Fehlermeldung, sondern nur ein Tag, das im Browser nicht aufgelöst wird.

7:38 Sie sehen dann eine Warnung in der Konsole und eine Lücke auf der Seite. Die entscheidenden Zeilen sind die dritte und die vierte. Tree Shaking bedeutet, dass der Bauprozess Code entfernt, den niemand verwendet. Bei global angemeldeten Komponenten kann er das nicht — er müsste ja beweisen, dass irgendwo in keinem einzigen Template dieses Tag vorkommt, und das ist ihm nicht möglich.

8:00 Also landet alles im Bündel, auch die drei Komponenten aus dem Prototyp von vor einem Jahr. Die vierte Zeile ist die menschliche Seite: Wenn Sie in einer fremden Datei ein unbekanntes Tag sehen, wollen Sie den Import lesen können, nicht suchen müssen. Ich will das nicht zum Dogma machen. Es gibt gute Gründe für globale Registrierung, und der letzte Punkt nennt sie: eine Handvoll Bausteine, die wirklich in fast jeder Datei vorkommen — ein Knopf, ein Eingabefeld, ein Symbol.

8:27 Für die spart man sich zwanzig identische Importzeilen, und das ist ein fairer Tausch. Was Sie vermeiden sollten, ist die Gewohnheit, jede neue Komponente sicherheitshalber global anzumelden. Am Ende steht eine Anwendung, in der niemand mehr sagen kann, woher ein Tag kommt und ob es noch gebraucht wird. Der erste Punkt ist der, der im Alltag am meisten nervt: Bei einer global registrierten Komponente kann Ihr Editor Ihnen kein Sprungziel anbieten.

8:53 Sie sehen ein Tag und müssen die Anwendung durchsuchen, um die Datei zu finden. Der dritte Punkt überrascht viele: Lokale Registrierung vererbt sich nicht. Wer eine Komponente in der Elternkomponente importiert hat und sie im Kind verwenden will, braucht dort einen eigenen Import. Das ist kein Mangel, sondern genau der Punkt — die Abhängigkeit steht in jeder Datei, die sie hat.

Strukturierung komplexer Benutzeroberflächen

9:15 Jetzt wird es zum ersten Mal wirklich um Entwurf gehen. Die Frage lautet: Wie zerlege ich eine Seite in Komponenten, ohne zu raten? Es gibt darauf keine mathematisch richtige Antwort, aber es gibt ein Vorgehen, das erstaunlich zuverlässig zu brauchbaren Ergebnissen führt — und das ohne Erfahrung funktioniert. Das ist die gute Nachricht dieses Kapitels: Ein brauchbarer Komponentenschnitt ist keine Frage der Begabung, sondern eines Verfahrens, das Sie in zehn Minuten lernen und danach immer wieder anwenden können.

9:44 Das Verfahren ist so einfach, dass man es fast nicht glaubt: Sie nehmen den Entwurf der Seite — ein Bild, eine Skizze, meinetwegen einen Screenshot des Vorgängers — und ziehen mit dem Stift Kästen um alles, was sichtbar zusammengehört. Dann markieren Sie, was sich wiederholt. Diese Kästen sind Ihre Komponenten. Der Reiz dabei ist, dass Sie sich am Sichtbaren orientieren und nicht an einer gedachten Struktur.

10:07 Und weil die Oberfläche das ist, was Ihre Nutzer erleben, ist ein Schnitt entlang der Oberfläche fast nie völlig falsch. Achten Sie auf die Reihenfolge, insbesondere auf Schritt eins und fünf. Zuerst das Bild, zuletzt die Datei. Die Versuchung ist groß, sofort Dateien anzulegen, weil es sich nach Fortschritt anfühlt — aber ein Schnitt, den Sie ohne Blick auf die tatsächliche Oberfläche machen, ist geraten.

10:31 Schritt vier ist der, den man gern überspringt und den man sich am ehesten merken sollte: Namen aus der Fachsprache. Eine Komponente, die Artikelkarte heißt, überlebt jeden Designwechsel. Eine, die Blaue Kachel heißt, überlebt ihn nicht. Das ist unser Beispiel, und ich möchte, dass Sie die Größenordnung im Gefühl haben: fünf Komponenten für eine einzelne Seite. Das ist ein üblicher Schnitt, kein besonders feiner.

10:56 Sehen Sie sich die rechte Spalte an — jede Zeile lässt sich in einem kurzen Satz beschreiben, ohne dass man das Wort und braucht. Das ist ein guter Test für einen Schnitt. Wo Sie zur Beschreibung ein und brauchen, haben Sie vermutlich zwei Zuständigkeiten in einer Komponente. Diese fünf Bausteine begleiten uns durch das restliche Seminar.

11:16 Der zweite Punkt ist mein Lieblingsärgernis. Namen wie Box, Wrapper oder Container beschreiben die technische Form, nicht den Inhalt — und in einem gewachsenen Projekt haben Sie am Ende sieben davon und wissen bei keinem, wofür es zuständig ist. Der letzte Punkt beschreibt das andere Extrem: Eine Komponente je HTML-Element ist keine Zerlegung, sondern eine Umbenennung.

11:37 Zwischen diesen beiden Fehlern liegt ein großes, angenehm tolerantes Feld — Sie müssen den Schnitt nicht perfekt treffen, nur begründen können.

Wiederverwendbare Komponenten entwickeln

11:46 Wiederverwendbarkeit ist so ein Wort, das in jedem Vortrag vorkommt und selten erklärt wird. In diesem Kapitel wird es konkret: Es gibt ein ziemlich klares Kriterium dafür, ob eine Komponente wiederverwendbar ist oder nicht — und es hat weniger mit Können zu tun als mit einer Entscheidung darüber, wer was wissen darf. Diese Entscheidung treffen Sie beim Schreiben, meist ohne es zu merken, und sie bestimmt, ob der Baustein später ein zweites Mal passt oder nicht.

12:12 Hier ist das Kriterium: Eine wiederverwendbare Komponente kennt ihren Kontext nicht. Sie weiß nicht, ob sie in einer Übersicht, in einer Suche oder in einem Dialog steht. Sie bekommt Daten von außen und meldet nach außen, was passiert ist — mehr nicht. Denken Sie an einen Lichtschalter. Der weiß nicht, welche Lampe an ihm hängt; er meldet nur, dass jemand ihn gedrückt hat. Genau deshalb können Sie denselben Schalter in jedem Raum verbauen.

12:38 Eine Komponente, die selbst entscheidet, was beim Klick passiert, ist ein Schalter mit eingebauter Lampe. Zwei Zeilen, und in denen steckt die ganze Idee. Oben wird deklariert, was die Komponente an Daten erwartet, darunter, was sie nach außen melden kann. Das ist zugleich die Dokumentation des Bausteins: Wer die Datei öffnet, sieht in den ersten Zeilen den kompletten Vertrag.

13:01 Achten Sie darauf, was im Template nicht steht — es gibt keinen Speicheraufruf, keine Prüfung, ob der Nutzer darf. Die Karte sagt nur: Jemand möchte ausleihen. Was daraus folgt, entscheidet die Ebene darüber. Der zweite Punkt hat einen praktischen Wert, den man erst später zu schätzen weiß: Eine Komponente ohne Kontextwissen lässt sich testen, ohne die halbe Anwendung hochzufahren.

13:25 Sie geben ihr Daten, Sie prüfen, was sie meldet, fertig. Der vierte Punkt ist der, der sich im Alltag am häufigsten auszahlt: Was eine Komponente braucht, steht sichtbar oben in der Datei. Sie müssen nicht das ganze Template lesen, um zu wissen, was Sie ihr geben müssen — vier Zeilen Deklaration genügen. Diese Aufgabe hat einen Nebeneffekt, auf den ich Sie hinweisen möchte.

13:47 Sie werden zwei fast gleiche Blöcke zusammenführen, und dabei stellt sich fast immer die Frage: Wie viele Unterschiede darf ich über Eingaben abbilden? Der Hinweis unten gibt eine Faustregel: Wer mehr als vier braucht, hat vermutlich zwei verschiedene Komponenten vor sich. Das ist kein Gesetz, aber ein gutes Warnsignal.

14:05 Denn eine Komponente mit acht Schaltern, die je nach Kombination anders aussieht, ist am Ende schwerer zu verstehen als zwei ehrlich getrennte Bausteine. Der letzte Punkt ist der wichtigste und wird am häufigsten missachtet: zu frühe Verallgemeinerung. Man baut eine Komponente und denkt sofort mit, wie sie später noch verwendet werden könnte — und baut Schalter für Fälle ein, die nie eintreten.

14:28 Meine Empfehlung: Bauen Sie erst den konkreten Fall. Beim zweiten Verwendungsort sehen Sie, welche Unterschiede es wirklich gibt, und verallgemeinern dann gezielt. Das ist nicht Faulheit, das ist eine Entscheidung auf Basis von Wissen statt auf Basis von Vermutung.

Komponentenhierarchien verstehen

14:43 Jetzt kommt eine Regel, die auf den ersten Blick streng wirkt und Ihnen später viel Ärger erspart: Der Datenfluss in Vue hat eine Richtung. Wenn Sie diese Regel einmal verinnerlicht haben, können Sie bei jedem Anzeigefehler in Sekunden sagen, wo Sie suchen müssen. Und Sie werden sehen: Die Strenge ist der eigentliche Komfort.

15:01 Frameworks, die beide Richtungen erlauben, wirken zunächst freundlicher — bis man den ersten Fehler sucht, der aus zwei sich gegenseitig überschreibenden Schreibzugriffen entsteht. Der Satz, den Sie mitnehmen sollten, ist der letzte: Geändert wird der Zustand dort, wo er wohnt. Eine Komponente, die einen Wert bekommt, darf ihn anzeigen und darf melden, dass jemand ihn ändern möchte — ändern darf sie ihn nicht. Denken Sie an eine Anzeigetafel im Bahnhof.

15:28 Die zeigt die Verspätung an und erfindet sie nicht. Wenn Sie eine falsche Zahl sehen, suchen Sie nicht in der Tafel, sondern bei dem, der sie beliefert. Genau diese Eindeutigkeit ist der Zweck der Regel. Sehen Sie sich an, wie die Zuständigkeiten hier verteilt sind. Oben liegt die Liste, oben liegt die Funktion, die etwas verändert.

15:48 Die Karte bekommt nur, was sie anzeigen soll, und meldet zurück, wenn jemand geklickt hat. Sie weiß nicht, dass es eine Liste gibt, und sie weiß nicht, was Ausleihen bedeutet. Das ist kein Umweg, das ist der Punkt: Wenn morgen das Ausleihen zusätzlich eine Prüfung braucht, ändern Sie eine Funktion an einer Stelle — und keine der zwanzig Karten, die auf der Seite stehen.

16:09 Der erste Punkt ist der praktische Gewinn im Alltag: Bei einer falschen Anzeige gibt es genau eine Stelle, an der der Wert entsteht. Sie müssen nicht raten, ob vielleicht ein Kind ihn unterwegs verändert hat. Der letzte Punkt fasst das Prinzip: Zwei Schreibrichtungen wären zwei Wahrheiten. Sobald zwei Stellen denselben Wert setzen dürfen, hängt das Ergebnis von der Reihenfolge ab — und Reihenfolgen sind in einer ereignisgesteuerten Oberfläche notorisch schwer vorherzusagen.

16:36 Die Einbahnstraße ist also kein Selbstzweck, sondern eine Vorsichtsmaßnahme. Vier Zeilen, und die dritte ist die einzige mit einem Nein. Wichtig ist der Hinweis darunter: Über mehr als zwei Ebenen hinweg wird das Durchreichen mühsam. Wenn Sie merken, dass eine Zwischenkomponente Daten weitergibt, die sie selbst gar nicht braucht, ist das kein Fehler — es ist ein Signal.

16:58 Für genau diesen Fall gibt es zwei weitere Werkzeuge, und beide kommen noch: provide und inject in Modul 7, der Store in Modul 10. Greifen Sie aber nicht zu früh danach. Der zweite Punkt ist eine echte Falle, weil er der Regel scheinbar widerspricht. Wenn Sie ein Objekt als Eingabe bekommen und darin ein Feld ändern, funktioniert das — es kommt keine Warnung, und die Elternkomponente sieht die Änderung sogar.

17:22 Der Grund ist, dass Objekte als Referenz übergeben werden. Trotzdem ist es falsch, und zwar aus demselben Grund wie vorhin: Sie erzeugen eine zweite Stelle, an der der Wert geändert wird. Der letzte Punkt ist die Kehrseite der Regel — Zustand zu weit oben anzusiedeln lässt zu viel neu rendern.

Best Practices für modulare Frontendarchitektur

17:40 Zum Abschluss ein Kapitel über Konventionen. Ich weiß, das klingt trocken. Aber Konventionen sind das, was ein Projekt auch dann noch zusammenhält, wenn drei Leute daran arbeiten und niemand mehr alles im Kopf hat. Es sind erfreulich wenige — und die entscheidende Erkenntnis ist am Ende eine ganz andere, nämlich dass Ihr erster Schnitt gar nicht der endgültige sein muss.

18:00 Das nimmt Druck aus der Entscheidung und macht sie dadurch besser. Der Satz, den ich hier hervorheben möchte, ist der letzte Halbsatz: die Bereitschaft, den Schnitt zu ändern, wenn er nicht mehr passt. Viele Architekturdiskussionen leiden darunter, dass alle nach der einen richtigen Struktur suchen — und sich deshalb nicht entscheiden können.

18:19 Eine tragfähige Struktur entsteht aber nicht aus einem Diagramm, sondern aus wenigen, konsequent eingehaltenen Regeln plus der Bereitschaft, nachzubessern. Das nimmt der ersten Entscheidung ihr Gewicht, und genau das macht sie leichter. Fünf Regeln, und die zweite ist die einzige, die Vue Ihnen technisch nahelegt: Mehrwortige Komponentennamen vermeiden Zusammenstöße mit HTML-Elementen.

18:41 Alle anderen sind Vereinbarungen. Der dritte Punkt ist mein Favorit für größere Projekte: Ein Präfix wie Basis macht auf einen Blick sichtbar, dass eine Komponente generisch ist und keine Fachlogik enthält. Der Satz in der Fußzeile ist der eigentliche Kern: Eine Konvention, die nur für die Hälfte der Dateien gilt, hilft niemandem — sie erzeugt nur den falschen Eindruck von Ordnung.

19:04 Der erste Punkt beschreibt eine Erfahrung, die man immer wieder macht: Der richtige Schnitt zeigt sich erst an der zweiten Verwendung. Vorher ist alles Vermutung. Deshalb ist der dritte Punkt so wichtig — Zusammenführen ist genauso legitim wie Aufteilen. Wir reden bei Architektur meist übers Zerlegen, aber der umgekehrte Weg gehört genauso dazu.

19:24 Wenn zwei Komponenten immer gemeinsam auftreten und niemand sie einzeln braucht, dürfen sie wieder eine werden. Der Schnitt ist eine Entscheidung auf Zeit, kein Vertrag. Diese Aufgabe ist ein Test, den Sie sich merken sollten, weil er in jedem Projekt funktioniert: Können Sie zu jeder Komponente in einem Satz sagen, wofür sie zuständig ist?

19:45 Ohne und, ohne außerdem. Wo Ihnen das nicht gelingt, haben Sie einen Kandidaten für eine Änderung gefunden. Wichtig ist der zweite Teil des Erfolgskriteriums: Es reicht, den Änderungsvorschlag zu notieren. Sie müssen nicht sofort umbauen — Sie müssen nur erkennen, wo es hakt. Das ist die schwierigere Hälfte. Der dritte Punkt ist der eigentliche Ratschlag dieses Kapitels: Der Wunsch nach dem endgültigen Schnitt blockiert den ersten.

20:11 Ich sehe das häufig — Teams diskutieren zwei Tage über Ordnerstrukturen, bevor die erste Komponente entsteht. Fangen Sie an, machen Sie es ordentlich, und ändern Sie es, wenn Sie mehr wissen. Und zum letzten Punkt: Struktur ersetzt keine Namen. Die schönste Ordnerhierarchie hilft nichts, wenn darin drei Dateien liegen, deren Namen niemand versteht.

Aus einer Komponente werden viele

20:32 Fassen wir zusammen. Komponenten bündeln, was zusammengehört, und machen eine Oberfläche in Teilen verstehbar. Lokal registrieren ist der Normalfall, global die begründete Ausnahme. Und die Regel, die Sie sich merken sollten: Daten fließen über Eingaben nach unten, Ereignisse melden nach oben. Im nächsten Modul gehen wir in die Komponente hinein und sehen uns an, was im Template alles möglich ist — von der einfachen Textausgabe über Bedingungen bis zu Schleifen und abgeleiteten Werten.