HTTP und API-Integration

HTTP und API-Integration

0:00 Bisher waren unsere Daten erfunden. Heute holen wir sie dort, wo sie in einer echten Anwendung herkommen: von einem Server. Das klingt nach einem technischen Detail und ist in Wahrheit der Punkt, an dem eine Anwendung erwachsen wird — denn ab jetzt kann etwas schiefgehen, das nicht in Ihrem Code liegt. Wir sehen uns an, wie man Daten holt, wie man mit Fehlern umgeht, wie man die Zugriffe strukturiert und was passiert, wenn Antworten in der falschen Reihenfolge eintreffen.

Kommunikation mit Backend APIs

0:26 Fangen wir mit der Rollenverteilung an. Ihre Vue-Anwendung läuft im Browser, und das bedeutet zweierlei: Sie kann nicht direkt an eine Datenbank, und sie ist öffentlich einsehbar. Beides hat Folgen für das, was Sie dort tun dürfen. Und dann kommt ein Denkmodell, das den Rest des Moduls trägt — die drei Zustände, in denen sich ein Datenabruf befinden kann.

0:47 Wenn Sie aus diesem Modul nur eine Sache mitnehmen, soll es dieses Denkmodell sein: Es entscheidet darüber, ob eine Anwendung sich solide anfühlt oder unfertig. Der wichtige Satz ist der letzte: Vue bringt für HTTP nichts mit. Das ist keine Lücke, sondern eine Entscheidung. Vue kümmert sich um die Oberfläche, und wie Sie Daten holen, überlässt es Ihnen. Für manche ist das ungewohnt — andere Frameworks liefern einen Client mit.

1:12 Der Vorteil dieser Zurückhaltung ist, dass Sie frei wählen können und dass Vue nicht mit Funktionen wächst, die die Hälfte der Projekte nicht braucht. Der Nachteil ist, dass Sie eine Entscheidung treffen müssen. Der dritte Punkt ist die ehrliche Begründung: Ein eingebauter Client wäre für die meisten zu viel und für manche zu wenig. Wer nur drei Aufrufe macht, braucht keine Bibliothek.

1:35 Wer Wiederholungen, Abbrüche, Zwischenspeicherung und Authentifizierung braucht, braucht eine ausgewachsene — und die kann Vue nicht in der passenden Form für alle liefern. Der letzte Punkt ist die Konsequenz daraus: Der Kern bleibt klein. Das ist ein Wert an sich, gerade bei etwas, das in jeder Anwendung mitläuft. Diese drei Zeilen sind das Denkmodell für das ganze Modul, und ich möchte, dass Sie sie mitnehmen.

2:00 Jeder Abruf ist in genau einem dieser Zustände: Er läuft noch, er ist erfolgreich gewesen, oder er ist fehlgeschlagen. Für jeden dieser Zustände braucht die Oberfläche eine Antwort. Die Fußzeile sagt es deutlich: Wer nur den Erfolgsfall baut, hat zwei Drittel vergessen. Und was dann passiert, kennen Sie als Nutzer — eine Seite, die einfach leer bleibt, ohne zu sagen, ob sie noch lädt oder aufgegeben hat.

2:24 Der erste Punkt ist eine Wahrnehmungsfrage: Als Entwickler auf einem schnellen Rechner mit lokalem Server sehen Sie fast nur den Erfolgsfall. Ihre Nutzer sitzen im Zug mit schlechtem Empfang. Der dritte Punkt ist eine Sicherheitswarnung, die ich früh setze: Alles, was im Frontend steht, ist lesbar — auch im Produktionsbau, auch verkleinert.

2:43 Ein Schlüssel im JavaScript ist ein veröffentlichter Schlüssel. Dazu kommen wir in Modul 12 noch einmal ausführlicher.

Datenabruf mit der Fetch API

2:51 Der Browser bringt seit Jahren einen eigenen Weg mit, Daten zu holen. Er ist gut, er ist überall verfügbar, und er kostet keine zusätzliche Abhängigkeit. Er hat allerdings eine Eigenheit, die man kennen muss, weil sie regelmäßig zu Fehlern führt, die aussehen wie Datenprobleme. Ich sage Ihnen gleich vorweg, worum es geht: um die Frage, was eigentlich als Fehler gilt.

3:12 Die Antwort ist eine andere, als die meisten erwarten — und wer sie nicht kennt, baut sich stille Fehler ein, die erst beim Nutzer auffallen. Hier ist die Eigenheit: Der Abruf scheitert nur bei Netzwerkfehlern. Eine Antwort mit einem Fehlerstatus — Seite nicht gefunden, Serverfehler — gilt als Erfolg. Aus Sicht des Werkzeugs ist das konsequent: Die Anfrage wurde ja zugestellt und beantwortet.

3:36 Aus Sicht Ihrer Anwendung ist es überraschend, denn Sie bekommen eine Antwort, die keine Daten enthält, und Ihr Code läuft in den Erfolgszweig. Deshalb müssen Sie den Status selbst prüfen — immer, ohne Ausnahme. Sieben Zeilen, und die Prüfung in der Mitte ist die, um die es geht. Ohne sie würde bei einer Fehlerseite deren Inhalt als vermeintliche Nutzdaten in Ihre Anwendung wandern.

3:59 Im besten Fall scheitert dann die Umwandlung mit einer kryptischen Meldung, im schlechteren zeigen Sie eine leere Liste an und niemand merkt, dass der Server etwas anderes gesagt hat. Die drei Zeilen kosten nichts und gehören in jede Abruffunktion — am besten schreiben Sie sie einmal und verwenden sie überall wieder. Fünf Zeilen, und zwei davon verdienen Aufmerksamkeit. Die erste ist Ihre Prüfung: ein Wahrheitswert für den Erfolgsbereich.

4:24 Die dritte ist die, über die viele stolpern — die Umwandlung in Daten ist selbst asynchron. Sie brauchen also ein zweites Warten. Das ist der Grund, warum ein Abruf typischerweise zwei Wartepunkte hat, und das verwirrt am Anfang. Merken Sie sich: Der erste liefert die Antwort, der zweite deren Inhalt. Beim Senden kommt Arbeit dazu, die andere Werkzeuge übernehmen.

4:47 Sie müssen den Rumpf selbst in Text umwandeln, und Sie müssen die Kopfzeile setzen, die dem Server sagt, worum es sich handelt. Beides vergisst man leicht, und die Folge ist ein Server, der die Daten nicht versteht — oft mit einer wenig hilfreichen Fehlermeldung. Das ist übrigens genau der Punkt, an dem eine Bibliothek anfängt, sich zu lohnen: Sie erledigt beides von selbst.

5:09 Der erste Punkt ist die Eigenheit noch einmal, und ich wiederhole sie bewusst. Der zweite ist ein Fall, den man erst beim Löschen bemerkt: Eine Antwort ohne Inhalt lässt die Umwandlung scheitern. Viele Server antworten auf eine erfolgreiche Löschung mit einem leeren Rumpf — und dann fliegt Ihnen der Erfolgsfall um die Ohren.

5:27 Der letzte Punkt ist eine technische Eigenheit, die selten stört und dann sehr: Eine Antwort lässt sich nur einmal auslesen. Wer erst den Text und dann die Daten haben will, muss vorher eine Kopie ziehen.

Nutzung der Axios-Bibliothek

5:39 Damit kommen wir zur Alternative. Es gibt eine seit Jahren verbreitete Bibliothek, die genau die Dinge übernimmt, die wir eben von Hand gemacht haben. Die Frage ist nicht, ob sie gut ist — sie ist gut. Die Frage ist, ab wann sich eine zusätzliche Abhängigkeit lohnt. Ich gebe Ihnen dafür eine Faustregel, und die hat mit der Größe Ihres Vorhabens zu tun.

6:01 Vier Dinge nimmt Ihnen die Bibliothek ab: die Umwandlung von Daten, die Fehlerbehandlung bei schlechtem Status, eine gemeinsame Grundkonfiguration und Abfangfunktionen für alle Anfragen. Der dritte und vierte Punkt sind die, die im Alltag am meisten bringen. Eine Instanz mit fester Grundadresse und festen Kopfzeilen bedeutet, dass jeder einzelne Aufruf kürzer wird.

6:22 Und Abfangfunktionen sind der Ort, an dem Sie eine Anmeldung anhängen oder Fehler einmal zentral übersetzen. Fünf Zeilen Gegenüberstellung. Die dritte ist die, die im Alltag den Unterschied macht: Ein Fehlerstatus führt bei der Bibliothek zu einem echten Fehler, den Ihr Fehlerzweig auffängt. Sie müssen also nicht mehr daran denken. Die Fußzeile liefert die Faustregel, die ich versprochen habe: Für wenige Aufrufe genügt der eingebaute Weg.

6:48 Sobald Sie aber ohnehin eine eigene Zugriffsschicht bauen — und das kommt in Kapitel fünf —, spart die Bibliothek spürbar Code. Zehn Zeilen, und darin steckt bereits eine solide Grundlage. Die Grundadresse kommt aus der Umgebung, damit Test und Produktion verschiedene Ziele haben können — dazu mehr in Modul 12. Die Zeitüberschreitung ist ein Detail, das viele vergessen und das im Ernstfall den Unterschied macht: Ohne sie wartet ein Aufruf theoretisch ewig.

7:15 Und die Abfangfunktion unten ist der Ort, an dem Sie technische Fehler einmal in verständliche Meldungen übersetzen, statt das in jeder Komponente zu tun. Der zweite Punkt ist der Unterschied, über den beim Umstieg jeder einmal stolpert: Die Nutzdaten liegen bei der Bibliothek in einem Feld der Antwort, nicht direkt im Ergebnis.

7:34 Der dritte Punkt ist eine Warnung zur Sorgfalt: Abfangfunktionen wirken global. Wenn Sie darin einen Sonderfall behandeln, gilt er für jeden Aufruf der Anwendung — und wer das sucht, sucht lange, weil an der aufrufenden Stelle nichts davon steht. Halten Sie sie schlank und vorhersehbar.

Fehlerbehandlung bei HTTP Requests

7:50 Jetzt zum Umgang mit dem, was schiefgeht. Ich möchte dabei eine Grundeinstellung vermitteln, die wichtiger ist als jede Technik: Ein fehlgeschlagener Abruf ist kein Ausnahmefall, den man wegfangen muss, sondern ein normaler Zustand, den man anzeigt. Wenn Sie das verinnerlicht haben, bauen Sie automatisch bessere Oberflächen.

8:09 Wir klären außerdem, wo im Code der Fehler eigentlich behandelt gehört — und das ist seltener dort, wo er entsteht. Die Frage, die man sich stellen muss, ist: Wo kann etwas Sinnvolles mit dem Fehler geschehen? Und die Antwort ist praktisch nie die reine Abruffunktion. Die weiß ja nicht, ob dieser Aufruf für eine Liste, ein Formular oder eine Hintergrundaktualisierung war.

8:31 Also lässt sie den Fehler durch und behandelt ihn dort, wo der Kontext bekannt ist — in der Komponente oder in dem Composable, das den Ladezustand führt. Das ist eine allgemeine Regel für Fehlerbehandlung, nicht nur in Vue. Das ist das Muster, das Sie in jeder Anwendung wiederfinden werden: Ladezustand setzen, Fehler zurücksetzen, versuchen, auffangen, und im letzten Zweig den Ladezustand wieder lösen.

8:55 Der letzte Zweig ist der wichtigste und wird am häufigsten vergessen. Ohne ihn bleibt Ihre Anwendung nach einem Fehler für immer im Ladezustand — der Nutzer sieht einen Ladehinweis, der sich nie auflöst. Das ist schlimmer als eine Fehlermeldung, weil es nach einem Aufhängen aussieht. Fünf Schritte, und Schritt fünf ist der, der aus einer korrekten eine gute Oberfläche macht: Wiederholung anbieten.

9:19 Die meisten Fehler beim Datenabruf sind vorübergehend — eine schlechte Verbindung, ein kurzer Ausfall. Wenn Sie einen Knopf anbieten, ist das Problem für den Nutzer in einer Sekunde gelöst. Ohne Knopf bleibt ihm nur, die Seite neu zu laden und dabei allen Zustand zu verlieren. Die Fußzeile fasst es: Eine Meldung ohne Handlungsmöglichkeit lässt den Nutzer allein.

9:41 Vier Kategorien, vier Reaktionen — und das ist der Unterschied zwischen einer generischen Meldung und einer hilfreichen. Bei einem Netzwerkproblem hilft Wiederholen. Bei einem Rechteproblem hilft die Anmeldung. Bei einem Serverfehler hilft nur Warten, und das sollte man ehrlich sagen. Die Fußzeile nennt den Fehler, den man ohne diese Unterscheidung macht: immer dieselbe unbrauchbare Meldung.

10:03 Sie müssen nicht alle vier Fälle einzeln behandeln, aber Netzwerk und Anmeldung sollten Sie trennen. Der erste Punkt ist der, den ich am häufigsten sehe: ein Fehlerzweig, der nur auf die Konsole schreibt. Das ist keine Fehlerbehandlung, das ist eine Notiz an Sie selbst — der Nutzer sieht davon nichts. Der zweite Punkt ist die andere Richtung: technische Meldungen in der Oberfläche.

10:26 Eine Statusnummer verunsichert und hilft niemandem. Und der letzte Punkt ist eine Feinheit, die im nächsten Kapitel wichtig wird: Ein abgebrochener Abruf löst ebenfalls den Fehlerzweig aus und ist trotzdem kein Fehler.

Strukturierung von API Zugriffen

10:39 Jetzt eine Strukturfrage, und die Empfehlung ist so einfach wie wirkungsvoll: Kein Abruf steht direkt in einer Komponente. Stattdessen gibt es eine eigene Schicht dafür. Das kostet eine Datei und zahlt sich mehrfach zurück — beim Ändern, beim Testen und beim Wechsel des Werkzeugs. Ich zeige Ihnen, wie diese Schicht aussieht und was sie enthalten sollte — und, fast ebenso wichtig, was sie ausdrücklich nicht enthalten sollte.

11:04 Die Idee: ein Modul je fachlichem Bereich, mit Funktionen, die einen sprechenden Namen tragen. Die Komponente ruft eine Funktion namens Lade-Artikel auf und weiß nichts über Adressen, Kopfzeilen oder Statuscodes. Das ist derselbe Gedanke wie bei den wiederverwendbaren Komponenten aus Modul 2: Wer weniger weiß, ist beweglicher.

11:23 Und es hat einen Nebeneffekt, den man erst später schätzt — die Funktionsnamen bilden zusammen eine lesbare Beschreibung dessen, was Ihre Anwendung mit dem Backend macht. Drei Funktionen, drei Zeilen Logik. Sehen Sie sich an, was diese Schicht tut und was sie nicht tut: Sie ruft auf und packt die Nutzdaten aus. Sie entscheidet nicht, was bei einem Fehler passieren soll, und sie hält keinen Zustand.

11:47 Diese Zurückhaltung ist Absicht — sie macht die Funktionen zu dem, was sie sein sollen: eine Übersetzung zwischen HTTP und Ihrer Fachsprache. Alles Weitere passiert eine Ebene darüber. Der zweite Punkt ist der, der sich beim Testen sofort auszahlt: Sie können die Funktion ersetzen und die Komponente ohne Netzwerk prüfen.

12:06 Der letzte Punkt ist der strategische — wenn Sie später vom eingebauten Weg auf eine Bibliothek wechseln oder umgekehrt, betrifft das ausschließlich diese Schicht. Keine Komponente muss angefasst werden. Das ist der Grund, warum ich in Kapitel drei gesagt habe, die Entscheidung zwischen beiden sei weniger dramatisch, als sie wirkt: Sie ist umkehrbar, wenn die Struktur stimmt.

12:27 Die Erfolgskriterien sind hier bewusst als Suchaufgabe formuliert: keine URL mehr in einer Komponente, keine Statusprüfung mehr in einer Komponente. Beides können Sie mit der Suchfunktion Ihres Editors nachprüfen — suchen Sie nach dem Schrägstrich-Muster einer Adresse oder nach dem Namen des Abrufwerkzeugs. Wenn ein Treffer außerhalb des API-Ordners liegt, ist die Aufgabe noch nicht fertig. Das ist eine der wenigen Aufräumaufgaben mit einem wirklich objektiven Prüfkriterium.

12:56 Der erste Punkt ist eine Grenzziehung, die ich betonen möchte: Die Schicht formt um, sie entscheidet nicht. Wer dort anfängt, Fehler zu behandeln oder Meldungen anzuzeigen, hat die Ebene verwechselt. Der letzte Punkt ist eine technische Falle, die im deutschen Sprachraum häufig zuschlägt: Adressen zusammenzubauen, ohne die Bestandteile zu kodieren, bricht bei Umlauten und Leerzeichen.

13:18 Ein Suchbegriff mit einem Ampersand darin kann Ihre ganze Abfrage zerlegen.

Nutzung von Composables für wiederverwendbare API-Logik

13:23 Jetzt schließen wir den Kreis zu Modul 5. Die drei Zustände eines Abrufs sehen bei jeder Ressource gleich aus — laden, Daten, Fehler. Genau solche Wiederholung ist der Anlass für ein Composable. Wir bauen eines, und danach kostet die Anbindung einer neuen Ressource in einer Komponente drei Zeilen. Das ist einer der befriedigendsten Momente in diesem Seminar — und ein gutes Beispiel dafür, dass sich die Beschäftigung mit den Grundlagen aus Modul 5 auszahlt.

13:51 Der Gedanke ist einfach: Wenn dasselbe Muster überall auftaucht, schreibt man es einmal. Die Funktion nimmt eine Abruffunktion entgegen und liefert die drei Zustände plus eine Möglichkeit, den Abruf erneut anzustoßen. Beachten Sie, wie allgemein das ist — das Composable weiß nichts über Artikel oder Ausleihen. Es weiß nur, dass es eine Funktion gibt, die ein Versprechen zurückgibt.

14:13 Damit funktioniert es für jede Ressource, die Sie jemals anbinden werden. Zehn Zeilen für etwas, das Sie hunderte Male benutzen werden. Interessant ist die vorletzte Zeile: Der Abruf wird beim Einhängen ausgelöst. Das ist eine Entscheidung, die man auch anders treffen kann — manche Composables laden erst auf Aufforderung.

14:33 Und die letzte Zeile ist die aus Modul 5 bekannte Regel: Ein gewöhnliches Objekt aus reaktiven Werten zurückgeben, damit der Aufrufer zerlegen kann, ohne die Reaktivität zu verlieren. Diese Regel gilt für jedes Composable. Und das ist das Ergebnis: drei Zeilen in der Komponente. Ein Import für das Composable, ein Import für die Abruffunktion, ein Aufruf.

14:55 Danach haben Sie Daten, Ladezustand, Fehler und eine Wiederholungsfunktion — alles reaktiv, alles einsatzbereit. Vergleichen Sie das mit den zwanzig Zeilen aus Kapitel vier, die sonst in jeder Komponente stünden. Das ist der Moment, in dem sich die Beschäftigung mit Composables aus Modul 5 auszahlt. Der letzte Punkt beschreibt das Problem, das die Funktion löst: Ohne diese Vorkehrung friert das Composable auf dem ersten Wert ein.

15:22 Stellen Sie sich vor, Sie übergeben eine Artikelkennung. Wenn die sich ändert — etwa weil der Nutzer zu einem anderen Artikel navigiert —, soll neu geladen werden. Das geht nur, wenn das Composable den reaktiven Wert selbst bekommt und nicht seinen Momentanwert. Die Normalisierungsfunktion sorgt dafür, dass beides funktioniert: ein reaktiver Wert und ein einfacher.

15:44 Der erste Punkt ist die Falle aus Modul 5, jetzt in einem konkreten Kontext: Zustand außerhalb der Funktion zu deklarieren teilt ihn über alle Aufrufer. Zwei Komponenten würden sich dann eine Datenmenge teilen — und beim zweiten Aufruf die erste überschreiben. Der letzte Punkt ist eine Warnung vor Übertreibung: Zu viel in ein Composable zu packen macht es so unbeweglich wie die Komponente vorher.

16:07 Wenn Ihr Abruf-Composable anfängt, Fachlogik zu enthalten, ist es zu groß geworden.

Asynchrone Datenverarbeitung in Vue-Komponenten

16:12 Jetzt ein Kapitel über einen Fehler, der lokal fast nie auftritt und im Betrieb ständig: Antworten, die in der falschen Reihenfolge eintreffen. Das klingt exotisch, ist es aber nicht — jede Suche mit Eingabefeld ist betroffen. Ich zeige Ihnen, wie das Problem entsteht und mit welchen zwei Werkzeugen man es löst. Und ich erkläre, warum dieser Fehler zu der unangenehmen Sorte gehört, die man nur im Betrieb sieht und im Test nie reproduziert.

16:38 Das Szenario: Jemand tippt in ein Suchfeld. Bei jedem Zeichen starten Sie eine Anfrage. Die Antwort auf die kurze Sucheingabe braucht länger, weil sie mehr Treffer liefert — und trifft deshalb nach der Antwort auf die längere ein. Das Ergebnis: Der Nutzer sieht Treffer zu einem Suchbegriff, den er schon längst weitergetippt hat. Die Anzeige ist falsch, obwohl jeder einzelne Aufruf korrekt war.

17:02 Das ist ein Wettlauf, und die Lösung ist, überholte Anfragen abzubrechen. Sechs Zeilen, und die Mechanik ist elegant. Bei jeder Änderung entsteht eine neue Steuerung, die an die Anfrage weitergereicht wird. Und bevor der nächste Durchlauf startet, wird die vorherige abgebrochen. Damit kann eine überholte Antwort gar nicht mehr ankommen.

17:23 Die Aufräumfunktion gibt es in dieser Form seit Vue 3.5 — vorher lief das über ein zusätzliches Argument des Rückrufs. Wenn Sie also ältere Beispiele sehen, meinen die dasselbe. Fünf Zeilen, und die Fußzeile nennt die Kombination, die im Alltag richtig ist: Entprellung und Abbruch zusammen. Sie lösen verschiedene Probleme.

17:43 Die Entprellung reduziert die Zahl der Anfragen — statt bei jedem Zeichen wird erst gesendet, wenn kurz Ruhe ist. Der Abbruch löst die Reihenfolge für die Anfragen, die trotzdem noch gleichzeitig unterwegs sind. Wer nur entprellt, hat den Wettlauf seltener, aber nicht beseitigt. Der erste Punkt ist der Grund, warum dieses Kapitel existiert: Lokal tritt der Fehler fast nie auf. Ihr Entwicklungsserver antwortet in fünf Millisekunden, da überholt nichts.

18:11 Der zweite Punkt macht es schlimmer: Das Symptom sieht aus wie ein Anzeigefehler, nicht wie ein Netzwerkproblem. Man sucht also in der Komponente. Deshalb der Rat aus dem letzten Punkt: Bauen Sie den Abbruch von Anfang an in Ihr Suchmuster ein, statt zu warten, bis jemand den Fehler meldet. Der erste Punkt ist der, der beim Einbauen des Abbruchs sofort auffällt: Ein abgebrochener Abruf löst den Fehlerzweig aus.

18:35 Wenn Sie das nicht unterscheiden, zeigen Sie bei jedem Tastenanschlag kurz eine Fehlermeldung. Prüfen Sie also im Fehlerzweig, ob es sich um einen Abbruch handelt, und ignorieren Sie den Fall. Der letzte Punkt ist ein Hinweis auf ein Werkzeug, das wir nicht vertiefen: Ein Warten direkt im Einrichtungsteil hält das Rendern an und braucht eine besondere Umgebung.

Integration von REST APIs in Vue-Anwendungen

18:56 Zum Abschluss setzen wir alles zusammen. Sie haben jetzt vier Bausteine kennen gelernt — die Umgebung, die Zugriffsschicht, das Composable und die Anzeige. Ich möchte Ihnen zeigen, wie die zusammenspielen und warum jede Schicht nur ihren Nachbarn kennen sollte. Am Ende steht die Anzeige, die alle drei Zustände abbildet — und damit schließt sich der Bogen zu der Tabelle vom Anfang dieses Moduls.

19:19 Vier Teile, und jeder kennt nur seinen Nachbarn. Die Umgebung weiß nichts. Der Client kennt die Grundadresse. Die Ressourcenfunktionen kennen den Client. Das Composable kennt die Ressourcen. Die Anzeige kennt das Composable. Diese Kette ist der Grund, warum sich einzelne Teile austauschen lassen, ohne dass der Rest davon erfährt.

19:40 Sie ist auch der Grund, warum Sie beim Suchen eines Fehlers genau wissen, in welcher Schicht Sie nachsehen müssen. Fünf Zeilen für die vier Ebenen plus die Umgebung, und die rechte Spalte ist der eigentliche Inhalt: wer wen kennt. Die Fußzeile enthält die Regel, die das Ganze zusammenhält — kein Sprung über eine Schicht hinweg.

20:00 Wenn eine Komponente direkt den Client anspricht, weil es gerade schneller geht, ist die Aufteilung wertlos. Das passiert übrigens nicht aus Böswilligkeit, sondern unter Zeitdruck. Deshalb lohnt es sich, die Regel im Team einmal ausdrücklich zu vereinbaren. Und hier ist das Ergebnis: sechs Zeilen Template mit drei Zweigen. Genau die drei Zustände vom Anfang des Moduls — laden, Fehler mit Wiederholung, Daten.

20:25 Keine Lücke, kein Fall, in dem der Nutzer nicht weiß, woran er ist. Sehen Sie sich den mittleren Zweig an: Die Meldung steht zusammen mit dem Knopf, der das Problem lösen kann. Das ist der Unterschied zwischen einer Fehlermeldung und einer Handlungsmöglichkeit — und er kostet ein zusätzliches Element. Diese Aufgabe ist die Zusammenfassung des Moduls in Praxis.

20:47 Der Hinweis unten ist der wichtigste Teil: Halten Sie den Entwicklungsserver des Backends an, um den Fehlerzweig zu erreichen. Sonst prüfen Sie nur den Erfolgsfall — und genau davor habe ich am Anfang gewarnt. Sie werden feststellen, dass sich der Fehlerzweig ganz anders anfühlt, wenn man ihn wirklich sieht. Oft merkt man erst dann, dass die Meldung zu technisch ist oder der Knopf fehlt.

21:10 Der dritte Punkt ist einer, den man leicht vergisst: der leere Erfolgsfall. Ein Abruf, der erfolgreich war und null Ergebnisse geliefert hat, sieht ohne eigene Anzeige genauso aus wie ein Fehler — nämlich leer. Sagen Sie dem Nutzer, dass es nichts gibt, und wenn möglich, warum. Der letzte Punkt ist ein Detail aus der Gestaltung: Ein Ladehinweis, der bei schnellen Antworten für achtzig Millisekunden aufblitzt, wirkt wie ein Flackern.

21:36 Dagegen hilft eine kleine Verzögerung, bevor er erscheint.

Daten im Griff

21:40 Fassen wir zusammen. Drei Zustände: lädt, erfolgreich, fehlgeschlagen — und alle drei gehören gebaut. Der eingebaute Weg meldet einen Fehlerstatus nicht von allein, die Bibliothek schon. Und die Trennung in Zugriffsschicht, Composable und Anzeige hält die Teile austauschbar. Im nächsten Modul geht es um Zustand, den mehrere Ansichten teilen — also um die Frage, wohin die geladenen Daten gehören, wenn nicht nur eine Komponente sie braucht.