CSR in Next.js verstehen: Clientseitiges Rendering erklärt

CSR (Client-Side Rendering) ist eine Methode zum Rendern einer Seite auf der Client-Seite, was bedeutet, dass sie nicht auf dem Server ausgeführt wird. CSR ist im Wesentlichen dasselbe wie SPA (Single Page Application). Wenn Sie also wissen, was eine SPA ist und wie sie funktioniert, verstehen Sie CSR bereits. Aber wenn Sie nicht sicher sind, was SPA ist oder wie es funktioniert, erkläre ich es Ihnen unten.

In diesem Artikel beschreibe ich, was SPA ist und wie es funktioniert. Danach vergleiche ich es mit CSR in Next.js und zeige Ihnen, wie Sie CSR in Ihrem Next.js-Projekt implementieren.

Was ist SPA?

Eine SPA (Single Page Application) besteht aus einer einzelnen HTML-Seite, die Inhalte nach Bedarf dynamisch umschreibt, anstatt für jede Interaktion eine neue HTML-Seite zu laden.

Wie funktioniert MPA?

Bevor Sie SPA verstehen, sollten Sie zunächst etwas über MPA wissen. Lasst uns mehr darüber erfahren:

Bevor SPAs populär wurden, wurden Websites mit dem Multi-Page-Application-Ansatz (MPA) erstellt. Wie funktionierten MPAs? Stellen Sie sich vor, Sie möchten als Entwickler eine Website mit zwei Seiten erstellen: der Startseite („/“) und einer About-Seite („/about“). Um dies mit der Multipage-Methode zu erstellen, müssten Sie für jede Route zwei separate HTML-Dateien erstellen: main.html für „/“ und about.html für „/about“.

In jede HTML-Datei müssten Sie spezifischen HTML-, CSS- und JavaScript-Code für diese Seite schreiben. Einige Teile des Codes, wie die Kopf- und Fußzeile, sind jedoch auf allen beiden Seiten gleich. Auch wenn Kopf- und Fußzeile identisch sind, müssten Sie als Entwickler sie in jeder HTML-Datei wiederholen.

Wenn das Projekt abgeschlossen und auf einem Server bereitgestellt ist, sendet der Server die vollständige HTML-Seite zusammen mit allen angeforderten Ressourcen an den Benutzer. Wenn ein Benutzer beispielsweise die Homepage zum ersten Mal besucht, sendet der Server die fertige Datei main.html und der Benutzer kann den Inhalt nach einer kurzen Wartezeit sofort sehen. Diese Methode ist gut für SEO, denn wenn ein Suchmaschinen-Crawler Ihre Website besucht, kann er den gesamten Inhalt der HTML-Datei sehen, da dieser zuvor vollständig gerendert wurde.

Wenn der Benutzer jedoch zu einer anderen Seite navigiert, z. B. „/about“, beginnt der Vorgang erneut. Der Server sendet die Datei about.html zusammen mit allen ihren Ressourcen (CSS, JS usw.). Der Benutzer muss noch einmal warten, bis die Seite geladen ist, und wenn seine Internetverbindung langsam ist, ist die Wartezeit länger. Noch ineffizienter ist, dass der Benutzer denselben Code für die Kopf- und Fußzeile erneut herunterladen muss, obwohl er sich nicht geändert hat. Diese Wiederholung von Code (wie Kopf- und Fußzeile) ist in den heutigen Webentwicklungspraktiken verschwenderisch und ineffizient.

Wie funktioniert SPA?

Da Sie nun verstanden haben, wie MPA (Multi-Page Application) funktioniert, wollen wir uns mit der Funktionsweise einer SPA befassen.

Aufgrund der Verzögerung beim Laden von Seiten bei jeder Anfrage, der Wiederholung des Codes und der Notwendigkeit, das gesamte DOM jedes Mal neu zu erstellen, wurden SPAs eingeführt, um diese Probleme zu lösen.

Stellen Sie sich vor, Sie sind Entwickler und erstellen eine Website mit zwei Routen: „/“ und „/about“. In einem SPA-Framework gibt es nur eine HTML-Datei namens index.html. Anstatt für jede Route separate HTML-Dateien zu erstellen, erstellen Sie Komponenten für jede Seite und laden sie dynamisch. Sie würden beispielsweise drei Komponenten erstellen – eine für jede Route, und sie in Ihre index.html importieren.

In SPAs können Sie auch wiederverwendbare Abschnitte Ihrer Website (wie die Kopf- und Fußzeile) in ihre eigenen Komponenten aufteilen. Anstatt für jede Seite denselben Kopf- und Fußzeilencode zu schreiben, importieren Sie diese Komponenten einfach dort, wo sie benötigt werden, ähnlich wie bei der Funktionsweise von Funktionen. Dies reduziert Wiederholungen und erleichtert die Entwicklung.

Wenn Ihr SPA-Projekt auf einem Server bereitgestellt wird, rendert der Server den Inhalt der Seite nicht mehr. Stattdessen wird die Datei index.html zusammen mit den JavaScript-Bundles bereitgestellt, die Ihre Komponenten enthalten. Das Rendern erfolgt clientseitig im Browser.

Wenn ein Benutzer Ihre Website zum ersten Mal besucht, sendet der Server die Datei index.html zusammen mit den erforderlichen JavaScript-Dateien. Dies kann im Vergleich zu einem MPA zu einer längeren Wartezeit führen, da das gesamte DOM erstellt wird, nachdem das JavaScript vollständig heruntergeladen, analysiert und ausgeführt wurde.

Sobald jedoch die erste Seite geladen ist, ist die Navigation zwischen den Seiten in einem SPA viel schneller. Wenn der Benutzer beispielsweise von / nach /about navigiert, muss der Browser nicht die gesamte Seite neu laden. Da allgemeine Elemente wie Kopf- und Fußzeile bereits geladen sind, ruft der Browser nur das JavaScript für den spezifischen Inhalt ab, der sich ändert (z. B. den Seiteninhalt /about). Das DOM wird dynamisch aktualisiert, ohne dass eine vollständige Seitenaktualisierung erforderlich ist, sodass der Benutzer das Gefühl hat, mit einer App und nicht mit einer herkömmlichen Website zu interagieren. Dies sorgt für ein flüssigeres, „App-ähnlicheres“ Erlebnis.

SPAs haben jedoch auch eine Kehrseite, insbesondere wenn es um SEO geht. Da die ursprüngliche index.html-Datei nur minimalen Inhalt enthält (wobei die meisten Daten über JavaScript geladen werden), sehen Suchmaschinen-Crawler möglicherweise eine leere Seite und haben Schwierigkeiten, den Inhalt zu indizieren. Aus diesem Grund kann SEO in SPAs im Vergleich zu herkömmlichen MPAs eine Herausforderung sein.

Ist CSR dasselbe wie die SPA-Methode?

Ja, CSR (Client-Side Rendering) ist eine Rendering-Methode, d. h. der Prozess der Konvertierung von Komponenten in ein Format, das im Browser angezeigt werden kann, sodass der Benutzer die Seite sehen kann. Es ist wichtig zu verstehen, dass CSR vollständig im Browser stattfindet. Für React und Next.js funktioniert CSR auf die gleiche Weise, es gibt keinen Unterschied zwischen den beiden, wenn es um das clientseitige Rendering geht.

Beim CSR sendet der Server beispielsweise beim ersten Besuch einer Website eine index.html-Datei mit minimalem Inhalt. Aber hier ist der Haken: Diese Datei hat noch nicht den vollständigen Inhalt. Der eigentliche Inhalt wird im Browser gerendert, nachdem alle notwendigen Komponentendateien (JavaScript, CSS usw.) heruntergeladen wurden. Anschließend erstellt React den DOM-Baum (Document Object Model) und erstellt anschließend ein virtuelles DOM, das einer leichten Kopie des realen DOM ähnelt.

Sobald das DOM und das virtuelle DOM eingerichtet sind, kann der Benutzer die Seite sehen. Dieser Rendering-Prozess findet im Browser statt und wandelt alle Komponenten in eine anzeigbare Seite um.

Wenn der Benutzer nun von einer Seite zur anderen navigiert (z. B. von / nach / ungefähr), erstellt React ein neues virtuelles DOM für die neue Seite. Es vergleicht das alte virtuelle DOM mit dem neuen, findet die Unterschiede und wendet diese Änderungen auf das reale DOM an. Dieser Prozess des Vergleichens und Aktualisierens des DOM erfolgt effizient und alles findet im Browser statt.

Zusammenfassend lässt sich sagen, dass CSR sowohl in React als auch in Next.js auf die gleiche Weise funktioniert. Das Rendering erfolgt im Browser und React verarbeitet DOM-Aktualisierungen effizient mithilfe des virtuellen DOM, wodurch die Benutzererfahrung reibungslos und schnell erfolgt.

Wie implementiert man CSR in Next.js?

Wenn Sie in Ihrer Komponente clientseitige Methoden wie useEffect anstelle von serverseitigen Methoden wie getStaticProps oder getServerSideProps verwenden, wird Ihre Seite auf dem Client gemäß der CSR-Methode (Client-Side Rendering) gerendert. Dies bedeutet, dass der Browser das Rendern übernimmt, nachdem der ursprüngliche HTML-Code geladen wurde.

Darüber hinaus ermöglicht die Verwendung von Bibliotheken wie SWR oder TanStack Query auch CSR, da diese Bibliotheken den Datenabruf im Client übernehmen, nachdem die Seite geladen wurde. Auf diese Weise wird Ihre Komponente im Browser gerendert und alle Datenaktualisierungen erfolgen nahtlos auf der Clientseite, ohne Beteiligung des Servers.

Abschluss

CSR ist eine Methode zum Rendern unseres Projekts im Client und entspricht im Wesentlichen der SPA-Definition (Single Page Application). React verwendet CSR zum Rendern, und dies ist einer der Hauptunterschiede zwischen MPA (Multi-Page Applications) und SPA. Next.js verwendet ebenfalls CSR, da es auf React aufbaut, aber um SEO zu verbessern und das Benutzererlebnis zu verbessern, hat Next.js SSG, ISR und SSR hinzugefügt. Sie können über SSR, ISR und SSG lesen. Wenn Sie über meine neuesten Artikel auf dem Laufenden bleiben möchten, folgen Sie meiner Website unter https://saeed-niyabati.ir . Vielen Dank fürs Lesen! Tschüss!

Das obige ist der detaillierte Inhalt vonCSR in Next.js verstehen: Clientseitiges Rendering erklärt. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!