Wie Jordan Walke mit React wiederverwendbare Komponenten, deklarative Views und zustandsgetriebenes Rendering einführte — und damit die moderne Frontend‑Architektur prägte.
Jordan Walke ist ein Software‑Ingenieur, der vor allem dafür bekannt ist, React bei Facebook entwickelt zu haben. Vor React wurden Frontends oft als Seiten und Templates gebaut — mit einer wachsenden Menge an „Glue‑Code“, der HTML, CSS und JavaScript synchron halten sollte. Walke schlug vor, das Modell umzudrehen: statt die UI als Dokumente zu sehen, die man über die Zeit patcht, betrachte sie als Baum kleiner, wiederverwendbarer Komponenten, die man zu größeren Features zusammensetzt.
Das war nicht nur eine neue Bibliothek — es war eine neue Denkweise für UI‑Arbeit. Eine Komponente bündelt ein Stück Oberfläche mit der Logik und dem State, den es braucht, und bietet eine klare Schnittstelle (props) für den Rest der App. Das macht das Erstellen von UI eher zu einem Bauen mit Lego‑Steinen als zum Bearbeiten einer einzelnen, fragilen Seite.
React war deshalb wichtig, weil es Teams half:
Wir gehen die praktischen Ideen durch, die React einflussreich gemacht haben:
Du musst kein Framework‑Experte sein, um mitzukommen. Ziel ist, das mentale Modell klar zu machen — damit du gute React‑Muster erkennst, häufige Missverständnisse vermeidest und die gleichen Prinzipien auch außerhalb von React anwenden kannst.
Vor React bauten viele Teams reiche Oberflächen, indem sie Templates, jQuery‑artige DOM‑Manipulation und eine wachsende Anzahl von „wenn X passiert, aktualisiere Y“‑Regeln zusammenfügten. Das funktionierte — bis die UI unübersichtlich wurde.
Ein gängiges Muster war: Daten holen, HTML rendern und dann Event‑Handler anhängen, die direkt das DOM verändern. Sobald sich der State änderte (ein neuer Eintrag, ein Validierungsfehler, ein Toggle), musste sich jemand an jeden Ort erinnern, der davon abhängt.
Das führte zu Bugs wie:
Mit der Zeit landeten die gleichen Geschäftsregeln in mehreren Handlern: „Button deaktivieren, wenn Feld leer ist“, „nicht gelesene Items hervorheben“, „leeren Zustand anzeigen, wenn keine Ergebnisse vorhanden sind“. Wenn sich Anforderungen änderten, musste man in vielen, nicht zusammenhängenden Dateien die Kopien suchen und anpassen.
Daten lassen sich oft mit wenigen klaren Strukturen modellieren: eine Liste von Beiträgen, ein Benutzerobjekt, ein Satz Filter. UI fügt jedoch Kombinationen hinzu: Laden vs. geladen, Fehler vs. Erfolg, gelesen vs. ungelesen, Bearbeiten vs. Ansicht, gefiltert vs. ungefiltert — häufig gleichzeitig.
Stell dir einen News‑Feed vor:
Ohne eine vorhersehbare Regel wie „die UI ist eine Funktion des State“ koordinierst du viele DOM‑Änderungen, die sich gegenseitig ins Gehege kommen können. Reacts Ziel war, Updates verlässlich zu machen: ändere die Daten/den State, und die UI rendert entsprechend nach — jedes Mal.
Eine Komponente ist ein kleines Stück der Benutzeroberfläche, das du benennen, wiederverwenden und isoliert betrachten kannst. Ganz einfach: eine Komponente nimmt Eingaben und gibt wieder, wie die UI für diese Eingaben aussehen soll.
Dieses „Eingaben → Ausgabe“‑Denken ist der Kern des Komponentenmodells. Anstatt einen Bildschirm als eine große Vorlage zu behandeln, teilst du ihn in gezielte Bausteine — Buttons, Karten, Menüs, Formulare und ganze Abschnitte — und setzt sie zusammen.
In React sind die häufigsten Eingaben props (kurz für „properties“). Props sind Werte, die du an eine Komponente übergibst, um sie zu konfigurieren: Texte, Zahlen, Flags, Event‑Handler oder sogar andere UI.
Die Ausgabe ist die UI, die die Komponente rendert. Wenn sich die Props ändern, kann die Komponente eine andere Ausgabe liefern — ohne dass du manuell suchen musst, wo das DOM aktualisiert werden soll.
Zum Beispiel könnte eine Button‑Komponente Props wie label, disabled und onClick erhalten. Eine UserCard könnte name, avatarUrl und status bekommen. Die Schnittstelle einer Komponente (ihre Props) kannst du genauso lesen wie eine Produktspezifikation: „Was braucht diese UI, um korrekt zu rendern?“
Die Aufteilung in Komponenten zahlt sich schnell aus:
Modal, Input oder Dropdown kann auf mehreren Seiten auftauchen.Das ist ein großer Bruch mit dem Kopieren und Anpassen von Markup pro Seite. Komponenten machen Duplikate unnötig — und irgendwann inakzeptabel.
React ermutigt dazu, UI so zu entwerfen, wie man ein System gestaltet: als zusammensetzbare Teile. Eine „Checkout‑Seite“ wird zum Komponentenbaum — CheckoutPage enthält OrderSummary, ShippingForm und PaymentMethod. Jeder Teil hat klare Eingaben und eine klare Verantwortung.
Dieser Perspektivwechsel — zuerst in Komponenten zu denken — ist ein Hauptgrund, warum React die Frontend‑Architektur veränderte. Es gab Teams eine gemeinsame Einheit für Design und Entwicklung: die Komponente.
Reacts größte gedankliche Veränderung ist die deklarative UI: du beschreibst, wie die Oberfläche für einen gegebenen Zustand aussehen soll, und React kümmert sich darum, die Seite zu aktualisieren, wenn sich dieser Zustand ändert.
Statt Elemente zu suchen, Text zu ändern, Klassen umzuschalten und das DOM synchron zu halten, konzentrierst du dich auf die „Form“ der UI. Wenn sich Daten ändern, wird die UI neu beschrieben, und React bestimmt die minimale Menge an Änderungen, die nötig sind.
JSX ist eine praktische Möglichkeit, die Struktur einer Komponente in einer HTML‑ähnlichen Syntax in JavaScript zu schreiben. Es ist keine völlig neue Templating‑Sprache, die du neu lernen musst; es ist eine Kurzschrift dafür, „diese Komponente rendert diesen Elementbaum“.
Der entscheidende Vorteil ist, dass Markup und Logik, die entscheiden, was angezeigt wird, zusammenleben — das macht Komponenten einfacher isoliert zu verstehen.
Imperativer Code konzentriert sich darauf, wie man die UI aktualisiert Schritt für Schritt:
// Imperativ: das DOM manuell synchron halten
function setLoggedIn(isLoggedIn) {
const el = document.querySelector('#status');
el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
el.classList.toggle('ok', isLoggedIn);
el.classList.toggle('warn', !isLoggedIn);
}
Deklarativer Code konzentriert sich darauf, wie die UI für den aktuellen Zustand aussehen soll:
function Status({ isLoggedIn }) {
return (
\u003cp className={isLoggedIn ? 'ok' : 'warn'}\u003e
{isLoggedIn ? 'Welcome back' : 'Please sign in'}
\u003c/p\u003e
);
}
Weil Rendering als reine Beschreibung ausgedrückt wird, sind Komponenten oft lesbarer, leichter zu reviewen und einfacher zu refactoren. Designer, produktorientierte Entwickler und neue Teammitglieder können JSX oft nachvollziehen, ohne Event‑Handler und DOM‑Mutationen suchen zu müssen.
Diese Klarheit verbessert die Zusammenarbeit: UI‑Entscheidungen sind an einem Ort sichtbar, und Änderungen erzeugen weniger versteckte Nebenwirkungen an anderer Stelle der Oberfläche.
„State“ ist einfach die Datenmenge, die sich ändern kann, während ein Benutzer mit deiner UI interagiert. Das kann der aktuelle Text in einer Sucheingabe sein, ob ein Menü offen ist, die Items im Warenkorb oder das Ergebnis einer Netzwerkabfrage. Wenn es sich ändern kann und der Bildschirm das widerspiegeln sollte, ist es State.
Reacts Kernidee ist, Rendering als Folge des States zu behandeln, nicht als Sequenz manueller DOM‑Schritte. Du beschreibst, wie die UI für einen gegebenen State aussehen soll. Wenn State aktualisiert wird, rendert React die relevanten Teile neu.
Dieses mentale Modell unterscheidet sich von „Finde ein Element, aktualisiere seinen Text, schalte diese Klasse um“. Stattdessen aktualisierst du den State, und die UI aktualisiert sich natürlich, weil sie von diesem State abgeleitet ist.
Einbahn‑Datenfluss bedeutet, dass Daten in eine Richtung fließen:
props an Kinder weiter.Das reduziert Überraschungen, weil du den Pfad eines Updates verfolgen kannst: ein Ereignis passiert, State ändert sich an einer Stelle und die UI rendert ausgehend von diesem neuen State. Es gibt weniger Unklarheit „wer hat diesen Wert geändert?".
function Counter() {
const [count, setCount] = React.useState(0);
return (
\u003cdiv\u003e
\u003cp\u003eCount: {count}\u003c/p\u003e
\u003cbutton onClick={() =\u003e setCount(count + 1)}\u003eAdd\u003c/button\u003e
\u003c/div\u003e
);
}
Hier ist count State. Ein Klick auf den Button aktualisiert den State mit setCount. React rendert dann neu und der Absatz zeigt die neue Zahl. Du bearbeitest niemals direkt das DOM.
Dasselbe Muster skaliert auf Listenfilterung (State = Filtertext, UI = gefilterte Items) oder Formularvalidierung (State = Feldwerte und Fehler, UI = Meldungen). Daten ändern sich zuerst; die Ansicht ist nur das Ergebnis.
Reacts Kernidee ist nicht „die Seite schneller neu zeichnen“. Sie lautet: Behandle die UI als Ergebnis des States und wenn sich der State ändert, vergleiche was du jetzt willst mit was vorher war — und aktualisiere nur das, was sich wirklich geändert hat.
Wenn sich der State oder die props einer Komponente ändern, ruft React deine Komponenten erneut auf, um eine neue Beschreibung der UI zu erzeugen. Denk daran wie an zwei Snapshots:
Statt das DOM zu leeren und neu aufzubauen, versucht React, die kleinste Menge an DOM‑Operationen zu berechnen, die nötig ist, um von A nach B zu kommen.
Der „virtuelle DOM“ ist einfach Reacts in‑memory Repräsentation der UI — ein leichtgewichtiger Baum von Elementen (und Komponenten‑Ausgaben), der beschreibt, was auf dem Bildschirm stehen sollte. Es ist kein zweiter Browser oder ein schnelleres DOM. Es ist eine Datenstruktur, die React effizient inspizieren und vergleichen kann.
Reconciliation ist der Prozess, herauszufinden, was sich zwischen dem vorherigen virtuellen Baum und dem neuen geändert hat. React nutzt Heuristiken, z. B.:
<div> ist nicht gleich einem <span>)keys helfen, Items in Listen zu identifizieren, sodass React „dasselbe Item“ zwischen Rendern zuordnen kannSobald React weiß, was sich geändert hat, wendet es gezielte Updates auf das reale DOM an.
Das ist kein Zauber. Performance hängt von den Mustern ab: stabile keys, vermeiden unnötiger Re‑Renders, kleine Komponentenarbeit und keine teuren Berechnungen während des Renderns. React kann den DOM‑Churn reduzieren, aber deine Komponentenstruktur und dein Datenfluss bestimmen letztlich, wie flüssig die App wirkt.
Reacts größter Skalierungstrick ist nicht ein Feature oder Add‑on — es ist Komposition: Bildschirme durch Verschachtelung von Komponenten bauen, Daten über props weiterreichen und children nutzen, damit eine Komponente andere UI „umwickeln“ kann.
Wenn Teams Komposition ernst nehmen, hören sie auf, in Einmalseiten zu denken, und beginnen, in kleinen, verlässlichen Teilen zu denken, die sich ohne komplette Neuschreibung umordnen lassen.
childrenVerschachtelung spiegelt die visuelle Struktur wider: eine Seite enthält Abschnitte, die Karten enthalten, die Buttons enthalten. props sind die Konfigurationsknöpfe (Text, States, Callbacks). children erlaubt Komponenten, Struktur bereitzustellen, während Aufrufer entscheiden, was hineinkommt.
Ein gutes mentales Modell: props passen an, children füllen, Verschachtelung setzt zusammen.
Layout‑Komponenten definieren Struktur und Abstände ohne Geschäftslogik zu besitzen. Beispiele: Page, SidebarLayout, Stack, Modal. Sie nutzen oft children, sodass dasselbe Layout viele Screens einhüllen kann.
Wiederverwendbare Eingaben standardisieren Formularverhalten und Styling: TextField, Select, DatePicker. Anstatt Labels, Fehlerzustände und Validierung auf vielen Seiten zu duplizieren, zentralisierst du diese Entscheidungen und stellst eine einfache props‑API bereit.
Listen‑ und Item‑Komponenten halten wiederkehrende UI vorhersehbar. Eine übliche Aufteilung ist ItemList (Fetching, Pagination, Empty States) plus ItemRow (wie ein einzelnes Element aussieht). So lässt sich das Rendern ändern, ohne die Datenbehandlung zu brechen.
Hooks sind der moderne Weg, zustandsbehaftetes Verhalten (Toggling, Formularzustand, Fetching) über Komponenten hinweg wiederzuverwenden, ohne sie in die gleiche UI‑Form zwingen zu müssen. Diese Trennung hilft Teams, Design zu entwickeln, während die Logik konsistent bleibt.
Komposition ist der Grund, warum Designsysteme konsistent bleiben: Komponenten werden zu den „zugelassenen“ Bausteinen, Layouts definieren Regeln für Abstände und Hierarchie. Wenn das System aktualisiert wird — Farben, Typografie, Interaktionszustände — übernehmen Produkte die Verbesserungen mit weniger manuellen Änderungen.
State ist einfach „Daten, die sich ändern können“. In React ist entscheidend, wo dieser State lebt.
Lokaler State gehört zu einer einzelnen Komponente (oder einem kleinen Widget) und muss sonst nirgends gelesen werden. Denk an: ob ein Dropdown offen ist, den aktuellen Wert eines Inputs oder welche Registerkarte gewählt ist.
Lokalen State zu behalten reduziert Koordination und macht Komponenten leichter wiederverwendbar. Faustregel: Wenn nur eine Komponente es braucht, exportiere es nicht in die ganze App.
Geteilter App‑State ist Daten, über die mehrere Teile der UI übereinstimmen müssen. Beispiele:
Wenn mehrere Komponenten dieselbe Informationsquelle brauchen, führt Duplikation zu Inkonsistenzen („Header sagt 3 Items, Warenkorbseite sagt 2“).
State hochziehen: verschiebe den State zum nächsten gemeinsamen Parent und gib ihn per props nach unten weiter. Oft die einfachste Option und hält Datenfluss explizit.
Context: nützlich, wenn viele Komponenten denselben Wert brauchen, ohne Prop‑Drilling (Theme, Auth). Context eignet sich für relativ stabile, app‑weite Belange.
Externe Stores: wenn State komplex wird (häufige Updates, abgeleitete Daten, workflows über Seiten hinweg), kann ein dediziertes Store Logik und Updates zentralisieren.
Reacts Einbahn‑Datenfluss wirkt am besten, wenn es einen klaren Eigentümer für jedes Stück State gibt. Strebe eine Single Source of Truth an, und leite alles Weitere (Counts, Totale, gefilterte Listen) von diesem State ab statt Duplikate zu speichern.
Reacts größter Alltagsgewinn ist nicht ein cleverer Rendering‑Trick — es sind die Komponentengrenzen, die UI‑Arbeit in kleinere, sichere Änderungen zerlegen. Wenn eine Komponente eine klare Verantwortung und eine stabile öffentliche Oberfläche (props) hat, können Teams das Innere refactoren, ohne die gesamte App umzuschreiben. Diese Stabilität erleichtert Code‑Reviews, reduziert unbeabsichtigte Fehler und hilft neuen Teammitgliedern, zu verstehen, wo Änderungen vorgenommen werden sollten.
Ein nützliches Modell ist: gegeben Props und State, sollte eine Komponente vorhersagbar die UI beschreiben. Auch wenn Effekte und Browser‑APIs existieren, kann ein Großteil der Komponentenlogik deterministisch bleiben. Deshalb konzentriert sich wartbares React‑Testing oft auf Verhalten und Ausgabe:
Barrierefreiheitsprüfungen passen hier gut rein: wenn du mit Roles und zugänglichen Namen testest, findest du fehlende Labels, kaputte Fokuszustände und inkonsistente Semantik früh. Konsistenzprüfungen (Linting, Formatierung, Design‑System‑Nutzung) verstärken dieselbe Idee: vorhersehbare Komponenten sind leichter zu warten.
Wenn Komponenten eine kleine props‑API nach außen zeigen und Implementierungsdetails verbergen, können mehrere Personen parallel arbeiten — eine passt Styling an, eine andere ändert das Datenfetching, eine dritte aktualisiert Tests — ohne sich gegenseitig zu behindern.
props bilden eine kleine, stabile API (vermeide "kitchen sink"‑Props).React‑Performance dreht sich weniger um „React ist langsam“ und mehr darum, wie viel Arbeit deine App dem Browser aufbürdet. Die schnellste UI macht am wenigsten: weniger DOM‑Knoten, weniger Layout/Reflow, weniger teure Berechnungen und weniger Netzwerk‑Runden.
Ein häufiges Problem sind unnötige Re‑Renders: eine kleine State‑Änderung lässt einen großen Subtree neu rendern, weil der State zu hoch liegt oder weil Props bei jedem Render neue Identitäten bekommen (neue Objekte/Funktionen inline erzeugt).
Ein weiterer Klassiker sind schwere Listen — Hunderte oder Tausende Reihen mit Bildern, Formatierung und Event‑Handlern. Auch wenn jede Reihe „billig“ ist, summiert sich die Arbeit und Scrollen wird ruckelig, weil der Browser nicht mehr mithält.
Fang bei der Struktur an:
Konzentriere dich außerdem auf das, was Nutzer fühlen: Eingabeverzögerungen reduzieren, First Meaningful Paint beschleunigen und Interaktionen flüssig halten. Eine 20ms‑Verbesserung in einer häufig genutzten Interaktion kann wichtiger sein als 200ms an einer seltenen Seite zu sparen.
Abgeleiteter State ist Daten, die du aus anderem State/Props berechnen kannst (z. B. fullName aus firstName + lastName oder gefilterte Items aus einer Liste + Query). Ihn zu speichern erzeugt oft Bugs: du hast jetzt zwei Wahrheitsquellen, die auseinanderlaufen können.
Bevorzuge Berechnung ab Render‑Zeit (oder Memoisierung, wenn teuer). Speichere nur, was sich nicht ableiten lässt — typischerweise Benutzereingaben, Serverantworten und UI‑Intentionen (z. B. „ist das Panel offen?“).
React hat nicht nur eine schönere Art eingeführt, UI zu schreiben; es veränderte, wie Teams Frontends strukturieren, teilen und warten. Bevor Komponenten das Standarddenken wurden, behandelten viele Projekte UI als Seiten mit verstreuten Skripten und Templates. Mit React wurde die Komponente zunehmend zur Einheit der Architektur: ein UI‑Stück mit klarer API (props) und vorhersehbarem Verhalten.
React passte gut zur Entstehung von Single‑Page‑Applications (SPAs). Wenn Rendering vom State gesteuert wird, wird die Seite nicht mehr als serverseitiges Template geliefert, sondern als Komposition von Komponenten plus clientseitigem Routing. Das führte dazu, Code nach Feature‑Bereichen und wiederverwendbaren UI‑Teilen zu strukturieren statt nach separaten HTML‑Dateien.
Sobald UI aus wiederverwendbaren Teilen besteht, liegt es nahe, diese zu standardisieren. Viele Organisationen wechselten vom Copy‑Pasten von Markup zu Komponentenbibliotheken: Buttons, Form Controls, Modals, Layout‑Primitiven und Muster wie Empty States. Mit der Zeit wurden diese Bibliotheken oft zu Designsystemen — geteilte Komponenten plus Richtlinien — sodass Teams konsistente Erlebnisse ausliefern konnten, ohne UI für jede Seite neu zu erfinden.
Komponenten brachten einheitliche Benennungen. Wenn alle von <Button>, <Tooltip> oder <CheckoutSummary> sprechen, werden Gespräche konkreter: Es geht um Verhalten und Grenzen, nicht nur um Aussehen. Dieses geteilte Vokabular hilft neuen Teammitgliedern beim Onboarding, weil das System durch den Code entdeckbar ist.
Reacts Erfolg beeinflusste, wie die gesamte Frontend‑Community über UI nachdachte: komponentenorientierte Entwicklung, deklaratives Rendering und vorhersehbarer Datenfluss wurden zu allgemeinen Erwartungen. Andere Frameworks übernahmen ähnliche Ideen, auch wenn die Implementierungen unterschiedlich sind — weil sich die Praktiken in echten Teams als leichter skalierbar erwiesen.
React hat seinen Ruf dadurch verdient, komplexe UIs leichter entwickelbar zu machen — aber es ist nicht kostenlos. Die Kenntnis der Kompromisse hilft Teams, React aus den richtigen Gründen einzuführen und Cargo‑Kult zu vermeiden.
React hat eine Lernkurve: Komponenten, Hooks und mentale Modelle wie State‑Updates und Effekte brauchen Zeit. Modernes React setzt auch meist Build‑Tooling voraus (Bundling, Linting, oft TypeScript), was Setup und Pflegeaufwand bedeutet. Schließlich bringt React Abstraktionsschichten mit sich — Komponentenbibliotheken, Routing, Datenfetch‑Muster — die nützlich sein können, aber auch Komplexität verbergen, bis etwas kaputtgeht.
„React ist nur die View.“ Theoretisch ja; praktisch formt React stark deine Architektur. Komponenten‑Grenzen, State‑Ownership und Kompositionsmuster beeinflussen Datenfluss und Organisation.
„Der virtuelle DOM ist immer schneller.“ Der virtuelle DOM geht vor allem um vorhersehbare Updates und Developer‑Ergonomie. React kann schnell sein, aber Performance hängt von Render‑Mustern, Memoisierung, Listengrößen und dem Vermeiden unnötiger Re‑Renders ab.
React passt gut zu Apps mit vielen interaktiven States, langlebigen Codebasen und mehreren Entwicklern, die parallel arbeiten. Für eine größtenteils statische Marketingseite oder ein paar kleine Widgets sind einfachere Optionen (server‑gerenderte Templates, leichtes JS oder minimale Frameworks) oft leichter zu liefern und zu warten.
Wenn ihr eine React‑App prototypen und diese Ideen schnell validieren wollt (Komponentengrenzen, State‑Ownership, Kompositionsmuster), kann ein vibe‑coding Workflow helfen. Zum Beispiel lässt Koder.ai dich Features im Chat beschreiben und erzeugt ein funktionierendes React‑Frontend plus Go/PostgreSQL‑Backend, dann iterierst du mit Snapshots/Rollback und exportierst den Source Code, wenn du bereit bist, manuell zu übernehmen. Das ist ein praktischer Weg, Architekturentscheidungen an einem echten Feature zu testen, bevor du dich voll festlegst.
Nächster Schritt: Prototypet ein reales Feature, messt Komplexität und Team‑Velocity und skaliert Muster bewusst — nicht automatisch.
Jordan Walke hat React bei Facebook entwickelt. React war wichtig, weil es fragile, manuelle DOM‑“Glue‑Code”-Muster durch ein komponentenbasiertes, zustandsgetriebenes Modell ersetzte — dadurch wurden komplexe Oberflächen leichter zu skalieren, zu debuggen und zu warten.
Templates verteilen UI‑Regeln oft über Markup und verstreute Event‑Handler ("wenn X passiert, aktualisiere Y"). Komponenten bündeln UI und Logik hinter einer kleinen Schnittstelle (props), sodass Features aus vorhersehbaren Bausteinen zusammengesetzt werden können, anstatt Seiten nachträglich zu flicken.
Eine Komponente ist eine wiederverwendbare Einheit, die Eingaben (meist props) annimmt und daraus beschreibt, wie die UI aussehen soll.
Praktische Regeln:
props‑APIprops sind die Eingaben, die du einer Komponente gibst, um sie zu konfigurieren (Text, Flags, Callbacks oder andere UI). Betrachte props als Vertrag:
disabled, onSubmit) statt vager "Alles‑rein"‑ObjekteDeklarative UI bedeutet, dass du beschreibst, was die Oberfläche für einen gegebenen Zustand sein soll, nicht wie man Schritt für Schritt das DOM ändert.
Praktisch heißt das:
JSX ist eine Syntax, mit der du die UI‑Struktur in einer HTML‑ähnlichen Schreibweise innerhalb von JavaScript beschreiben kannst. Es ist nützlich, weil Rendering‑Logik und das kontrollierte Markup zusammenstehen, wodurch eine Komponente leichter zu lesen und zu prüfen ist.
State ist jede Information, die sich im Laufe der Zeit ändern kann und die das zu sehende UI beeinflusst (Eingabetext, Ladezustand, Warenkorbinhalte etc.).
Praktische Faustregel: Speicher die Quelle der Wahrheit (Benutzereingaben, Serverantworten, UI‑Intentionen) und leite alles andere (Counts, gefilterte Listen) davon ab.
Einbahn‑Datenfluss bedeutet:
props nach untenDas hilft beim Debuggen, weil sich Updates linear nachverfolgen lassen: Ereignis → State‑Änderung → Re‑Render.
Der virtuelle DOM ist Reacts In‑Memory‑Repräsentation der UI. Wenn sich State oder props ändern, vergleicht React die vorherige UI‑Beschreibung mit der neuen und aktualisiert das reale DOM nur dort, wo es nötig ist.
Um typische Probleme zu vermeiden:
key‑Werte für ListeneinträgeStarte einfach und skaliere nur bei Bedarf:
Bevorzuge eine einzige Quelle der Wahrheit und leite den Rest ab, um Inkonsistenzen zu vermeiden.
props natürlich die Ausgabe ändern (statt manuell das DOM zu mutieren)