React im kleinen Rahmen
Wenn man an React oder ähnliche Frontend-Frameworks (Vue.js, Angular, etc.) denkt, denken die meisten vermutlich auch an eine PWA (Progressive Web Application) mit Javascript-Router und REST-API Calls. Im Kontrast dazu denkt man bei kleinen Widgets, auf einer ansonsten serverseitig gerenderten Seite, an Libraries wie jQuery (oder mittlerweile hoffentlich an moderne Javascript APIs – aber das ist ein anderes Thema).
Muss das denn so sein?
Wer sagt denn, dass man mit den großen modernen Frameworks nicht auch kleine Dinge umsetzen kann. Natürlich macht es keinen Sinn 106 kB Javascript Code in eine Website einzubinden, nur um beispielsweise ein Element per Klick ein- oder auszublenden. Allerdings ist jQuery, wie es zum Beispiel von Bootstrap verwendet wird, nur 10 - 20 kB kleiner – dafür ist kein performance-optimiertes DOM-Manipulating dabei. Diese ganzen Scripte sind ja für gewöhnlich auch nicht zwingend erforderlich, um den Initialzustand der Website zu rendern. Wenn diese also asynchron geladen werden behindert das den FMP kaum. Bis der User die besagten Funktionen benötigt ist normalerweise bereits alles geladen und einsatzbereit. Im Zweifelsfall bekommt der User das notwendige visuelle Feedback, um ihm zu zeigen, dass etwa der Button (noch) nicht funktionstüchtig ist.
Es lassen sich ja bereits kleine Tools damit umsetzen. Nehmen wir zum Beispiel ein Collapse Element. Ja, da gibt es einen Haufen fertige Libraries und auch im oben erwähnten Bootstrap gibt es das bereits. Aber angenommen, wir verwenden React bereits auf der Seite und möchten auch nichts anderes dazu einbinden. Ein Hindernis ist, dass wir nicht ohne Umwege ein “Template” aus unserem HTML-Dokument in einer React-Komponente rendern können. Ein Work-Around ist allerdings nicht allzu kompliziert.
Wenn diese also asynchron geladen werden behindert das den FMP kaum.
Wenn ich jetzt aber eine Liste von X-Elementen aus meiner Datenbank anzeigen will? Muss ich dazu einen API-Endpunkt zur Verfügung stellen? Nein, nicht unbedingt. Ich hatte einmal den Fall, dass ein Kunde Events auf einer Seite auflisten wollte. Die notwendigen Daten waren kompakt genug, um alles in einem HTML-Script-Tag in eine Variable zu packen und dann von der Komponente auslesen zu lassen. So haben wir die Filterung, Sortierung und sogar die Suche nach Adressen über Google Maps im Frontend integriert – und so dem Benutzer ein fast wartezeitenfreies Erlebnis geboten und den Kunden glücklich gemacht.
Diese Herangehensweisen sind trotzdem nur situationsbedingt sinnvoll. Ich behalte sie aber gerne im Hinterkopf, um mir je nach Anwendung die effizienteste Variante aussuchen zu können. Selbstverständlich lässt sich das auch mit (vermutlich) jedem anderen Framework umsetzen. Nur die Implementierung ist auf jeden Fall anders.