React v19 - TanStack Router

React v19+ — TanStack Router

0:00 Ein defekter Link ist ein seltsamer Fehler. Er bricht nichts, er wirft keine Warnung, er sieht im Code völlig unauffällig aus — und führt den Nutzer trotzdem auf eine leere Seite. Der Grund ist banal: Ein Pfad ist eine Zeichenkette, und Zeichenketten prüft niemand. Wer eine Route umbenennt, kann nicht wissen, an welchen vierzig Stellen der alte Name noch steht.

0:21 TanStack Router beantwortet genau diese Frage anders: Die Route kennt ihre Typen, und ein defekter Link kommt gar nicht erst durch den Compiler. Was das im Alltag bedeutet, schauen wir uns heute an.

Typsicheres Routing mit TanStack Router

0:33 Der Weg führt von der ersten Einrichtung bis zu einer Navigation, die sich verzögerungsfrei anfühlt. Unterwegs kommen zwei Ideen vor, die über gewöhnliches Routing hinausgehen. Die erste: Die Adresszeile ist ein Zustandsspeicher, den man teilen und als Lesezeichen sichern kann — man muss ihn nur ernst nehmen. Die zweite: Daten werden geladen, bevor eine Seite gezeichnet wird, nicht danach. Beide verändern die Struktur einer Anwendung deutlich.

1:00 Die zweite Frage zielt auf etwas, das viele noch nie erlebt haben — und es ist der Unterschied, um den es heute geht. Wer mit typisierten Links gearbeitet hat, kennt das Gefühl, eine Route umzubenennen und den Compiler alle betroffenen Stellen auflisten zu lassen. Wer es nicht kennt, hat vermutlich schon einmal nach einem Link gesucht, der ins Leere zeigte, ohne dass jemand wusste seit wann.

1:22 Sagen Sie gern, aus welcher Welt Sie kommen — die Umstellung sieht je nachdem anders aus.

Einführung & Setup

1:28 Beginnen wir mit der Einrichtung, denn hier steckt der Mechanismus, der alles Weitere trägt. Ein Baustein im Bauprozess erzeugt aus Ihren Dateien einen Routen-Baum samt Typen — und diese eine Generierung ist der Grund, warum später alles typisiert ist, ohne dass Sie etwas deklarieren. Es lohnt sich, das einmal genau zu verstehen — fast jede spätere Irritation lässt sich auf diesen Mechanismus zurückführen.

1:51 Das Wort "verlustfrei" ist hier der Schlüssel. Die Typinformation reicht von der Definition einer Route bis zu jeder Stelle, die dorthin verlinkt — ohne dass sie unterwegs zu einer beliebigen Zeichenkette wird. Möglich macht das die generierte Datei: Sie ist das Bindeglied zwischen Ihren Dateien und dem Typsystem. Wichtig zur Einordnung: Dieses Werkzeug denkt vom Browser her.

2:13 Es gibt eine Erweiterung für den Server-Anteil, aber die ist ein eigenes Thema — wir bleiben heute im Client. Der dritte Punkt beschreibt eine Bedingung, die man verstehen sollte: Der Routen-Baum wird erzeugt, nicht geschrieben. Solange der Bauprozess läuft, geschieht das automatisch — Sie legen eine Datei an, und Sekunden später kennt der Editor die neue Route.

2:35 Das ist bequem und gelegentlich verwirrend, wenn der Prozess nicht läuft und der Compiler eine Route nicht findet, die eindeutig da ist. Merken Sie sich diese Ursache; sie erspart die erste Ratlosigkeit. Der fünfte Schritt sieht nach einer Formalie aus und ist der wichtigste von allen. Es sind drei Zeilen, die dem Typsystem mitteilen, welcher Router gemeint ist.

2:56 Ohne sie funktioniert alles — nur eben ohne Typen. Sie bekommen keine Fehlermeldung, keine Warnung, sondern schlicht keine Autovervollständigung. Und weil das Fehlen von etwas schwer auffällt, sucht man dann an ganz anderer Stelle. Wenn Ihre Links nicht vorgeschlagen werden: Diese drei Zeilen prüfen. Das Herzstück ist der mittlere Block. Er sieht aus wie eine technische Zeremonie und ist der Moment, in dem aus einem gewöhnlichen Router ein typisierter wird.

3:24 Sie melden Ihren konkreten Router beim Typsystem an, und ab da weiß jede Link-Komponente in Ihrer gesamten Anwendung, welche Pfade es gibt und welche Parameter dazugehören. Bemerkenswert ist der Aufwand: einmal drei Zeilen, danach nie wieder. Sie werden an keiner Aufrufstelle jemals einen Typ angeben müssen. Setzen Sie den Router auf. Der Prüfstein ist schön unmittelbar: Tippen Sie in einem Link einen Schrägstrich und schauen Sie, ob Ihnen die verfügbaren Pfade vorgeschlagen werden.

3:52 Wenn ja, sitzt die Anmeldung aus dem letzten Schritt. Wenn nicht, wissen Sie jetzt, wo Sie suchen. Die Zusatzaufgabe mit den sinnvollen Voreinstellungen greift dem letzten Kapitel vor — legen Sie sie ruhig gleich an, dann sind sie später schon da. Der dritte Punkt verdient eine klare Ansage: Die generierte Datei ist kein Quellcode, sie ist ein Ergebnis. Jede Änderung darin ist beim nächsten Bau weg.

4:15 Wenn dort etwas nicht stimmt, liegt die Ursache in Ihrer Dateistruktur. Der letzte Punkt ist eine praktische Erinnerung: Das Entwicklungswerkzeug ist im Alltag großartig und gehört nicht in die ausgelieferte Anwendung — dort ist es nur zusätzliches Gewicht.

Routing-Grundlagen

4:31 Jetzt zur Struktur. Der Grundgedanke ist alt und bewährt: Die Ordnerstruktur ist die Anwendungsstruktur. Neu ist, was daraus entsteht — nämlich nicht nur Routen, sondern auch die Typen dafür. Und ein paar Namenskonventionen lohnt es sich zu kennen. Sie sind schnell erklärt und ersparen Ihnen das Nachschlagen mitten in der Arbeit.

4:51 Der Ansatz folgt dem Grundsatz Konvention statt Konfiguration: Der Dateiname beschreibt die Route, es gibt keine zentrale Liste. Zwei Konventionen verdienen Aufmerksamkeit. Ein Dollarzeichen markiert ein dynamisches Segment — hier steht später eine Kennung. Und ein Unterstrich am Anfang erzeugt ein Layout ohne eigenes Adresssegment.

5:11 Das klingt kryptisch und ist praktisch: Damit teilen sich mehrere Seiten eine gemeinsame Umgebung — sagen wir eine Seitenleiste — ohne dass die Adresse dadurch länger wird. Der letzte Punkt ist das eigentliche Verkaufsargument dieses Kapitels, und ich mache ihn konkret. Sie benennen eine Route um. In einem gewöhnlichen Router passiert danach: nichts.

5:33 Alles kompiliert, und irgendwann meldet jemand, dass ein Menüpunkt ins Leere führt. Hier passiert etwas anderes: Der Bau schlägt fehl und listet Ihnen jede Stelle auf, die noch auf den alten Pfad zeigt. Sie arbeiten die Liste ab und sind fertig. Das ist der Unterschied zwischen Suchen und Abhaken. Der vierte Punkt ist eine schöne Kleinigkeit.

5:54 In einem Ordner, in dem jede Datei zur Route wird, stellt sich schnell die Frage: Wohin mit den Hilfskomponenten, die nur zu dieser Seite gehören? Ein Präfix markiert Dateien als Nicht-Routen — sie dürfen im selben Ordner liegen, ohne dass eine Adresse daraus wird. Damit können Sie zusammenlegen, was zusammengehört, statt Hilfsdateien in einen entfernten gemeinsamen Ordner zu verbannen.

6:17 Beachten Sie die Trennung: Der Pfad enthält den Platzhalter als solchen, und die konkreten Werte kommen getrennt daneben. Das ist mehr als Stil. Weil der Pfad unverändert bleibt, kann der Compiler ihn mit den bekannten Routen abgleichen — und aus dem Platzhalter ableiten, welche Parameter Sie liefern müssen. Vergessen Sie einen, meldet er das. Beim üblichen Zusammenbauen einer Adresszeichenkette kann das niemand prüfen; dort ist ein fehlender Wert einfach ein Wort weniger im Pfad.

6:45 Bauen Sie die klassische Struktur aus Liste und Detailansicht mit gemeinsamem Rahmen. Machen Sie danach den Test, der den Kern des Kapitels zeigt: Benennen Sie eine Route um und schauen Sie zu, wie der Compiler alle betroffenen Links anzeigt. Das ist der Moment, in dem die Sache greifbar wird. Und probieren Sie das Layout ohne eigenes Adresssegment aus — es ist die eleganteste Antwort auf die Frage, wie ein geschützter Bereich mit gemeinsamer Umgebung aussieht.

7:11 Der dritte Punkt ist der, der auch erfahrenen Leuten aus Gewohnheit passiert. Ein gewöhnlicher Anker sieht identisch aus und tut etwas völlig anderes: Er lädt die komplette Anwendung neu. Der Nutzer sieht eine kurze weiße Seite und verliert den gesamten Zustand — und weil es ja funktioniert, fällt es beim Entwickeln kaum auf.

7:29 Der letzte Punkt ist die Generierungsfalle aus Kapitel eins, hier in ihrer häufigsten Variante: nach dem Umbenennen läuft der Prozess nicht.

Search Params als First-Class State

7:38 Jetzt kommt der Teil, der die Architektur einer Anwendung wirklich verändert. Die Frage lautet: Wo lebt eigentlich der Zustand einer Filteransicht? Die übliche Antwort ist eine lokale Variable. Die bessere Antwort steht in der Adresszeile — und dafür muss man sie ernst nehmen. Wer das einmal gemacht hat, will es in keinem Projekt mehr anders — es löst nebenbei drei Probleme, an die man gar nicht gedacht hatte.

8:03 Machen wir es an einem Alltagsfall fest. Jemand filtert eine Liste, sortiert sie, blättert auf Seite drei — und will einer Kollegin genau diese Ansicht schicken. Liegt der Zustand in lokalen Variablen, ist das unmöglich; der Link führt zur ungefilterten Liste. Liegt er in der Adresszeile, genügt Kopieren. Dasselbe gilt für das Lesezeichen, den Zurück-Knopf und das Neuladen der Seite.

8:25 Der springende Punkt hier: Diese Werte sind typisiert und werden beim Betreten der Route geprüft — nicht einfach als rohe Zeichenketten weitergereicht. Der dritte Punkt löst ein Problem, das man beim Gedanken "Zustand in der Adresse" sofort hat: Diese Zeile kann jeder verändern. Jemand tippt bei der Seitenzahl einen Buchstaben, und was passiert? Ohne Prüfung ein Absturz oder ein seltsames Verhalten.

8:50 Mit einem Schema und einem Rückfallwert wird daraus eine Eins. Diese Robustheit ist die Bedingung dafür, dass man die Adresszeile überhaupt als Zustandsspeicher verwenden kann. Ungeprüfte Werte aus der Adresse sind fremde Eingaben. Der fünfte Schritt enthält eine Feinheit, die man kennen muss. Beim Schreiben von Werten in die Adresszeile geben Sie eine Funktion an, die aus dem bisherigen Zustand den neuen macht — statt ein fertiges Objekt.

9:16 Der Grund ist einfach: Wer ein vollständiges Objekt schreibt, löscht alles, was er nicht erwähnt hat. Ein Link, der nur die Seite weiterschaltet, würde also den Filter verwerfen. Mit der funktionalen Schreibweise bleibt alles Übrige erhalten. Zwei Dinge lohnen den Blick. Oben die Rückfallwerte — jeder Parameter hat einen, also gibt es keinen ungültigen Zustand.

9:38 Ein manipulierter Wert wird zur Vorgabe, ohne dass die Anwendung stolpert. Unten die funktionale Schreibweise von eben: Der bisherige Zustand wird übernommen, nur die Seite wandert eins weiter. Diese beiden Muster zusammen sind das ganze Kapitel. Wer sie einhält, bekommt eine Adresszeile, die sich verhält wie ein ordentlicher Zustandsspeicher — inklusive funktionierendem Zurück-Knopf.

10:02 In dieser Übung bauen Sie eine Filteransicht, deren Zustand komplett in der Adresse lebt. Der Prüfstein ist genau der Alltagsfall von vorhin: Kopieren Sie die Adresse, öffnen Sie sie in einem anderen Fenster, und Sie sollten exakt dieselbe Ansicht sehen. Testen Sie außerdem den Zurück-Knopf — er sollte schrittweise durch Ihre Filterungen zurückgehen.

10:22 Das bekommen Sie hier geschenkt und wäre mit lokalem Zustand eine eigene Baustelle. Der dritte Punkt ist der Umstellungsfehler, den fast jeder einmal macht: Man schreibt den Wert in die Adresse und behält aus Gewohnheit die lokale Variable bei. Damit gibt es zwei Wahrheiten — und beim Zurück-Knopf ändert sich die Adresse, während die lokale Variable stehenbleibt. Die Ansicht passt dann nicht mehr zur Adresszeile.

10:46 Entscheiden Sie sich: Wenn der Wert in die Adresse gehört, gehört er nur dorthin. Der letzte Punkt ist der Objektverlust von eben.

Data Loading & Guards

10:54 Jetzt zum Datenladen — und zu einem Wechsel der Reihenfolge, der mehr verändert, als es klingt. Bisher lautete das Muster: Seite zeichnen, dann laden, dann noch einmal zeichnen. Hier lautet es: laden, dann zeichnen. Das beseitigt eine ganze Klasse von Problemen. Und es ändert etwas an der Struktur Ihrer Komponenten: Sie müssen nicht mehr damit rechnen, ohne Daten gezeichnet zu werden.

11:19 Der eigentliche Gewinn steckt in der Notiz und verdient eine Erklärung. Beim Laden innerhalb von Komponenten entsteht ein Wasserfall: Die äußere Komponente lädt, zeichnet, dann beginnt die innere zu laden, zeichnet, dann die nächste. Drei Ebenen bedeuten drei nacheinander wartende Ladevorgänge. Beim Laden auf Routen-Ebene weiß der Router von vornherein, welche Routen betroffen sind — und startet alle Ladevorgänge gleichzeitig.

11:44 Aus drei mal vierhundert Millisekunden werden vierhundert. Ohne dass Sie irgendetwas parallelisiert hätten. Der dritte Punkt betrifft die Zugriffskontrolle, und dazu gehört eine Klarstellung, die auf der Stolperstein-Folie noch einmal kommt: Diese Prüfung ist Wegweisung, keine Sicherheit. Sie sorgt dafür, dass niemand versehentlich auf einer Seite landet, die er nicht sehen soll, und leitet ihn freundlich zur Anmeldung.

12:08 Sie hindert niemanden daran, die Daten direkt bei der Schnittstelle abzufragen. Alles, was wirklich geschützt sein muss, prüft der Server. Immer. Punkt zwei ist die schönste Verzahnung des Tages. Wenn Sie ohnehin mit einem Datenzwischenspeicher arbeiten, füllt der Lader diesen — statt an ihm vorbei eigene Daten zu holen.

12:28 Die Komponente fragt dann ganz normal ab und findet alles bereits vor. Kein zweites Laden, kein doppelter Weg. Punkt vier ist die Feinabstimmung: Nicht alles muss vor dem Zeichnen da sein. Was die Seite trägt, wird abgewartet; was am Rand steht, darf nachkommen. Zwei Blöcke, zwei Aufgaben. Oben die Wegweisung — die Umleitung wird geworfen, nicht zurückgegeben, was anfangs ungewohnt aussieht und den Vorteil hat, dass sie den weiteren Ablauf sofort beendet.

12:56 Unten das Vorfüllen des Zwischenspeichers. Beachten Sie, dass beide auf denselben geteilten Kontext zugreifen: Dort liegen die Anmeldeinformationen und der Zwischenspeicher, vererbt von der Wurzelroute nach unten. Diese eine Einrichtung macht beides möglich, ohne dass irgendwo ein globaler Zugriff nötig wäre. Sichern Sie eine Route ab und laden Sie ihre Daten vor. Der schönste Moment kommt, wenn Sie mit Anmeldung auf die Seite wechseln und feststellen: Es gibt kein Ladesymbol.

13:24 Die Daten waren fertig, bevor gezeichnet wurde. Prüfen Sie anschließend die Wegweisung — ohne Anmeldung sollten Sie sauber auf der Anmeldeseite landen, nicht kurz die geschützte Seite aufblitzen sehen. Die Zusatzaufgabe mit dem verzögerten Nachladen lohnt sich, wenn eine Ihrer Abfragen deutlich langsamer ist als die anderen.

13:43 Der zweite Punkt hat ein Symptom, das echt verwirrt: Sie wechseln den Filter, die Adresse ändert sich, und die Daten bleiben gleich. Der Grund ist, dass der Lader nicht weiß, dass ihn dieser Wert etwas angeht — man muss die Abhängigkeit ausdrücklich erklären. Der erste Punkt ist die Sicherheitsklarstellung, die ich lieber einmal zu oft wiederhole: Eine Wegweisung im Browser ist keine Zugriffskontrolle. Der Server prüft, immer.

Performance & Produktionsreife

14:08 Zum Abschluss die Frage, wie sich Navigation verzögerungsfrei anfühlt, obwohl die Daten dieselbe Zeit brauchen. Die Antwort ist keine schnellere Leitung, sondern ein besserer Zeitpunkt — und der liegt vor dem Klick. Der Aufwand dafür beträgt zwei Konfigurationszeilen, die Wirkung erstreckt sich auf jeden Link Ihrer Anwendung.

14:28 Der Gedanke hinter dem absichtsbasierten Vorausladen ist psychologisch klug. Wenn jemand mit der Maus auf einem Menüpunkt stehenbleibt, hat er sich praktisch schon entschieden — er braucht nur noch ein paar hundert Millisekunden bis zum Klick. Genau die nutzt der Router, um die Zielroute samt Daten zu holen. Beim Klick ist alles da. Für den Nutzer sieht das aus, als hätte die Anwendung keine Ladezeit.

14:50 Tatsächlich hat sie nur an einer Stelle stattgefunden, an der niemand gewartet hat. Der dritte Punkt ist die Feinabstimmung, die man leicht übersieht. Wenn das Vorausladen die Daten holt und die als sofort veraltet gelten, holt die Zielkomponente sie beim Klick gleich noch einmal — Sie haben also doppelte Anfragen und trotzdem eine Wartezeit.

15:10 Die Frischezeit muss also mindestens die Spanne zwischen Vorausladen und Klick überdecken. Ein paar Sekunden genügen. Ohne diese Abstimmung ist der ganze Aufwand nicht nur wirkungslos, sondern kontraproduktiv. Der zweite Punkt regelt eine praktische Frage: Wie lange muss jemand verweilen, bevor vorgeladen wird? Ohne Verzögerung löst jede Mausbewegung über eine Navigationsleiste zehn Ladevorgänge aus — Sie holen dann mehr Daten als vorher.

15:36 Etwa hundert Millisekunden treffen es gut: schnell genug, um vor dem Klick fertig zu sein, träge genug, um zufälliges Überfahren zu ignorieren. Der letzte Punkt ist eine Nutzerfreundlichkeit, die man nicht vergessen sollte — die Warnung vor ungespeicherten Änderungen beim Verlassen eines Formulars. Vier Zeilen, die den spürbarsten Unterschied dieses ganzen Tages ausmachen. Zwei Einstellungen, einmal zentral gesetzt, und die gesamte Navigation wirkt anders.

16:04 Was mir daran gefällt: Es ist keine Optimierung im üblichen Sinn — nichts wird schneller, es wird nur früher begonnen. Und weil es zentral gilt, profitiert jeder Link, auch die, die erst nächstes Jahr geschrieben werden. Das ist die Sorte Verbesserung, die man einmal macht und dann vergisst. Aktivieren Sie das Vorausladen und stimmen Sie es mit Ihrem Zwischenspeicher ab.

16:26 Drosseln Sie dafür unbedingt die Verbindung im Browser-Werkzeug — sonst sehen Sie weder vorher noch nachher einen Unterschied. Beobachten Sie im Netzwerkfenster, wann die Anfrage tatsächlich losgeht: beim Verweilen, nicht beim Klick. Und prüfen Sie, ob beim Klick eine zweite Anfrage folgt. Wenn ja, ist die Frischezeit zu kurz — genau der Fehler von der letzten Folie.

16:48 Der letzte Punkt verdient eine ehrliche Warnung. Ein Wechsel von einem anderen Router ist kein Austausch von Importen. Die Art, wie navigiert wird, wie Parameter ankommen und wie Daten geladen werden, unterscheidet sich grundlegend — und gerade der Datenteil bedeutet, dass auch Ihre Komponenten sich ändern. Planen Sie das als Umbau, nicht als Aktualisierung. Für ein neues Projekt ist die Entscheidung leicht; für ein bestehendes gehört sie ehrlich kalkuliert.

17:15 Fassen wir zusammen. Die Typisierung entsteht aus dem generierten Routen-Baum und trägt bis in jeden Link — ein defekter Pfad ist ab jetzt ein Bau-Fehler, keine Nutzermeldung. Die Adresszeile wird zum geprüften, teilbaren Zustandsspeicher, womit Lesezeichen und Zurück-Knopf von selbst funktionieren. Daten kommen vor dem Zeichnen und parallel statt kaskadiert. Die Wegweisung sitzt an der Route, die echte Prüfung beim Server.

17:39 Und das absichtsbasierte Vorausladen verschiebt die Wartezeit dorthin, wo sie niemand bemerkt.

Fragen & Weiterarbeiten

17:46 Alle Beispiele und Routen-Bäume liegen in der Freigabe. Nehmen Sie sich vor allem die Filteransicht aus Übung zwei mit — der Gedanke, den Zustand in die Adresse zu verlegen, lässt sich in fast jedem bestehenden Projekt an einer Stelle ausprobieren, ohne alles umzustellen. Die offizielle Dokumentation ist umfangreich, und das Beispiel-Repository beantwortet die meisten Sonderfälle schneller als jede Suche.

18:08 Bei Fragen aus dem eigenen Projekt melden Sie sich gern. Vielen Dank für Ihre Aufmerksamkeit.