Next.js App Router: Der Leitfaden für Thinking Server by Default

Als Next.js den App Router startete, tat es etwas, das technisch zu sein schien, im Wesentlichen aber eine Mentalitätsentscheidung war: Es kehrte das Muster um. Früher war jede Komponente Eigentum des Kunden, bis Sie etwas anderes sagten. Jetzt ist jede Komponente serverseitig, bis Sie überprüfen, ob sie clientseitig sein muss.

Diese Inversion ist in der Syntax klein und in der Praxis riesig. Es verändert die Frage, die das Team jeder Komponente stellt. Anstatt davon auszugehen, dass alles im Browser läuft, begründen Sie, warum dort etwas laufen müsste.

Für diejenigen, die mit dem traditionellen React arbeiten, ist der App Router nicht nur ein neuer Ordner mit einem anderen Router. Es ist eine Einladung, zu überdenken, wo jeder Teil der Anwendung untergebracht werden soll. Und diese Einladung neigt dazu, die Orientierung zu verlieren, bevor sie einen Sinn ergibt.

Das Muster hat sich umgekehrt

In App Router sind Layouts und Seiten standardmäßig Serverkomponenten. Das bedeutet, dass, wenn Sie eine neue Seite erstellen, diese auf dem Server ausgeführt wird, ohne dass Sie etwas tun müssen. Sein Code wird nicht an den Browser gesendet, und die Datensuche kann direkt dort erfolgen, bevor die Antwort ausgegeben wird.

Die unmittelbare Konsequenz ist, dass viele Dinge, die Sie an den Client übertragen würden, nun natürlich auf dem Server verbleiben. Die Produktliste, der Artikelinhalt, der Header mit Benutzerdaten, all dies wird vor dem Eintreffen gerendert, ohne dass JavaScript-Kosten auf dem Gerät anfallen.

Wenn Sie Interaktivität benötigen, markieren Sie die Komponente mit der "use client"-Anweisung. Von diesem Zeitpunkt an werden diese Komponente und das, was sie rendert, im Browser ausgeführt, mit Status und Ereignissen. Es handelt sich um eine explizite Grenze, nicht um einen Zufall.

Der gesunde Nebeneffekt ist, dass der Kunde zur bewussten Ausnahme wird. Man fällt nicht durch Trägheit hinein, sondern man entscheidet selbst, wann man einsteigt. Wenn dies immer noch abstrakt klingt, lohnt es sich, einen Blick darauf zu werfen, was React Server Components](/post/o-que-sao-react-server-components) sind, bevor Sie fortfahren.

Wenn die Komponente ein Server sein muss

Die richtige Frage betrifft die Art der Arbeit. Wenn die Komponente nur Informationen sucht und anzeigt, hat sie alle Voraussetzungen, um ein Server zu sein. Auflistungsseiten, Blog-Inhalte, Bestelldetails, Dashboards, die nur Zahlen anzeigen: Für all das ist kein Browser erforderlich.

Serverkomponenten glänzen beim Abrufen von Daten. Sie konsultieren direkt die Bank, rufen interne Dienste mit der geringen Latenzzeit derjenigen innerhalb der Infrastruktur auf und erstellen das fertige Ergebnis. Sie benötigen keine Zwischen-API-Route, nur damit der Browser die Daten anfordern kann, da sich die Komponente bereits auf der rechten Seite befindet.

Es gibt auch den Vorteil, das Gewicht des Klienten zu reduzieren. Umfangreiche Formatierungsbibliotheken, Markdown-Verarbeitung, Datumsmanipulation: Wenn dies auf dem Server läuft, gelangt es nie in das Paket, das der Benutzer herunterlädt. Das Paket schrumpft und das Gerät des Benutzers dankt es Ihnen.

Die mentale Regel, die funktioniert, lautet: Beginnen Sie mit der Übernahme des Servers. Gehen Sie nur dann zum Kunden, wenn ein konkreter Interaktionsbedarf besteht. Dem Drang zu widerstehen, als Kunde alles zu brandmarken, ist die halbe Miete.

Wenn die Komponente clientseitig sein muss

Nicht alles passt auf den Server und der Versuch, dies zu erzwingen, führt zu Frustration. Es gibt klare Situationen, die Kunden erfordern, und wenn man sie schnell erkennt, vermeidet man Zeitverschwendung.

Der erste ist der Zustand, der sich auf dem Bildschirm ändert. Ein Zähler, eine ausgewählte Registerkarte, ein Menü, das sich öffnet und schließt: Alles, was sich zwischen Interaktionen merken muss, lebt im Client. Das zweite ist ein Benutzerereignis. Klicken, Tippen, Ziehen – jede direkte Manipulation erfolgt im Browser, denn dort befindet sich der Benutzer.

Der dritte ist die Nutzung von Browserressourcen. Der Zugriff auf lokalen Speicher, Geolokalisierung, Lesefenstergröße und alles, was nur in der Browserumgebung vorhanden ist, erfordert, dass die Komponente clientseitig ist. Es gibt keine Möglichkeit, dies auf dem Server auszuführen, da der Server einfach kein Fenster und keine Maus hat.

Das Detail, das den Geist des Teams freischaltet, ist das Verständnis, dass es hier nicht um alles oder nichts geht. Sie können eine Serverseite haben, die eine kleine Clientkomponente nur für die interaktive Schaltfläche rendert. Der Rest der Seite bleibt kompakt und wird auf dem Server gerendert. Interaktivität wird dort isoliert, wo sie wirklich wichtig ist, anstatt die gesamte Seite zu verunreinigen.

Datensuche ändert den Standort

Im alten Modell war das Abrufen von Daten ein bekanntes Ritual: Die Komponente wurde zusammengesetzt, löste einen Effekt aus, der als API bezeichnet wurde, kümmerte sich um Lade- und Fehlerzustände und aktualisierte den Zustand, wenn die Antwort zurückkam. Es funktionierte, aber es war ausführlich und voller Fallstricke.

Mit Serverkomponenten wird das Abrufen von Daten wieder unkompliziert. Sie holen sich die Daten beim Rendern auf dem Server, warten dort auf das Ergebnis und geben die fertige Schnittstelle zurück. Fügen Sie dem Client viel Tanz der Ladezustände hinzu, da die Daten bereits mit der Seite ankommen.

Dies vereinfacht den Code und verbessert gleichzeitig das Erlebnis, was selten vorkommt. Der Benutzer erhält bereits ausgefüllte Inhalte, ohne dass beim Laden jedes Teils die Folge leerer Bildschirme blinkt. Und wenn Sie progressives Laden benötigen, bietet das Framework Streaming an, um Blöcke zu liefern, sobald sie bereit sind – ein Thema, mit dem es sich zu beschäftigen lohnt Caching und Streaming in Next.js.

Die Datenmutation folgt einer ähnlichen Logik. Anstatt für jedes Formular eine vollständige API zusammenzustellen, können Sie Serveraktionen verwenden, Funktionen, die auf dem Server ausgeführt und direkt von der Schnittstelle aufgerufen werden. Damit schließt sich der Kreislauf: Lesen und Schreiben nah an der Quelle, ohne Schichten, die nur dazu da waren, dem Browser zu dienen.

Der Mentalitätswandel, mit dem das Team konfrontiert ist

Das Schwierige an App Router ist nicht die Syntax. Es verlernt den Reflex, dass alles im Browser läuft. Teams mit Erfahrung in React neigen aus Gewohnheit dazu, Komponenten als Client zu markieren, weil sie so gelernt haben, und verlieren dann einen Großteil des Gewinns.

Das klassische Symptom ist das "use client" oben in fast jeder Datei. Wenn dies geschieht, wird die Anwendung wieder zu einer getarnten SPA, mit dem Gewicht von vorher und der neuen Komplexität obendrauf. Das Team muss verinnerlichen, dass jeder Kundentermin eine Entscheidung ist, die es zu rechtfertigen gilt, und kein Muster, das es zu kopieren gilt.

Es gibt auch eine mentale Anpassung darüber, wo der Code ausgeführt wird. Wenn man davon ausgeht, dass ein Teil des Baums auf dem Server und ein Teil auf dem Browser läuft, muss man sich Gedanken darüber machen, was jede Seite tun kann. Der Versuch, eine Browserfunktion in einer Serverkomponente zu verwenden, führt zu Fehlern, und diese anfänglichen Stolpersteine sind ein normaler Teil des Lernens.

Sobald der Groschen fällt, wird das Modell intuitiv. Die Frage stellt sich, ob diese Interaktion automatisch erfolgen muss, und das Team beginnt standardmäßig mit dem Entwurf einfacher Schnittstellen. Um dorthin zu gelangen, ist jedoch eine technische Führung erforderlich, die bereit ist, den Code geduldig zu überprüfen und alte Reflexe zu korrigieren.