Bestehende Apps und besondere UI-Anforderungen

Bestehende Apps und besondere UI-Anforderungen

0:00 Gestern haben wir festgestellt, dass ein großer Teil des Forge-Wissens im Netz veraltet ist. Heute schauen wir uns an, wie dieses veraltete Wissen konkret aussieht — und was daraus wird. Das hat zwei praktische Seiten. Erstens erkennen Sie fremde Beispiele in Sekunden statt in einer halben Stunde. Zweitens können Sie eine bestehende App übertragen, ohne sie neu zu schreiben.

0:22 Und danach sprechen wir über die Fälle, in denen UI Kit tatsächlich nicht reicht — und wie man die Ausnahme klein hält.

Migration, Betrieb und Abschlussprojekt

0:29 Der letzte Tag schließt die Klammer. Erst die Migration und die Frage nach besonderen UI-Anforderungen. Dann der Betrieb: Umgebungen, Releases, Beobachtung, Verteilungswege. Und am Nachmittag Ihr Abschlussprojekt mit einem gegenseitigen Review. Danach haben Sie nicht nur eine App, sondern etwas, das sich übergeben lässt.

Ältere UI-Kit-Beispiele erkennen

0:50 Beginnen wir mit dem Erkennen. Vier Merkmale genügen, und Sie werden sie nie wieder übersehen. Die erste Fassung von UI Kit arbeitete mit einem anderen Paket, einem einzigen Einstiegspunkt, eigenen Hooks und Komponenten, die es heute nicht mehr gibt. Wichtig ist das Wort im letzten Satz: Solcher Code wird nicht angepasst, er wird übertragen. Das ist keine Wortklauberei, sondern eine Erwartungshaltung.

1:15 Wer versucht, Zeile für Zeile zu reparieren, mischt am Ende beide Fassungen und hat ein Projekt, das niemand mehr versteht. Wer überträgt, geht systematisch vor und ist in zwei Stunden fertig. Vier Merkmale in acht Zeilen. Erstens der Paketname — das ist das schnellste Erkennungszeichen überhaupt, ein Blick auf die Importzeile genügt.

1:36 Zweitens die Renderfunktion der alten Fassung. Drittens ein Hook für Zustand, den es in React so nicht gibt. Und viertens eine Rahmenkomponente, die den Modultyp im Code abbildet — heute steht das ausschließlich im Manifest. Die Fußzeile fasst es zusammen: Sehen Sie eines dieser Merkmale, sehen Sie meist alle vier. Dann wissen Sie, woran Sie sind, bevor Sie eine Zeile gelesen haben.

2:00 Vier Gründe, und sie werden sich so schnell nicht ändern. Ältere Artikel und Beispiele stehen weiterhin gut auffindbar im Netz — Suchmaschinen belohnen Alter und Verlinkung. Sprachmodelle geben die häufigere Fassung wieder. Der Code wirkt plausibel und scheitert erst beim Ausrollen. Und die teilweise Übernahme mischt beide Welten.

2:20 Das klingt frustrierend, hat aber eine gute Seite: Weil das Muster so gleichförmig ist, ist auch die Gegenmaßnahme immer dieselbe. Der erste Punkt ist die halbe Übernahme, über die wir gerade gesprochen haben. Der zweite beschreibt ein Verhalten, das viel Zeit kostet: Die Fehlermeldung wird gesucht, statt die Herkunft des Codes zu prüfen.

2:40 Fünf Sekunden auf die Importzeile hätten die Antwort gegeben. Und der dritte ist der leise Rest: Eine alte Abhängigkeit bleibt in der Paketdatei stehen. Sie stört nicht sofort — sorgt aber dafür, dass beim nächsten Beispiel wieder beide Pakete verfügbar sind und die Verwirrung von vorn beginnt.

Auf das aktuelle Modell übertragen

2:57 Jetzt die Gegenrichtung: Wie kommt so eine App auf den heutigen Stand, ohne dass es zum Abenteuer wird? Fünf Schritte, und sie sind in jeder Migration dieselben. Das Paket wechselt. Der Einstiegspunkt wandert in den Frontend-Ordner und rendert über den Reconciler. Das Manifest bekommt die Angabe für natives Rendern und verweist auf eine Ressource statt auf eine Funktion. Komponenten werden ersetzt.

3:22 Und Kontextwerte kommen asynchron — der Punkt vom zweiten Tag, der in einer Migration besonders gern zubeißt, weil der alte Code sie synchron gelesen hat. Diese Tabelle ist Ihre Übersetzungshilfe, und ich empfehle, sie beim ersten Umbau offen danebenzulegen. Lesen Sie sie als Muster, nicht als Liste: Links die alte Welt, rechts die heutige. Die letzten beiden Zeilen sind die folgenreichsten.

3:46 Die vorletzte betrifft das Manifest — Ressource plus Resolver statt einer Funktion. Und die letzte ist die, die Sicherheitsfolgen hat: API- Aufrufe aus dem Frontend laufen über die Bridge, und App-Rechte gibt es nur im Resolver. Die Fußzeile nennt den Rest, der ersatzlos wegfällt: die Rahmenkomponenten. Vergleichen Sie diese Zeilen mit dem Beispiel von vorhin. Dasselbe Ziel, dieselbe Anzahl Zeilen — und trotzdem ist jede einzelne anders.

4:13 Import aus dem neuen Paket, Rendern über den Reconciler, React in strikter Betriebsart, keine Rahmenkomponente. Worauf es ankommt: Die Struktur der App ist damit nicht mehr im Code sichtbar, sondern im Manifest. Das ist eine Umstellung im Denken — und der Grund, warum sich die Migration nicht Datei für Datei machen lässt, sondern am Manifest beginnt.

4:35 Der rote Faden ist die Zerlegung. Schritt zwei ist mein Favorit: Manifest umstellen, ausrollen und eine leere Oberfläche prüfen. Wenn die leere Oberfläche erscheint, wissen Sie, dass die halbe Migration schon funktioniert — Modul, Ressource, Rendern. Alles Weitere ist dann Komponentenarbeit. Schritt drei warnt vor dem Alles-auf-einmal, Schritt vier betrifft den Zustand, und Schritt fünf ist die Sicherheitsarbeit: API-Aufrufe trennen.

5:01 Genau dort entscheidet sich, ob die migrierte App auch nach heutigen Maßstäben sauber ist. Der erste Punkt ist der Klassiker der Migration: Der Kontext wird synchron gelesen wie früher und ist undefined. Der zweite ist subtiler — Formulare verhalten sich beim Absenden anders als in der alten Fassung, und das fällt erst auf, wenn jemand zweimal klickt.

5:22 Und der dritte ist der organisatorische Fehler, den man in jedem zweiten Projekt sieht: Alles wird auf einmal umgestellt, und danach ist nicht mehr zuzuordnen, welcher Schritt den Fehler gebracht hat.

Frame und Custom UI gezielt einsetzen

5:33 Kommen wir zu den Fällen, in denen UI Kit tatsächlich an eine Grenze stößt — und zur Frage, wie groß die Ausnahme werden darf. Frame ist die Insel: eine begrenzte Fläche mit eigenem Web-Inhalt innerhalb einer UI-Kit-App. Sie bauen die App also nicht um, sondern schaffen eine Ausnahme an genau der Stelle, an der sie nötig ist.

5:53 Custom UI ersetzt dagegen die ganze Oberfläche durch einen iframe — volle Freiheit, aber auch volle Verantwortung für Aussehen, Zugänglichkeit und Pflege. Die Frage ist selten „was ist besser", sondern „wie klein kann die Ausnahme bleiben". Diese Schichtung sollten Sie als Treppe lesen, die man nur so weit hinuntersteigt wie nötig. Oben UI Kit: geringster Aufwand, weil das Produkt die Gestaltung liefert.

6:19 In der Mitte Frame: eine begrenzte Insel. Unten Custom UI: eigene Oberfläche, volle Verantwortung. Jede Stufe kostet mehr Arbeit, und zwar nicht einmalig, sondern dauerhaft. Die praktische Frage in jedem Projekt lautet deshalb: Welche Stufe reicht — und was genau ist es, das die obere unmöglich macht? Vier Gründe, warum man oben anfängt. Jede Stufe übernimmt Aufgaben, die vorher die Plattform erledigt hat.

6:46 Aussehen, Kontrast und Tastaturbedienung fallen zurück ins Projekt — das Thema vom zweiten Tag, diesmal als Kostenfrage. Der Aufwand fällt bei jeder Änderung erneut an. Und der letzte Punkt ist der praktisch wichtigste: Eine Insel lässt sich zurückbauen, eine Custom-UI-App selten. Entscheidungen, die man leicht zurücknehmen kann, trifft man gern früh — die anderen besser spät.

7:10 Der erste Punkt ist der teuerste: Custom UI wegen einer einzigen Bibliothek. Da lohnt die Gegenfrage, ob die Aufgabe dieser Bibliothek nicht auch anders lösbar wäre. Der zweite beschreibt eine schleichende Entwicklung — die Insel wächst, bis sie die eigentliche Oberfläche ist, und dann hat man Custom UI mit zusätzlicher Komplexität.

7:29 Und der dritte ist eine Erfahrung aus dem Support: Wenn das eigene Aussehen vom Produkt abweicht, halten Nutzende das für einen Fehler und melden ihn.

Vorschau- und Frühzugangsfunktionen einordnen

7:38 Zum Abschluss des Vormittags ein Thema, das in jeder Plattform-Entwicklung auftaucht: Was tun mit Funktionen, die noch nicht fertig sind? Teile der Plattform sind als Vorschau oder Frühzugang gekennzeichnet. Das heißt nicht, dass sie schlecht wären — es heißt, dass sie sich ändern können, anderen Zusagen unterliegen und manchmal eingeschränkt sind.

7:58 Das Modul für Rovo Skills etwa lässt sich im Frühzugang nur in die Entwicklungsumgebung ausrollen. Solche Einschränkungen sind in der Dokumentation vermerkt und werden trotzdem regelmäßig übersehen — meist, weil man die Funktion in einem Blogartikel entdeckt hat und nicht in der Doku. Drei Beispiele aus dem laufenden Monat, und die dritte Spalte ist die interessante. Die Dashboard-Module sind allgemein verfügbar — einsetzbar, mit Zusagen.

8:23 Die Frontend-Protokolle sind hilfreich, aber im Frühzugang, also kein Fundament für einen Betriebsprozess. Und das Skill-Modul darf nur nach development. Die Fußzeile ist der eigentliche Merksatz: Diese Tabelle ist eine Momentaufnahme. Vor jeder Durchführung und vor jedem Release gehört das Änderungsprotokoll erneut geprüft — sonst tragen Sie Aussagen weiter, die längst überholt sind.

8:47 Fünf Schritte, deren erster oft den ganzen Fall klärt: Stand im Änderungsprotokoll nachschlagen, nicht im Blogartikel. Dann die praktische Frage, ob die Funktion in Produktion überhaupt laufen darf. Schritt drei ist die eigentliche Absicherung — einen Weg ohne sie beschreiben, bevor man sie einplant. Schritt vier dokumentiert die Abhängigkeit, und Schritt fünf setzt einen Termin zur erneuten Prüfung.

9:10 Der Termin ist der Unterschied zwischen einer bewussten Entscheidung und einer vergessenen. Der erste Punkt ist der riskanteste: Eine Frühzugangsfunktion trägt eine Kernfunktion der App. Dann hängt Ihr Produkt an etwas, das sich ohne Rücksicht auf Sie ändern darf. Der zweite ist die Momentaufnahme, die zur Wahrheit wird — einmal geprüft, danach gesetzt.

9:31 Und der dritte ist der, der wehtut, weil er spät kommt: Die Einschränkung auf die Entwicklungsumgebung fällt erst beim Release auf, wenn alles fertig ist.

Übung

9:41 In der Übung migrieren Sie eine kleine Alt-App und ordnen zwei neue Anforderungen ein. Die Falkenmoos GmbH hat aus einem früheren Versuch eine kleine App im Bestand, die Prüfprotokolle an einem Vorgang anzeigt — geschrieben in der alten Fassung. Sie soll auf den aktuellen Stand kommen. Dazu stehen zwei neue Anforderungen an: eine Signaturansicht mit fester Darstellung und ein interaktives Messdiagramm.

10:04 Beide sind bewusst so gewählt, dass die Antwort nicht offensichtlich ist — genau wie im echten Projekt. Drei Erfolgskriterien. Die App läuft — das ist das handwerkliche. Jede Änderung ist mit Grund benannt — das ist das, was aus der Migration Wissen macht. Und für beide Anforderungen ist die Wahl begründet. Achten Sie beim Hinweis besonders auf das Diagramm: Prüfen Sie zuerst, ob die mitgelieferten Diagramm-Komponenten ausreichen.

10:31 Es wäre nicht das erste Mal, dass eine Custom-UI-Entscheidung an einer Komponente scheitert, die es längst gibt. Die Reihenfolge ist die aus dem zweiten Kapitel, und sie hat sich bewährt. Erst die vier Merkmale im Beispiel markieren — das schärft den Blick für die nächste fremde Datei. Dann Abhängigkeiten, Struktur und Manifest, und ausrollen. Dann Komponenten einzeln, mit Prüfung nach jedem Schritt. Dann der Kontext.

10:57 Und zum Schluss die beiden Anforderungen einordnen. Wenn Sie zwischendurch nicht weiterkommen: Der leere, aber laufende Zwischenstand nach Schritt zwei ist wertvoller als ein vollständiger, der nicht startet. Drei Punkte zum Mitnehmen. Die Migration in einem Zug lässt sich nicht eingrenzen, wenn etwas schiefgeht. Die Begründung nennt den Aufwand statt den fachlichen Bedarf — und Aufwand ist eine Momentaufnahme, Bedarf nicht.

11:23 Und für das Diagramm wird Custom UI gewählt, ohne UI Kit geprüft zu haben. Nach der Pause geht es um den Betrieb: Umgebungen, Releases und die Frage, wer eigentlich reagiert, wenn etwas ausfällt.