Frage zu React, "Single Page Application" und projekttauglichkeit.

[headhunter5575]

Hi,

Ich bin gerade dabei React zu lernen. Habe mir einige Tutorials angeschaut und auch schon mal eine Todo-List programmiert.

Nun habe ich mir mal die Top 10 Seiten angeschaut die mit React gebaut wurden. Unter anderem sind dabei: Paypal, Netflix, airbnb und Dropbox. Es ist immer die Rede von "Single Page Applications". Wenn ich mir diese Webseiten ansehe, ist keine davon wirklich eine Single Page. Man kann auf bestimmte Links klicken und man landet auf einer anderen HTML Seite mit einer anderen URL. Der Browser lädt also tatsächlich die Seite neu.
Oder hab ich hier was übersehen/nicht verstanden? Das macht das doch zur Multi-Page-Application?

Meine zweite Frage: Ich möchte zur Übung einen ebay-kleinanzeigen-Klon schreiben. Eignet sich hierfür React? So wie ich es verstanden habe, sollte React geeignet sein.

Falls ja, dann habe ich noch eine Frage. Ich möchte es ja dem User möglich machen, seine Account-Daten zu managen. Ich habe also auf der Hauptseite einen Link der zum Account führt. Ich möchte das aber in einer anderen URL machen "(.../account/"). Wie binde ich diese Webseite ebenfalls als React-Komponente ein? Schließlich bin ich ja weg von der "Single Page Application".

Sorry für die evtl. Anfängerfragen, aber ich habe noch einiges zu lernen...

Ich bedanke mich im Vorraus

 

[Hellblazer]

Hast du Beispiele bei z.B. PayPal, wo man auf einer anderen Seite landet? Vielleicht war das ja gar keine React-App?

Die URL in der Adresszeile kann sich aber auch bei SPAs verändern. Wie das bei React ist, weiß ich nicht. Bei Angular ist das aber normal, dass in der Adresszeile trotzdem der Pfad zur Page steht (früher getrennt mit "#", mittlerweile gehts auch ohne).

Mit deinem Account managen verstehe ich nicht ganz. Hast du eine extra Webseite dafür oder willst du das in einer Page in der React-App machen?

 

[JP-M]

Single Page Application heißt nicht zwangsweise, dass man gar keine "echten" Seitenwechsel hat. Viele Seiten verfolgen eher das Ziel mehrere, nach Aufgaben getrennte und spezialisierte "Mini SPAs" zu benutzen und nicht eine einzige "riesige".

Diese lassen sich am Ende auch leichter auf verschiedene Server, je nach anfallender Last / Nutzung, verteilen. Hier kommt es halt ganz auf den Anwendungsfall an welche Art "SPA" geeignet ist.

Grundsätzlich eignet sich React für beide Varianten.

 

[new Account()]

Diese lassen sich am Ende auch leichter auf verschiedene Server, je nach anfallender Last / Nutzung, verteilen.

Klingt irgendwie nicht sehr überzeugend. Das vergrößert doch nur die Serverlast, da mehrere Apps geladen werden müssen.
Zudem ist eine SPA nur ein quasi einmaliger Download.
Und dann gibts sowieos noch lazy loading, und man kann noch einen loadbalancer dazwischen hängen.

 

[JP-M]

Mag für dich nicht überzeugend klingen, wird aber "leider" durchaus gemacht.

 

[Hellblazer]

@JP-M: hast du öffentlich zugängliche Beispiele, wo das so gemacht wird?
Das geht völlig gegen den Sinn einer SPA. Da haben wohl die Verantwortlichen "micro service architecture" etwas zu weit gedacht.

 

[Dalek]

Der typische Einsatz von React ist für SPAs, aber man kann auch einzelne React Komponenten innerhalb einer klassischen Webanwendung einbinden. Ist interessant wenn man z.B. im wesentlichen statische/serverseitig gerenderte Seiten hat und nur einzelne Teile interaktiv machen will. Oder wenn man eine ältere Webanwendung migriert.

Stichwort für URL ist "routing". Klassisch ist das serverseitig, bei React SPA machst du dann einfach client-seitiges routing. Man kann von JS aus einfach die URL manipulieren, bzw. auslesen und die entsprechenden Komponenten rendern. Gibt auch fertige Libraries dafür. In einer SPA kannst du die URL ändern ohne das die Seite neugeladen wird, und wenn jemand mit einer bestimmten URL die Seite aufrufst, kannst du dann einfach die korrekte Komponente anzeigen, wie z.B. die Accountmanagement Komponente.

 

[headhunter5575]

@Hellblazer
Ich habe dir mal zwei Screenshots angehängt. Es gibt eine URL zum managen des Accounts und es gibt die "Hauptseite" bzw. "HauptApplikation". Beide sind offensichtlich mit React geschrieben, aber wie gesagt, es ist keine SinglePageApplication.

Ich denke es ist das was @Dalek mit Routing meint. Ich weiß noch nicht wie das in React funktioniert.

 

[blubsterer]

Der Begriff der Single Page Application ist ein wenig unglücklich bzw. zumindest mehrdeutig.

Bei den 3 großen Javascript-Frameworks (ReactJS, VueJS, Angular) bezieht sich das mehr auf das initiale Markup, das beim ersten Seitenaufruf geladen wird. Denn unabhängig von der URL wird (sofern es sich um eine App handelt, die vollständig auf dem Client gerendert wird, dazu unten mehr), immer dasselbe Markup ausgeliefert. Etwas vereinfacht sieht das ungefähr so aus:

<html>
<head>
    <!-- hier kommen die Head Scripten hin -->
</head>
<body>
    <!-- ROOT Knoten -->
    <div id="app"></div>
    <!-- hier kommen die eigentlichen JS Skripten hin -->
    <script src="vendor.js"></script>
    <script src="a.js"></script>
</body>
</html>

Alle oben genannten JS-Frameworks verwalten die darzustellenden Seiteninhalte in sogenannten Shadow (oder Virtual) DOMs, die abhängig von bestimmten User-Aktionen (Klicks, Scrolling, Eingaben, URLs, etc...) darzustellen sind. Diese werden in den Root-Knoten (#app) per JS hineingerendert.

Hinzu kommt, dass alle diese Frameworks sogenannte Router Komponenten haben. Mit diesen lassen sich sehr komfortabel gültige URLs definieren, URL-Wechsel beobachten und entsprechend View-Anpassungen vornehmen. Das erfolgt aber alles clientseitig. Zu keinem Zeitpunkt wird tatsächlich ein neues HTML-Dokument vom Server angefordert.

Und daher rührt eigentlich auch der Begriff der SPA. Einmal das initiale HTML-Dokument mit den grundlegenden Ressourcen-URLs vom Server anfordern und dann auf dem Client entsprechend die Inhalte austauschen und ggf. neu benötigte Ressourcen "just in time" anfordern, also dann, wenn sie gebraucht werden.

Der URL-Wechsel ist im übrigen nicht gänzlich sinnbefreit, auch wenn es sich im eigentlichen Sinne zunächst einmal nur um eine Manipulation der Browser-History durch die oben erwähnten Router-Komponenten handelt. Als Vorteile wären zu nennen:

• Deeplink-Fähigkeit: der Anfangszustand der App richtet sich nach der URL, mit der die Seite aufgerufen wurde
• Suchmaschinen-Indexierbarkeit (der Googlebot ist mittlerweile ein Chrome der aktuellsten Generation und kommt ohne weiteres mit solchen Shadow DOMs zurecht)
• Bookmarkfähigkeit

Darüber hinaus gibt es für alle 3 Frameworks auch die Möglichkeit, sogenannte "isomorphe" Anwendungen zu erstellen. Dabei wird initial (abhängig von der angeforderten URL) eine vollständige HTML-Seite auf dem Server vorgerendert, dann an den Client übertragen und erst dann im Zuge weiterer Interaktionen die Seite clientseitig wie oben beschrieben manipuliert. Es wird auch dann nur einmal ein vollständiges HTML-Dokument übertragen, aber für jede URL, die in der App vorkommt, eben ein anderes. Der Vorteil dieses Ansatzes ist weniger Zeit bis zum "First meaningful paint". Der Nachteil: es macht es ein wenig aufwendiger.

Was Deine Frage anbelangt: so etwas lässt sich ohne Schwierigkeiten mit ReactJS erstellen. Es ist sogar noch ein eher trivialer Fall, weil es eine sehr überschaubare Anzahl an Routen benötigt. Ich selbst habe schon SPAs mit React und Vue erstellt, in denen ich gut 30 unterschiedliche URLs und Fallbacks benötigt habe.

 

[benneq]

Es gibt eine URL zum managen des Accounts und es gibt die "Hauptseite" bzw. "HauptApplikation"

Benutzeraccounts werden meist auf eine ganz eigene Plattform ausgelagert - das macht eigentlich jede große Plattform so. Stell dir vor, bei Google hätte jede Seite ihren eigenen "My Account" Bereich wo man sein Passwort und E-Mail Adresse ändern könnte. Das wäre zum einen ein enormer Entwicklungsaufwand, und zum anderen evtl. auch ein Sicherheitsrisiko, weil man von hunderten Stellen aus den Zugriff auf die Credentials ermöglichen müsste.

Zum eigentlichen Thema:

In React gibt es von Haus aus keine Routing Funktionalität. Man hat halt Zugriff auf die HTML5 Browser History und deren pushState Methode. Und selbstverständlich gibt's von Drittherstellern passende Routing Libraries, die auf die HTML5 Browser History aufbauen: react-router (vermutlich am verbreitetsten) und reach-router (der wird z.B. von gatsby benutzt).

Und ein bisschen abschweifen:

Grundsätzlich bin (oder vielleicht eher: war) ich großer Angular Fan. Alles schön strukturiert und typisiert und alles was man braucht aus einer Hand. Aber die Jungs kriegen es einfach nicht gesch*ssen die Developer Experience zu verbessern. Soll heißen: Es ist jedes mal ein Krampf und seitenweise Code nötig, um ein bisschen vorwärts zu kommen. Und die Typisierung fehlt seit Jahren an der wichtigsten Stelle: Formulare. Die Typisierung im Markup lässt auch zu wünschen übrig. Das wurde angeblich in der letzten Version mit Ivy endlich behoben. Bei React geht das schon seit Jahren problemlos, obwohl der TypeScript Support nur von der Community kommt.
Jetzt hat das Angular Team das erste mal eine wirklich öffentliche Roadmap aufgestellt und das Ziel geäußert ihre tausenden GitHub Issues zu bearbeiten. Bevor das nicht abgeschlossen ist, werde ich mich fernhalten.

React und VueJs haben in letzter Zeit dermaßen aufgeholt, dass es wirklich Spaß macht damit typsicher zu programmieren. Es geht einfach von der Hand und man erlangt schnell gute Ergebnisse.

Und wieder back to topic:

Soll heißen: Ich würde aktuell alles in Richtung SPA mit React schreiben. VueJs 3 sieht auch vielversprechend aus, aber das ist noch nicht offiziell draußen. Aber könnte dann in ein paar Monaten auch eine gute Alternative sein. VueJs 2 war schon mal ein solider Start, aber ich bin damit nicht so richtig warm geworden. Mit Version 3 sieht das schon deutlich hübscher aus. Ich bin gespannt.

 

[headhunter5575]

Danke an alle für die Antworten . Mir ist jetzt alles etwas klarer.