Einführung in React Server Components

Früher, wenn ein Benutzer auf eine React-Anwendung zugriff, gab der Server eine leere HTML-Datei mit einer oder mehreren JavaScript-Dateien zurück. Der Browser analysierte das HTML, lud dann die JavaScript-Dateien herunter und rendert die Webseite auf der Client-Seite.

Das Aufkommen von React Server Components (RSC) hat den Umfang von React erweitert. Wie der Name schon sagt, sind React Server Components Reacts serverseitige Komponenten. Sie laufen nur auf dem Server und können serverseitige Methoden aufrufen, auf Datenbanken zugreifen usw. Nach jedem Pre-Rendering sendet RSC das HTML an den Client, der es dann hydriert und formell rendert. Der Vorteil dieses Ansatzes besteht darin, dass ein Teil des Codes, der ursprünglich in der clientseitigen JavaScript-Datei enthalten war, nun auf dem Server ausgeführt werden kann, wodurch die clientseitige Belastung reduziert und die Gesamtleistung und Reaktionsgeschwindigkeit der Anwendung verbessert wird.

"Die Serverressourcen voll ausschöpfen" ist die größte Motivation für die Veröffentlichung von RSC. Mit anderen Worten, alles, was keine Interaktion erfordert, sollte auf dem Server platziert werden. Der React-Offizielle lieferte ein sehr typisches Beispiel - das Rendern von Markdown-Inhalten.

Clientseitiges Komponenten-Rendering

import marked from'marked'; // 35.9K (11.2K gzipped)
import sanitizeHtml from'sanitize-html'; // 206K (63.3K gzipped)

function NoteWithMarkdown({text}) {
  const html = sanitizeHtml(marked(text));
  return (/* rendering */);
}

In diesem Beispiel muss der Client, wenn er mit clientseitigen Komponenten gerendert wird, mindestens über 200 KB an Dateien herunterladen, um den Inhalt zu rendern. Der Markdown-Inhalt erfordert hier jedoch keine Interaktion und erzeugt keinen Bedarf an aktualisierten Informationen aufgrund von Benutzeraktionen, was sehr gut mit dem Konzept der Verwendung von RSC übereinstimmt. Wenn RSC verwendet wird:

Serverseitiges Komponenten-Rendering

import marked from'marked'; // zero packaging size
import sanitizeHtml from'sanitize-html'; // zero packaging size

function NoteWithMarkdown({text}) {
  // the same as before
}

Die Abhängigkeitspakete werden auf dem Server platziert, und der Server gibt nur den Inhalt zurück, den der Benutzer sehen muss. Das clientseitige Paket wird plötzlich um über 200 KB reduziert.

Bis zu diesem Punkt war die vorherrschende Meinung in der Community positiv, bis Next.js, basierend auf den Eigenschaften von RSC, aggressiv voranschritt, und dann traten Unterschiede auf.

Meinungsverschiedenheiten in der Community

Der grundlegendste Grund für die Meinungsverschiedenheiten ist, dass React das Konzept der Serverseite eingeführt hat. Serverseitige Komponenten und clientseitige Komponenten weisen offensichtliche Unterschiede auf:

• Serverseitige Komponenten können keine React-Hooks wie useState und useEffect verwenden; clientseitige Komponenten können dies.
• Serverseitige Komponenten haben keinen Zugriff auf Browser-APIs; clientseitige Komponenten haben volle Browser-API-Berechtigungen.
• Die Serverseite hat das Recht, direkt auf serverseitige Programme und APIs zuzugreifen; während clientseitige Komponenten nur über Anfragen auf einige Programme zugreifen können.

Mit der Veröffentlichung von Next.js v13 und v14 wurde RSC, das sich in React noch in der Canary-Version befindet, von Next.js in die Produktionsumgebung verschoben. 'use client' und 'use server' werden von immer mehr Menschen diskutiert. Entwickler sagen, es gäbe jetzt "zwei Reacts", und die Community hat begonnen, darüber zu streiten, ob React im Laufe der Jahre Fortschritte oder Rückschritte gemacht hat.

Gegensätzliche Stimmen in der Community

Renommierte Softwareentwicklerin Cassidy Williams

Sie wies auf die Entwicklungsprobleme von React in den letzten zwei Jahren hin:

• Die neuen Konzepte, die durch "zwei Reacts" entstanden sind, sind für die meisten Menschen kein klares und leicht verständliches Wissen. Diese Aufteilung kann zu zusätzlicher Verwirrung und Lernbarrieren führen.
• Seit Juni 2022 hat React nicht nur keine neuen Versionen veröffentlicht, sondern auch Entwickler ermutigt, Frameworks der oberen Ebene zu verwenden. Diese Frameworks der oberen Ebene veröffentlichten Funktionen basierend auf RSC, ohne darauf zu warten, dass RSC auf eine stabile Version aktualisiert wird (fast Nennung von Next.js).
• In den letzten Jahren sind einige Mitglieder von React den Teams anderer Frameworks der oberen Ebene beigetreten. Sie haben nicht nur versäumt, die Version zu aktualisieren, sondern auch die Dokumentation zu aktualisieren.

Tanner Linsley, der Entwickler von React Query

Er äußerte auch Bedenken und Unzufriedenheit mit der Entwicklung von React:

• Seit React Hooks und die Suspense-API eingeführt hat, hat sich React übermäßig auf einige wenige Konzepte konzentriert. Obwohl diese neuen Konzepte die Grenzen und Grenzen der Single-Thread-UI-API technisch erweitern, haben sie wenig Auswirkungen auf seine tägliche Arbeit, den Benutzern einen Mehrwert zu bieten.
• Ausgehend von der Veröffentlichung von RSC verfolgt das React-Team nicht mehr so stark das Ziel der clientseitigen Leistung.

Tom MacWright, ein Experte für Kartentechnik und Visualisierungstechnologie

Er kritisierte die Fragmentierung des React-Ökosystems:

• Derzeit wird React nur langsam aktualisiert. Stattdessen stehen zwei Frameworks der oberen Ebene, Remix (finanziert von Shopify) und Next.js (finanziert von Vercel), in einem harten Wettbewerb.
• Die Schnittmenge zwischen dem React-Team und dem Next.js-Team ist zu groß, was Vercel einen Vorsprung verschafft. Andere Frameworks, die nicht zum Vercel- und Facebook-Ökosystem gehören, wie z. B. Remix, sind von Fehlern in React betroffen, die behoben, aber nicht veröffentlicht wurden.

Positive Einstellungen in der Community

Angesichts der zunehmenden Anzahl von gegensätzlichen Stimmen in der Community äußerte sich auch Dan Abramov, ein wichtiger Mitwirkender von React, mehrmals zu seinen Ansichten. Er hat eine offene Haltung gegenüber technologischen Veränderungen:

• Der App Router von Next.js hat große Ambitionen, befindet sich aber noch in der Anfangsphase der Entwicklung und wird in Zukunft weiter verbessert.
• Die Arbeit von clientseitigen Komponenten ist UI = f(state), und die Arbeit von serverseitigen Komponenten ist UI = f(data). React hofft, die Vorteile beider zu kombinieren, um UI = f(data, state) zu erreichen. Er forderte die Community auf, gemeinsam die Verwirklichung dieses Ziels zu fördern.
• In Bezug auf die Veröffentlichung von RSC in der Produktionsversion durch Next.js ist Dan der Meinung, dass "produktionsreif" eine subjektive Einschätzung ist. Obwohl sich RSC noch in der Canary-Version befindet, hat Facebook es bereits in großem Umfang eingesetzt. Er glaubt, dass die Überprüfung in der Praxis die Technologie schneller verbessern und letztendlich Reife und Stabilität erreichen kann.
• Die Entwicklung neuer Technologien ist ein schrittweiser Prozess, der kontinuierliche Tests, Feedback und Iteration beinhaltet. Die Kraft der Community ist sehr wichtig.

Insgesamt hofft Dan, dass alle ihre Vorurteile ablegen und gemeinsam die Transformation von React in die nächste Phase in der Praxis erkunden können.

Fazit

RSC hat definitiv eine positive Bedeutung für die Verbesserung der modernen Webanwendungsentwicklung. Die offensichtlichsten Vorteile sind, dass es die Leistung von großen Anwendungen verbessern, die clientseitige Last reduzieren, den Datenerfassungsprozess optimieren usw. kann. Die Erledigung dieser Aufgaben durch RSC ist bequemer als die bisherigen SSR-Lösungen.

Mit der Veröffentlichung von Node v20 und der Anwendung von RSC wird der Abstand zwischen dem Front-End und der Serverseite weiter verringert. Wir haben die Möglichkeit, die "Backendisierung" der Front-End-Arbeit mitzuerleben - Front-End-Ingenieure werden mehr Aufgaben übernehmen, die traditionell zum Back-End gehören, wie z. B. Datenabfrageoptimierung, Serverressourcenmanagement usw. Dies öffnet tatsächlich eine Tür für Front-End-Ingenieure und gibt uns die Möglichkeit, das gesamte Web umfassend zu beherrschen.

Leapcell: Die beste Serverless-Plattform für Nodejs-Hosting

Abschließend empfehle ich eine Plattform, die sich am besten für die Bereitstellung von Node.js-Diensten eignet: Leapcell

1. Mehrsprachige Unterstützung

• Entwickeln Sie mit JavaScript, Python, Go oder Rust.

2. Stellen Sie unbegrenzt Projekte kostenlos bereit

• Zahlen Sie nur für die Nutzung - keine Anfragen, keine Gebühren.

3. Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

4. Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

5. Mühelose Skalierbarkeit und hohe Leistung

• Auto - Skalierung zur einfachen Bewältigung hoher Parallelität.
• Null Betriebsaufwand - konzentrieren Sie sich einfach auf das Bauen.

Erfahren Sie mehr in der Dokumentation!

Leapcell Twitter: https://x.com/LeapcellHQ