React und Next.js einfach erklärt: Komponenten, Props, State

Was React ist, einfach erklärt

Du baust ein Haus aus LEGO. Du knetest es ja nicht aus einem einzigen monolithischen Plastikklumpen. Stein-Fenster, Stein-Tür, Stein-Wand - aus Einzelteilen zusammengesteckt. Einmal ein gutes Stein-Fenster gebaut - und schon steckst du es rein, wo du willst, meinetwegen zwanzig Stück hintereinander.

Genau darum geht’s bei React React - eine Bibliothek, um Interfaces aus wiederverwendbaren Blöcken zusammenzubauen. Der beliebteste Weg, moderne Websites und Apps zu bauen. . Ein Baukasten für Websites. Button, Produktkarte, Header, Formular - jedes Stück Interface ist eine Komponente Komponente - ein eigenständiger Block des Interfaces mit eigener Struktur und Logik. Button, Karte, Menü - das alles sind Komponenten, die man überall einbauen kann. . Die Seite wird aus Komponenten zusammengesteckt, wie ein Haus aus Bausteinen. Langweilig? Dafür funktioniert’s.

Und Next.js Next.js - ein Aufsatz auf React: bringt Seiten, Adressen (Routing), Arbeit auf dem Server und jede Menge fertigen Komfort mit. Der gängigste Weg, eine echte Website mit React zu bauen. ist die LEGO-Box „alles inklusive“. Dieselben React-Bausteine, aber plus fertige Schienen für Seiten, Adressen und Server. Mit nacktem React baust du ein Häuschen. Mit Next.js - gleich eine ganze Stadt mit Straßen und Ampeln.

Warum ein Vibecoder React verstehen sollte

Du bist Vibecoder. Code von Hand schreiben musst du nicht. Aber fast jede Website, die dir der Agent generiert, landet bei React oder Next.js - viel Auswahl gibt’s da nicht. Und wenn du verstehst, wie das tickt, dann:

• gibst du dem Agenten Befehle in seiner Sprache, und er „schwimmt“ nicht;
• verstehst du, warum die Änderung an einem Button plötzlich drei andere zerschossen hat;
• erwischst du den Moment, in dem der Agent eine Wand statt sauberer Bausteine zusammenklatscht, und schickst ihn zum Nachbessern;
• zuckst du nicht mehr zusammen bei Worten wie „Komponente“, „Prop“, „State“ - und die wirst du oft hören, gewöhn dich dran.

Der Unterschied zwischen „der Agent hat eine Website gebaut, die man nicht ändern kann“ und „eine Website gebaut, die man in einer Minute anpasst“ - das ist das Verständnis von drei Dingen: Komponenten, Props, State. Damit fangen wir an.

Die drei Säulen von React: Komponenten, Props, State

Komponenten sind LEGO-Bausteine

Jedes Stück Interface ist ein eigener Baustein. Der Button Kaufen, die Produktkarte, das Menü oben. Eine aus der Praxis hart erkämpfte Regel: Eine Komponente soll klein sein und nur eine Sache machen. Die Karte zeigt das Produkt. Der Button wird geklickt. Punkt. Klatsch keinen „Mega-Baustein“ hin, der auf einen Schlag alles auf der Welt kann - den verfluchst du später selbst.

Props - Daten, die die Komponente von außen bekommt

Die Stein-Karte ist für sich genommen leer. Damit sie ein konkretes Produkt zeigt, gibst du ihr Daten von außen mit - Name, Preis, Bild. Genau diese mitgegebenen Daten sind die Props Props (von properties) - Daten, die eine Komponente von außen, vom Eltern-Element, bekommt. Das sind die „Einstellungen“ des Bausteins: welcher Text gezeigt wird, welches Bild, was beim Klick passiert. .

Eine Stein-Karte plus verschiedene Props ergibt zwanzig verschiedene Produktkarten. Eine Komponente, überall wiederverwendet. Darin liegt die ganze Stärke. Einmal den Baustein geschrieben - und dann hundertmal mit anderem Inhalt benutzt, und jedes Mal sieht er aus wie neu.

State (Zustand) - das Gedächtnis der Komponente selbst

Props kommen von außen. Der State State (Zustand) - das interne Gedächtnis einer Komponente, das sich ändern kann: ob das Menü offen ist oder nicht, was im Feld eingegeben wurde, wie viele Produkte im Warenkorb sind. Ändert sich der State, rendert React von selbst neu, was nötig ist. dagegen ist das, was sich der Baustein über sich selbst merkt und was sich direkt während der Arbeit ändert. Ob das Menü offen oder zu ist. Was du ins Suchfeld getippt hast. Wie viele Stück im Warenkorb liegen.

Die Magie von React in einem Satz: State geändert - der Bildschirm aktualisiert sich von selbst. Du musst nicht von Hand reingreifen und die Seite umschreiben. Produkt in den Warenkorb gelegt - die Zahl oben aktualisiert sich von allein. Praktisch.

Server gegen Browser in Next.js: wo der Code lebt

Genau hier dreht es Anfängern am heftigsten durch. In Next.js gibt’s Code in zwei Sorten, und die darfst du nicht verwechseln.

• Server-Komponenten laufen auf dem Server. Sie können in die Datenbank greifen, geheime Keys lesen, die Seite vorab vorbereiten. Auf Klicks reagieren und State halten können sie aber nicht. Das ist die „Küche“: Da wird das Gericht gekocht, Gäste kommen da nicht rein.
• Client-Komponenten laufen im Browser beim Nutzer. Klicks, Eingaben, Animationen, State - alles ihre Baustelle. Das ist der „Gastraum“: Da wird serviert und mit dem Gast geredet. Man markiert sie mit der speziellen Zeile use client am Anfang der Datei.

Gute und schlechte Komponenten-Struktur: wie man’s erkennt

Der Agent hat dir eine Website gebaut. So erkennst du auf einen Blick die saubere Struktur von der, an die du dich später nicht mehr rantraust.

Beispiel aus dem Leben: Produktkatalog mit Suche

Du bittest den Agenten: „Bau eine Seite mit Produktkatalog und Suche.“ Er spuckt munter eine Datei mit 900 Zeilen aus, in der alles auf einen Haufen geworfen ist. Dann bittest du „ändere die Produktkarte“ - und er zerschießt nebenbei die Suche, weil alles zu einem Knäuel verflochten ist. Und danach flackert und zuckt die Liste bei jedem Tastendruck, als hätte sie einen nervösen Tick. Kommt dir bekannt vor?

Was schiefgelaufen ist:

1. Es gab keine Bausteine - eine Wand, in der alles an allem hängt.
2. Die Suchanfrage flog bei jedem Buchstaben in die Datenbank - daher das Zucken.
3. Die Daten wurden schief geladen, deshalb sprang die Liste bei jedem Update.

Und jetzt dasselbe, aber vernünftig, damit’s sauber wird:

Bau eine Seite mit Produktkatalog und Suche mit React und Next.js. Anforderungen:

Zerleg in kleine Komponenten: Produktkarte, Karten-Grid, Suchfeld. Jede Komponente macht nur eine Sache.
Die Produktkarte bekommt alle Daten über Props und greift selbst nirgends in die Datenbank.
Im State speicher nur das, was sich ändert: den Text in der Suche. Die gefilterte Liste rechne an Ort und Stelle aus, speicher sie nicht separat.
Mach die Suche mit ungefähr einer halben Sekunde Verzögerung, nachdem das Tippen aufhört, nicht bei jedem Buchstaben, damit die Liste nicht zuckt.
Gib jeder Karte in der Liste einen stabilen Key nach der Produkt-id, nicht nach der Nummer.
Zeig mir zuerst die Struktur der Komponenten als Liste und warte auf mein OK, dann schreib den Code.

Warum die Website buggt und flackert: schnelle Diagnose

Bevor du den Agenten anschnauzt, geh die Checkliste durch.

1. Alles flackert und zuckt? Wahrscheinlich werden die Daten bei jedem Mucks geladen oder die Suche fliegt bei jedem Buchstaben in die Datenbank. Verlang eine Verzögerung und ein vernünftiges Laden.
2. Eine Änderung hat etwas anderes zerschossen? Heißt, alles ist in einen Baustein gekippt. Verlang, es in kleinere Komponenten aufzuteilen.
3. Zahlen laufen auseinander (im Warenkorb steht eins, in der Summe was anderes)? Im State wird dupliziert, was an Ort und Stelle ausgerechnet werden sollte. Verlang „ableiten, nicht speichern“.
4. Button reagiert nicht, Formular tot in Next.js? Sieht aus wie eine Server-Komponente, dabei braucht’s eine Client-Komponente (use client).
5. Lange Liste lahmt? Bei Hunderten Elementen - verlang Virtualisierung: Wir rendern nur, was auf dem Bildschirm sichtbar ist, der Rest wartet hinter den Kulissen.

Wir machen es schön: Barrierefreiheit und verständliche Tags

Das Kapitel heißt „Wir machen es schön“, also nimm eine kurze Interface-Regel mit: Bitte den Agenten, ganz normale, verständliche HTML-Tags zu benutzen - ein Button ist button, ein Link ist a, ein Menü ist nav. Das ist nicht Pingeligkeit um der Pingeligkeit willen. Solche Websites funktionieren mit der Tastatur, Screenreader für Blinde verstehen sie und Suchmaschinen gleich mit dazu. Jedes Eingabefeld sollte ein Label haben. Eine schöne Website sind nicht nur angenehme Farben. Schön heißt auch, dass alle sie nutzen können - nicht nur die Maus an einem großen Monitor.

Häufige Anfängerfehler in React

• „Mach alles in einer Datei“ verlangen. Du kriegst eine Wand, die man nicht ändern kann. Verlang Bausteine.
• Denken, Copy-Paste sei Wiederverwendung. Fünf Kopien eines Blocks - das sind fünf Stellen, an denen du denselben Bug fixen musst. Eine Komponente mit Props - eine Stelle.
• Daten im State duplizieren. Summen, Endbeträge, gefilterte Listen - rechne an Ort und Stelle aus, speicher sie nicht separat.
• Server und Browser in Next.js verwechseln. Klicks und Eingabe - Client-Baustein. Secrets und Datenbank - Server-Baustein.
• Die Suche bei jedem Buchstaben jagen. Die Website zuckt und lahmt. Verlang eine Verzögerung.
• Stabile Keys in Listen vergessen. Sonst weiß die Liste bei Änderungen nicht mehr, was wohin gehört, und veranstaltet ein Chaos.