React machte komponentenbasierte UI, deklaratives Rendering und zustandsgesteuerte Ansichten populär — und verschob Teams von seitenzentriertem Code hin zu wiederverwendbaren Systemen und Mustern.
React brachte nicht nur eine neue Bibliothek—es veränderte, was Teams meinen, wenn sie „Frontend-Architektur“ sagen. Praktisch ist Frontend-Architektur die Menge von Entscheidungen, die ein UI-Codebase auf großer Skala verständlich halten: wie du die UI in Teile aufteilst, wie Daten zwischen ihnen fließen, wo State lebt, wie du Nebeneffekte (z. B. Datenabruf) handhabst und wie du das Ergebnis testbar und konsistent im Team hältst.
Component Thinking ist, jedes UI-Stück als kleine, wiederverwendbare Einheit zu behandeln, die ihr Rendering besitzt und sich mit anderen Einheiten zu ganzen Seiten zusammensetzen lässt.
Bevor React populär wurde, waren viele Projekte um Seiten und DOM-Manipulation organisiert: „Finde dieses Element, ändere seinen Text, toggel diese Klasse.“ React veränderte die Default-Vorstellung:
Diese Ideen veränderten die tägliche Arbeit. Code-Reviews fragten plötzlich „Wem gehört dieser State?“ statt „Welchen Selektor hast du benutzt?“ Designer und Entwickler konnten sich auf ein gemeinsames Komponenten-Vokabular einigen, und Teams konnten Bibliotheken von UI-Bausteinen wachsen lassen, ohne komplette Seiten neu zu schreiben.
Selbst wenn ein Team später auf ein anderes Framework wechselt, bleiben viele React-geprägte Gewohnheiten: komponentenbasierte Architektur, deklaratives Rendering, vorhersehbarer Datenfluss und eine Präferenz für wiederverwendbare Designsystem-Komponenten statt einmaligem Page-Code. React machte diese Muster normal—und das beeinflusste das gesamte Frontend-Ökosystem.
Vor React bauten viele Teams Interfaces rund um Seiten, nicht um wiederverwendbare UI-Einheiten. Ein häufiges Setup waren serverseitig gerenderte Templates (PHP, Rails, Django, JSP usw.), die HTML erzeugten, mit jQuery obendrauf für Interaktivität.
Du renderst eine Seite und „aktivierst“ sie dann mit Skripten: Datepicker, Modal-Plugins, Formular-Validatoren, Karussells—jeweils mit eigenen Markup-Erwartungen und Event-Hooks.
Der Code sah oft so aus: finde ein DOM-Element, hänge einen Handler an, verändere das DOM und hoffe, dass nichts anderes kaputtgeht. Mit wachsender UI wurde das DOM selbst zur stillen „Quelle der Wahrheit“.
UI-Verhalten lebte selten an einem Ort. Es war aufgeteilt zwischen:
Eine einzelne Komponente—z. B. eine Checkout-Übersicht—konnte teilweise auf dem Server aufgebaut, teilweise per AJAX aktualisiert und teilweise von einem Plugin kontrolliert werden.
Dieser Ansatz funktionierte für kleine Verbesserungen, führte aber zu wiederkehrenden Problemen:
Frameworks wie Backbone, AngularJS und Ember versuchten, mit Modellen, Views und Routing Struktur hereinzubringen—oft ein großer Schritt nach vorne. Viele Teams mischten jedoch weiterhin Muster, sodass eine Lücke für einen einfacheren Weg blieb, UIs als wiederholbare Einheiten zu bauen.
React’s wichtigste Verschiebung ist einfach zu sagen und überraschend mächtig in der Praxis: die UI ist eine Funktion des State. Statt das DOM als „Quelle der Wahrheit“ zu behandeln und es manuell synchron zu halten, behandelst du deine Daten als Quelle der Wahrheit und lässt die UI das Ergebnis sein.
State ist einfach die aktuellen Daten, von denen dein Screen abhängt: ob ein Menü offen ist, was in einem Formularfeld steht, welche Items in einer Liste sind, welcher Filter ausgewählt ist.
Wenn sich State ändert, musst du nicht die Seite durchsuchen, um mehrere DOM-Knoten zu aktualisieren. Du änderst den State, und die UI rendert neu, um dazu zu passen.
Traditioneller DOM-zentrierter Code endet oft mit verstreuter Update-Logik:
Mit Reacts Modell werden diese „Updates“ zu Bedingungen im Render-Output. Der Screen wird zu einer lesbaren Beschreibung dessen, was für einen gegebenen State sichtbar sein soll.
function ShoppingList() {
const [items, setItems] = useState([]);
const [text, setText] = useState("");
const add = () => setItems([...items, text.trim()]).then(() => setText(""));
return (
<section>
<form onSubmit={(e) => { e.preventDefault(); add(); }}>
<input value={text} onChange={(e) => setText(e.target.value)} />
<button disabled={!text.trim()}>Add</button>
</form>
{items.length === 0 ? <p>No items yet.</p> : (
<ul>{items.map((x, i) => <li key={i}>{x}</li>)}</ul>
)}
</section>
);
}
Beachte, wie die Leermeldung, der deaktivierte Button und der Listeninhalt alle von items und text abgeleitet sind. Das ist der architektonische Gewinn: Datenform und UI-Struktur stimmen überein, was Screens leichter verständlich, testbar und erweiterbar macht.
React machte „Komponente“ zur Standard-Einheit der UI-Arbeit: ein kleines, wiederverwendbares Stück, das Markup, Verhalten und Styling-Hooks hinter einer klaren Schnittstelle bündelt.
Statt HTML-Templates, Event-Listener und CSS-Selektoren über unzusammenhängende Dateien zu verteilen, bringt eine Komponente die beweglichen Teile zusammen. Das heißt nicht, dass alles in einer Datei leben muss—aber der Code wird um das organisiert, was der Benutzer sieht und tut, nicht um die DOM-API.
Eine praktische Komponente beinhaltet üblicherweise:
Die wichtige Verschiebung ist, dass du nicht mehr in Begriffen wie „aktualisiere dieses div“ denkst, sondern in Begriffen wie „render den Button im deaktivierten Zustand“.
Wenn eine Komponente nur eine kleine Menge an Props (Inputs) und Events/Callbacks (Outputs) nach außen zeigt, lässt sich ihr Inneres ändern, ohne den Rest der App zu brechen. Teams können bestimmte Komponenten oder Verzeichnisse (z. B. „checkout UI“) verantworten und sie mit Vertrauen verbessern.
Kapselung reduziert auch unbeabsichtigte Kopplung: weniger globale Selektoren, weniger file-übergreifende Nebeneffekte, weniger „warum funktioniert dieser Click-Handler nicht mehr?“-Überraschungen.
Sobald Komponenten die Hauptbausteine wurden, fing Code an, das Produkt zu spiegeln:
Das erleichtert UI-Diskussionen: Designer, PMs und Entwickler sprechen über dieselben „Dinge“.
Component Thinking verschob viele Codebasen zu feature- oder domänenbasierter Organisation (z. B. /checkout/components/CheckoutForm) und zu gemeinsamen UI-Bibliotheken (oft /ui/Button). Diese Struktur skaliert besser als nur seitenorientierte Ordner, wenn Features wachsen, und bereitet Designsysteme vor.
Reacts Rendering-Stil wird oft als deklarativ beschrieben: du beschreibst, wie die UI in einer bestimmten Situation aussehen soll, und React findet heraus, wie der Browser diese Vorgabe umsetzt.
In älteren DOM-first Ansätzen schrieb man meist Schritt-für-Schritt-Anweisungen:
Beim deklarativen Rendering drückst du stattdessen das Ergebnis aus:
Wenn der Nutzer eingeloggt ist, zeige seinen Namen. Wenn nicht, zeige einen „Sign in“-Button.
Dieser Wechsel reduziert die Menge an „UI-Verwaltungsarbeit“, die du tun musst. Du verfolgst nicht ständig, welche Elemente existieren und was aktualisiert werden muss—du konzentrierst dich auf die Zustände, die deine App haben kann.
JSX ist im Grunde eine bequeme Weise, UI-Struktur nahe an der Logik zu schreiben, die sie steuert. Statt Template-Dateien und Logikdateien zu trennen und zwischen ihnen zu springen, kannst du zusammengehörige Teile nahe beieinander halten: markup-ähnliche Struktur, Bedingungen, kleine Formatierungsentscheidungen und Event-Handler.
Diese Co-Lokation ist ein großer Grund, warum Reacts Komponentenmodell praktisch erschien. Eine Komponente ist nicht nur ein HTML-Stück oder ein Bündel JavaScript—sie ist eine Einheit von UI-Verhalten.
Ein üblicher Einwand ist, dass JSX HTML und JavaScript mischt, was wie ein Rückschritt klingen kann. JSX ist aber kein echtes HTML—es ist Syntax, die JavaScript-Aufrufe erzeugt. Wichtiger noch: React vermischt nicht so sehr Technologien wie vielmehr Dinge, die zusammen geändert werden. Wenn Logik und UI-Struktur eng verknüpft sind (z. B. „zeige Fehlermeldung nur wenn Validierung fehlschlägt“), kann es klarer sein, sie an einem Ort zu halten, statt Regeln über separate Dateien zu verstreuen.
JSX machte React zugänglich, aber das Grundkonzept geht darüber hinaus. Du kannst React ohne JSX schreiben, und andere Frameworks verwenden ebenfalls deklaratives Rendering mit anderen Template-Syntaxen. Die dauerhafte Auswirkung ist die Denkweise: behandle UI als Funktion des State und lass das Framework die Mechanik übernehmen, den Bildschirm synchron zu halten.
Vor React war eine häufige Fehlerquelle simpel: die Daten änderten sich, aber die UI nicht. Entwickler holten neue Daten, fanden dann manuell die richtigen DOM-Knoten, aktualisierten Text, toggelten Klassen, fü gten/entfernten Elemente und versuchten, all das konsistent über Randfälle hinweg zu halten. Über Zeit wurde die „Update-Logik“ oft komplizierter als die UI selbst.
React verändert den Workflow: du befiehlst dem Browser nicht, wie er die Seite ändern soll. Du beschreibst, wie die UI für einen State aussehen soll, und React ermittelt, wie das echte DOM am kleinsten angepasst wird, um dazu zu passen.
Reconciliation ist der Prozess, in dem React vergleicht, was du zuletzt gerendert hast, mit dem, was du jetzt renderst, und dann die minimale Menge an Änderungen am Browser-DOM vornimmt.
Wichtig ist nicht, dass React ein „Virtual DOM“ als magischen Performance-Trick nutzt. Wichtig ist, dass React dir ein vorhersehbares Modell gibt:
Diese Vorhersagbarkeit verbessert den Entwickler-Workflow: weniger manuelle DOM-Updates, weniger inkonsistente Zustände und UI-Updates, die im gesamten Projekt nach den gleichen Regeln ablaufen.
Beim Rendern von Listen braucht React eine stabile Methode, „alte Items“ mit „neuen Items“ während der Reconciliation abzugleichen. Dafür sind key-Props da.
{todos.map(todo => (
<TodoItem key={todo.id} todo={todo} />
))}
Verwende Keys, die stabil und eindeutig sind (z. B. IDs). Vermeide Array-Indizes, wenn Elemente neu geordnet, eingefügt oder gelöscht werden können — sonst kann React die falsche Komponente wiederverwenden und überraschendes Verhalten (z. B. falsche Input-Werte) erzeugen.
Einer der größten architektonischen Unterschiede von React ist, dass Daten in eine Richtung fließen: von Eltern zu Kindern. Statt allen Teilen der UI zu erlauben, in andere Teile „hineinzufassen“ und globalen State zu mutieren, ermutigt React dazu, Updates als explizite Ereignisse nach oben zu schicken, während die resultierenden Daten nach unten fließen.
function Parent() {
const [count, setCount] = React.useState(0);
return (
<Counter
value={count}
onIncrement={() => setCount(c => c + 1)}
/>
);
}
function Counter({ value, onIncrement }) {
return (
<button onClick={onIncrement}>
Clicks: {value}
</button>
);
}
Beachte, was nicht passiert: Counter ändert count nicht direkt. Es erhält value (Daten) und onIncrement (eine Möglichkeit, um Änderung zu bitten). Diese Trennung ist der Kern des mentalen Modells.
Dieses Muster macht Grenzen offensichtlich: „Wer besitzt diese Daten?“ wird meist mit „der nächstgelegene gemeinsame Elternteil“ beantwortet. Wenn etwas unerwartet ändert, verfolgst du die Ursache oft zur Stelle, wo der State verwaltet wird—nicht durch ein Netz versteckter Mutationen.
Diese Unterscheidung hilft Teams zu entscheiden, wo Logik hingehört und verhindert versehentliche Kopplung.
Komponenten, die über Props gesteuert werden, sind leichter wiederzuverwenden, weil sie nicht von globalen Variablen oder DOM-Abfragen abhängen. Sie sind auch einfacher zu testen: du rendert sie mit bestimmten Props und prüfst das Ergebnis, während zustandsbehaftetes Verhalten dort getestet wird, wo der State verwaltet wird.
React schob Teams weg von Klassensystemen für UI und hin zum Zusammensetzen kleiner, fokussierter Teile. Statt eine Basis-Button-Klasse in zehn Varianten zu vererben, kombinierst du typischerweise Verhalten und Darstellung durch Zusammenfügen von Komponenten.
Ein häufiges Muster sind Layout-Komponenten, die nichts über die Daten wissen, die sie enthalten:
PageShell für Header/Sidebar/FooterStack / Grid für Abstände und AusrichtungCard für konsistente EinrahmungDiese Komponenten akzeptieren children, sodass die Seite entscheidet, was hinein gehört, nicht das Layout.
Leichte Wrapper wie RequireAuth oder ErrorBoundary fügen ein Anliegen um das, was sie umschließen, hinzu, ohne das Innenleben der umschlossenen Komponente zu verändern.
Wenn mehr Kontrolle als „nur children“ nötig ist, verwenden Teams häufig slot-ähnliche Props:
Modal mit title, footer und childrenTable mit renderRow oder emptyStateDas hält Komponenten flexibel, ohne die API aufzublähen.
Tiefe Vererbungshierarchien beginnen oft mit guten Absichten („wir nutzen die Basis wieder“), werden aber schwer zu pflegen, weil:
Hooks machten Komposition noch praktischer. Ein Custom Hook wie useDebouncedValue oder usePermissions erlaubt mehreren Feature-Komponenten, Logik zu teilen, ohne UI zu teilen. Kombiniert mit gemeinsamen UI-Primitiven (Buttons, Inputs, Typografie) und Feature-Komponenten (CheckoutSummary, InviteUserForm) erhältst du Wiederverwendung, die verständlich bleibt, wenn die App wächst.
React machte es natürlich, mit lokalem Komponenten-State zu beginnen: ein Formularfeldwert, ein offenes Dropdown, ein Lade-Spinner. Das funktioniert gut—bis die App wächst und mehrere Teile der UI synchron bleiben müssen.
Mit wachsendem Funktionsumfang müssen Daten oft von Komponenten gelesen oder aktualisiert werden, die nicht in direkter Eltern-Kind-Beziehung stehen. „Props durchreichen“ wird zu langen Ketten von Props durch Komponenten, die sich nicht wirklich um die Daten kümmern. Das macht Refactoring riskanter, erhöht Boilerplate und kann zu verwirrenden Bugs führen, in denen zwei Stellen versehentlich denselben Zustand unterschiedlich darstellen.
Verschiebe den State in den nächsten gemeinsamen Elternteil und gib ihn als Props weiter. Das ist meist die einfachste Option und hält Abhängigkeiten explizit, kann aber zu „God Components“ führen, wenn es überstrapaziert wird.
React Context hilft, wenn viele Komponenten denselben Wert brauchen (Theme, Locale, aktueller Nutzer). Es reduziert Prop-Drilling, aber wenn du häufig ändernde Daten in Context speicherst, kann es schwieriger werden, Updates und Performance zu verstehen.
Mit wachsender App-Größe reagierte das Ökosystem mit Bibliotheken wie Redux und ähnlichen Store-Patterns. Diese zentralisieren State-Updates, oft mit Konventionen rund um Actions und Selectors, was bei großer Skala Vorhersagbarkeit bringen kann.
Bevorzuge lokalen State per Default, hebe State hoch, wenn Geschwister koordinieren müssen, nutze Context für bereichsübergreifende Anliegen und erwäge einen externen Store, wenn viele entfernte Komponenten dieselben Daten brauchen und das Team strengere Update-Regeln benötigt. Die „richtige“ Wahl hängt von App-Komplexität, Teamgröße und Änderungsfrequenz der Anforderungen ab.
React führte nicht nur eine neue Art zu schreiben ein—es schob Teams in eine komponentengetriebene Arbeitsweise, in der Code, Styling und Verhalten als kleine, testbare Einheiten entwickelt werden. Diese Verschiebung beeinflusste, wie Frontend-Projekte gebaut, validiert, dokumentiert und ausgeliefert werden.
Wenn die UI aus Komponenten besteht, ist es natürlich, „von den Rändern nach innen“ zu arbeiten: erst einen Button bauen, dann ein Formular, dann eine Seite. Teams begannen, Komponenten als Produkte mit klaren APIs (Props), vorhersehbaren Zuständen (Loading, Empty, Error) und wiederverwendbaren Styling-Regeln zu behandeln.
Ein praktischer Effekt: Designer und Entwickler können sich an einem gemeinsamen Komponenten-Inventar ausrichten, Verhalten isoliert prüfen und späte Überraschungen auf Seiten-Ebene reduzieren.
Reacts Popularität half, eine moderne Toolchain zu standardisieren, die viele Teams inzwischen als Standard ansehen:
Auch wenn ihr nicht dieselben Tools wählt, bleibt die Erwartung: eine React-App sollte Schutzmechanismen haben, die UI-Regressionen früh erkennen.
Als neuere Erweiterung dieses „Workflow-first“-Denkens nutzen manche Teams auch Chat-gestützte Plattformen wie Koder.ai, um React-Frontends (und das Backend darum herum) zu scaffolden—nützlich, um Komponentenstruktur, State-Eigentum und Feature-Grenzen schnell vorab zu validieren, bevor Wochen in handgefertigte Infrastruktur fließen.
React-Teams populärisierten die Idee eines Komponenten-Explorers: eine Umgebung, in der du Komponenten in verschiedenen Zuständen rendern, Notizen anhängen und eine Quelle der Wahrheit für Nutzungsrichtlinien teilen kannst.
Dieses Storybook-ähnliche Denken (ohne ein bestimmtes Produkt vorzuschreiben) verändert die Zusammenarbeit: du kannst das Verhalten einer Komponente prüfen, bevor sie in eine Seite integriert wird, und Edge-Cases gezielt testen statt darauf zu hoffen, dass sie während manueller QA auftauchen.
Wenn du eine wiederverwendbare Bibliothek baust, passt das natürlich zu einem Designsystem-Ansatz—siehe /blog/design-systems-basics.
Komponentenbasiertes Tooling fördert kleinere Pull Requests, klarere visuelle Reviews und sicherere Refactors. Mit der Zeit shippen Teams UI-Änderungen schneller, weil sie an gut abgegrenzten Teilen iterieren statt sich durch verknoteten, seitenweiten DOM-Code zu kämpfen.
Ein Designsystem ist praktisch gesprochen zwei Dinge zusammen: eine Bibliothek wiederverwendbarer UI-Komponenten (Buttons, Formulare, Modals, Navigation) und Richtlinien, die erklären, wie und wann sie eingesetzt werden (Abstände, Typografie, Ton, Zugänglichkeitsregeln, Interaktionsmuster).
React machte diesen Ansatz natürlich, weil „Komponente" bereits die Kerneinheit der UI ist. Statt Markup zwischen Seiten zu kopieren, können Teams ein \u003cButton />, \u003cTextField /> oder \u003cDialog /> einmal veröffentlichen und überall wiederverwenden—bei kontrollierter Anpassung über Props.
React-Komponenten sind in sich geschlossen: sie können Struktur, Verhalten und Styling hinter einer stabilen Schnittstelle bündeln. Das macht es einfach, eine Komponentenbibliothek zu bauen, die:
Wenn du von null startest, hilft eine einfache Checkliste, damit aus „einer Ansammlung von Komponenten" nicht schnell ein inkonsistenter Haufen wird: /blog/component-library-checklist.
Ein Designsystem ist nicht nur visuelle Konsistenz—es ist auch Verhaltenskonsistenz. Wenn ein Modal immer den Fokus korrekt fängt oder ein Dropdown immer Tastaturnavigation unterstützt, wird Zugänglichkeit zur Standardeinstellung statt zur Nachgedanken-Aufgabe.
Theming wird ebenfalls einfacher: Tokens (Farben, Abstände, Typografie) können zentralisiert und von Komponenten genutzt werden, sodass Markenänderungen nicht jede Seite anfassen müssen.
Für Teams, die bewerten, ob sich die Investition in gemeinsame Komponenten lohnt, hängt die Entscheidung oft von Skalierung und Wartungskosten ab; einige Organisationen verknüpfen diese Bewertung mit Plattformplänen wie /pricing.
React veränderte nicht nur, wie wir UIs bauen—es veränderte, wie wir Qualität bewerten. Sobald deine App aus Komponenten mit klaren Eingaben (Props) und Ausgaben (gerenderte UI) besteht, werden Testing und Performance zu Architekturfragen, nicht zu last-minute Aufgaben.
Komponentengrenzen erlauben Tests auf zwei nützlichen Ebenen:
Das funktioniert am besten, wenn Komponenten klare Ownership haben: ein Ort verwaltet State, Kinder zeigen Daten und senden Ereignisse.
React-Apps wirken oft schnell, weil Teams Performance in die Struktur einplanen:
Eine nützliche Regel: optimiere die wirklich teuren Teile—große Listen, komplexe Berechnungen und häufig gerenderte Bereiche—statt nach kleinen Gewinnen zu jagen.
Mit der Zeit driftet ein Team leicht in bekannte Fallen: Überkomponentisierung (zu viele winzige Teile ohne klaren Zweck), Prop-Drilling (Daten werden durch viele Schichten gereicht) und unscharfe Grenzen, bei denen niemand weiß, welche Komponente State „besitzt".
Wenn du schnell vorankommst (insbesondere mit auto-generiertem oder scaffolded Code), tauchen diese Fallen eher auf: Komponenten vermehren sich und Ownership wird schwammig. Ob du per Hand code oder ein Tool wie Koder.ai nutzt, die Leitlinie bleibt: State-Verantwortung explizit halten, Komponent-APIs klein halten und in Richtung klarer Feature-Grenzen refactoren.
Server Components, Meta-Frameworks und bessere Tooling werden weiter ändern, wie React-Apps ausgeliefert werden. Die bleibende Lektion ist aber unverändert: entwirf um State, Ownership und komponierbare UI-Bausteine, und lass Tests sowie Performance natürlich folgen.
Für tiefergehende Architekturentscheidungen siehe /blog/state-management-react.
React hat die Frontend-Architektur um einige Kernentscheidungen neu gerahmt:
Die praktische Folge: weniger manuelles DOM-Bookkeeping und klarere Grenzen für Teams und Tools.
Component Thinking bedeutet, jedes UI-Stück als kleine, wiederverwendbare Einheit zu behandeln, die ihr Rendering besitzt und sich zu größeren Bildschirmen zusammenfügen lässt. Praktisch bündelt eine Komponente:
Das verschiebt die Arbeit von „dieses DOM-Element updaten“ zu „diese Komponente für diesen Zustand rendern“.
Im DOM-ersten Code wird das DOM oft zur Quelle der Wahrheit, sodass du mehrere Elemente manuell synchron halten musst. In React änderst du den State und renderst basierend darauf; Bedingungen wie Ladeindikatoren, deaktivierte Buttons und leere Zustände bleiben so automatisch konsistent.
Ein guter Test: Wenn du viele Schritte wie „Element finden und Klasse toggeln“ schreibst, kämpfst du gegen das Modell; wenn die UI aus dem Zustand fällt, ist oft ein Problem mit der Zustandsverantwortung die Ursache.
Vor React waren viele Apps seitenzentriert: servergerenderte Templates plus jQuery und Plugins. Verhalten war über Server-Views, HTML-Attribute und JS-Initialisierer verteilt.
Häufige Probleme waren:
React brachte Teams zu wiederverwendbaren Komponenten und vorhersehbaren Updates.
Deklaratives Rendering bedeutet, zu beschreiben, wie die UI für einen gegebenen Zustand aussehen soll, statt wie man Schritt für Schritt das DOM verändert.
Statt:
Drückst du Bedingungen im Render-Output aus (z. B. „wenn eingeloggt, Namen zeigen, sonst Sign-in-Button“), und React kümmert sich um die Aktualisierung des echten DOMs.
JSX machte es bequem, UI-Struktur neben der Logik zu platzieren, die sie steuert (Bedingungen, Formatierung, Handler). Das reduziert das Hin- und Herspringen zwischen separaten Template- und Logikdateien.
JSX ist kein HTML; es kompiliert zu JavaScript. Der Schlüsselvorteil ist organisatorisch: Dinge, die sich zusammen ändern (UI + Verhalten), bleiben in einer Komponente zusammen und sind dadurch leichter wartbar.
Reconciliation ist der Prozess, bei dem React den früheren Render mit dem neuen vergleicht und die minimale Menge an Änderungen am DOM anwendet.
Die praktische Schlussfolgerung ist Vorhersagbarkeit: du schreibst Render-Logik, als würdest du die UI neu aufbauen, und React wendet inkrementelle Updates an.
Bei Listen: nutze stabile, eindeutige key-Werte (z. B. IDs). Vermeide Array-Indexe, wenn Elemente neu geordnet, eingefügt oder gelöscht werden können — sonst kann React falsche Komponentinstanzen wiederverwenden (z. B. Eingabewerte bleiben beim falschen Element).
Einbahn-Datenfluss bedeutet: Daten gehen von Eltern an Kinder via props, während Kinder Änderungen über Callbacks anfragen.
Das macht Grenzen offensichtlich:
Beim Debuggen lautet die Frage oft: „Wo lebt dieser State?“ statt lange nach versteckten Mutationen zu suchen.
Komposition heißt, Verhalten durch Kombination von Komponenten zu bauen statt durch Klassen-Hierarchien zu erben.
Gängige Muster:
Eine praktische Vorgehensweise beim State-Management im Wachsen einer App:
children akzeptieren (z. B. Shells, Grids, Cards)RequireAuth oder ErrorBoundaryfooter, emptyState, renderRow) wenn children nicht ausreichenDas bleibt flexibel und vermeidet tiefe Vererbungshierarchien und weitreichende Nebenwirkungen von Basis-Klassen.
Die Wahl sollte von Komplexität und Teamgröße abhängen, nicht von Modetrends.