Styling von Komponenten

Styling von Komponenten

0:00 In diesem Modul geht es um das Aussehen — und um ein Problem, das so alt ist wie CSS selbst: Stile wirken global, Komponenten sind lokal. Wie bringt man das zusammen? Vue hat darauf eine erfreulich pragmatische Antwort, und wir sehen uns an, wie sie funktioniert und wo ihre Grenzen liegen. Außerdem geht es um dynamische Klassen, um Stile, die vom Zustand abhängen, und um die Frage, ob man heute überhaupt noch einen Preprozessor braucht.

0:26 Die Antwort darauf ist inzwischen weniger eindeutig als früher.

Globale und komponentenspezifische Styles

0:30 Fangen wir mit der Aufteilung an. In jeder Vue-Anwendung gibt es zwei Ebenen von Stilen, und es lohnt sich, von Anfang an klar zu haben, was wohin gehört. Wer das nicht trennt, landet nach ein paar Monaten bei einer globalen Datei mit achthundert Zeilen, von denen niemand mehr weiß, welche noch gebraucht werden. Die Regel dafür ist einfach, sie muss nur konsequent gelten.

0:52 Die Aufteilung folgt einer einfachen Frage: Gilt das für alles oder nur für diesen einen Baustein? Global gehören drei Dinge hin — das Zurücksetzen der Browservorgaben, die Grundtypografie und die Farbvariablen. Alles andere gehört zur Komponente, die es betrifft, und liegt in deren Datei. Das ist dieselbe Idee wie beim Komponentenschnitt aus Modul 2: Was zusammengehört, liegt beieinander.

1:15 Und es hat denselben Vorteil — wenn eine Komponente verschwindet, verschwindet ihr Stil mit ihr, ohne Karteileichen zu hinterlassen. Vier Zeilen Gegenüberstellung, und der Hinweis unten ist der eigentliche Rat des Kapitels: Farbvariablen gehören nach oben. Wenn Ihre Markenfarbe in zwanzig Komponentendateien als Hexwert steht, ist ein Farbwechsel ein Suchen-und- Ersetzen-Vorgang mit Fehlerrisiko.

1:39 Steht sie an einer Stelle, ist es eine Zeile. Das ist übrigens auch die Regel, nach der dieses Repository selbst arbeitet — das gesamte Foliendesign steckt in einer einzigen Datei mit Gestaltungswerten, und kein Foliensatz enthält einen eigenen Farbwert. Vier Zeilen, und die dritte ist die interessante. Ein Import ohne Zielvariable sieht auf den ersten Blick nach einem Fehler aus — er weist ja nichts zu.

2:03 Für Vite ist das aber die Anweisung: Nimm diese Datei mit ins Bündel. Der Bauprozess kümmert sich dann um alles Weitere, inklusive Verkleinerung und Prüfsumme im Dateinamen. Das ist einer der Punkte, an denen moderne Bauwerkzeuge Ihnen Arbeit abnehmen, die früher von Hand oder über eine Sammeldatei erledigt wurde. Der zweite Punkt ist der, der im Alltag am meisten Ärger macht: ein globaler Selektor auf ein Element.

2:28 Jemand schreibt eine Regel für alle Knöpfe, und drei Monate später sieht ein Knopf in einem Dialog falsch aus — und niemand versteht, warum. Der letzte Punkt ist die wichtige Ausnahme: Variablen sind harmlos. Sie wirken nur dort, wo sie tatsächlich abgerufen werden. Eine globale Datei, die nur aus Variablen besteht, kann beliebig wachsen, ohne jemandem in die Quere zu kommen.

2:51 Der erste Punkt ist eine Falle, die man leicht übersieht: Ein Stilblock ohne den Zusatz für die Begrenzung wirkt global — auch wenn er in einer Komponentendatei steht. Und er wirkt weiter, nachdem die Komponente längst verschwunden ist, denn die Regeln landen beim Bauen ohnehin in einer gemeinsamen Datei. Der letzte Punkt ist eine Reihenfolgefrage: Ein Zurücksetzen der Browservorgaben, das nach den Komponentenstilen geladen wird, überschreibt genau das, was Sie eben sorgsam eingestellt haben.

Scoped CSS verstehen und anwenden

3:18 Jetzt zu dem Werkzeug, das das Grundproblem löst: Stile, die nur für eine Komponente gelten. Ich möchte Ihnen dabei nicht nur zeigen, wie man es benutzt, sondern auch, was technisch passiert. Denn das erklärt gleichzeitig, wo die Grenzen liegen — und die sind wichtiger, als viele denken. Es ist nämlich keine echte Kapselung, auch wenn es sich so anfühlt.

3:39 Wer das verwechselt, wundert sich später, warum eine globale Regel trotzdem in seine Komponente hineinwirkt. Der Mechanismus ist verblüffend einfach: Vue hängt an jedes Element der Komponente ein eindeutiges Datenattribut und ergänzt jeden Ihrer Selektoren um genau dieses Attribut. Fertig. Es ist keine Sandbox, keine Kapselung im Sinne von Web Components — es ist eine Verschärfung der Selektoren.

4:03 Das klingt weniger beeindruckend, hat aber einen großen Vorteil: Sie können den erzeugten Selektor in den Entwicklerwerkzeugen lesen und verstehen. Bei Systemen, die Klassennamen generieren, steht dort nur noch Buchstabensalat. Hier sehen Sie es in beide Richtungen: oben Ihr Code, unten das Ergebnis. Die Zeichenfolge im Attribut ist je Komponente eindeutig und bleibt über Neubauten hinweg stabil, solange sich die Datei nicht ändert.

4:29 Genau deshalb kollidieren Klassennamen nicht mehr: Ihre Karte und die Karte aus einer anderen Komponente tragen verschiedene Attribute. Sie dürfen also in jeder Datei eine Klasse gleichen Namens verwenden — was in der Praxis eine erhebliche Entlastung ist, weil Namensfindung Zeit kostet. Der zweite Punkt ist der, der mich überzeugt hat: Ein Stil verschwindet mit seiner Komponente.

4:51 In einer klassischen Stylesheet-Sammlung traut sich nach zwei Jahren niemand mehr, eine Regel zu löschen — weil man nicht beweisen kann, dass sie unbenutzt ist. Hier stellt sich die Frage gar nicht. Der letzte Punkt ist ein Nebeneffekt, den man unterschätzt: Sie brauchen keine Namenskonvention wie BEM mehr, um Zusammenstöße zu vermeiden.

5:11 Das Werkzeug erledigt es. Der erste Punkt ist die wichtigste Ausnahme, und sie ist Absicht: Das Wurzelelement einer Kindkomponente trägt beide Attribute — das eigene und das der Eltern. Damit können Eltern das Layout ihrer Kinder beeinflussen, etwa Abstände setzen, ohne in die Kindkomponente hineinzugreifen. Der zweite Punkt ist eine echte Falle: Inhalt, der über rohes HTML eingesetzt wird, bekommt kein Attribut und bleibt deshalb ungestylt.

5:38 Wer formatierte Texte aus einem Redaktionssystem anzeigt, stolpert darüber garantiert.

Klassen dynamisch setzen

5:43 Jetzt zum Alltagswerkzeug schlechthin: Klassen, die vom Zustand abhängen. Aktiv, ausgewählt, fehlerhaft, deaktiviert — für all das schalten Sie Klassen um, und Vue bietet dafür zwei Schreibweisen an. Beide sind einfach, und die Frage ist weniger, welche funktioniert, als welche in welcher Situation lesbar bleibt. Genau darum geht es in diesem Kapitel.

6:05 Und es gibt eine Faustregel dafür, ab wann man die Logik besser aus dem Markup herausholt — die verrate ich Ihnen gleich, sie hat mit der Zahl zwei zu tun. Zwei Schreibweisen mit klarer Arbeitsteilung. Die Objektform schaltet benannte Klassen anhand von Wahrheitswerten — der Klassenname steht fest, nur das Ob variiert. Die Array-Form setzt eine Liste von Namen, die selbst aus Variablen kommen dürfen. Der wichtige Zusatz steht am Ende: Beide vertragen sich mit einem statischen Klassenattribut.

6:35 Vue führt die Angaben zusammen, statt eine durch die andere zu ersetzen. Sie können also feste Grundklassen und dynamische Zustände sauber nebeneinander schreiben. Vier Zeilen mit den wichtigsten Varianten. Oben die Kombination aus fester und dynamischer Angabe — das ist der häufigste Fall im Alltag. Darunter die Array-Form mit Variablen, und ganz unten eine Mischung mit einem Bedingungsausdruck.

6:58 Die letzte Variante funktioniert, aber ich würde sie als Warnsignal lesen: Sobald ein Bedingungsausdruck im Klassenattribut steht, wird es beim Lesen zäh. Dafür gibt es eine schönere Lösung, und die kommt auf der nächsten Folie. Das ist die Lösung, die ich meine, und sie ist im Grunde dieselbe Idee wie in Modul 3: Was mehr als einen Gedanken enthält, gehört ins Skript.

7:21 Hier steht ein abgeleitetes Objekt, in dem jede Klasse ihre eigene Bedingung hat — sauber untereinander, gut lesbar, testbar. Im Template bleibt eine einzige, kurze Bindung. Das lohnt sich ab etwa zwei Bedingungen. Und es hat einen zweiten Vorteil: Wenn die Regel sich ändert, ändern Sie eine Zeile im Skript und nicht einen verschachtelten Ausdruck im Markup.

7:42 Vier Fälle, vier Antworten — das ist Ihre Entscheidungshilfe für den Alltag. Der Hinweis unten greift ein Thema aus Modul 2 wieder auf: Eine Klasse, die Sie an eine Komponente geben, landet automatisch an deren Wurzelelement. Das ist sehr praktisch, denn es funktioniert genau so, wie man es intuitiv erwartet. Aber es setzt eben ein einziges Wurzelelement voraus.

8:04 Bei mehreren weiß Vue nicht, wohin damit — dann müssen Sie in der Komponente selbst festlegen, welches Element die Klasse bekommt. Der erste Punkt ist eine reine Syntaxfalle: Klassennamen mit Bindestrich sind in einem Objektliteral keine gültigen Schlüssel und brauchen Anführungszeichen. Der letzte Punkt ist der wichtigere und wird gern übersehen: Klassennamen zur Laufzeit zusammenzubauen — etwa aus einem Präfix und einer Variable — erzeugt Zeichenketten, die in keiner Suche mehr auftauchen.

8:33 Wenn Sie später fragen, wo diese Klasse verwendet wird, findet Ihr Editor nichts. Schreiben Sie die Namen lieber vollständig aus.

Dynamische Styles mit Bindings

8:41 Manchmal reicht eine Klasse nicht, weil der Wert selbst aus dem Zustand kommt — eine berechnete Breite, eine Farbe aus den Daten, eine Position. Dafür gibt es zwei Wege, und der zweite ist der interessantere, weil er weniger bekannt ist und im Ergebnis fast immer besser. Sehen wir uns beide an und klären, wann welcher passt.

8:59 Der Unterschied liegt vor allem darin, wo der Stil am Ende steht — und das entscheidet darüber, ob Sie ihn später noch überschreiben können. Der erste Weg ist der naheliegende: Inline-Stile aus einem Objekt binden. Die Schlüssel schreiben Sie entweder in der JavaScript-Schreibweise oder in der CSS-Schreibweise mit Anführungszeichen.

9:19 Der zweite Weg ist der elegantere: eine Funktion, mit der Sie im Stilblock direkt auf den Zustand zugreifen können. Damit bleibt der Stil dort, wo er hingehört, und nur der veränderliche Wert kommt von außen. Vue setzt das intern über eine CSS-Variable um. Drei Zeilen mit den Varianten. Oben die JavaScript-Schreibweise für die Eigenschaftsnamen, in der Mitte die CSS-Schreibweise in Anführungszeichen, unten mehrere Stilobjekte in einer Liste.

9:45 Ein Detail, das Vue Ihnen abnimmt, steht in der Fußzeile: Herstellerpräfixe werden zur Laufzeit ergänzt, wenn der Browser sie braucht. Das war vor einigen Jahren ein großes Thema und ist heute weitgehend erledigt — aber es ist gut zu wissen, dass es passiert, falls Sie in den Entwicklerwerkzeugen mehr Regeln sehen, als Sie geschrieben haben.

10:05 Das ist der Weg, den ich meine, und ich finde ihn deutlich schöner. Sehen Sie sich an, wo der Stil steht: im Stilblock, wo man ihn sucht. Das Markup bleibt frei von Gestaltungsangaben, und trotzdem ist der Wert dynamisch. Vue übersetzt das beim Bauen in eine CSS-Variable, die es am Wurzelelement der Komponente setzt und bei jeder Änderung aktualisiert.

10:26 Sie schreiben also normales CSS mit einer beweglichen Stelle — statt Ihre Gestaltung ins Markup zu verlagern. Der dritte Punkt ist der praktisch wichtigste: Inline-Stile haben eine sehr hohe Spezifität und lassen sich kaum überschreiben. Wenn Sie später eine Ausnahme brauchen — für den Druck, für einen dunklen Modus, für einen bestimmten Kontext —, kommen Sie gegen einen Inline-Stil nur mit dem Ausrufezeichen an, und das ist eine Eskalation, die man vermeiden will.

10:53 Beim Weg über den Stilblock bleibt alles eine normale CSS-Regel und damit überschreibbar. Der erste Punkt ist der Klassiker in diesem Bereich: eine vergessene Einheit. Eine nackte Zahl ist bei den meisten Eigenschaften ungültig, und der Browser ignoriert die Angabe kommentarlos. Der dritte Punkt ist eine Syntaxbesonderheit, die man kennen muss: Sobald der Ausdruck im Stilblock einen Punkt enthält, also ein Feld eines Objekts anspricht, brauchen Sie Anführungszeichen.

11:20 Ohne sie scheitert der Compiler — und die Meldung dazu ist nicht besonders sprechend.

Styling verschachtelter Komponenten

11:25 Und jetzt zu den Grenzen. Begrenzte Stile enden an der Komponentengrenze, und manchmal muss man genau darüber hinweg. Es gibt dafür drei Sonderselektoren, und jeder hat einen klaren Zweck. Ich möchte sie Ihnen zeigen — und gleichzeitig warnen, denn der erste davon ist mächtig genug, um sich damit ein Wartungsproblem einzuhandeln.

11:44 Das ist überhaupt die Eigenart dieses Kapitels: Alle drei Selektoren sind Ausnahmen, und Ausnahmen sollten begründet sein. Drei Selektoren für drei begründete Ausnahmen. Der erste greift in eine Kindkomponente hinein — für den Fall, dass Sie eine fremde Komponente anpassen müssen, die keine Gestaltungsschnittstelle anbietet.

12:04 Der zweite betrifft Inhalt, der von außen hereingereicht wurde; dazu mehr in Modul 7. Der dritte hebt die Begrenzung bewusst auf, etwa für eine Klasse am Dokumentkörper. Alle drei funktionieren nur innerhalb eines begrenzten Blocks — ohne diesen Zusatz sind sie wirkungslos. Drei Zeilen, drei Zwecke. Der erste ist der, den Sie am häufigsten brauchen werden, und zwar fast immer für dasselbe: eine Komponente aus einer fremden Bibliothek, die nicht ganz so aussieht, wie Sie es wollen.

12:33 Der zweite hat einen Grund, den man kennen sollte — hereingereichter Inhalt gehört zur Elternkomponente und trägt deren Attribut, deshalb erreichen Ihre eigenen Selektoren ihn nicht. Der dritte ist der Notausgang für die Fälle, in denen wirklich etwas global gelten muss. Drei Beispiele. Beachten Sie beim ersten, was die Fußzeile sagt: Nur der linke Teil des Selektors trägt das Attribut, der rechte nicht.

12:56 Das ist genau der Punkt — Sie schränken auf Ihre Komponente ein und greifen von dort aus in die Tiefe. Das dritte Beispiel zeigt den typischen Fall für die globale Ausnahme: eine Klasse am Dokumentkörper, die einen dunklen Modus schaltet. Die kommt von außerhalb Ihrer Komponente, und deshalb müssen Sie die Begrenzung an dieser Stelle aufheben.

13:17 Der zweite Punkt ist der Kern der Warnung: Wenn die Kindkomponente ihr Markup ändert, bricht Ihr Stil — und zwar ohne jede Fehlermeldung. Sie greifen ja auf eine innere Struktur zu, die niemand Ihnen zugesagt hat. Bei einer Bibliotheksaktualisierung ist das ein realer Fall. Der dritte Punkt nennt die saubere Alternative: Eine gut gebaute Komponente bietet selbst eine Gestaltungsschnittstelle an, über eine Eingabe oder eine CSS-Variable.

13:42 Wenn Sie solche Komponenten schreiben, denken Sie daran. Der erste Punkt betrifft ältere Beispiele im Netz: Es gab früher Schreibweisen mit Pfeilen für dasselbe, und die sind heute veraltet. Wenn Sie so etwas sehen, wissen Sie, dass die Quelle älter ist. Der letzte Punkt ist die inhaltliche Warnung noch einmal in kurz: Wer eine Kindkomponente über den tiefen Selektor umbaut, koppelt zwei Dateien fest aneinander.

14:07 Notieren Sie sich in so einem Fall wenigstens einen Kommentar — dann weiß der nächste, warum diese Regel existiert.

Integration von CSS Preprozessoren

14:14 Ein kurzes, sehr praktisches Kapitel. Preprozessoren waren jahrelang Standardwerkzeug im Frontend, und die Einbindung in ein Vite-Projekt ist erfreulich unspektakulär: ein Paket installieren, ein Attribut setzen, fertig. Kein Plugin, keine Konfiguration. Wir sehen uns an, wie es geht — und im nächsten Kapitel dann die Frage, ob Sie das überhaupt noch brauchen.

14:37 Diese Reihenfolge ist Absicht: erst die Technik, dann die Bewertung. Der wichtige Satz ist der erste Halbsatz: ohne eigenes Plugin. Vite erkennt an der Sprachangabe im Stilblock, welchen Preprozessor es aufrufen soll, und kümmert sich um den Rest. Sie müssen also nur den Preprozessor selbst installieren. Für Sass empfiehlt die Dokumentation die eingebettete Variante — die ist deutlich schneller als die ältere JavaScript-Fassung, was bei größeren Projekten spürbar wird.

15:06 Ein Detail, das man sonst leicht falsch macht. Ein Befehl, das ist alles. Und die Fußzeile sagt das Entscheidende: Es braucht kein Vite-Plugin. Das ist erwähnenswert, weil das in der webpack-Welt anders war — dort brauchte jede Sprache ihren eigenen Loader und einen Eintrag in der Konfiguration. Wenn Sie also eine ältere Anleitung finden, in der von Loadern und Regeln die Rede ist, sind Sie in der falschen Werkzeuggeneration. Bei Vite genügt wirklich die Installation.

15:34 Und so sieht es dann aus: ein zusätzliches Attribut am Stilblock, und Sie schreiben in der Preprozessorsprache. Hier sehen Sie die Verschachtelung, die lange das Hauptargument für Sass war. Merken Sie sich diese Zeile — im nächsten Kapitel werden wir feststellen, dass genau dieses Argument heute nicht mehr zieht, weil natives CSS die Verschachtelung inzwischen selbst beherrscht.

15:56 Was bleibt, sind andere Gründe, und die sehen wir uns dann an. Drei Sprachen, drei Pakete. Für den Alltag ist die erste Zeile die relevante, die anderen beiden sind heute Nischen. Die Fußzeile nennt eine Bequemlichkeit, die man leicht übersieht: Vite löst Importe auf und rechnet Pfadangaben in Stilen korrekt um — auch über Verzeichnisgrenzen hinweg.

16:16 Das klingt banal, ist aber genau die Sorte Problem, die einen früher eine Stunde gekostet hat, wenn ein Hintergrundbild nach dem Bauen plötzlich nicht mehr gefunden wurde. Der zweite Punkt ist der, der die meiste Zeit kostet: Variablen aus einer Datei sind nicht automatisch überall verfügbar. Jede Komponente, die sie benutzt, muss die Datei einbinden — sonst bricht der Bau mit einer Meldung über eine undefinierte Variable.

16:40 Der letzte Punkt ist eine Vorwegnahme des nächsten Kapitels und wichtig: Preprozessor-Variablen sind Werte zur Bauzeit. Sie stehen nach dem Bauen fest und lassen sich zur Laufzeit nicht mehr ändern. Für einen Themenwechsel taugen sie damit nicht.

Nutzung von SASS und modernen CSS Workflows

16:55 Und damit zur ehrlichen Frage: Brauchen Sie das heute noch? Die Antwort hat sich in den letzten Jahren deutlich verschoben, weil CSS selbst dazugelernt hat. Einiges, wofür man früher zwingend einen Preprozessor brauchte, kann der Browser inzwischen von Haus aus. Wir sortieren, was noch übrig bleibt — und sehen uns die Alternative an, die für Themes klar überlegen ist.

17:16 Das ist eine der Stellen, an denen sich ein Blick auf den aktuellen Stand wirklich lohnt: Vieles, was man vor Jahren gelernt hat, ist heute schlicht überholt. Die Verschiebung in einem Satz: Verschachtelung, Variablen und Kaskadenebenen kann CSS heute selbst. Was beim Preprozessor bleibt, sind Dinge, die zur Bauzeit passieren sollen — Aufteilung in Dateien, Mixins, berechnete Farbwerte.

17:40 Das ist weiterhin nützlich, aber es ist ein deutlich kleinerer Bereich als vor fünf Jahren. Und für den wichtigsten Anwendungsfall im Alltag, nämlich Farbwerte, ist der native Weg sogar der bessere. Warum, sehen wir gleich. Sechs Zeilen, und die entscheidenden sind die zweite und die dritte: Variablen zur Laufzeit gegen Variablen zur Bauzeit.

18:01 Das ist kein Feinheitsunterschied, sondern der Kern der Sache. Eine Preprozessor-Variable existiert nach dem Bauen nicht mehr — sie wurde durch ihren Wert ersetzt. Eine CSS-Variable existiert im Browser und lässt sich jederzeit ändern. Damit ist die Fußzeile klar: Für Themes gewinnen CSS-Variablen, und zwar nicht knapp.

18:21 So sieht das aus: Variablen an der Wurzel des Dokuments definiert, in den Komponenten abgerufen. Der Gewinn steht in der Fußzeile — ein Themenwechsel setzt nur diese Werte um, ohne neuen Bau und ohne Neuladen. Sie können das sogar aus JavaScript heraus tun, etwa wenn der Nutzer eine Farbe auswählt. Mit Preprozessor-Variablen wäre das unmöglich, denn die gibt es zur Laufzeit schlicht nicht mehr. Wer einen dunklen Modus plant, sollte hier anfangen.

18:49 Der letzte Punkt schließt einen Kreis, den ich hübsch finde: Die Bindungsfunktion aus Kapitel vier erzeugt intern genau solche Variablen. Sie haben also längst damit gearbeitet, ohne es zu merken. Der dritte Punkt ist der technisch wichtigste: CSS-Variablen folgen der Kaskade und wirken auf alle Nachfahren. Das heißt, Sie können sie auch bereichsweise überschreiben — etwa für einen Kasten, der andere Farben haben soll. Das ist eine Mächtigkeit, die Preprozessor-Variablen nie hatten.

19:18 Diese Aufgabe hat einen sehr befriedigenden Nachweis, und den empfehle ich Ihnen: Öffnen Sie die Entwicklerwerkzeuge, ändern Sie die Variable von Hand und sehen Sie zu, wie sich die ganze Seite umfärbt. Wenn das funktioniert, haben Sie die Aufgabe gelöst — und zwar sichtbar. Das Erfolgskriterium ist streng: kein direkter Farbwert mehr in einem Komponentenstil.

19:39 Gehen Sie ruhig mit der Suche durch das Projekt; Hexwerte findet man gut. Der erste Punkt ist ein Fehler, den fast jeder einmal macht: eine Preprozessor-Variable in einem CSS-Variablenaufruf. Das sind zwei verschiedene Systeme, die zu verschiedenen Zeitpunkten arbeiten, und sie lassen sich so nicht mischen. Der dritte Punkt ist eine Wechselwirkung mit Kapitel zwei: Eine Variable, die Sie in einem begrenzten Stilblock definieren, wirkt erst ab dem Wurzelelement der Komponente — nicht darüber.

20:08 Für anwendungsweite Werte gehört sie deshalb in die globale Datei.

Aussehen im Griff

20:12 Fassen wir zusammen. Global bleibt knapp: Zurücksetzen, Typografie, Variablen. Der Begrenzungszusatz verschärft Selektoren, er kapselt nicht — und die Ausnahmen dafür kennen Sie jetzt. Dynamik läuft über Klassen, dynamische Werte besser über CSS-Variablen als über Inline-Stile. Und für Themes gilt: Was sich zur Laufzeit ändern soll, gehört in eine CSS-Variable.

20:35 Im nächsten Modul wird es wieder inhaltlich: Es geht darum, wie Komponenten miteinander reden — über Eingaben, Ereignisse, weitergereichten Kontext und hereingereichtes Markup.