Thema: React.

React ist eine JavaScript-Bibliothek für Oberflächen, die sich verändern, während man sie benutzt. React lohnt sich überall dort, wo eine Seite mehr können muss als anzeigen: Konfiguratoren, Filter über große Datenbestände, Buchungsstrecken, interne Dashboards. Bei JFconcept in Menden im Sauerland gehört React zusammen mit TypeScript und Tailwind zum festen Stack im Webengineering.

Jeder Klick lädt die Seite neu, und der Interessent bricht ab

Das typische Bild ist ein Produktkonfigurator auf Basis eines Standard-Plugins. Jede Auswahl schickt das Formular zum Server, die Seite springt, das Ergebnis erscheint mit spürbarer Verzögerung. Wer nur wissen will, was seine Variante kostet, gibt vorher auf.

Der zweite Fall ist stiller und teurer. Eine Oberfläche wächst über Jahre aus Skripten, die niemand mehr im Zusammenhang versteht. Ein neues Feld im Formular bricht die Preisberechnung an einer Stelle, an die keiner gedacht hat, und es fällt erst auf, wenn eine Bestellung falsch herauskommt.

Erst die Datenstruktur in TypeScript, dann die Oberfläche

JFconcept beginnt solche Projekte nicht mit Screens, sondern mit den Daten: welche Felder es gibt, welche Werte erlaubt sind, welche Kombinationen sich ausschließen. Diese Struktur wird in TypeScript festgeschrieben und gilt anschließend für die gesamte Oberfläche. Ein Feld, das es nicht gibt, lässt sich gar nicht erst anzeigen: Der Fehler erscheint im Editor, nicht später in einer Bestellung.

Erst danach entsteht die Oberfläche aus React-Komponenten. Jedes Element bauen wir einmal und variieren es über Eigenschaften, statt es pro Seite zu kopieren. Das ist der Grund, warum eine Änderung an einem Button später an einer einzigen Stelle passiert und nicht überall dort, wo jemand ihn irgendwann dupliziert hat.

Für das Aussehen kommt Tailwind mit festen Design-Tokens für Abstände, Schriftgrößen und Radien dazu. So bleibt eine über Monate gewachsene Anwendung optisch eine Einheit, auch wenn mehrere Leute daran arbeiten. Die Daten dahinter liefert meist ein Backend auf Laravel als Basis für individuelle Anwendungen, und wo React nur ein Teil einer größeren Individualentwicklung ist, ordnet sich das in unsere Arbeit im Webengineering ein.

Vor jedem Launch laufen die Änderungen über Staging-Umgebungen und Git-Versionierung, abgesichert durch automatisierte Tests. Eine Preislogik, die im Konfigurator falsch rechnet, soll auf der Testumgebung auffallen und nicht in der ersten echten Bestellung.

Ohne serverseitiges Rendering bleibt eine React-Anwendung für Maschinen leer

Suchmaschinen-Crawler und KI-Bots führen kein JavaScript aus oder tun es nur eingeschränkt und verzögert. Eine React-Anwendung, die ihren Inhalt erst im Browser erzeugt, liefert diesen Besuchern eine leere Hülle. JFconcept rendert React deshalb auf dem Server vor, sodass fertiges HTML ankommt und die Interaktivität sich anschließend darüberlegt.

Diese Website ist der Beleg dafür. Sie läuft auf React mit Inertia und serverseitigem Rendering: Was hier zu lesen ist, steht im ausgelieferten HTML, bevor eine einzige Zeile JavaScript ausgeführt wurde. Wer den Quelltext dieser Seite öffnet, findet diesen Absatz darin. Für einen Konfigurator heißt das, dass auch die Einstiegsseite mit ihren Erklärungen auffindbar bleibt und nicht hinter der Anwendung verschwindet.

Der Erfolg zeigt sich an abgeschlossenen Konfigurationen, nicht an der Verweildauer

Der erste Gradmesser ist der Abbruch. Ein Konfigurator, der ohne Nachladen reagiert, wird zu Ende geklickt. Sichtbar wird das an den Anfragen, die tatsächlich ankommen, und daran, wie vollständig sie ausgefüllt sind.

Der zweite Gradmesser zeigt sich erst im laufenden Betrieb: Änderungswünsche bleiben kalkulierbar. Wenn ein zusätzliches Feld auch lange nach dem Launch noch genauso ruhig eingebaut wird wie am Anfang, hat die Typsicherheit gehalten, was sie versprochen hat. Verweildauer sagt darüber nichts. Eine Oberfläche, in der jemand lange sucht, ist selten die bessere.