React-Mentalmodelle: Denkweisen im Stil von Dan Abramov

Warum React schwer wirkt, bis du die richtigen Mentalmodelle hast

React kann anfangs frustrierend sein, weil du die UI eine Änderung sehen kannst, aber nicht immer erklären kannst, warum sie passiert ist. Du klickst einen Button, etwas aktualisiert sich, und dann überrascht dich ein anderer Bereich der Seite. Das ist meist nicht „React ist seltsam.“ Sondern: „Mein Bild davon, was React tut, ist unscharf.“

Ein Mentalmodell ist die einfache Geschichte, die du dir darüber erzählst, wie etwas funktioniert. Wenn die Geschichte falsch ist, triffst du selbstsichere Entscheidungen, die zu verwirrenden Ergebnissen führen. Denk an ein Thermostat: ein schlechtes Modell ist „Ich stelle 22°C ein, also wird es sofort 22°C im Raum.“ Ein besseres Modell ist „Ich stelle ein Ziel ein, und der Heizkörper schaltet über die Zeit an und aus, um es zu erreichen.“ Mit der besseren Geschichte wirkt das Verhalten nicht mehr zufällig.

React funktioniert genauso. Sobald du ein paar klare Ideen übernommen hast, wird React vorhersehbar: Du kannst dir die aktuellen Daten anschauen und zuverlässig erraten, was auf dem Bildschirm stehen wird.

Dan Abramov hat dieses „mach es vorhersehbar“-Mindset populär gemacht. Es geht nicht darum, Regeln auswendig zu lernen. Es geht darum, ein kleines Set an Wahrheiten im Kopf zu behalten, sodass du durch Nachdenken und nicht durch Versuch und Irrtum debuggen kannst.

Behalte diese Ideen im Blick:

• Die UI ist das Ergebnis von State, nicht eine Reihe manueller DOM-Änderungen.
• Komponenten sind Funktionen, die beschreiben, wie die UI aussehen sollte.
• Daten fließen nach unten; Änderungen gehen über Events nach oben.
• Seiteneffekte sind getrennt vom Rendering und haben einen konkreten Zweck.

Hältst du dich daran, hört React auf, wie Magie zu wirken. Es wird zu einem System, dem du vertrauen kannst.

Komponenten, Props und State: das Kernbild

React wird leichter, wenn du aufhörst, in „Screens“ zu denken, und anfängst, in kleinen Teilen zu denken. Eine Komponente ist eine wiederverwendbare UI-Einheit. Sie nimmt Eingaben und gibt eine Beschreibung dessen zurück, wie die UI für diese Eingaben aussehen sollte.

Es hilft, eine Komponente als reine Beschreibung zu behandeln: „gegeben diese Daten, zeige das.“ Diese Beschreibung kann an vielen Stellen verwendet werden, weil sie nicht davon abhängt, wo sie lebt.

Props sind die Eingaben. Sie kommen von einer Elternkomponente. Props werden nicht „von der Komponente besessen“ und sollten nicht stillschweigend von der Komponente verändert werden. Wenn ein Button label="Save" erhält, ist die Aufgabe des Buttons, dieses Label zu rendern, nicht zu entscheiden, dass es anders sein sollte.

State ist besessene Daten. Es ist das, woran sich die Komponente über die Zeit erinnert. State ändert sich, wenn ein Nutzer interagiert, wenn eine Anfrage fertig ist oder wenn du entscheidest, dass etwas anders sein sollte. Im Gegensatz zu Props gehört State dieser Komponente (oder der Komponente, die du als Besitzer ausgewählt hast).

Die kurze Version der Kernidee: UI ist eine Funktion des State. Wenn der State „loading“ sagt, zeige einen Spinner. Wenn State „error“ sagt, zeige eine Nachricht. Wenn State „items = 3“ sagt, rendere drei Zeilen. Deine Aufgabe ist, die UI aus dem State lesen zu lassen, nicht in versteckte Variablen abdriften zu lassen.

Eine schnelle Trennung der Konzepte:

• Komponente: das UI-Stück (SearchBox, ProfileCard, CheckoutForm)
• Props: was sie zum Anzeigen braucht (name, price, disabled)
• State: was sie sich merkt (isOpen, query, selectedId)

Beispiel: ein Modal. Der Parent kann title und onClose als Props übergeben. Das Modal könnte isAnimating im State besitzen.

Selbst wenn du UI per Chat generierst (zum Beispiel auf Koder.ai), bleibt diese Trennung der schnellste Weg, um den Überblick zu behalten: Entscheide zuerst, was Props vs. State ist, dann lass die UI folgen.

Rendering und Re-Rendering: was sich tatsächlich ändert

Eine nützliche Art, React im Kopf zu behalten (sehr im Sinne von Dan Abramov) ist: Rendering ist eine Berechnung, kein Malvorgang. React führt deine Komponentenfunktionen aus, um herauszufinden, wie die UI für die aktuellen Props und den aktuellen State aussehen sollte. Die Ausgabe ist eine UI-Beschreibung, keine Pixel.

Ein Re-Render bedeutet einfach, dass React diese Berechnung wiederholt. Es heißt nicht „die ganze Seite wird neu gezeichnet.“ React vergleicht das neue Ergebnis mit dem vorherigen und wendet die kleinste Menge an Änderungen am echten DOM an. Viele Komponenten können re-rendern, während nur wenige DOM-Knoten tatsächlich aktualisiert werden.

Die meisten Re-Renders passieren aus einigen einfachen Gründen: der State einer Komponente hat sich geändert, ihre Props haben sich geändert, oder ein Parent hat re-rendered und React bat das Kind erneut zu rendern. Letzteres überrascht oft Leute, ist aber meist unproblematisch. Wenn du Render als „billig und langweilig“ behandelst, bleibt deine App leichter nachvollziehbar.

Die Faustregel, die das sauber hält: mache Render rein. Gegeben die gleichen Eingaben (Props + State) sollte deine Komponente die gleiche UI-Beschreibung zurückgeben. Halte Überraschungen aus dem Render heraus.

Konkretes Beispiel: wenn du eine ID mit Math.random() im Render generierst, ändert sie sich bei einem Re-Render und plötzlich verliert ein Checkbox-Fokus oder ein Listeneintrag remounted. Erzeuge die ID einmal (State, memo oder außerhalb der Komponente) und das Rendern bleibt stabil.

Merke dir einen Satz: Ein Re-Render bedeutet „berechne neu, wie die UI sein sollte“, nicht „baue alles neu auf“.

State-Updates: halte Änderungen klein und vorhersehbar

Ein weiteres hilfreiches Modell: State-Updates sind Anfragen, keine sofortigen Zuweisungen. Wenn du einen Setter wie setCount(count + 1) aufrufst, bittest du React, ein Render mit einem neuen Wert einzuplanen. Wenn du State direkt danach liest, siehst du möglicherweise noch den alten Wert, weil React noch nicht gerendert hat.

Darum sind „kleine und vorhersehbare“ Updates wichtig. Beschreibe die Änderung, anstatt dich auf den vermeintlich aktuellen Wert zu verlassen. Wenn der nächste Wert vom vorherigen abhängt, benutze die Updater-Form: setCount(c => c + 1). Das passt zu Reacts Arbeitsweise: mehrere Updates können in eine Warteschlange gestellt und dann in Reihenfolge angewendet werden.

Unveränderlichkeit ist die andere Hälfte des Bildes. Verändere Objekte und Arrays nicht in-place. Erzeuge ein neues Objekt/Array mit der Änderung. React kann dann erkennen: „dieser Wert ist neu“ und dein Gehirn kann nachverfolgen, was sich geändert hat.

Beispiel: Ein Todo-Item togglen. Der sichere Ansatz ist, ein neues Array und ein neues Todo-Objekt für das geänderte Item zu erstellen. Der riskante Ansatz ist, todo.done = !todo.done im bestehenden Array zu drehen.

Halte State außerdem minimal. Eine häufige Falle ist das Speichern von Werten, die du berechnen kannst. Wenn du bereits items und filter hast, speichere nicht filteredItems im State. Berechne es während des Renderns. Weniger State-Variablen bedeuten weniger Möglichkeiten, dass Werte auseinanderlaufen.

Ein einfacher Test, was in den State gehört:

• Speichere es, wenn es sich über die Zeit ändern kann und die UI reagieren muss.
• Speichere es nicht, wenn es sich aus anderem State oder Props ableiten lässt.
• Speichere keine Duplikate derselben Wahrheit an zwei Stellen.

Wenn du UI per Chat baust (auch auf Koder.ai), bitte um Änderungen als kleine Patches: „Füge ein boolean-Flag hinzu“ oder „Aktualisiere diese Liste unveränderlich.“ Kleine, explizite Änderungen halten den Generator und deinen React-Code im Einklang.

Effects sind fürs Synchronisieren, nicht für grundlegende UI-Logik

Rendering beschreibt die UI. Effects synchronisieren mit der Außenwelt. „Außen“ sind Dinge, die React nicht kontrolliert: Netzwerkanfragen, Timer, Browser-APIs und manchmal imperatives DOM-Arbeiten.

Wenn etwas aus Props und State berechnet werden kann, sollte es normalerweise nicht in einem Effect leben. Es in einen Effect zu setzen fügt einen zweiten Schritt hinzu (rendern, Effect ausführen, State setzen, erneut rendern). Dieser zusätzliche Hop ist der Ort, an dem Flackern, Loops und „warum ist das veraltet?“-Bugs auftreten.

Eine häufige Verwirrung: Du hast firstName und lastName und speicherst fullName im State mit einem Effect. fullName ist aber keine Nebenwirkung. Berechne es während des Renderns und es stimmt immer.

Als Gewohnheit: leite UI-Werte während des Renderns ab (oder mit useMemo, wenn etwas wirklich teuer ist), und benutze Effects, um „etwas zu tun“ (z. B. fetchen, abonnieren), nicht um „etwas herauszufinden“.

Das Dependency-Array ist eine Trigger-Liste

Behandle das Dependency-Array als: „Wenn diese Werte sich ändern, resynce mit der Außenwelt.“ Es ist kein Performance-Trick und kein Ort, um Warnungen zu unterdrücken.

Beispiel: Wenn du Benutzerdetails holst, wenn sich userId ändert, gehört userId ins Dependency-Array, weil es die Synchronisation auslösen soll. Wenn der Effect auch token verwendet, nimm ihn auf, sonst kannst du mit einem alten Token fetchen.

Ein guter Praxistest: Wenn das Entfernen eines Effects nur die UI falsch macht, war es wahrscheinlich kein echter Effect. Wenn das Entfernen dazu führt, dass ein Timer nicht mehr gestoppt wird, eine Subscription nicht gekündigt wird oder ein Fetch nicht ausgeführt wird, war es wahrscheinlich ein echter Effect.

Datenfluss: eine Quelle der Wahrheit schlägt verstreuten State

Eines der nützlichsten Mentalmodelle ist simpel: Daten fließen den Baum hinunter, und Nutzeraktionen gehen nach oben.

Ein Parent gibt Werte an Kinder weiter. Kinder sollten nicht heimlich denselben Wert an zwei Stellen „besitzen“. Sie fordern Änderungen an, indem sie eine Funktion aufrufen, und der Parent entscheidet, wie der neue Wert aussieht.

Wenn zwei UI-Teile übereinstimmen müssen, wähle einen Ort, um den Wert zu speichern, und gib ihn nach unten weiter. Das ist „State liften.“ Es kann sich wie zusätzlicher Aufwand anfühlen, aber es verhindert ein schlimmeres Problem: zwei States, die auseinanderlaufen und Hacks erzwingen, um sie synchron zu halten.

Beispiel: eine Suchbox und eine Ergebnisliste. Wenn das Input-Feld seine eigene Query speichert und die Liste ihre eigene Query, wirst du irgendwann sehen: „Das Input zeigt X, aber die Liste benutzt Y.“ Die Lösung ist, query in einem Parent zu halten, ihn an beide weiterzugeben und dem Input ein onChangeQuery(newValue)-Handler zu geben.

State zu liften ist nicht immer die Antwort. Wenn ein Wert nur innerhalb einer Komponente wichtig ist, behalte ihn dort. State nah an der Stelle zu halten, wo er gebraucht wird, macht den Code oft lesbarer.

Eine praktische Grenze:

• Lokaler State: nur UI-Details (Dropdown offen, welcher Tab hervorgehoben ist)
• Geteilter State: Daten, die mehrere Komponenten abstimmen müssen (Filter, ausgewähltes Item, Auth-Status)

Wenn du unsicher bist, ob du State liften sollst, suche nach Signalen wie: zwei Komponenten zeigen denselben Wert unterschiedlich; eine Aktion an einer Stelle muss etwas weit entferntes updaten; du kopierst Props in State „nur für den Fall“; oder du fügst Effects hinzu, nur um zwei Werte synchron zu halten.

Dieses Modell hilft auch beim Bauen via Chat-Tools wie Koder.ai: Fordere einen einzigen Owner für jedes Stück geteilten State und generiere Handler, die nach oben fließen.

Schritt für Schritt: Entwirf ein Feature, indem du zuerst den State zeichnest

Wähle ein Feature, das klein genug ist, um es im Kopf zu halten. Ein gutes Beispiel ist eine durchsuchbare Liste, bei der man auf ein Item klicken kann, um Details in einem Modal zu sehen.

Beginne damit, die UI-Teile und die möglichen Events zu skizzieren. Denk noch nicht an Code. Denk daran, was der Benutzer tun kann und was er sehen kann: es gibt ein Suchfeld, eine Liste, eine Hervorhebung der ausgewählten Zeile und ein Modal. Die Events sind Tippen in die Suche, Klick auf ein Item, Öffnen des Modals und Schließen des Modals.

„Zeichne dann den State.“ Schreib die wenigen Werte auf, die gespeichert werden müssen, und entscheide, wer sie besitzt. Eine einfache Regel funktioniert gut: der nächste gemeinsame Parent von allen Orten, die einen Wert brauchen, sollte ihn besitzen.

Für dieses Feature kann der gespeicherte State klein sein: query (String), selectedId (id oder null) und isModalOpen (Boolean). Die Liste liest query und rendert Items. Das Modal liest selectedId, um Details anzuzeigen. Wenn sowohl Liste als auch Modal selectedId brauchen, halte es im Parent, nicht in beiden.

Als Nächstes trenne abgeleitete Daten von gespeicherten Daten. Die gefilterte Liste ist abgeleitet: filteredItems = items.filter(...). Speichere sie nicht im State, weil sie immer aus items und query neu berechnet werden kann. Abgeleitete Daten zu speichern ist der Weg, wie Werte auseinanderlaufen.

Frage dann: brauchen wir einen Effect? Wenn Items bereits im Speicher sind, nein. Wenn das Tippen einer Query Ergebnisse fetchen soll, ja. Wenn das Schließen des Modals etwas speichern soll, ja. Effects sind fürs Synchronisieren (fetch, save, subscribe), nicht fürs grundlegende UI-Wiring.

Teste abschließend den Ablauf mit ein paar Randfällen:

• Schnell tippen und dann das Feld leeren: kehrt die Liste zur Normalität zurück?
• Auf ein Item klicken, dann ändert die Liste sich durch die Suche: ist selectedId noch gültig?
• Modal schließen: behältst du die Auswahl oder setzt du sie zurück?
• Items werden vom Server aktualisiert: was passiert, wenn das ausgewählte Item verschwindet?

Wenn du diese Fragen auf Papier beantworten kannst, ist der React-Code meist unkompliziert.

Häufige Fehler, die das mentale Modell zerstören

Die meiste React-Verwirrung hat nichts mit Syntax zu tun. Sie entsteht, wenn dein Code aufhört, zur einfachen Geschichte in deinem Kopf zu passen.

Fehler-Muster (und das Symptom, das du bemerkst)

Abgeleiteten State speichern. Du speicherst fullName im State, obwohl es nur firstName + lastName ist. Es funktioniert, bis eines der Felder sich ändert und das andere nicht, und die UI zeigt veraltete Werte.

Effect-Loops. Ein Effect holt Daten, setzt State, und die Dependency-Liste lässt ihn wieder laufen. Das Symptom sind wiederholte Requests, wackelige UI oder State, der nie zur Ruhe kommt.

Veraltete Closures. Ein Klick-Handler liest einen alten Wert (z. B. einen veralteten Zähler oder Filter). Das Symptom ist „Ich klickte, aber es benutzte den Wert von gestern.“

Globaler State überall. Wenn du jedes UI-Detail in einen globalen Store packst, wird es schwer herauszufinden, wer was besitzt. Das Symptom ist: Du änderst eine Sache und drei Bildschirme reagieren überraschend.

Verschachtelte Objekte mutieren. Du aktualisierst ein Objekt oder Array in-place und wunderst dich, warum die UI nicht aktualisiert. Das Symptom ist „die Daten haben sich geändert, aber nichts re-rendered.“

Ein konkretes Beispiel: ein „search and sort“-Panel für eine Liste. Wenn du filteredItems im State speicherst, kann es auseinanderdriften, wenn neue Daten ankommen. Stattdessen: speichere die Eingaben (Suchtext, Sortierwahl) und berechne die gefilterte Liste während des Renderns.

Bei Effects: nutze sie für das Synchronisieren mit der Außenwelt (fetching, subscriptions, timer). Wenn ein Effect grundlegende UI-Arbeit macht, gehört sie oft ins Render oder in einen Event-Handler.

Beim Generieren oder Editieren von Code per Chat zeigen sich diese Fehler schneller, weil Änderungen in großen Stücken kommen können. Eine gute Gewohnheit ist, Anfragen in Begriffen von Besitz zu formulieren: „Was ist die Quelle der Wahrheit für diesen Wert?“ und „Können wir das berechnen statt zu speichern?"

Kurze Checkliste, wenn State unordentlich wird

Wenn deine UI unvorhersehbar wird, liegt es selten an „zu viel React“. Es ist meist zu viel State, an den falschen Stellen, der Dinge tut, die er nicht tun sollte.

Bevor du ein weiteres useState hinzufügst, halte kurz inne und frag:

• Was ist die kleinste Menge an Werten, die beschreibt, was der Nutzer gerade sieht?
• Wo sollte jeder Wert leben, damit die Teile, die ihn brauchen, ihn lesen können, und die, die ihn nicht brauchen, ungestört bleiben?
• Ist dieser Wert wirklich neue Information, oder kannst du ihn aus Props, URL-Params oder anderem State berechnen?
• Nutzt du einen Effect, um UI zu berechnen, oder nur, um mit etwas außerhalb von React zu synchronisieren (Netzwerk, Timer, Browser-API)?
• Wenn ein Wert sich ändert, welche Komponenten sollten neu rendern, weil sie ihn lesen, und welche nicht?

Kleines Beispiel: Suchfeld, Filter-Dropdown, Liste. Wenn du sowohl query als auch filteredItems im State hast, hast du zwei Quellen der Wahrheit. Stattdessen behalte query und filter als State und leite filteredItems während des Renderns aus der vollen Liste ab.

Das ist wichtig, auch wenn du schnell über Chat-Tools baust. Geschwindigkeit ist toll, aber frag immer: „Haben wir State hinzugefügt oder versehentlich ein abgeleitetes Feld gespeichert?“ Wenn es abgeleitet ist, lösche diesen State und berechne ihn neu.

Beispiel: schnell iterieren an einer UI ohne Vorhersehbarkeit zu verlieren

Ein kleines Team baut ein Admin-UI: eine Tabelle mit Bestellungen, ein paar Filter und ein Dialog zum Bearbeiten einer Bestellung. Die erste Anforderung ist vage: „Füge Filter und ein Edit-Popup hinzu.“ Das klingt einfach, aber oft endet es mit zufällig verteiltem State.

Mach es konkret, indem du die Anforderung in State und Events übersetzt. Statt „Filter“ nenne den State: query, status, dateRange. Statt „Edit-Popup“ nenne das Event: „User klickt Edit an einer Zeile.“ Dann entscheide, wer welchen State besitzt (Page, Table oder Dialog) und was abgeleitet werden kann (wie die gefilterte Liste).

Beispiel-Prompts, die das Modell intakt halten (funktionieren auch gut in Chat-basierten Buildern wie Koder.ai):

• „Erstelle eine OrdersPage, die filters und selectedOrderId besitzt. OrdersTable wird von filters kontrolliert und ruft onEdit(orderId) auf.“
• „Leite visibleOrders aus orders und filters ab. Speichere visibleOrders nicht im State.“
• „Füge einen EditOrderDialog hinzu, der order und open erhält. Beim Speichern rufe onSave(updatedOrder) und schließe das Dialog.“
• „Wenn Daten gefetcht werden, halte sie an einem Ort. Nutze einen Effect nur, um filters in die URL zu synchronisieren, nicht um gefilterte Zeilen zu berechnen."

Nachdem die UI generiert oder aktualisiert wurde, überprüfe die Änderungen mit einer kurzen Prüfung: jeder State-Wert hat einen Owner, abgeleitete Werte werden nicht gespeichert, Effects synchronisieren nur mit der Außenwelt (URL, Netzwerk, Storage), und Events fließen als Props nach unten und als Callbacks nach oben.

Wenn State vorhersehbar ist, fühlt sich Iteration sicher an. Du kannst Layouts ändern, einen neuen Filter hinzufügen oder Dialogfelder anpassen, ohne zu raten, welcher versteckte State als Nächstes kaputtgeht.

Nächste Schritte: schneller bauen mit Chat, aber das React-Modell beibehalten

Geschwindigkeit hilft nur, wenn die App weiterhin leicht zu verstehen bleibt. Der einfachste Schutz ist, diese Mentalmodelle wie eine Checkliste zu behandeln, die du anwendest, bevor du UI schreibst (oder generierst).

Beginne jedes Feature gleich: schreibe den benötigten State auf, die Events, die ihn ändern können, und wer ihn besitzt. Wenn du nicht sagen kannst: „Diese Komponente besitzt diesen State, und diese Events aktualisieren ihn“, wirst du wahrscheinlich verstreuten State und überraschende Re-Renders bekommen.

Wenn du über Chat baust, starte im Planungsmodus. Beschreibe Komponenten, State-Shape und Übergänge in einfacher Sprache, bevor du nach Code fragst. Zum Beispiel: „Ein Filter-Panel aktualisiert query-State; die Ergebnisliste leitet sich aus query ab; das Auswählen eines Items setzt selectedId; Schließen leert es.“ Wenn das sauber lesbar ist, wird das Generieren der UI zum mechanischen Schritt.

Wenn du Koder.ai (koder.ai) nutzt, lohnt sich ein kurzer Sanity-Check: ein eindeutiger Owner für jeden State-Wert, UI leitet sich vom State ab, Effects nur für Sync, und keine doppelten Wahrheiten.

Dann iteriere in kleinen Schritten. Wenn du die State-Struktur ändern willst (z. B. mehrere Booleans zu einem einzigen Status-Feld zusammenfassen), mach vorher einen Snapshot, experimentiere und rolle zurück, wenn das mentale Modell schlechter wird. Und wenn du eine tiefere Überprüfung oder Übergabe brauchst, macht das Exportieren des Quellcodes es leichter, die eigentliche Frage zu beantworten: Erzählt die State-Form noch die Geschichte der UI?