Start / Seminare / React v19 Grundlagen & Moderne Features

Modul

React v19 - Komponenten-Architektur

4 Kapitel in diesem Modul-Video · Laufzeit

Vertonung mit synthetischer Stimme · Inhalte redaktionell verantwortet · © 2026 HECKER CONSULTING, alle Rechte vorbehalten

Transkript

Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.

React v19+ — Komponenten-Architektur

0:00 Fast jede Oberfläche, die Sie heute im Browser oder auf dem Handy bedienen, ist aus Bausteinen zusammengesetzt — ein Suchfeld, eine Karte, eine Liste. React hat dieses Denken populär gemacht: Nicht eine große Seite bauen, sondern viele kleine Teile, die man zusammensteckt. Klingt banal, entscheidet aber darüber, ob ein Projekt nach zwei Jahren noch wartbar ist oder zum Flickenteppich wird.

0:23 Mit Version 19 ist das Modell so aufgeräumt wie nie: Komponenten sind Funktionen, Klassen praktisch Geschichte. Heute schauen wir uns an, wie man diese Bausteine gut schneidet — und wo man sich typischerweise selbst im Weg steht.

Komponenten-Architektur mit React v19+

0:37 Der rote Faden für heute ist eine Bewegung: von der einzelnen Komponente hin zur zusammengesetzten Oberfläche. Wir starten bei der kleinsten Einheit — der Funktion, die JSX zurückgibt. Dann klären wir, wie Daten zwischen diesen Bausteinen fließen und wie man sie ineinander schachtelt. Danach kommt die Interaktion: auf Klicks reagieren, situativ rendern. Und zum Schluss die bewährten Bauformen für Projekte, die wachsen.

1:03 Vier Kapitel, die aufeinander aufbauen — jedes mit einer eigenen Übung. Bevor wir loslegen, würde ich gern wissen, wo Sie stehen. React ist inzwischen zehn Jahre alt, und das merkt man an den Vorerfahrungen: Manche kommen aus der Klassen-Ära mit `this` und Lifecycle-Methoden, andere haben von Anfang an nur Hooks gesehen — und beide Gruppen stolpern über völlig verschiedene Dinge.

1:25 Auch die Version macht einen Unterschied, zwischen 16 und 19 liegt einiges. Sagen Sie mir also gern kurz: Womit arbeiten Sie, was tragen Sie an Altlasten mit sich herum, und vor allem — was soll heute Abend konkret hängengeblieben sein?

Funktionale Komponenten & JSX

1:39 Fangen wir ganz unten an, beim kleinsten Baustein. Was genau ist eine Komponente in React — und was ist dieses JSX, das aussieht wie HTML, aber keines ist? Diese beiden Fragen klären wir jetzt, denn alles Weitere baut darauf auf. Eine Komponente ist in React nichts Geheimnisvolles, sondern schlicht eine JavaScript-Funktion.

2:00 Sie bekommt etwas hinein — die sogenannten Props — und gibt etwas zurück, nämlich JSX. Denken Sie an eine Kaffeemaschine: Bohnen und Wasser rein, Kaffee raus. Und JSX ist trotz der spitzen Klammern kein HTML, sondern syntaktischer Zucker. Der Build-Schritt übersetzt es in Aufrufe von `React.createElement`. Das ist mehr als eine Randnotiz: Weil JSX ein ganz normaler JavaScript-Ausdruck ist, können Sie damit alles tun, was Sie mit Ausdrücken tun — in Variablen packen, zurückgeben, aus Schleifen erzeugen.

2:33 Warum hat sich dieses Funktionsmodell so durchgesetzt? Vor allem, weil es Ballast abwirft. Kein Konstruktor, kein `this`, das je nach Aufrufkontext etwas anderes bedeutet — genau diese Fehlerquelle hat früher unzählige Stunden gekostet. Statt Lifecycle-Methoden mit klingenden Namen gibt es Hooks, die State und Effekte direkt in die Funktion holen.

2:53 Seit Version 19 ist das nicht mehr nur der empfohlene, es ist faktisch der einzige relevante Weg — sogar `ref` ist jetzt eine ganz normale Prop, `forwardRef` können Sie vergessen. Und der stille Gewinn: Eine Funktion, die aus Eingabe Ausgabe macht, testen Sie ohne jedes Zeremoniell. Es gibt ein paar Konventionen, die Sie sich früh angewöhnen sollten — sie kosten nichts und ersparen viel Sucherei.

3:18 Der Name beginnt groß, in PascalCase, denn daran und nur daran erkennt React, dass es sich um Ihre Komponente handelt und nicht um ein HTML-Tag. Zurückgegeben wird genau ein Wurzelelement; brauchen Sie mehrere Geschwister, umschließt ein Fragment sie unsichtbar. Logik gehört vor das `return`, damit das Markup lesbar bleibt.

3:37 Wiederholt sich Markup, wird es eine eigene Komponente — das ist der Moment, in dem Architektur entsteht. Und bei Listen vergeben Sie stabile Keys aus der fachlichen ID. Hier sehen Sie das Muster in seiner Reinform: eine Funktion, die Props im Kopf auseinandernimmt, und darunter das JSX, das zurückgeht. Mehr ist es nicht — und genau das ist der Punkt. Worauf es ankommt, sind die geschweiften Klammern im Markup.

4:02 Alles darin ist echtes JavaScript, kein Template mit eigener Mini-Sprache. Sie können dort rechnen, formatieren, eine Funktion aufrufen. Der Unterschied zu klassischen Template-Engines ist damit fundamental: Sie lernen keine zweite Syntax für Bedingungen und Schleifen, Sie benutzen die Sprache, die Sie ohnehin schon können.

4:22 Jetzt sind Sie dran. Bauen Sie eine eigene Komponente, die Daten über Props entgegennimmt und daraus sauberes JSX macht. Das Lernziel ist nicht, etwas Schönes zu produzieren — es geht um die Mechanik: Wie kommen Werte hinein, wie kommen sie im Markup an? Ihr Erfolgskriterium ist angenehm objektiv: Die Konsole bleibt still. Keine Warnung über fehlende Keys, keine Beschwerde über mehrere Wurzelelemente.

4:46 Wenn Sie schneller fertig sind, rendern Sie gleich eine ganze Liste solcher Karten mit `.map()` — dann merken Sie sofort, warum das Thema Keys gleich noch einmal auftaucht. Diese vier Fehler macht wirklich jeder einmal, deshalb lohnt es sich, sie zu kennen. Mehrere Elemente ohne Fragment zurückzugeben scheitert schon an der Syntax — unangenehm, aber wenigstens sofort sichtbar.

5:08 Tückischer sind `class` statt `className` und `for` statt `htmlFor`: Beides sind reservierte Wörter in JavaScript, deshalb heißen sie in JSX anders. Der Klassiker ist der klein geschriebene Komponentenname — React hält ihn dann für ein HTML-Tag und rendert kommentarlos Unsinn, ohne Fehlermeldung. Und Keys: Fehlen sie oder nehmen Sie einfach den Array-Index, funktioniert es erst mal. Bis sortiert oder gelöscht wird.

Props & Component Composition

5:34 Eine einzelne Komponente ist noch keine Anwendung. Interessant wird es, wenn Bausteine miteinander reden und ineinander stecken. Wie Daten dabei fließen und warum React auf Zusammensetzung statt auf Vererbung setzt — darum geht es jetzt. Props sind die Eingaben einer Komponente, und sie sind schreibgeschützt — ein Kind darf lesen, was es bekommt, aber niemals daran herumändern.

5:56 Composition ist der zweite Baustein: Statt eine Komponente mit immer neuen Schaltern zu konfigurieren, schachteln Sie Inhalte über die `children`-Prop hinein. Denken Sie an einen Bilderrahmen. Der Rahmen weiß nicht, welches Bild er hält, und genau deshalb passt er zu jedem. Das ist Reacts Antwort auf die klassische Vererbung: nicht `extends`, sondern hineinlegen. Wer das einmal verinnerlicht hat, baut deutlich weniger Sonderfälle in seine Komponenten.

6:23 Der Nutzen zeigt sich erst im größeren Projekt — aber dann deutlich. Daten fließen in React nur in eine Richtung, von oben nach unten. Das klingt einschränkend, macht aber nachvollziehbar, woher ein Wert stammt, wenn etwas Merkwürdiges auf dem Bildschirm steht. Weil Props read-only sind, kann kein Kind hinter Ihrem Rücken den Zustand der Eltern verbiegen.

6:43 Und Composition löst ein Problem, das man erst schmerzhaft kennenlernt: Prop-Drilling, dieses Durchreichen von Werten durch fünf Ebenen, die den Wert selbst gar nicht brauchen. Hüllen wie Card, Modal oder Layout schreiben Sie so genau einmal. Der Weg dahin ist unspektakulär, aber wirkungsvoll. Nehmen Sie die Props gleich im Funktionskopf auseinander — dann steht in der ersten Zeile, was diese Komponente überhaupt erwartet, und Sie ersparen sich einen Blick in den Aufruf.

7:11 Default-Werte setzen Sie direkt dabei, das erspart Prüfungen im Rumpf. Inhalte reichen Sie über `children` durch, statt sie fest zu verdrahten — das ist der eigentliche Schritt zur Wiederverwendbarkeit. Und wenn eine Hülle mehrere Bereiche hat, geben Sie diesen Slots eigene Namen wie `header` oder `footer`. Damit bleibt lesbar, was wo landet.

7:31 Achten Sie hier auf eine einzige Zeile: die geschweiften Klammern mit `children` darin. An dieser Stelle wird alles eingesetzt, was zwischen den Tags der Komponente steht — im Kommentar unten sehen Sie es angewendet. Das Bemerkenswerte ist, was das Panel *nicht* weiß: Es kennt seinen Inhalt nicht, hat keine Ahnung, ob dort ein Avatar, eine Tabelle oder ein weiteres Panel landet.

7:53 Genau diese Unwissenheit macht es wiederverwendbar. Die Alternative wäre eine Komponente mit einem Dutzend Boolean-Props für jeden denkbaren Fall — und die kennen Sie vermutlich alle aus irgendeinem Projekt. In dieser Übung bauen Sie genau so eine Hülle. Das Lernziel ist eine Denkumstellung: nicht konfigurieren, sondern zusammensetzen.

8:13 Statt Flags einzuführen, die das Verhalten umschalten, öffnen Sie die Komponente für beliebige Inhalte. Der Erfolg lässt sich hart prüfen — dieselbe Hülle muss zwei völlig verschiedene Inhalte umschließen, ohne dass Sie an der Hülle selbst auch nur ein Zeichen ändern. Gelingt das, haben Sie das Prinzip verstanden. Als Erweiterung ergänzen Sie einen benannten Slot für einen Footer und sehen, wie sich beide Techniken kombinieren lassen.

8:38 Auch hier gibt es wiederkehrende Muster. Props im Kind zu verändern ist schlicht verboten — es sieht manchmal so aus, als funktioniere es, aber Sie hebeln damit Reacts Datenfluss aus. Der Spread-Operator über alle Props wirkt bequem, macht aber unsichtbar, was eine Komponente eigentlich erwartet; spätestens beim Debuggen rächt sich das.

8:56 Prop-Drilling über drei oder mehr Ebenen ist ein Alarmsignal — dann ist Composition oder Context die Antwort. Und ein Sonderfall, der regelmäßig verwirrt: `key` sieht aus wie eine Prop, ist aber für React reserviert und kommt im Kind nie an.

Event Handling & Conditional Rendering

9:10 Bisher waren unsere Komponenten stumm — sie zeigen an, mehr nicht. Jetzt kommt Bewegung ins Spiel: auf Klicks und Eingaben reagieren und die Oberfläche je nach Situation anders darstellen. Zwei Alltagsthemen, an denen erfahrungsgemäß die meisten Fehler passieren. Zwei Konzepte, die im Alltag ständig zusammen auftreten. Event-Handler sind Funktionen, die React an Ereignisse bindet — an einen Klick, eine Eingabe.

9:36 React schiebt dabei eine eigene Schicht dazwischen, die synthetischen Events. Sie können sich das wie einen Übersetzer vorstellen, der die Eigenheiten der verschiedenen Browser wegbügelt, bevor Ihr Code sie überhaupt zu sehen bekommt. Conditional Rendering heißt schlicht: Sie entscheiden mit ganz normalem JavaScript, welches JSX zurückgegeben wird.

9:57 Kein spezielles `v-if`, kein `ng-show` — eine if-Abfrage, ein Ternary, ein logisches Und. Mehr braucht es nicht. Der eigentliche Gewinn liegt in einer Denkweise, die man aus der jQuery-Zeit erst verlernen muss. Früher hat man auf einen Klick reagiert, indem man im DOM herumgegriffen und Elemente ein- oder ausgeblendet hat.

10:16 In React ändern Sie stattdessen den State — und die Oberfläche folgt automatisch. Die Anzeige ist immer ein Abbild des Zustands, nie ein Ergebnis der Klickhistorie. Das erspart genau die Fehlerklasse, bei der die UI nach fünf Interaktionen in einem Zustand hängt, den niemand mehr erklären kann. Und eine Regel merken Sie sich am besten sofort: Handler werden übergeben, nicht aufgerufen.

10:39 Diese fünf Punkte sind praktisch eine Checkliste für den Alltag. Der Handler wird ohne Klammern übergeben — die Klammern würden ihn sofort ausführen. Brauchen Sie Argumente, wickeln Sie ihn in eine Arrow-Funktion; die wird beim Klick aufgerufen, nicht beim Rendern. Für einfaches Ein und Aus reicht das logische Und, für ein Entweder-oder der Ternary.

11:00 Und wenn es komplizierter wird — drei, vier Fälle —, bereiten Sie das Ergebnis vor dem `return` in einer Variablen vor. Verschachtelte Bedingungen mitten im JSX sind der schnellste Weg zu unlesbarem Code. Dieses kleine Beispiel enthält beide Themen des Kapitels auf einmal. Ein Zustand wird gehalten, ein Klick verändert ihn, und die Beschriftung des Buttons hängt an genau diesem Zustand — die Oberfläche folgt also dem State, nicht umgekehrt.

11:26 Entscheidend ist der Pfeil vor `setOpen`. Ohne diesen Wrapper würde die Funktion schon beim Rendern feuern, den State ändern, ein erneutes Rendern auslösen — und Sie hätten eine Endlosschleife, bevor Sie überhaupt geklickt haben. Ein Zeichen Unterschied, eine völlig andere Wirkung. Behalten Sie das im Kopf. Bauen Sie jetzt selbst einen Umschalter. Das Lernziel verbindet die beiden Themen: State über ein Event verändern und die Ausgabe an genau diesen State koppeln.

11:53 Der Erfolg ist sichtbar — ein Klick wechselt zwischen zwei Zuständen, ohne dass die Seite neu lädt. Achten Sie dabei bewusst darauf, dass Sie nirgends ein Element selbst versteckt oder eingeblendet haben; das erledigt allein die Bedingung im Rendern. Wer mag, ergänzt einen dritten Zustand über eine Ternary-Kette — und merkt schnell, wo die Grenze dieser Schreibweise liegt.

12:14 Der erste Punkt ist der teuerste Tippfehler in React: Klammern hinter dem Handler, und er feuert beim Rendern statt beim Klick. Der zweite ist subtiler und trifft jeden einmal — ein Zähler mit dem Wert null. In JavaScript ist die Null falsy, aber React rendert sie brav als sichtbare Ziffer auf den Bildschirm. Prüfen Sie deshalb ausdrücklich auf größer null.

12:35 Der Array-Index als Key rächt sich, sobald Einträge umsortiert oder gelöscht werden, weil React dann Elemente falsch zuordnet. Und Handler-Logik direkt ins JSX zu schachteln macht jede Zeile schwerer lesbar, als sie sein müsste.

Komponenten-Design-Patterns

12:49 Zum Abschluss der Blick nach vorn: auf das Projekt, das nicht mehr aus fünf, sondern aus fünfzig Komponenten besteht. Dafür haben sich einige Bauformen etabliert. Wichtig dabei — Patterns sind kein Selbstzweck, sie lösen konkrete Probleme. Welche das sind, klären wir jetzt. Design-Patterns sind keine Erfindung von React, sondern gesammelte Erfahrung: Wenn ein Problem oft genug auftaucht, kristallisiert sich eine bewährte Bauform heraus.

13:16 In der Komponentenwelt geht es dabei fast immer um dieselbe Frage — wie trenne ich Logik von Darstellung? Drei Antworten schauen wir uns an. Custom Hooks bündeln Verhalten, das mehrere Komponenten brauchen. Compound Components halten Teile zusammen, die fachlich zusammengehören, wie Tabs und ihre Panels. Und das Container/Presentational-Muster trennt Datenbeschaffung von Anzeige. Alle drei zielen darauf, dass Sie Dinge kombinieren statt duplizieren können.

13:44 Der Nutzen wird oft erst spät sichtbar — nämlich dann, wenn eine Anwendung wächst. Logik in einem Custom Hook können Sie über beliebig viele Komponenten teilen, während dieselbe Logik per Copy-Paste an drei Stellen garantiert auseinanderläuft; eine wird gefixt, zwei nicht. Trennen Sie Darstellung von Datenbeschaffung, lassen sich beide einzeln testen — die Anzeige mit festen Werten, die Logik ohne Browser.

14:08 Compound Components halten zusammen, was zusammengehört, statt es über die Codebasis zu verstreuen. Unterm Strich: weniger Duplikate und klarere Verantwortlichkeiten. Beides zahlt sich nicht heute aus, sondern in einem Jahr. Wie kommen Sie praktisch dorthin? Sobald sich Zustandslogik in zwei Komponenten ähnelt, ziehen Sie sie in einen `useXyz`-Hook — das ist der häufigste und meist lohnendste Schritt.

14:33 Die Präsentation bleibt dabei bewusst dumm: eine Komponente, die nur Props bekommt und daraus Markup macht, ohne zu wissen, woher die Daten stammen. Zusammengehörige Teile bündeln Sie unter einem gemeinsamen Namensraum. Und der wichtigste Punkt steht ganz unten, fast als Warnung: Im Zweifel erst Composition versuchen. Sie kommen erstaunlich weit damit, bevor Sie überhaupt ein Pattern brauchen.

14:56 Ein Custom Hook sieht unspektakulär aus — es ist einfach eine Funktion, die selbst Hooks benutzt. Hier steckt die Umschaltlogik darin, und zurück kommt ein Paar aus aktuellem Wert und Umschaltfunktion, genau wie bei den eingebauten Hooks. Zwei Dinge sind wichtig. Erstens das `use`-Präfix im Namen: Daran erkennen React und die Lint-Regeln, dass hier Hook-Regeln gelten — es ist Konvention mit Konsequenz.

15:21 Zweitens: Jede Komponente, die diesen Hook nutzt, bekommt ihren eigenen, unabhängig gehaltenen Zustand. Geteilt wird die Logik, nicht die Daten. Das ist eine Verwechslung, die häufig vorkommt. Die letzte Übung ist eine Refactoring-Aufgabe — und damit die realistischste des Tages, denn genau so entsteht ein Hook im Alltag: nicht am Reißbrett, sondern weil Ihnen Wiederholung auffällt.

15:44 Nehmen Sie Zustandslogik aus einer bestehenden Komponente und ziehen Sie sie heraus. Der Erfolg ist erreicht, wenn zwei Komponenten sich denselben Hook teilen und die Logik nur noch an einer Stelle steht. Wenn Sie mögen, ergänzen Sie eine `reset`-Funktion — dann sehen Sie, dass Sie die Schnittstelle eines Hooks jederzeit erweitern können, ohne die Aufrufer anzufassen.

16:05 Hier lauert die Gefahr nicht im Zuwenig, sondern im Zuviel. Ein Pattern einzuführen, bevor es ein echtes Wiederverwendungsproblem gibt, erzeugt Struktur ohne Nutzen — und Struktur ohne Nutzen ist einfach nur Aufwand. Fehlt das `use`-Präfix, greifen die Lint-Regeln nicht, und Sie verlieren genau das Sicherheitsnetz, das Hook-Fehler früh meldet.

16:24 Ein Hook, in den zu viel hineingepresst wurde, ist so schwer testbar wie die Komponente, aus der er stammt — dann war die Trennung wertlos. Und Container und Presentational strikt zu trennen, wo simple Composition gereicht hätte, verdoppelt nur die Dateizahl. Ziehen wir die Linie durch den Tag. Alles beginnt bei einer Funktion, die aus Props JSX macht — mehr ist eine Komponente nicht.

16:47 Diese Bausteine reden über Props miteinander, streng in eine Richtung und ohne dass ein Kind daran herumändert; zusammengesetzt werden sie über `children`, nicht über immer neue Schalter. Kommt Interaktion dazu, gilt: Handler übergeben statt aufrufen, und die Anzeige aus dem Zustand ableiten statt am DOM zu schrauben. Und Patterns kommen zuletzt, wenn ein echter Bedarf da ist — meist reicht dann ein Custom Hook. Von der einzelnen Komponente zur wartbaren Oberfläche.

Fragen & Weiterarbeiten

17:15 Damit sind wir am Ende. Alle Beispiele und Übungen finden Sie in der Freigabe — schauen Sie ruhig noch einmal in die Aufgaben, die Sie nur angerissen haben, gerade die Stretch-Teile. Für alles Weitere ist react.dev die richtige Anlaufstelle: Die offizielle Dokumentation ist seit dem Relaunch wirklich gut und auf dem Stand von Version 19 — Sie ersparen sich damit veraltete Blogartikel aus der Klassen-Ära, von denen noch reichlich im Netz herumliegt.

17:40 Und wenn im Projektalltag Fragen auftauchen, erreichen Sie uns unter der Adresse auf der Folie. Vielen Dank für Ihre Aufmerksamkeit.

Lieber mit Trainer? Dieses Modul ist Teil unserer Team-Schulungen — mit Übungen, Ihrem eigenen Code und Fragen, die ein Video nicht beantwortet. Mehr erfahren →