Routing und Navigation

Routing und Navigation

0:00 Beim Routing möchte ich gleich mit dem Satz anfangen, der am häufigsten missverstanden wird: Ein Guard schützt den Bedienfluss, nicht die Daten. Wer das verwechselt, baut eine Tür ohne Wand — sie sieht solide aus, und man geht einfach daneben vorbei. Alles, was im Browser läuft, kann dort auch geändert werden. In diesem Modul geht es um Routen und Deep Links, um sinnvolle Bündelgrenzen, um Guards mit ihren Grenzen und um die Frage, wann Daten vor der Navigation geladen werden sollten und wann danach.

Navigation, Daten und Formulare

0:28 Der dritte Tag bringt den sichtbaren Teil zusammen: Wie kommt der Benutzer von A nach B, woher kommen die Daten, und wie gibt er etwas ein? Am Abend hat Spurweite eine Detailansicht, eine Bearbeitung und einen Datenzugriff mit definiertem Verhalten im Fehlerfall.

Routen, Parameter und verschachtelte Ansichten

0:44 Fangen wir beim Routenbaum an. Der ist nämlich mehr als eine technische Zuordnung — er ist die Struktur Ihrer Anwendung, so wie der Benutzer sie erlebt. Das Routing wird beim Start eingerichtet, ein Array beschreibt die Zuordnung von Pfad zu Komponente. Pfadparameter stehen als eigenes Segment im Pfad, Abfrageparameter hinter dem Fragezeichen — und beide sind mehr als Technik. Der Pfadparameter sagt: Das hier ist ein anderes Ding.

1:11 Der Abfrageparameter sagt: Das ist dasselbe Ding, anders betrachtet. Verschachtelte Ansichten entstehen über Kindrouten und einen weiteren Platzhalter im Template. Damit bilden Sie ab, was inhaltlich ineinandersteckt. Achten Sie auf die Verschachtelung: Die Bearbeitung ist ein Kind des Details, kein eigener Zweig. Das ist inhaltlich richtig — man bearbeitet einen bestimmten Auftrag, nicht irgendetwas — und hat den praktischen Vorteil, dass die Adresse den Zusammenhang trägt.

1:39 Der zweite wichtige Punkt steht in der Fußzeile: Mit der passenden Option bindet Angular den Routenparameter direkt als Eingabe der Komponente. Damit brauchen Sie keinen Zugriff auf die aktivierte Route mehr — der Parameter kommt an wie jede andere Eingabe. Ich formuliere das bewusst als Anforderung und nicht als nette Zugabe.

1:59 Eine Meisterin bei Falkenhorst will einen Auftrag per Nachricht an die Werkstatt schicken — dafür braucht sie eine Adresse, die funktioniert. Der Zurück-Knopf soll sich erwartbar verhalten, sonst verlieren Benutzer das Vertrauen in die Anwendung. Der Zustand der Ansicht steht in der Adresse und nicht nur im Speicher, was das Neuladen überlebt.

2:18 Und für Sie selbst ist es der praktischste Punkt: Ein Fehler wird reproduzierbar, wenn man den Zustand verlinken kann. Der erste Punkt ist der, der beim Testen sofort auffällt und trotzdem oft bleibt: Die Auswahl steckt nur im Speicher, ein Neuladen verliert sie. Der zweite ist derselbe Gedanke eine Stufe weiter: Filter stehen nicht in den Abfrageparametern und sind deshalb nicht teilbar.

2:40 Jemand schickt einen Link, und der Empfänger sieht etwas anderes. Und der dritte ist ein technischer, der gern übersehen wird: Ein Parameter wird einmalig gelesen — beim Initialisieren — obwohl sich die Route ändern kann, ohne dass die Komponente neu aufgebaut wird.

Lazy Loading und Bündelgrenzen

2:55 Jetzt zum Nachladen. Technisch ist das schnell erklärt — die interessante Frage ist, wo die Grenze verlaufen soll. Es gibt zwei Varianten: eine einzelne Komponente nachladen oder eine ganze Routengruppe. Beides entsteht als eigener Teil der Auslieferung. Die Frage, die Sie beantworten müssen, ist nicht technisch, sondern fachlich: Welcher Bereich wird nur von einem Teil der Benutzer geöffnet, oder nur selten?

3:20 Denken Sie an ein Reisegepäck. Sie packen ein, was Sie unterwegs brauchen. Das Zelt bleibt zu Hause, wenn Sie ins Hotel fahren — nicht weil es zu schwer wäre, sondern weil es niemand auspacken wird. Die Schreibweise ist unspektakulär: eine Funktion, die einen dynamischen Import zurückgibt. Worauf es ankommt, steht nicht im Code, sondern daneben: Die Komponente darf außerhalb dieses Blocks nicht statisch importiert werden.

3:46 Ein einziger zusätzlicher Import an anderer Stelle, und sie landet wieder im Startbündel — das Nachladen ist dann wirkungslos, ohne dass irgendetwas warnt. Das ist eine der Stellen, an denen eine Messung mehr wert ist als eine Annahme. Wir kommen darauf in Modul siebzehn zurück. Vier Kriterien, und die ersten drei laufen auf dieselbe Frage hinaus: Wer öffnet das, und wie oft?

4:09 Ein Bereich, den nur Standortleitungen sehen, gehört hinter eine Grenze — für alle anderen ist er Ballast. Selten genutzte Auswertungen tragen oft große Abhängigkeiten, etwa Diagrammpakete. Die Startansicht sollte so wenig wie möglich mitbringen, weil sie über den ersten Eindruck entscheidet. Und der vierte ist die Gegenwarnung: Zu viele kleine Teile kosten mehr Anfragen, als sie an Größe sparen. Auch hier gilt: messen.

4:36 Der erste Punkt ist der, vor dem ich gerade gewarnt habe, und er passiert wirklich oft: Eine nachgeladene Route importiert ihr Ziel zusätzlich statisch — meistens durch eine Typangabe, die jemand ergänzt hat. Der zweite ist ein Zuschnittsfehler: Die Grenze verläuft nach Ordnern statt nach Nutzung. Das ist bequem und trifft selten das Richtige.

4:55 Und der dritte betrifft die Wahrnehmung: Das Nachladen bleibt ohne sichtbare Rückmeldung, und für den Benutzer sieht eine halbe Sekunde Stille aus wie ein Hänger.

Guards und Autorisierung

5:05 Kommen wir zu dem Punkt, mit dem ich angefangen habe. Guards sind nützlich — und sie sind etwas anderes, als viele denken. Es gibt drei Arten, und der Unterschied ist praktisch relevant. Die eine erlaubt oder verweigert das Aktivieren einer Route. Die zweite greift schon beim Zuordnen — sie verhindert damit auch das Nachladen des Bündels. Die dritte schützt vor dem Verlassen mit ungespeicherten Änderungen.

5:30 Alle drei sind heute Funktionen, keine Klassen, und dürfen Abhängigkeiten beziehen. Und jetzt der Satz, der dazugehört: Verbindliche Autorisierung gehört auf den Server. Ein Guard steuert, was der Benutzer zu sehen bekommt. Er steuert nicht, was er bekommen kann. Ein knappes Muster mit zwei Feinheiten. Erstens die Wahl der Art: Die Variante, die schon beim Zuordnen greift, verhindert zusätzlich, dass das Bündel überhaupt geladen wird.

5:57 Für einen Bereich, den die meisten Benutzer nie sehen, ist das die bessere Wahl. Zweitens die Rückgabe: keine einfache Ablehnung, sondern eine Umleitung. Und zwar auf eine Route, die diesen Guard nicht trägt — sonst läuft die Navigation im Kreis, und das ist ein Fehler, den man im Browser als eingefrorene Seite erlebt. Der erste Punkt ist der wichtigste dieses Moduls: Der Guard gilt als Zugriffsschutz, und die Schnittstelle prüft nicht noch einmal.

6:24 Dann ist Ihre Zugriffssteuerung eine Anzeigeeinstellung. Der zweite ist die Variante davon: Rollen werden im Browser entschieden — und dort lassen sie sich ändern. Der dritte ist der technische Klassiker, den ich eben erwähnt habe: Eine Umleitung führt im Kreis. Und der vierte ist nutzerseitig ärgerlich: Ungespeicherte Änderungen gehen verloren, weil der Verlassen-Schutz fehlt.

Resolver gegen nicht blockierendes Laden

6:46 Bleibt eine Entscheidung je Route, die sich leicht übersehen lässt und die der Benutzer sehr wohl bemerkt: Wann kommen die Daten? Zwei Wege. Der eine lädt vor der Navigation — die Ansicht erscheint erst, wenn die Daten da sind. Der andere navigiert sofort und lädt in der Ansicht, mit sichtbarem Ladezustand. Der erste Weg wirkt ruhiger, weil es keinen Zwischenzustand gibt; er verzögert dafür jede Navigation.

7:10 Der zweite ist schneller sichtbar und braucht einen gut gestalteten Zwischenzustand. Es gibt hier kein richtig und falsch für die ganze Anwendung — nur eine Entscheidung je Route, die man an der Dauer des Abrufs festmacht. Die letzte Zeile ist die Entscheidungshilfe: Das eine passt zu kleinen Datenmengen, das andere zu langsamen Abrufen.

7:30 Dazwischen steht die Zeile, die man gern übersieht — beim Resolver tritt der Fehler vor der Ansicht auf, beim anderen Weg in der Ansicht. Das klingt nebensächlich und ist es nicht: Ein Fehler vor der Ansicht bedeutet, dass die Navigation abbricht und der Benutzer auf der alten Seite bleibt, oft ohne Erklärung. Ein Fehler in der Ansicht kann erklärt werden, mit einem Knopf zum erneuten Versuchen.

7:53 Vier Schritte, und der erste ist der, den man überspringt: messen, wie lange der Abruf typischerweise dauert. Nicht schätzen. Dann die inhaltliche Frage — ergibt die Ansicht ohne die Daten überhaupt Sinn? Eine Detailansicht ohne Daten hat immerhin noch Kopfzeile und Navigation. Eine reine Ergebnisliste ohne Ergebnisse hat nichts. Daraus folgt die Wahl.

8:14 Und die Fußzeile ist die Bedingung für den zweiten Weg: Ohne gestalteten Ladezustand wirkt nicht blockierendes Laden wie ein Fehler. Der erste Punkt ist die typische Überdehnung: Der Resolver lädt viel, und die Navigation fühlt sich blockiert an — was sie ja auch ist. Der zweite ist der, den ich eben genannt habe: Der Ladezustand fehlt, die Ansicht bleibt kurz leer, und der Benutzer klickt noch einmal.

8:38 Und der dritte ist der unangenehmste, weil er stumm ist: Ein Fehler im Resolver bricht die Navigation ohne Rückmeldung ab. Der Benutzer klickt, und es passiert nichts. Er klickt noch einmal, und es passiert wieder nichts.

Übung

8:51 Bauen wir den Navigationsfluss von Spurweite — mit allen vier Themen dieses Moduls in einer Übung. Spurweite braucht eine Detailansicht je Auftrag und darunter eine Bearbeitung. Beide müssen direkt verlinkbar sein, denn die Meisterin will den Link an die Werkstatt weitergeben können — das ist keine technische Anforderung, sondern eine aus dem Betrieb.

9:12 Die Auswertung dagegen ist nur für Standortleitungen gedacht. Damit haben Sie in einer Übung alles beisammen: Routenbaum, Deep Links, Nachladen, Zugriffssteuerung und die Entscheidung über den Ladeweg. Das Lernziel hat zwei Teile, und der zweite ist der, auf den es mir ankommt: die Grenzen der Guards benennen. Nicht nur einen Guard bauen — auch sagen können, wogegen er nicht schützt.

9:35 Das Erfolgskriterium nennt drei prüfbare Punkte: Detail und Bearbeitung direkt aufrufbar, Auswertung nachgeladen und ohne Berechtigung nicht erreichbar, Lade- und Fehlerzustand sichtbar. Wer früh fertig ist, ergänzt den Verlassen-Schutz für die Bearbeitung — und merkt dabei, wie oft man selbst versehentlich wegnavigiert.

9:54 Der erste Schritt ist der konzeptionelle: den Routenbaum aus dem Bedienfluss ableiten, nicht aus der Ordnerstruktur. Der zweite ist der, der oft fehlt: Filter in Abfrageparameter überführen, damit die Liste teilbar wird. Der dritte kombiniert Nachladen und Schutz an einer Stelle. Der vierte ist die eigentliche Denkarbeit — für eine Route den Ladeweg wählen und die Wahl begründen.

10:16 Und der fünfte ist der, den man gern weglässt und der am meisten zeigt: den Fehlerfall auslösen und die Rückmeldung anschauen. Der erste Punkt ist der, der beim Weitergeben auffällt: Der Filter bleibt im Speicher, und der geteilte Link zeigt etwas anderes als das, was der Absender sah. Der zweite ist der wichtigste des ganzen Moduls — der Guard schützt die Route, die Schnittstelle bleibt offen.

10:38 Und der dritte ist ein Benutzerärgernis mit Ansage: Die Bearbeitung verliert Eingaben beim Zurückspringen. Im nächsten Modul kümmern wir uns darum, woher die Daten überhaupt kommen — und was passiert, wenn die Antwort nicht so aussieht wie erwartet.