App Router und Routing-Grundlagen

App Router und Routing-Grundlagen

0:00 In diesem Modul geht es um die Frage, wie aus Ordnern auf Ihrer Festplatte Adressen im Browser werden. Das klingt nach einem Thema, das man in zehn Minuten abhandelt — und tatsächlich ist die Grundregel schnell erzählt. Interessant wird es an den Stellen, an denen der App Router mehr kann, als die meisten nutzen: Layouts, die ihren Zustand behalten, Ordner, die in der URL unsichtbar bleiben, und Bereiche, die unabhängig voneinander laden.

0:24 Am Ende dieses Moduls steht die Grundstruktur des Hafenmeister-Portals. Und Sie kennen eine Eigenschaft von Layouts, die harmlos aussieht und uns im Sicherheitsmodul noch beschäftigen wird.

Dateibasiertes Routing verstehen

0:35 Fangen wir mit dem Grundprinzip an. Dateibasiertes Routing kennen viele aus anderen Frameworks, und die erste Reaktion ist oft: Das habe ich verstanden, weiter. Der App Router weicht aber in einem Detail von dem ab, was Sie vielleicht aus dem älteren Pages Router kennen — und dieses Detail ist der Grund für fast alles, was danach kommt.

0:54 Es lohnt sich also, kurz genau hinzusehen, bevor wir zu den Bausteinen gehen. Das Prinzip ist so einfach, dass es fast nicht der Rede wert scheint: Ihre Ordnerstruktur ist Ihre Adressstruktur. Ein Verzeichnis mit dem Namen liegeplaetze wird zur Adresse Schrägstrich liegeplaetze. Verschachtelte Ordner ergeben verschachtelte Pfade.

1:13 Sie pflegen also keine Routingtabelle mehr, in der Pfade und Komponenten von Hand verheiratet werden — das Dateisystem ist die Tabelle. Der Unterschied zum Pages Router steckt in einem Wort: Nicht die Datei ist die Route, sondern der Ordner. Warum das mehr ist als Wortklauberei, sehen wir gleich. Der Grund ist einfach: Ein Ordner kann mehrere Dateien tragen, eine Datei nur sich selbst.

1:37 Wenn die Route ein Ordner ist, können Sie an dieser Stelle nicht nur sagen, was angezeigt wird, sondern auch, was während des Ladens erscheint, was bei einem Fehler passiert und welche Hülle darum liegt. Vorher waren das Entscheidungen für die gesamte Anwendung, jetzt sind sie Entscheidungen je Ebene. Der zweite Gewinn ist praktischer Natur: Nur Dateien mit festgelegten Namen erzeugen eine Adresse.

2:00 Alles andere darf danebenliegen — Komponenten, Tests, Hilfsfunktionen, alles, was fachlich dorthin gehört. Sehen Sie sich die rechte Spalte an, dann haben Sie das Prinzip. Der Ordner trägt den Namen, die Datei heißt immer gleich. Das wirkt beim ersten Mal ungewohnt, weil Sie am Ende ein Dutzend Dateien mit identischem Namen im Projekt haben.

2:20 In der Praxis stört das weniger, als man denkt — die Editoren zeigen den Ordner mit an, und Sie suchen ohnehin nach dem Bereich, nicht nach der Datei. Interessant ist die dritte Zeile mit den eckigen Klammern. Die kommt aus den Daten, nicht aus Ihrer Ordnerstruktur, und ist gleich ein eigenes Kapitel wert. Der erste Punkt kostet regelmäßig eine Viertelstunde Fehlersuche: Ein Ordner ohne die richtige Datei ist keine Route.

2:45 Sie können dort ein Layout, einen Ladezustand und eine Fehlergrenze anlegen — die Adresse bleibt trotzdem eine Vierhundertvier, weil der Inhalt fehlt. Das fühlt sich falsch an, ist aber konsequent: Ein Ordner ist erst dann eine Seite, wenn er eine hat. Der dritte Punkt ist unauffälliger und schmerzt später: Groß- und Kleinschreibung im Ordnernamen landet unverändert in der Adresse.

3:07 Was Sie hier tippen, steht irgendwann in einer E-Mail-Signatur.

Pages, Layouts und Templates

3:11 Kommen wir zu den drei Bausteinen, aus denen jede Seite besteht. Zwei davon sehen auf den ersten Blick identisch aus und verhalten sich vollkommen unterschiedlich. Der Unterschied lässt sich in einem einzigen Wort zusammenfassen — Zustand — und er entscheidet darüber, ob Ihre Oberfläche bei jedem Klick flackert oder ruhig bleibt.

3:30 Wir sehen uns an, welcher Baustein wofür gedacht ist und woran Sie die Wahl festmachen. Denken Sie an einen Bilderrahmen an der Wand. Die Seite ist das Bild, das Layout ist der Rahmen. Wenn Sie das Bild wechseln, bleibt der Rahmen hängen — genau so verhält sich ein Layout bei der Navigation: Es bleibt bestehen, behält seinen Zustand und rendert nicht neu.

3:51 Das Template sieht aus wie ein Rahmen, wird aber bei jedem Bildwechsel abgenommen und neu aufgehängt. Alles, was darin steckte, ist danach weg. Beides ist manchmal richtig. Die Frage ist nur, ob der Zustand bleiben soll oder verschwinden. Diese wenigen Zeilen sind der Rahmen um Ihre gesamte Anwendung, und zwei Dinge daran sind Pflicht: Es muss existieren, und es muss die äußeren Dokumentelemente enthalten.

4:15 Das ist ungewohnt, wenn Sie aus React-Projekten kommen, wo diese Struktur in einer Indexdatei stand, die niemand mehr angefasst hat. Hier ist sie Teil Ihres Codes — Sie können also je nach Sprache umschalten, Schriften einbinden oder globale Anbieter setzen. Worauf es ankommt: Alles, was Sie hier hineinschreiben, läuft auf jeder einzelnen Seite. Das macht diese Datei gleichzeitig mächtig und gefährlich.

4:39 Diese Tabelle beantwortet die Frage in vier Zeilen, aber die eigentliche Entscheidungshilfe steht darunter: Im Zweifel Layout. Das Template ist die Ausnahme, nicht die Alternative. Der Grund liegt in dem, was Nutzer erwarten. Ein Menü, das sich bei jedem Seitenwechsel wieder zuklappt, wirkt kaputt, auch wenn technisch alles stimmt.

4:58 Umgekehrt gibt es genau die Fälle, in denen das Zurücksetzen erwünscht ist — ein mehrstufiges Formular etwa, das beim zweiten Aufruf nicht die alten Eingaben zeigen soll. Fragen Sie sich also nicht, welcher Baustein moderner ist, sondern was mit dem Zustand passieren soll. Machen wir es an unserem Portal fest. Die Kopfzeile mit Hafenname und Benutzermenü gehört ins Wurzel-Layout: Sie soll stehen bleiben, egal wohin der Gast klickt.

5:24 Der Buchungsassistent dagegen führt über mehrere Schritte, und wenn jemand ihn verlässt und später neu beginnt, soll er von vorn anfangen — also ein Template. Sie sehen an diesem Paar, dass die Entscheidung nicht technisch ist, sondern fachlich. Und Sie merken sie in beide Richtungen: Ein Layout, das seinen Zustand verliert, lässt die Oberfläche flackern. Ein Template, das ihn behält, zeigt Eingaben von gestern.

Dynamische Segmente

5:49 Bisher haben wir Adressen gebaut, die wir selbst angelegt haben. Jetzt kommt der Fall, der in echten Anwendungen überwiegt: Adressen, die aus Daten entstehen. Für jeden Liegeplatz eine eigene Seite anzulegen, wäre absurd — es gibt dreihundert davon, und morgen kommt einer dazu. Wir sehen uns an, wie das gelöst wird, und stoßen dabei auf einen Punkt, der später sicherheitsrelevant wird.

6:13 Ein Ordnername in eckigen Klammern ist ein Platzhalter. Der Ordner heißt nicht mehr liegeplatz-zwoelf, sondern schlicht nummer — und bedient damit alle Liegeplätze auf einmal. Der konkrete Wert kommt zur Laufzeit aus der Adresse und landet in Ihrer Komponente. Eine Besonderheit sollten Sie sich merken: Diese Parameter kommen als Versprechen an, nicht als fertiger Wert. Sie müssen also darauf warten.

6:36 Das wirkt umständlich, hat aber einen Grund, den wir in Modul fünf verstehen werden — es hängt damit zusammen, wann eine Seite gebaut werden kann. Worauf es hier ankommt, sind zwei Dinge. Das eine ist das Warten auf den Parameter, das andere ist der Typ, der die Route als Text enthält. Dieser Typ wird von Next.js selbst erzeugt, aus Ihrer Ordnerstruktur — Sie schreiben ihn nicht, Sie bekommen ihn.

7:00 Der praktische Nutzen zeigt sich beim Umbenennen: Wenn Sie den Ordner umbenennen und vergessen, die Komponente anzupassen, sagt Ihnen das die Typprüfung, statt dass Sie es im Browser bemerken. Das ist genau der Gewinn, den ich in Modul eins angekündigt habe. Drei Schreibweisen, und der Unterschied ist die Anzahl der Segmente. Die erste ist der Normalfall und deckt das meiste ab.

7:23 Die anderen beiden werden gebraucht, wenn die Tiefe der Adresse selbst variabel ist — bei einer Dokumentation etwa, in der Kapitel beliebig verschachtelt sind, oder bei Dateipfaden. Mein Rat: Greifen Sie erst dann zu den Sammelvarianten, wenn Sie den Fall wirklich haben. Sie machen die Route flexibel, aber auch unschärfer, und Sie müssen im Code entscheiden, was ein leerer Pfad bedeutet. Der einfache Platzhalter ist die ehrlichere Zusage.

7:48 Der zweite und dritte Punkt sind die wichtigen, und sie hängen zusammen. Ordner in Klammern sind Benutzereingabe — jeder kann in die Adresszeile schreiben, was er möchte. Wenn dieser Wert ungeprüft in eine Datenbankabfrage fließt, haben Sie eine offene Tür gebaut, ohne es zu merken. Machen Sie es sich zur Gewohnheit, diese Werte wie Formulardaten zu behandeln. Wir kommen in Modul sieben und elf darauf zurück.

8:12 Der vierte Punkt ist ein Vorgriff auf das Rendering: Ein Warten auf den Parameter im Layout verhindert, dass die Seite vorab gebaut werden kann.

Route Groups und private Ordner

8:21 Jetzt zu zwei kleinen Werkzeugen, die überraschend viel Ordnung schaffen. Beide lösen dasselbe Problem aus zwei Richtungen: Sie wollen Ihren Code strukturieren, ohne dass diese Struktur in den Adressen sichtbar wird. Denn Ordner sind Adressen — und das heißt normalerweise, dass jede Aufräumaktion die URLs ändert. Diese beiden Klammerformen brechen genau diese Kopplung auf.

8:44 Ein Ordner in runden Klammern ist für das Routing unsichtbar. Er gruppiert, ohne in der Adresse zu erscheinen. Damit können zwei Bereiche Ihrer Anwendung vollkommen unterschiedliche Layouts bekommen, obwohl beide direkt unter der Wurzel liegen. Der Ordner mit dem führenden Unterstrich geht noch weiter: Er bleibt komplett aus dem Routing heraus.

9:03 Stellen Sie sich das wie die Rückseite einer Bühne vor — dort steht alles, was gebraucht wird, aber das Publikum sieht davon nichts, egal wie viel dort liegt. Das ist die Aufteilung, die wir für das Hafenmeister-Portal übernehmen. Achten Sie auf die rechte Spalte: Die Klammern verschwinden vollständig. Die Tarifseite liegt unter Schrägstrich tarife, nicht unter oeffentlich Schrägstrich tarife. Der Gewinn ist doppelt.

9:27 Erstens bekommen die beiden Bereiche eigene Layouts, Ladezustände und Fehlerseiten — der öffentliche Auftritt sieht anders aus als der angemeldete Bereich. Zweitens bleiben die Adressen kurz und sprechend. Und sollten Sie später den Zuschnitt ändern, ändern sich die Adressen nicht mit. Das ist mehr wert, als es klingt. Diese Aufteilung finden Sie in fast jeder größeren Next.js-Anwendung, und der Grund ist die Praxis.

9:53 Öffentliche Seiten und geschützter Bereich unterscheiden sich in nahezu allem: andere Navigation, andere Fußzeile, andere Ladezustände, andere Fehlerbehandlung. Diese Unterschiede in einem gemeinsamen Layout mit Bedingungen abzubilden, wird schnell unübersichtlich. Zwei Gruppen lösen das sauber. Ein Hinweis ist mir wichtig, weil er später wiederkommt: Eine Gruppe ist eine Strukturhilfe, keine Sicherheitsgrenze. Dass ein Bereich portal heißt, schützt dort gar nichts.

10:21 Der erste Punkt tritt schneller ein, als man denkt: Zwei Gruppen dürfen nicht dieselbe Adresse erzeugen. Wenn beide eine Startseite haben, bricht der Build ab — was gut ist, denn zur Laufzeit wäre es nicht mehr entscheidbar. Der zweite Punkt ist der wichtigste dieser Folie, und ich wiederhole ihn bewusst: Eine Gruppe ist keine Absicherung. Der dritte Punkt betrifft eine seltenere Konstruktion.

10:44 Wenn Sie in verschiedenen Gruppen jeweils ein eigenes Wurzel- Layout setzen, lädt der Browser beim Wechsel die Seite komplett neu. Das kann gewollt sein, überrascht aber, wenn man es nicht weiß.

Verschachtelte Layouts in der Praxis

10:55 Wir haben Layouts als Rahmen kennengelernt. Jetzt sehen wir uns an, was passiert, wenn mehrere davon ineinanderstecken — und was dabei stehen bleibt und was neu gerendert wird. Dieses Kapitel ist kurz, aber es enthält den Satz, auf den ich in Modul elf zurückkommen werde. Wenn Sie sich aus diesem Modul eine Sache merken, dann bitte diese.

11:16 Layouts stapeln sich entlang des Pfades wie Schachteln ineinander: Das Wurzel- Layout umschließt das Portal-Layout, dieses die konkrete Seite. Jede Ebene wird einmal gerendert und bleibt anschließend stehen, solange Sie sich innerhalb ihres Zweigs bewegen. Wenn ein Gast also von der Liegeplatzliste zu den eigenen Buchungen wechselt, wird nur der innerste Teil ausgetauscht.

11:37 Kopfzeile, Menü und Seitenleiste bleiben, wo sie sind — sie werden nicht einmal neu berechnet. Das ist der Grund, warum sich Navigation in einer solchen Anwendung so ruhig anfühlt. Der Gewinn ist zuerst einmal ein wahrnehmbarer: Nichts flackert, Scrollpositionen bleiben, eingeklappte Menüs bleiben eingeklappt. Dazu kommt ein technischer: Übertragen wird nur der Teil, der sich tatsächlich ändert, und Layout und Seite werden parallel gerendert statt nacheinander.

12:04 Das ist gut durchdacht und im Alltag genau das, was man will. Und trotzdem steckt in diesem erwünschten Verhalten eine Falle, die regelmäßig übersehen wird — nämlich dann, wenn man ein Layout für etwas benutzt, das eigentlich bei jedem Seitenwechsel passieren müsste. Hier ist die Falle. Ein Layout rendert bei Navigation im eigenen Zweig nicht erneut.

12:25 Eine Prüfung, die nur dort steht — etwa, ob jemand angemeldet ist — läuft also genau einmal und danach nie wieder, solange der Nutzer im selben Bereich bleibt. Noch weniger bekannt ist der zweite Teil: Ein Layout entscheidet gar nicht darüber, ob der Rest gerendert wird. Wenn Sie dort etwas ausblenden, wird es trotzdem berechnet und steht in der übertragenen Nutzlast. Es ist versteckt, nicht verhindert.

12:49 Merken Sie sich das — in Modul elf wird daraus eine Sicherheitsregel. Jetzt bauen Sie das Gerüst, auf dem alle weiteren Module aufsetzen. Der Reiz dieser Aufgabe liegt nicht im Tippen, sondern im Schneiden: Sie sollen die Routen so anlegen, dass die Layout-Ebenen den fachlichen Bereichen folgen und nicht der Technik. Der Nachweis ist konkret nachprüfbar — beide Bereiche tragen eigene Layouts, und die Adressen kommen ohne Präfix aus.

13:14 Wer schneller ist, legt für das Portal einen eigenen Ladezustand an. Der wird uns im nächsten Modul ohnehin begegnen, dann aber mit einer wichtigen Einschränkung.

Parallele und abfangende Routen

13:24 Zum Abschluss zwei Werkzeuge, die mächtig sind und deshalb gern zu früh gezogen werden. Ich zeige sie Ihnen vollständig, verbinde das aber mit einer Empfehlung zur Zurückhaltung. Denn beide erhöhen die Einstiegshürde für jeden, der später in Ihr Projekt kommt — und oft löst eine ganz gewöhnliche Komponente dasselbe Problem.

13:43 Parallele Routen erlauben es, mehrere unabhängige Bereiche in einem Layout zu rendern, jeder mit eigenem Lade- und Fehlerzustand. Denken Sie an ein Cockpit: Der Tacho fällt nicht aus, weil die Tankanzeige klemmt. Abfangende Routen sind etwas anderes — sie zeigen dieselbe Route in einem anderen Zusammenhang. Der Klassiker ist das Detail, das beim Klick als Overlay über der Liste erscheint, beim direkten Aufruf derselben Adresse aber als vollwertige Seite.

14:10 Beides sind gute Antworten auf echte Probleme. Die Frage ist, ob Sie diese Probleme haben. Hier sehen Sie das Muster für das Hafenmeister-Dashboard. Die beiden Ordner mit dem Klammeraffen sind benannte Bereiche, und sie kommen im Layout nicht als Kinder an, sondern als eigene Eigenschaften. Der praktische Gewinn steht in der letzten Zeile: Jeder Bereich bringt seinen eigenen Ladezustand mit.

14:33 Die Belegung kann also schon stehen, während die Meldungen noch geladen werden. Worauf es ankommt: Dieses Muster lohnt sich, wenn die Bereiche tatsächlich unterschiedlich schnell sind. Laden beide gleich, haben Sie nur Struktur hinzugefügt, ohne etwas zu gewinnen. Diese Tabelle lesen Sie am besten von unten nach oben, denn die unteren beiden Zeilen sind der häufigere Fall.

14:55 Wenn zwei Bereiche gemeinsam laden dürfen, ist eine gewöhnliche Komponente die richtige Antwort. Wenn der Inhalt an einem Schalter hängt, ist es Zustand im Browser. Die oberen beiden Zeilen beschreiben echte Anwendungsfälle, aber sie sind seltener, als die Aufregung um diese Funktionen vermuten lässt. Meine Einschätzung: Beide Werkzeuge sind gut gemacht.

15:15 Sie sollten sie kennen, damit Sie sie erkennen — einsetzen sollten Sie sie erst, wenn die einfache Lösung nachweislich nicht trägt. Der erste Punkt trifft jeden, der parallele Routen einsetzt: Beim Neuladen der Seite fehlt einem Bereich unter Umständen die Zuordnung, und ohne eine Rückfalldatei gibt es dann eine Vierhundertvier.

15:34 Das ist unangenehm, weil es beim Klicken funktioniert und nur beim direkten Aufruf scheitert — also genau dann, wenn jemand einen Link teilt. Ähnlich beim Abfangen: Der Weg über den Klick und der Weg über die Adresszeile führen zu unterschiedlicher Darstellung. Das ist gewollt, muss aber beides gebaut und beides getestet werden. Rechnen Sie also mit doppeltem Aufwand.

Modul 2 zusammengefasst

15:55 Fassen wir zusammen. Der Ordner ist die Route, und die Konventionsdatei bestimmt seine Rolle. Layout bewahrt Zustand, Template setzt ihn zurück. Runde Klammern gruppieren, ohne Spuren in der Adresse zu hinterlassen, der Unterstrich schließt ganz aus. Und der Satz zum Mitnehmen: Ein Layout rendert im eigenen Zweig nicht neu — merken Sie sich das für Modul elf.

16:16 Im nächsten Modul geht es darum, wie sich Navigation anfühlt: Was zeigt die Anwendung, während geladen wird, was passiert bei einem Fehler, und wie wird ein Klick eigentlich sofort.