Seite 10 - React

Environment Variablen in React Builds werden anders verarbeitet als in einem Backend: sie landen fest im Bundle, sobald sie das richtige Präfix tragen. Wer das nicht versteht, baut Secrets versehentlich in öffentlich einsehbaren JavaScript-Code ein oder wundert sich, warum eine geänderte Variable nach dem Deployment nicht greift.

Die Wahl der Datenschicht entscheidet über Type-Safety, Caching-Verhalten und die Geschwindigkeit, mit der ein React-Team neue Features ausliefert. REST bleibt der pragmatische Standard, GraphQL bringt flexible Queries für komplexe Datenmodelle, und tRPC liefert End-to-End-Typsicherheit ohne Schema-Sprache, sofern Backend und Frontend im selben TypeScript-Monorepo liegen.

React nutzt den key-Prop normalerweise, um Listenelemente zu identifizieren. Ändert man den key außerhalb einer Liste bewusst, verwirft React die gesamte Komponenteninstanz und erzeugt eine völlig neue. Dieses Muster ist ein unterschätztes Werkzeug, um internen State ohne manuelle Reset-Logik zuverlässig zurückzusetzen.

Filter, Sortierung, Pagination und aktive Tabs landen in vielen React Anwendungen in useState, obwohl sie eigentlich Teil der Adresse sind. Wer diesen Zustand stattdessen in der URL speichert, bekommt Deep Linking, funktionierenden Browser Zurück Button und teilbare Links geschenkt, ganz ohne zusätzlichen Store.

Manuelles Memoizing mit useMemo und useCallback ist fehleranfällig, schwer wartbar und wird häufig falsch eingesetzt. Der React Compiler analysiert Komponentencode zur Build-Zeit und fügt automatisch die richtigen Memoizing-Wrapper ein – ohne dass Entwickler Dependencies-Arrays verwalten oder entscheiden müssen, wann etwas gecacht werden soll. Wie das funktioniert und was es bedeutet.

Daten in React zu laden bedeutete bislang immer: useEffect, useState, Lade-State, Error-State, Boilerplate. Der use()-Hook aus React 19 macht das deklarativ: Ein Promise rein, der aufgelöste Wert raus – Suspense übernimmt den Rest.

Der Array-Index als key-Wert funktioniert scheinbar problemlos, bis eine Liste sortiert, gefiltert oder verändert wird. Dann recycelt React internen Komponenten-State zwischen den falschen Elementen, mit teils gravierenden, schwer nachvollziehbaren Folgen.

Wer zum ersten Mal einen console.log in einem useEffect sieht, der im Entwicklungs-Build plötzlich zweimal auftaucht, hält das fast immer für einen Fehler. Tatsächlich ist die doppelte Ausführung in React 18 und 19 unter Strict Mode bewusst eingebaut, um genau die Effects zu entlarven, die kein korrektes Cleanup besitzen und in der Produktion später zu schwer auffindbaren Bugs führen würden.

Ein nicht abgefangener Fehler in einer React-Komponente zerstört den gesamten Komponentenbaum und zeigt dem Benutzer einen leeren Bildschirm. Error Boundaries sind der Mechanismus, der JavaScript-Fehler im Rendering isoliert, Fallback-UIs zeigt und die Anwendung stabil hält – korrekt implementiert, zuverlässig und mit Monitoring-Integration.

shadcn/ui ist keine Bibliothek im klassischen Sinne — es ist ein Katalog von Copy-Paste-Komponenten auf Radix-UI-Basis. Wer das Copy-Paste-Modell versteht, kann darauf eine vollständig kontrollierbare, themeable Komponentenbibliothek für das eigene Design System aufbauen.