Komponentenkommunikation

Komponentenkommunikation

0:00 In Modul 2 haben wir festgestellt: Daten fließen nach unten, Ereignisse nach oben. Heute füllen wir diese Regel mit Leben und ergänzen sie um zwei weitere Werkzeuge. Es geht um Eingaben und ihre Prüfung, um eigene Ereignisse, um Kontext, der über mehrere Ebenen hinweg bereitgestellt wird, und um Slots — also darum, dass eine Komponente nicht nur Werte, sondern ganzes Markup von außen entgegennehmen kann.

0:23 Am Ende dieses Moduls kennen Sie alle Wege, auf denen zwei Komponenten miteinander in Beziehung treten können.

Datenfluss in Vue-Anwendungen

0:30 Bevor wir ins Detail gehen, verschaffen wir uns einen Überblick. Es gibt vier Wege, und die Kunst besteht weniger darin, sie zu beherrschen, als darin, den passenden auszuwählen. Denn jeder von ihnen löst ein anderes Problem — und wer den falschen nimmt, baut sich Kopplungen ein, die später schwer aufzulösen sind. Deshalb zuerst die Landkarte, dann die Details.

0:51 Und ich gebe Ihnen dabei eine Reihenfolge mit, in der man die vier Wege durchprüfen sollte — die schützt vor den meisten Fehlgriffen. Die Grundregel kennen Sie: eine Richtung, Daten nach unten, Absichten nach oben. Für die Fälle, in denen das nicht reicht, gibt es zwei Ergänzungen. Die eine stellt Werte für einen ganzen Teilbaum bereit, ohne dass jede Zwischenstation sie durchreichen muss.

1:14 Die andere dreht die Blickrichtung um: Statt Werte hineinzureichen, reicht die Elternkomponente ganzes Markup hinein, und die Komponente bestimmt nur, wo es landet. Diese vier Wege decken zusammen so ziemlich alles ab. Fünf Zeilen, und die letzte deutet auf Modul 10 voraus. Ich möchte, dass Sie die Reihenfolge im Kopf behalten, denn sie ist auch die Prüfreihenfolge: Erst schauen, ob Eingaben und Ereignisse reichen.

1:40 Wenn nicht, prüfen, ob es Kontext für einen Teilbaum ist. Wenn es um Markup geht, sind es Slots. Und erst wenn nichts davon passt, ist ein Store das Richtige. Wer diese Reihenfolge einhält, baut keine globalen Zustände für Dinge, die zwei Komponenten betreffen. Der erste Punkt ist der praktische Gewinn: Bei einem falschen Wert gibt es genau eine Stelle, an der er entsteht. Das ist bei der Fehlersuche unbezahlbar.

2:05 Der letzte Punkt ist einer, an den man selten denkt: Auch die Werkzeuge profitieren. Die Vue-Entwicklerwerkzeuge zeigen Ihnen den Komponentenbaum mit den Eingaben jeder Komponente — und dieses Bild ist nur deshalb aussagekräftig, weil die Werte wirklich von oben kommen. In einem Netz aus wechselseitigen Zugriffen könnte kein Werkzeug das sinnvoll darstellen.

2:26 Der erste Punkt ist der wichtigste Satz dieses Kapitels: Der schnellste Weg ist selten der richtige. Wenn Sie merken, dass Sie eine Eingabe über drei Ebenen durchreichen, ist die Versuchung groß, das mit einem bereitgestellten Kontext abzukürzen. Manchmal ist das richtig — oft verstecken Sie damit nur eine Abhängigkeit, statt sie zu lösen.

2:45 Der letzte Punkt beschreibt das Endergebnis solcher Abkürzungen: Wer alle vier Wege gleichzeitig verwendet, hat keinen Datenfluss mehr, sondern ein Netz.

Props zur Datenübergabe an Child Komponenten

2:54 Jetzt zu den Eingaben — dem Weg nach unten. Sie haben ihn schon benutzt, aber wir sehen ihn uns jetzt gründlich an: wie man deklariert, welche Schreibweisen gelten und warum es eine strenge Regel gibt, an die man sich halten sollte, auch wenn sich technisch etwas anderes machen ließe. Diese Regel ist der eigentliche Inhalt des Kapitels — der Rest ist Handwerk, das Sie in fünf Minuten beherrschen.

3:16 Der Satz, den ich hervorheben möchte, ist der letzte: Die Deklaration ist zugleich die Dokumentation. Wenn Sie eine fremde Komponente verwenden wollen, öffnen Sie die Datei und lesen die ersten Zeilen — dort steht, was sie erwartet. Das ist ein unterschätzter Vorteil gegenüber Komponenten, die einfach ein beliebiges Objekt entgegennehmen.

3:35 Und es hat einen zweiten Effekt: Was nicht deklariert ist, ist auch keine Eingabe, sondern rutscht als gewöhnliches Attribut durch — dazu gleich mehr bei den Stolpersteinen. Oben die Deklaration, unten die Verwendung. Achten Sie auf den Unterschied zwischen den beiden Attributen in der letzten Zeile: Beim ersten steht kein Doppelpunkt, beim zweiten schon.

3:56 Das ist kein Schönheitsfehler, sondern der Unterschied zwischen einer festen Zeichenkette und einem Ausdruck. Wenn Sie eine Zahl ohne Doppelpunkt übergeben, kommt sie als Zeichenkette an — und die Typprüfung meldet das in der Entwicklung als Warnung. Das ist einer der Fälle, in denen sich die Deklaration sofort auszahlt.

4:14 Drei Zeilen, und die mittlere ist eine Konvention, keine Vorschrift. Vue rechnet zwischen den Schreibweisen um, Sie könnten also auch im Template die JavaScript-Schreibweise verwenden. Üblich ist aber die HTML-Schreibweise mit Bindestrichen, weil sie sich in den Rest des Markups einfügt. Was nicht optional ist, steht in der ersten Zeile: In der Deklaration brauchen Sie einen gültigen JavaScript-Bezeichner, also die Schreibweise ohne Bindestriche.

4:40 Dort haben Sie keine Wahl. Der erste Punkt nennt den technischen Grund: Beim nächsten Rendern der Elternkomponente wäre Ihre Änderung wieder überschrieben. Sie bauen also etwas, das manchmal funktioniert und manchmal nicht — die schlechteste aller Eigenschaften. Die beiden letzten Punkte nennen die Alternativen, und die decken praktisch alle Fälle ab.

5:01 Wollen Sie den Wert lokal bearbeiten, legen Sie einen eigenen Zustand an und starten ihn mit der Eingabe. Wollen Sie ihn nur anders darstellen, nehmen Sie eine Ableitung. Der erste Punkt ist der subtilste: Ein Objekt können Sie innen verändern, weil es als Referenz übergeben wird. Es funktioniert sogar — die Elternkomponente sieht die Änderung.

5:21 Trotzdem ist es falsch, aus genau dem Grund von vorhin: Sie haben zwei Stellen, die schreiben. Der zweite Punkt ist eine Mechanik, die man kennen muss: Ein Attribut, das Sie nicht deklariert haben, verschwindet nicht — es landet am Wurzelelement der Komponente. Das ist meistens nützlich und gelegentlich überraschend.

Validierung von Props

5:41 Ein kurzes Kapitel über etwas, das viele weglassen: die genauere Beschreibung der Eingaben. Typ, Pflicht, Vorgabewert, eigene Regel. Das kostet ein paar Zeilen und zahlt sich mehrfach zurück — beim Entwickeln, beim Lesen und im Editor. Ich zeige Ihnen die Möglichkeiten und sage dazu, wo die Grenze dieses Werkzeugs liegt, denn die wird oft falsch eingeschätzt.

6:03 Es ist nämlich kein Schutzmechanismus, auch wenn der Name das nahelegt. Vier Angaben sind möglich: Typ, Pflichtangabe, Vorgabewert und eine eigene Prüffunktion. Und jetzt der Satz, auf den es ankommt und der oft übersehen wird: Im Produktionsbau entfällt die Prüfung. Sie ist ein Werkzeug für die Entwicklungszeit — eine Hilfe für Sie, kein Schutz zur Laufzeit. Wer glaubt, damit ungültige Daten abzufangen, irrt.

6:29 Für echte Prüfungen an einer Systemgrenze brauchen Sie etwas anderes; hier geht es darum, Fehler beim Entwickeln früh sichtbar zu machen. Vier Eingaben mit vier verschiedenen Ausprägungen. Die dritte zeigt die eigene Prüffunktion: Sie bekommt den Wert und gibt zurück, ob er in Ordnung ist. Das ist der Ort für fachliche Regeln, etwa eine Aufzählung erlaubter Zustände.

6:51 Die letzte Zeile enthält den wichtigsten Hinweis dieses Kapitels, und der steht auch in der Fußzeile: Ein Vorgabewert, der ein Objekt oder ein Array ist, muss aus einer Funktion kommen. Sonst teilen sich alle Instanzen der Komponente dasselbe Objekt — mit sehr verwirrenden Folgen. Vier Zeilen, und die Fußzeile ergänzt eine praktische Kleinigkeit: Mehrere erlaubte Typen schreiben Sie als Liste.

7:14 Das brauchen Sie öfter, als man denkt — etwa wenn eine Kennung mal eine Zahl und mal eine Zeichenkette ist. Die letzte Zeile ist die interessanteste: Die eigene Prüffunktion bekommt neben dem Wert auch die übrigen Eingaben. Damit können Sie Abhängigkeiten zwischen zwei Eingaben prüfen, etwa dass ein Höchstwert nicht kleiner sein darf als ein Mindestwert.

7:35 Der dritte Punkt ist der, der im Alltag am meisten bringt und den viele nicht auf dem Schirm haben: Der Editor kann auf Basis der Deklaration vervollständigen. Sie tippen den Komponentennamen, und die Erweiterung schlägt Ihnen die verfügbaren Eingaben vor — samt Typ. Das ersetzt eine Menge Nachschlagen. Der letzte Punkt ist der inhaltliche: Eine eigene Prüffunktion hält eine fachliche Regel dort, wo sie gilt, statt sie an jeder Verwendungsstelle zu wiederholen.

8:01 Der erste Punkt ist die Grenze, die ich vorhin genannt habe, und ich wiederhole sie bewusst: Im Produktionsbau prüft Vue nicht mehr. Der dritte Punkt ist eine Sache der Logik: Pflichtangabe und Vorgabewert gemeinsam ist widersprüchlich — wenn ein Wert immer angegeben werden muss, wird der Vorgabewert nie verwendet. Und der letzte Punkt ist eine Einladung: Die Kurzform mit einer bloßen Namensliste ist erlaubt, verschenkt aber genau den Nutzen, über den wir gerade gesprochen haben.

Ereignisse für Kommunikation zu Parent Komponenten

8:28 Jetzt die Gegenrichtung: Wie meldet ein Kind etwas nach oben? Über eigene Ereignisse, die genauso funktionieren wie die eingebauten des Browsers — nur dass Sie sie selbst benennen. Es gibt dabei eine Deklaration, die nicht nur Dokumentation ist, sondern auch technisch etwas bewirkt. Und es gibt eine Eigenschaft, die man kennen muss: Diese Ereignisse steigen nicht auf.

8:50 Wer aus der DOM-Welt kommt, erwartet oft das Gegenteil — deshalb sage ich es gleich zu Beginn. Zwei Dinge stecken in dieser Definition. Erstens der Mechanismus: Das Kind meldet, die Elternkomponente hört zu, und was gemeldet wird, benennen Sie selbst. Zweitens ein technischer Nebeneffekt der Deklaration: Deklarierte Ereignisse werden aus dem Attributdurchgriff herausgenommen.

9:13 Ohne Deklaration würde ein Listener zusätzlich als gewöhnliches Attribut am Wurzelelement landen und dort möglicherweise doppelt feuern. Das ist einer der Fälle, in denen die Deklaration nicht nur Stil, sondern Funktion ist. Oben das Kind, das ein Ereignis mit einem Wert meldet, unten die Elternkomponente, die zuhört. Achten Sie auf die Formulierung des Ereignisnamens: Er beschreibt, was passiert ist — nicht, was zu tun ist. Das ist mehr als Kosmetik.

9:40 Ein Ereignis namens Erhöhen kann von verschiedenen Eltern verschieden behandelt werden. Ein Ereignis namens Zähler-Erhöhen legt schon fest, was die Elternkomponente tun soll — und damit hat das Kind eine Annahme über seinen Kontext eingebaut. Drei Formen, und die zweite ist die, die man selten sieht und die manchmal Gold wert ist: Sie können die Nutzdaten prüfen lassen.

10:02 Die Funktion bekommt, was gemeldet wurde, und gibt zurück, ob es plausibel ist. Bei falscher Rückgabe warnt Vue in der Entwicklung. Das ist besonders nützlich bei Komponenten, die andere Teams verwenden — dort merkt man Fehler sonst erst spät. Die dritte Form ist die Wahl, wenn Sie mit Typisierung arbeiten; dann bekommen Sie auch die Argumente typisiert.

10:24 Man könnte ja auch einfach eine Funktion als Eingabe übergeben — das ist in anderen Frameworks der übliche Weg, und es funktioniert in Vue genauso. Der erste Punkt nennt den Unterschied: Der Name beschreibt, was geschehen ist, nicht was zu tun ist. Der zweite ist praktisch: Mehrere Zuhörer sind ohne Zusatzaufwand möglich.

10:43 Und der dritte ist der, der sich beim Lesen auszahlt: Die Deklaration listet alle Ausgänge des Bausteins an einer Stelle. Bei übergebenen Funktionen sind sie über die Eingabeliste verstreut. Der erste Punkt ist eine Schreibweisenfrage, die Vue Ihnen abnimmt: Sie melden in der JavaScript-Schreibweise und hören in der HTML-Schreibweise mit Bindestrichen.

11:04 Der zweite Punkt ist der technische Nebeneffekt von vorhin — ohne Deklaration funktioniert alles, aber der Listener landet zusätzlich in den durchgereichten Attributen. Der dritte Punkt ist die Eigenschaft, die ich angekündigt habe: Ereignisse steigen nicht auf. Nur die direkte Elternkomponente hört zu; über mehrere Ebenen ist Weiterreichen Handarbeit.

Lifecycle Hooks im Kontext von Komponenteninteraktion

11:25 Ein Kapitel über Zeit. Wenn mehrere Komponenten zusammenspielen, ist nicht nur wichtig, wer was weiß, sondern auch wann. Die Reihenfolge, in der ein Komponentenbaum entsteht, ist nämlich nicht die, die man naiv erwartet — und daraus folgt eine Anforderung an jede Kindkomponente, die man beim Bauen leicht vergisst. Sie ist die Ursache für eine ganze Klasse von Fehlern, die lokal nie auftreten und beim Kunden schon.

11:49 Hier ist die Reihenfolge, und sie ist auf den ersten Blick überraschend: Das Einrichten läuft von außen nach innen, das Einhängen aber von innen nach außen. Ein Kind ist also fertig eingehängt, bevor seine Eltern es sind. Beim Abbau ist es umgekehrt — die Kinder verschwinden zuerst. Wenn Sie einen Moment darüber nachdenken, ist das logisch: Ein Elternteil kann erst fertig sein, wenn alles darin fertig ist.

12:13 Aber es hat Folgen für die Frage, wann welche Daten verfügbar sind. Vier Zeilen, und die dritte ist die, die im Alltag am häufigsten zuschlägt: Bei einer Aktualisierung läuft es wieder von außen nach innen. Die Elternkomponente verarbeitet die Änderung, gibt dann die neuen Werte an die Kinder weiter, und die reagieren danach.

12:31 Zwischen diesen Schritten liegt ein Moment, in dem die Kinder noch die alten Werte haben. Deshalb sollte man in diesem Bereich nie annehmen, dass alles gleichzeitig passiert — es passiert in einer definierten Reihenfolge. Das ist das übliche Muster: Beim Einhängen laden, und bis die Daten da sind, gibt es einen Ladezustand.

12:50 Sehen Sie sich an, was die Kindkomponente in dieser Zeit bekommt — eine leere Liste. Erst danach die echten Daten. Das ist der Normalfall in jeder Anwendung, die Daten von einem Server holt, und es ist genau der Punkt aus der Fußzeile: Das Kind muss beides vertragen. Wer beim Bauen einer Kindkomponente nur den gefüllten Fall im Kopf hat, baut einen Fehler ein.

13:12 Der dritte Punkt beschreibt den typischen Fehler: eine Annahme über Vorhandensein. Die Kindkomponente greift auf ein Feld des ersten Listenelements zu — und beim ersten Rendern ist die Liste leer. Das Ergebnis ist eine Fehlermeldung in der Konsole und eine kaputte Anzeige, die nach einer Sekunde von selbst wieder heil wird.

13:31 Solche Fehler sind unangenehm, weil sie lokal fast nie auftreten: Auf Ihrem Rechner ist die Antwort so schnell da, dass der Zustand kaum sichtbar wird. Der zweite Punkt ist der praktisch häufigste: Eine Referenz auf ein Element ist erst nach dem Einhängen belegt. Wer im Einrichtungsteil darauf zugreift, bekommt einen leeren Wert.

13:50 Der dritte Punkt hat eine Wechselwirkung mit Modul 3: Ein Kind unter einer echten Bedingung durchläuft bei jedem Umschalten den vollen Lebenszyklus — wird also wirklich abgebaut und neu erzeugt. Das ist gewollt, kostet aber, wenn im Kind etwas Teures beim Einhängen passiert.

Datenweitergabe mit Provide und Inject

14:06 Jetzt das dritte Werkzeug: Werte für einen ganzen Teilbaum bereitstellen. Das löst ein reales Problem — nämlich Daten, die durch fünf Zwischenkomponenten gereicht werden, die damit gar nichts zu tun haben. Aber es hat einen Preis, und den möchte ich klar benennen, bevor wir uns die Technik ansehen. Denn dieses Werkzeug wird häufiger falsch als richtig eingesetzt — meist dann, wenn jemand eigentlich einen Store gebraucht hätte und den Umweg gescheut hat.

14:32 Der Mechanismus ist einfach: Eine Komponente stellt unter einem Schlüssel einen Wert bereit, und jeder beliebig tief liegende Nachfahre kann ihn abholen. Die Zwischenstationen merken davon nichts. Wichtig ist der letzte Satz: Der Wert darf reaktiv sein. Dann sehen alle Nachfahren Änderungen — was diesen Weg überhaupt erst brauchbar macht. Ein fester Wert, der sich nie ändert, wäre selten die Mühe wert.

14:57 Der typische Anwendungsfall ist deshalb Kontext, der sich gelegentlich ändert: Thema, Sprache, Konfiguration. Sehen Sie sich an, was hier bereitgestellt wird: nicht nur der Wert, sondern ein Paar aus dem geschützten Wert und einer Funktion, die ihn ändert. Das ist das empfohlene Muster, und der Grund steht in der Fußzeile: Der Schreibzugriff bleibt beim Anbieter.

15:18 Die Nachfahren dürfen lesen und dürfen um eine Änderung bitten, aber sie können den Wert nicht selbst setzen. Damit bleibt nachvollziehbar, wo er geändert wird — und genau das ist bei diesem Weg sonst die große Gefahr. Fünf Zeilen. Die erste ist der einfache Fall mit einer Zeichenkette als Schlüssel, und für kleine Anwendungen reicht das.

15:38 Die zweite ist der saubere Weg für größere: ein Symbol aus einer eigenen Datei. Das kann nicht kollidieren, und Sie können der Definition folgen, um zu sehen, wer diesen Schlüssel benutzt. Die dritte und vierte Zeile decken den Fall ab, dass gar kein Anbieter existiert — dann können Sie einen Vorgabewert angeben. Die letzte Zeile ist die anwendungsweite Variante.

16:00 Hier ist der Preis, den ich angekündigt habe. Der erste Punkt: Die Abhängigkeit ist im Kind sichtbar, im Baum darüber aber nicht. Sie können also eine Komponente aus dem Baum lösen und woanders einsetzen — und sie bricht, ohne dass irgendetwas darauf hingedeutet hätte. Der zweite Punkt macht es schlimmer: Ohne Anbieter gibt es keinen Fehler, sondern nur einen leeren Wert. Der Fehler zeigt sich also weit entfernt von seiner Ursache.

16:26 Deshalb: für Kontext ja, für Anwendungszustand lieber ein Store. Der erste Punkt ist die Kehrseite des Musters von Folie 33: Wenn der Wert im Kind geändert werden darf, ist die Herkunft der Änderung nicht mehr auffindbar. Sie haben dann eine globale Variable ohne die Ehrlichkeit einer globalen Variablen. Der zweite Punkt ist ein häufiger Anfängerfehler: Ein nicht reaktiver Wert bleibt stehen.

16:50 Wer eine einfache Zahl bereitstellt statt eines reaktiven Behälters, wundert sich, warum die Nachfahren die Änderung nicht sehen. Der Wert wurde einmal kopiert, das war es.

Slots zur flexiblen Inhaltsintegration

17:01 Und jetzt zum vierten Weg, der sich von den anderen grundsätzlich unterscheidet. Bisher ging es um Werte. Bei Slots geht es um Markup: Die Elternkomponente reicht ganzen Inhalt hinein, und die Komponente bestimmt nur, wo er landet und was drumherum steht. Das ist ein mächtiges Werkzeug für wiederverwendbare Bausteine — und deutlich unterschätzt.

17:21 Wer einmal verstanden hat, was damit geht, baut Komponenten anders: offener und mit weniger Eingaben. Stellen Sie sich einen Bilderrahmen vor. Der Rahmen bestimmt die Form, das Glas, die Aufhängung — aber nicht, welches Bild darin hängt. Genau so funktioniert ein Slot: Die Komponente liefert die Struktur drumherum, der Aufrufer den Inhalt.

17:42 Und was zwischen den Slot-Tags steht, ist der Ersatzinhalt — das Bild, das mitgeliefert wird, wenn niemand ein eigenes einlegt. Der Reiz ist, dass die Komponente die möglichen Inhalte gar nicht kennen muss. Ein sehr kleines Beispiel mit großer Wirkung. Ohne Inhalt zeigt der Knopf seine Standardbeschriftung, mit Inhalt die übergebene.

18:03 Vergleichen Sie das einmal mit der Alternative über eine Eingabe: Die könnte nur Text entgegennehmen. Über den Slot können Sie auch ein Symbol mitgeben, einen Ladehinweis, formatiertes Markup. Das ist der entscheidende Unterschied — und der Grund, warum Basisbausteine wie Knöpfe, Karten und Dialoge fast immer mit Slots gebaut werden.

18:23 Das ist die fortgeschrittene Variante, und sie ist wirklich elegant. Die Komponente kümmert sich um die Schleife, um das Laden, um die Struktur — und reicht bei jedem Durchlauf die Daten nach außen. Wie diese Daten dargestellt werden, entscheidet der Aufrufer. Damit können Sie eine Listenkomponente bauen, die für Artikel, Mitglieder und Ausleihen gleichermaßen funktioniert, obwohl sie keines dieser Dinge kennt.

18:46 Sie liefert das Verhalten, die Darstellung kommt von außen. Der dritte Punkt ist der, der oft überrascht: Der übergebene Inhalt gehört zur Elternkomponente, samt deren Zustand. Er wird nur woanders angezeigt. Das heißt, Sie können darin auf alles zugreifen, was in der Elternkomponente verfügbar ist — und das funktioniert, obwohl das Markup in einer anderen Datei gerendert wird.

19:09 Der letzte Punkt fasst den Nutzen: Scoped Slots liefern Daten heraus, ohne die Darstellung vorzuschreiben. Das ist die sauberste Form der Trennung von Verhalten und Aussehen. Der erste Punkt ist eine Wechselwirkung mit Modul 6, die Sie kennen sollten: Slot-Inhalt trägt die Kennung der Elternkomponente. Ihre begrenzten Stile in der Komponente erreichen ihn deshalb nicht — dafür gibt es den Sonderselektor, den wir dort besprochen haben.

19:35 Der dritte Punkt ist praktisch: Ein leerer Slot rendert die Hülle trotzdem. Wenn Sie also einen Rahmen um den Slot legen, sehen Sie einen leeren Rahmen. Die Lösung dafür kommt im nächsten Kapitel.

Named Slots für komplexe Layoutstrukturen

19:47 Zum Abschluss des Moduls die Ausbaustufe: mehrere Aussparungen in einer Komponente. Damit bauen Sie Layoutkomponenten — Karten mit Kopf und Fuß, Dialoge mit Titel und Knopfleiste, Seitengerüste. Es kommt eine Schreibweise dazu, und eine kleine Technik, mit der Sie leere Bereiche gar nicht erst rendern. Beides ist schnell erklärt und im Alltag sehr nützlich — die zweite besonders, weil sie den Unterschied zwischen einem soliden und einem halbfertigen Layoutbaustein ausmacht.

20:15 Mehrere Aussparungen, jede mit einem Namen — mehr ist es nicht. Gefüllt werden sie über Hüllelemente, die den Namen tragen. Der letzte Satz ist die praktische Erleichterung: Was ohne Zuordnung übergeben wird, landet im Standard-Slot. Sie müssen also nicht jeden Inhalt in ein Hüllelement wickeln, sondern nur die benannten Bereiche.

20:34 Das hält den Aufrufcode angenehm kurz, gerade wenn der Hauptinhalt der umfangreichste Teil ist. Hier sehen Sie die Technik gegen leere Rahmen, die ich angekündigt habe: eine Prüfung darauf, ob der jeweilige Slot überhaupt gefüllt ist. Ohne diese Prüfung bekämen Sie einen leeren Kopfbereich mit Rahmen und Abstand, auch wenn niemand etwas hineingegeben hat. Mit der Prüfung entsteht dort schlicht nichts.

20:58 Das ist eine Kleinigkeit, die den Unterschied zwischen einer soliden und einer halbfertigen Layoutkomponente ausmacht — und sie kostet drei Zeichen je Bereich. Und so sieht die Verwendung aus. Zwei Hüllelemente für die benannten Bereiche, und dazwischen ein Absatz ohne Hülle — der landet automatisch im Hauptbereich. Achten Sie auf die Raute: Das ist die Kurzform, die wir in Modul 3 schon einmal gestreift haben. Sie brauchen sie hier zum ersten Mal wirklich.

21:24 Und beachten Sie, wie lesbar der Aufruf bleibt: Man sieht auf einen Blick, welcher Inhalt wohin gehört, ohne die Komponente öffnen zu müssen. Fünf Zeilen. Die vierte ist die Kombination aus benannt und mit Daten — das ist die mächtigste Form und die, die Sie in guten Komponentenbibliotheken häufig sehen. Die fünfte ist exotisch und wird selten gebraucht. Der Hinweis unten ist eine Syntaxregel, über die man einmal stolpert: Die Kurzform braucht immer ein Argument.

21:52 Ein alleinstehendes Rautezeichen ist ungültig — wenn Sie den Standardbereich ausdrücklich benennen wollen, schreiben Sie ihn aus. Diese Aufgabe ist der Abschluss des Moduls, und das Erfolgskriterium hat es in sich: Dieselbe Layoutkomponente soll zwei sichtbar verschiedene Seiten tragen, ohne eine der beiden zu kennen. Das ist der Test darauf, ob Sie wirklich Struktur und Inhalt getrennt haben.

22:15 Der zweite Teil des Kriteriums ist der Feinschliff: Nicht gefüllte Bereiche dürfen kein leeres Markup erzeugen. Der Hinweis unten sagt, wie — über die Prüfung von Folie 45, nicht über eine zusätzliche Eingabe. Der zweite Punkt ist der ärgerlichste, weil er völlig stumm scheitert: ein Tippfehler im Slotnamen. Es gibt keine Warnung, kein rotes Feld — der Inhalt erscheint einfach nicht.

22:38 Wenn also übergebenes Markup spurlos verschwindet, prüfen Sie zuerst die Schreibweise des Namens auf beiden Seiten. Der letzte Punkt ist eine Einschränkung, die logisch ist, aber überrascht: Die mitgelieferten Daten stehen nur innerhalb des jeweiligen Hüllelements zur Verfügung, nicht daneben.

Komponenten reden miteinander

22:55 Fassen wir zusammen. Eingaben hinunter, Ereignisse herauf — das trägt den Alltag, und alles andere ist Ergänzung für begründete Fälle. Bereitgestellter Kontext eignet sich für Thema, Sprache und Konfiguration, nicht für Anwendungszustand. Und Slots übergeben Markup statt Werte und halten Komponenten damit offen für Verwendungen, die Sie beim Schreiben noch nicht kennen.

23:17 Im nächsten Modul verlassen wir die einzelne Seite: Es geht um Routing, also darum, wie aus einer Anwendung mehrere Ansichten werden.