Seite 11 - React

Klassisches serverseitiges Rendering zwingt den Server dazu, den gesamten Komponentenbaum einer Seite vollständig durchzurendern, bevor auch nur das erste Byte an den Browser gesendet werden darf. Hängt irgendeine Komponente auf einer langsamen Datenbankabfrage oder einem externen API-Call, wartet der komplette Response so lange, wie die langsamste Komponente braucht, selbst wenn neun von zehn Bereichen der Seite längst fertig wären. React 18 löst dieses Problem mit echtem Streaming SSR: renderToPipeableStream sendet das HTML in mehreren Chunks, sobald sie fertig sind, statt auf die komplette Seite zu warten. Kombiniert mit Suspense-Boundaries lässt sich gezielt steuern, welche Bereiche sofort und welche verzögert nachgeliefert werden, mit messbaren Verbesserungen bei Time-to-First-Byte und wahrgenommener Ladezeit.

Wer React im Browser beherrscht, bringt bereits das Kernwissen für React Native mit: Komponenten, Hooks und State funktionieren identisch. Was sich ändert, sind die Bausteine für die Oberfläche, das Styling-Modell und die Art, wie native Funktionen wie Kamera oder Push-Benachrichtigungen angebunden werden. Dieser Artikel zeigt den direkten Umstieg mit konkretem Code.

React 19 ist kein inkrementelles Update. Server Components verlassen die experimentelle Phase, Server Actions werden Teil des Kern-APIs, der React Compiler übernimmt automatisches Memoizing, und neue Hooks vereinfachen Formulare, optimistische Updates und Asset-Loading grundlegend. Was davon für bestehende Projekte relevant ist – und was sich tatsächlich im Alltag ändert.

Ein Modal, das in einer tief verschachtelten Komponente liegt, wird von overflow: hidden eines Vorfahren oft sichtbar abgeschnitten. createPortal() rendert es an einen anderen DOM-Knoten, ohne dass es im React-Baum seinen logischen Platz fuer Events und Context verliert.

Ein Design System ohne lebende Dokumentation ist nach sechs Monaten veraltet. Storybook 8 verbindet Component-Driven Development, automatisch generierte Docs und visuelles Regressionstesting zu einem Workflow, der tatsächlich durchgehalten wird – von der ersten Button-Komponente bis zur produktionsreifen Bibliothek.

Streaming SSR zerlegt eine Serverantwort in mehrere Chunks, statt auf das vollständige HTML zu warten, bevor überhaupt etwas an den Browser geschickt wird. React Suspense definiert dabei die Grenzen, an denen einzelne Teile der Seite nachgeliefert werden, während schnell verfügbare Inhalte sofort sichtbar sind.

Beim React Deployment entscheidet die Wahl der Plattform über Build-Zeiten, Kosten und Kontrolle. Vercel, Netlify und ein selbst betriebener Docker-Stack lösen dasselbe Problem mit unterschiedlichen Kompromissen. Dieser Artikel zeigt konkrete Konfigurationen, eine CI/CD-Pipeline und die Entscheidungskriterien für jede Situation.

Ein Bild, das erst nach dem restlichen Layout nachlaedt, verschiebt sichtbare Inhalte und verschlechtert den Cumulative-Layout-Shift-Wert. Mit React Suspense laesst sich das Rendern einer Bildkomponente gezielt zurueckhalten, bis die Bilddatei tatsaechlich im Browser-Cache liegt. Dieser Artikel zeigt ein eigenes Preload-Pattern auf Basis von Promise-Wrapping, inklusive Caching, Fehlerbehandlung und Grenzen des Ansatzes.

useMemo und useCallback überall einsetzen macht React-Apps nicht schneller — es macht sie komplizierter. Wer zuerst misst, findet die echten Engpässe: unnötige Re-Renders, teure Berechnungen an der falschen Stelle und Layout-Thrashing. Dieser Artikel zeigt den richtigen Ablauf mit React Profiler, Chrome DevTools und handfesten Metriken.

React StrictMode ist kein optionaler Komfort — er ist ein Frühwarnsystem für Bugs, die in Production still und tückisch fehlschlagen. Warum er Components zweifach rendert, useEffect doppelt feuert und was das mit Concurrent Features zu tun hat.