React-Erfahrung auf UI Kit übertragen

React-Erfahrung auf UI Kit übertragen

0:00 Wer React beherrscht, beherrscht UI Kit zu neunzig Prozent. Das ist die gute Nachricht. Die interessantere ist: Die restlichen zehn Prozent liegen genau an den Stellen, an denen man aus Gewohnheit nicht mehr hinsieht. Wie kommt der Kontext in die Komponente. Wann feuert ein Effekt. Welche Bibliothek darf mit. Dieses Modul arbeitet diese zehn Prozent systematisch ab — nicht, weil sie kompliziert wären, sondern weil sie leise sind.

0:26 Ein Fehler in diesem Bereich meldet sich selten mit einer klaren Fehlermeldung. Er meldet sich als „irgendwas lädt zu oft" oder „manchmal ist das Feld leer".

React-Erfahrung auf UI Kit übertragen

0:37 Der Nachmittag des zweiten Tages dreht die Perspektive um. Am Vormittag ging es darum, was UI Kit anbietet. Jetzt geht es darum, was von Ihrem bisherigen Wissen trägt. Wir schauen uns die Hooks an, den asynchronen Kontext, das Nachladen von Daten, die Frage nach fremden Bibliotheken — und zum Schluss ein Thema, das man gern auf später schiebt und dann nie macht: Mehrsprachigkeit.

Hooks und asynchroner Kontext

1:00 Beginnen wir mit der Stelle, an der die meisten UI-Kit-Apps beim allerersten Rendern stolpern — und zwar reproduzierbar. Hier ist der wichtigste Satz des Nachmittags: Der Produktkontext ist beim ersten Rendervorgang noch nicht da. Stellen Sie sich vor, Sie betreten einen Raum und sollen sofort sagen, wer sonst noch da ist — aber das Licht geht erst eine Sekunde später an.

1:22 Genau so verhält sich useProductContext: Beim ersten Aufruf liefert er undefined, danach den Kontext. Das ist kein Fehler, sondern die Bauweise. Die übrigen Hooks funktionieren wie gewohnt, solange sie nicht auf DOM-Knoten oder den synchronen Ablauf des Browsers angewiesen sind. Drei Zeilen, und sie sind die Lösung für ein Problem, das sonst sporadisch auftritt. Kontext holen, prüfen, ob er schon da ist, und erst danach darauf zugreifen.

1:48 Das Muster erinnert bewusst an die Zustände von heute Vormittag — auch hier gilt: erst der Sonderfall, dann der Inhalt. Wer die Prüfung weglässt, bekommt keine schöne Fehlermeldung, sondern einen Zugriff auf etwas, das noch nicht existiert. Die Fußzeile nennt den zweiten Weg: Dieselbe Angabe liefert view.getContext aus dem Bridge-Paket, dort als Promise — nützlich, wenn Sie den Kontext außerhalb einer Komponente brauchen.

2:14 Diese Tabelle ist beruhigender, als sie aussieht: Praktisch alles, was Sie täglich verwenden, steht darin. Die Logik dahinter ist eine einzige Frage — hängt der Hook am DOM oder nicht? Zustand, Effekte, Kontext, Merken von Werten: alles kein Problem. Lediglich useRef verliert seine häufigste Verwendung, weil es keine Elemente gibt, auf die man zeigen könnte — als Behälter für einen Wert über Rendervorgänge hinweg funktioniert es weiterhin.

2:40 Und zwei Hooks kommen hinzu, die es in React nicht gibt: der Produktkontext und die Übersetzung. Beide holen Sie aus dem Forge-Paket, nicht aus React. Der erste Punkt ist die direkte Folge der fehlenden Prüfung — und er zeigt sich gern erst auf einem langsameren Rechner als Ihrem. Der zweite ist heimtückisch: Ein eigener Hook, den Sie aus einem anderen Projekt mitnehmen, greift irgendwo tief innen auf window zu. Das sieht man der Signatur nicht an.

3:07 Und der dritte ist eine Erfahrung, die fast jeder einmal macht: Im Tunnel sind die Daten sofort da, also fühlt sich alles synchron an. In der echten Instanz, über eine echte Verbindung, ist es das nicht.

Effekte und Datenabrufe

3:19 Damit sind wir beim Nachladen — und bei der Frage, wie oft eine App eigentlich lädt, wenn niemand hinsieht. Das Muster ist Ihnen vertraut: Ein Effekt holt die Daten nach dem ersten Rendern. Entscheidend ist die Abhängigkeitsliste — sie bestimmt, wann erneut geladen wird. Und hier lauert der Klassiker aller React-Projekte: Objekte und Funktionen, die bei jedem Rendervorgang neu entstehen, sehen für React jedes Mal wie ein neuer Wert aus.

3:46 Der Effekt feuert also erneut, setzt Zustand, löst ein Rendern aus — und beginnt von vorn. In einer Web-Anwendung fällt das oft nicht auf. Hier schon, und zwar auf der Rechnung. An diesem Beispiel sind zwei Dinge wichtig. Erstens die Abhängigkeitsliste am Ende: nur die Vorgangskennung, ein einfacher Wert. Damit lädt der Effekt einmal und erst wieder, wenn sich der Vorgang tatsächlich ändert.

4:09 Zweitens die kleine Aufräumfunktion mit der Variablen, die merkt, ob die Komponente noch aktuell ist. Das wirkt übertrieben, bis der erste Nutzer schnell zwischen zwei Vorgängen hin und her springt — dann kommt eine späte Antwort zurück und setzt Daten, die längst nicht mehr gelten. Worauf es ankommt: Jeder der drei Ausgänge wird behandelt, auch der Fehlerfall und das Ende des Ladens.

4:32 Und jetzt die Einordnung, die diesen Punkt von einer Stilfrage zu einer Architekturfrage macht. In einer Web-Anwendung kostet ein überflüssiger Abruf etwas Bandbreite. Hier geht jeder Aufruf über die Plattform, zählt gegen Grenzen und erzeugt Verbrauch — also Kosten. Ein Panel wird oft geöffnet und geschlossen, selten neu geladen.

4:51 Wenn ein Effekt dabei doppelt feuert, verdoppeln Sie die Aufrufzahl Ihrer App bei gleicher Nutzung. Am fünften Tag sehen wir, dass genau diese Verdopplung in den Metriken sichtbar wird — sie ist eines der zuverlässigsten Warnsignale im Betrieb. Der erste Punkt ist der eben beschriebene Klassiker. Der zweite ist eine Bequemlichkeit mit Folgen: Nach dem Speichern die ganze Liste neu laden, statt den neuen Eintrag anzuhängen.

5:16 Bei fünf Einträgen ist das egal, bei fünfhundert nicht mehr — und die Nutzerin sieht jedes Mal den Ladezustand. Der dritte ist der unangenehmste: Der Fehler wird zwar abgefangen, aber der Ladezustand bleibt stehen. Dann dreht sich der Spinner für immer, und niemand weiß, warum.

Grenzen gewohnter Bibliotheken

5:34 Kommen wir zu der Frage, die in jedem Projekt spätestens in der zweiten Woche auftaucht: Welche Pakete darf ich eigentlich mitbringen? Die Antwort lässt sich auf eine einzige Frage reduzieren: Braucht das Paket einen Browser? Datumsrechnung, Validierung, Formatierung, Schemata — alles, was nur rechnet, funktioniert hier genauso wie überall.

5:54 Alles, was rendert, misst oder auf document zugreift, funktioniert nicht. Diese Trennlinie ist scharf, und sie läuft nicht entlang der Paketgröße oder Bekanntheit. Das bekannteste Diagramm-Paket der Welt hilft Ihnen hier nicht, eine winzige Hilfsbibliothek für Zeitzonen dagegen schon. Diese Gegenüberstellung sollten Sie als Prüffrage mitnehmen, nicht als Liste. Links steht, was rechnet — rechts, was zeichnet oder anfasst.

6:20 Interessant ist die letzte Zeile rechts: DOM-basierte Testwerkzeuge. Das trifft viele unvorbereitet, weil Tests kein Feature sind und deshalb erst spät angefasst werden. Am vierten Tag schauen wir uns an, wie man damit umgeht — die kurze Antwort lautet: Man testet, was nicht rendert, und schneidet den Code entsprechend.

6:40 Und ganz rechts unten: Für Diagramme müssen Sie kein Fremdpaket suchen, UI Kit bringt welche mit. Fünf Schritte, deren roter Faden Vorsicht mit möglichst wenig Aufwand ist. Klären, ob das Paket rechnet oder rendert. In die Abhängigkeiten schauen — oft verrät erst die zweite Ebene den Browser-Bezug. Dann der praktische Teil: in einer winzigen Testkomponente einbinden und tatsächlich ausrollen.

7:04 Und hier steht der Schritt, der den Unterschied macht: im Produkt prüfen, nicht nur im Tunnel. Der letzte Punkt ist eine Haltungsfrage — im Zweifel die Aufgabe selbst lösen. Eine Abhängigkeit, die man nicht versteht, wird irgendwann zum Termin. Der erste Punkt ist der Grund für Schritt vier von eben: Im Tunnel läuft manches, was in der Instanz nicht läuft.

7:26 Der zweite ist die zweite Ebene — eine Unterabhängigkeit bringt den DOM-Zugriff mit, und Ihr Paket selbst sieht harmlos aus. Und der dritte ist eine vertane Gelegenheit: Für Diagramme wird ein Fremdpaket gesucht, obwohl die Plattform Balken-, Linien- und Tortendiagramme mitbringt — die dann auch noch aussehen wie das Produkt.

Mehrsprachigkeit

7:45 Zum Abschluss des Tages ein Thema, das man selten am Anfang angeht und fast immer am Anfang angehen sollte. Forge macht Mehrsprachigkeit erfreulich unspektakulär. Im Manifest melden Sie je Sprache eine JSON-Datei an und geben eine Ausweichreihenfolge mit einer Standardsprache an. In der Oberfläche liefert ein Hook die Übersetzungsfunktion, meist einfach t genannt, und ein Anbieter-Baustein steht an der Wurzel der App.

8:10 Das Angenehme daran: Die Sprache der Nutzerin kommt aus dem Produkt, Sie müssen sie nicht selbst ermitteln. Das Unangenehme: Wer erst nachträglich umstellt, geht durch jede Komponente. Deshalb lohnt es sich, von Anfang an Schlüssel statt Texte zu schreiben. Oben sehen Sie die Anmeldung im Manifest — je Sprache ein Schlüssel und ein Pfad, dazu die Standardsprache für den Fall, dass eine Sprache nicht aufzulösen ist.

8:35 Wichtig: Die Standardsprache muss selbst in der Liste der Ressourcen stehen, sonst greift die Auflösung ins Leere. In der Komponente holen Sie sich dann zwei Dinge, wie die Fußzeile zeigt: einen Bereitschaftsmerker und die Übersetzungsfunktion. Der Bereitschaftsmerker ist kein Beiwerk — solange er falsch ist, zeigt die Oberfläche sonst kurz die nackten Schlüssel. Auch das ist wieder ein Zustand vor dem Inhalt.

8:59 Die Reihenfolge ist hier entscheidend. Erst die Texte in Schlüssel überführen, dann die Dateien anlegen, dann den Anbieter setzen. Schritt vier wird am häufigsten vergessen und fällt am stärksten auf: Auch Texte aus dem Manifest gehören übersetzt, etwa der Titel des Moduls. Es wirkt seltsam, wenn die Oberfläche deutsch ist und die Registerkarte darüber englisch.

9:20 Und Schritt fünf ist die einzige verlässliche Prüfung: Stellen Sie Ihre Profilsprache um und sehen Sie sich die App an. Alles andere ist Hoffnung. Der erste Punkt ist der sichtbarste: Ohne das Abwarten der Bereitschaft blitzen die Schlüssel auf — und ein „klarpfad.titel" auf dem Bildschirm sieht immer nach Baustelle aus.

9:38 Der zweite ist der leiseste und ärgerlichste: Fehler- und Leermeldungen bleiben als einzige hart im Code stehen, weil sie beim Umstellen niemand sieht. Genau die bekommen Nutzende aber zu sehen, wenn es klemmt. Und der dritte ist ein Konfigurationsfehler mit unauffälliger Wirkung — die Standardsprache fehlt in den Ressourcen, und die Auflösung scheitert still.

Übung

9:59 In der Übung bringen wir beide Themen des Nachmittags zusammen: robustes Nachladen und Texte, die nicht mehr im Code stehen. Klarpfad lädt inzwischen nach — und damit werden Fälle sichtbar, die im Tunnel nie auftreten: langsame Antworten, abgebrochene Aufrufe, wiederholtes Öffnen. Das ist typisch für diese Art von App: Sie ist kein Bildschirm, den man einmal betritt, sondern eine Fläche, die ständig auf- und zugeklappt wird.

10:24 Parallel bereiten Sie die Oberfläche auf eine zweite Sprache vor — solange sie noch klein ist und der Aufwand eine halbe Stunde beträgt statt zweier Tage. Das Erfolgskriterium hat drei Teile, und jeder prüft etwas anderes. Ein erzwungener Fehler zeigt eine eigene Meldung — also kein technischer Text, kein ewiger Spinner.

10:43 Wiederholtes Öffnen löst keinen zweiten Abruf aus — das ist die Prüfung der Abhängigkeitsliste. Und alle sichtbaren Texte kommen aus Schlüsseln. Wer früh fertig ist, ergänzt eine Schaltfläche für einen erneuten Versuch nach einem Fehler. Das ist kein Beiwerk: Eine Fehlermeldung ohne Ausweg ist nur eine höflichere Sackgasse.

11:04 Der Ablauf folgt genau den Kapiteln dieses Nachmittags. Erst der Effekt mit klarer Abhängigkeit, dann Ladezustand, Fehlerfall und Aufräumfunktion. Schritt drei ist der, den ich Ihnen besonders ans Herz lege: einen Fehler gezielt herbeiführen. Kommentieren Sie den Aufruf aus, geben Sie einen falschen Schlüssel an — Hauptsache, Sie sehen Ihre eigene Fehleranzeige einmal mit eigenen Augen.

11:27 Danach die Texte und zum Schluss die Gegenprobe mit umgestellter Profilsprache. Drei Punkte zum Mitnehmen. Der Fehlerfall wird angenommen, aber nie ausgelöst — dann ist er Dekoration. Die Abhängigkeitsliste bleibt leer, und beim Wechsel des Vorgangs lädt nichts nach; das fällt erst auf, wenn jemand zwei Vorgänge vergleicht.

11:47 Und übersetzt wird die Oberfläche, während der Modultitel im Manifest englisch bleibt. Morgen verlassen wir die Oberfläche und gehen nach hinten: zu den Resolvern, den Produkt-APIs und der Frage, wem man eigentlich trauen darf.