React im Atlassian-Forge-Umfeld

React im Atlassian-Forge-Umfeld

0:00 Und jetzt der Moment, auf den die ganze Schulung hinausläuft. Wir bringen React dorthin, wo es bei Ihnen tatsächlich laufen soll: in Jira und Confluence. Atlassian Forge ist dabei ein interessanter Fall — eine Plattform, die einem sehr viel abnimmt und dafür einen Rahmen setzt. Hosting, Anmeldung, Skalierung, Datenhaltung kommen von Atlassian; Sie liefern den Code.

0:22 Wie das im Alltag aussieht, was es erleichtert und wo die Grenzen liegen, gehen wir heute vollständig durch — von der Plattform bis zur eigenen App im Produkt.

React im Atlassian-Forge-Umfeld

0:32 Sechs Stationen liegen vor uns. Zuerst die Frage, was Forge überhaupt ist und wie es sich einordnet. Dann sehr praktisch: die lokale Umgebung, der Projektaufbau und die zentrale Konfigurationsdatei. Im vierten Block kommt React ins Spiel, über das sogenannte UI Kit. Danach Bereitstellung und Test — der Weg ins echte Produkt. Und zum Schluss bauen wir gemeinsam eine kleine App.

0:55 Wer heute mitmacht, hat am Abend eine funktionierende Anwendung in einem echten Jira. Kurz zu Ihnen, und diesmal sind die Voraussetzungen etwas gemischter als sonst. Wie viel React-Erfahrung bringen Sie mit — die vergangenen Module zählen ausdrücklich mit? Haben Sie schon einmal eine Atlassian-App gebaut, sei es mit Forge oder noch mit dem Vorgänger Connect? Und was möchten Sie heute mitnehmen?

1:19 Die zweite Frage ist wichtig, weil Umsteiger von Connect an manchen Stellen umdenken müssen — Forge funktioniert anders, und einige gewohnte Freiheiten gibt es hier nicht.

Einführung in Atlassian Forge

1:29 Beginnen wir mit der Einordnung. Was ist Forge, was nimmt es einem ab — und was gibt man dafür auf? Diese beiden Seiten gehören zusammen. Forge ist Atlassians Plattform, um Apps für Jira, Confluence und weitere Produkte zu bauen. Das Besondere: Code, Hosting, Anmeldung und Datenspeicher laufen serverlos auf Atlassians eigener Infrastruktur. Sie betreiben also nichts.

1:52 Stellen Sie sich den Unterschied zwischen einem eigenen Ladenlokal und einem Stand in einer Markthalle vor — Sie kümmern sich um Ihr Angebot, Strom, Sicherheit und Öffnungszeiten kommen vom Betreiber. Das ist bequem und es bedeutet zugleich, dass Sie sich an die Hausordnung halten. Genau diese Abwägung sollte man beim Einstieg bewusst treffen.

2:13 Vier Punkte. Der serverlose Betrieb nimmt Ihnen Laufzeit, Skalierung und Sicherheit ab — für kleinere Teams ist das der größte Gewinn, weil genau das sonst viel Zeit kostet. Eine einzige deklarative Konfigurationsdatei beschreibt die ganze App; darauf kommen wir gleich. React ist über UI Kit direkt eingebaut, Sie brauchen kein eigenes Hosting fürs Frontend.

2:34 Und der vierte Punkt ist für Unternehmenskunden oft der entscheidende: Berechtigungen und Compliance sind Teil der Plattform. Wer schon einmal eine Datenschutzprüfung für eine eigene Cloud-Anwendung begleitet hat, weiß, was das wert ist. Diese Datei ist das Herzstück jeder Forge-App, und es lohnt sich, ihre Logik zu verstehen. Oben stehen die Module — sie sagen, wo im Produkt Ihre App überhaupt auftaucht.

2:58 Hier ist es ein Panel an einem Jira-Vorgang. Unten die Ressourcen: Sie verweisen auf den Code, der die Oberfläche liefert. Beide sind über einen Schlüssel verbunden. Worauf es ankommt, steht in der Fußzeile: Diese Datei ist die zentrale Wahrheit über Module, Rechte und Ressourcen. Wenn Ihre App irgendwo nicht erscheint oder etwas nicht darf, schauen Sie zuerst hierhin.

3:22 Eine kurze Denkaufgabe zum Einstieg, ohne Code. Überlegen Sie sich einen konkreten Anwendungsfall — gern einen aus Ihrem eigenen Arbeitsalltag — und suchen Sie in der Modulliste der Forge-Dokumentation den passenden Typ dazu. Ein Panel am Vorgang, ein Makro in Confluence, ein Gadget im Dashboard? Das Lernziel dahinter: Bei Forge beginnt der Entwurf nicht mit dem Code, sondern mit der Frage, an welcher Stelle im Produkt die App eigentlich sitzt.

3:48 Diese Entscheidung prägt danach alles Weitere. Drei wichtige Einordnungen. Erstens: Forge ist nicht Connect. Ältere Atlassian-Apps nutzen die Vorgängerplattform, die anders funktioniert — wenn Sie im Netz auf Anleitungen stoßen, prüfen Sie zuerst, um welche der beiden es geht. Zweitens läuft nicht jede Node-Bibliothek in der Forge-Umgebung; sie ist abgeschottet und eingeschränkt.

4:11 Und drittens ein Punkt, der viele überrascht: Ausgehende Netzwerkaufrufe müssen ausdrücklich in der Konfiguration freigegeben werden. Das ist keine Schikane, sondern genau die Sicherheitszusage, die die Plattform ihren Kunden gibt.

Lokale Entwicklungsumgebung

4:25 Jetzt wird es praktisch. Bevor wir Code schreiben, brauchen wir eine funktionierende Umgebung — und das ist erfahrungsgemäß der Punkt, an dem in Seminaren die meiste Zeit verlorengeht. Sie brauchen drei Dinge: eine aktuelle Node-Version mit Langzeitunterstützung, den Paketmanager npm und das Kommandozeilenwerkzeug von Forge.

4:45 Dieses Werkzeug trägt den gesamten Lebenszyklus — es meldet Sie an, legt Apps an, stellt sie bereit und öffnet einen Tunnel für schnelles Ausprobieren. Diesen Tunnel möchte ich vorweg hervorheben, weil er die Arbeitsweise verändert: Er führt Ihren lokalen Code aus, während die App im echten Produkt läuft. Sie sehen also Änderungen sofort, ohne bei jedem Versuch neu bereitzustellen.

5:07 Vier Punkte zur Einordnung. Node und npm liefern Laufzeit und Paketverwaltung — Standardwerkzeug, das Sie kennen. Das Forge-Kommandozeilenwerkzeug bündelt den gesamten Lebenszyklus an einer Stelle, was den Einstieg spürbar vereinfacht. Der Tunnel gibt Ihnen sofortige Rückmeldung statt einer Wartezeit pro Versuch — und Rückmeldungsgeschwindigkeit ist beim Entwickeln fast alles.

5:30 Und viertens: Ein Zugriffstoken verbindet das Werkzeug sicher mit Ihrem Atlassian-Konto. Das ist zugleich der häufigste Stolperstein, deshalb steht er gleich zweimal auf diesen Folien. Vier Schritte, die Sie gleich selbst gehen: Node installieren, das Werkzeug global installieren, anmelden, Anmeldung prüfen. Der vierte Schritt ist der wichtigste und wird gern übersprungen — er kostet zwei Sekunden und erspart Ihnen die Sorte Fehlersuche, bei der man zehn Minuten später merkt, dass man gar nicht angemeldet war.

6:00 Und die Fußzeile ist ernst zu nehmen: Es braucht eine aktuelle Node-Version mit Langzeitunterstützung. Eine zu alte Version ist die mit Abstand häufigste Ursache für seltsame Fehlermeldungen bei der Installation. Drei Zeilen, mehr ist es nicht. Installieren, anmelden, prüfen. Bei der mittleren Zeile passiert der eine kritische Punkt: Sie werden nach E-Mail-Adresse und Token gefragt — nicht nach Ihrem Passwort.

6:24 Das Token erzeugen Sie vorher in den Einstellungen Ihres Atlassian-Kontos. Worauf es ankommt: Diese Unterscheidung kostet erfahrungsgemäß die meiste Zeit im Seminar, weil die Fehlermeldung nicht besonders deutlich ist. Wenn die Anmeldung also scheitert, ist die erste Frage nicht „was ist kaputt", sondern „habe ich wirklich ein Token benutzt".

6:44 Richten Sie Ihre Umgebung jetzt ein. Das Erfolgskriterium ist präzise und leicht prüfbar: Der Prüfbefehl zeigt Ihr Atlassian-Konto ohne Fehlermeldung. Nehmen Sie sich die Zeit — alles Weitere heute setzt darauf auf, und es ist ausgesprochen frustrierend, mitten in einer interessanten Übung an einer Anmeldung hängenzubleiben.

7:03 Wenn Sie fertig sind, helfen Sie gern den Nachbarn. Erfahrungsgemäß gibt es zwei oder drei Rechner, bei denen die Node-Version im Weg steht, und zu zweit ist das in fünf Minuten geklärt. Genau die drei Klassiker, die Sie eben vielleicht schon erlebt haben. Eine veraltete Node-Version — prüfen Sie das zuerst, wenn irgendetwas seltsam ist.

7:23 Passwort statt Token bei der Anmeldung, der Punkt von eben. Und drittens ein Berechtigungsproblem bei der globalen Installation: Auf manchen Systemen darf man nicht ohne Weiteres global installieren, und dann bricht die Installation mit einer kryptischen Meldung ab. Die saubere Lösung ist keine erhöhte Berechtigung, sondern eine Node-Versionsverwaltung — die haben viele ohnehin, und sie löst das Problem an der Wurzel.

Projektaufbau

7:47 Die Umgebung steht. Jetzt legen wir ein Projekt an — und schauen uns an, wie eine Forge-App eigentlich aufgebaut ist. Ein Projekt entsteht aus einer Vorlage. Was Sie danach vor sich haben, hat drei Teile: die Konfigurationsdatei, den Frontend-Code und — optional — den Backend-Code, die sogenannten Resolver. Diese Dreiteilung sollten Sie sich merken, denn sie strukturiert das ganze Modul.

8:12 Vorne die Oberfläche, hinten die Logik, dazwischen die Konfiguration, die beides verbindet und dem Produkt erklärt, was die App darf. Wenn Sie später einen Fehler suchen, hilft es sehr, zuerst zu klären, in welchem dieser drei Bereiche er steckt. Vier Punkte. Die Vorlage liefert eine sofort lauffähige App als Startpunkt — Sie beginnen also nicht mit einem leeren Ordner, sondern mit etwas Funktionierendem, das Sie umbauen.

8:37 Die Konfigurationsdatei ist die zentrale Wahrheit über Module und Rechte. Die Trennung von Frontend und Backend ist klar gezogen und schwer zu verwischen, was hier ausnahmsweise angenehm ist. Und die Vorlagen decken die gängigen Produkte und Modultypen ab — Sie finden also fast immer einen passenden Ausgangspunkt statt bei null anzufangen.

8:57 Fünf Schritte: Projekt erzeugen und Vorlage wählen, ins Verzeichnis wechseln, Abhängigkeiten holen, Konfiguration anpassen, erstmalig bereitstellen. Der vierte Schritt ist der einzige, der Nachdenken erfordert — dort tragen Sie ein, was Ihre App tun soll und darf. Und die Fußzeile erklärt einen Nebenaspekt, der oft für Verwirrung sorgt: Eine App bekommt eine eindeutige Kennung, und die verwaltet das Werkzeug für Sie.

9:21 Die soll man nicht anfassen; sie ist der Anker, über den Atlassian Ihre App wiedererkennt. Hier sehen Sie die Dreiteilung als Ordnerbild. Oben die Konfiguration und die Abhängigkeiten, darunter Frontend und Backend sauber getrennt. Vergleichen Sie das einmal mit dem, was wir im Modul über Projektstruktur besprochen haben — Forge gibt Ihnen hier eine typbasierte Struktur vor.

9:44 Bei einer kleinen App ist das genau richtig; bei einer größeren dürfen Sie innerhalb dieser Ordner durchaus nach Features gliedern. Worauf es ankommt, steht in der Fußzeile: Der Pfad in der Konfiguration muss auf die tatsächliche Frontend-Datei zeigen. Sonst bleibt das Panel leer. Legen Sie ein Projekt an und verschaffen Sie sich einen Überblick.

10:04 Das Erfolgskriterium ist bewusst nicht „es läuft", sondern „Sie können es erklären": Zeigen Sie auf die Konfiguration, auf das Frontend, auf den Resolver und sagen Sie, wofür jedes zuständig ist. Öffnen Sie dabei die Konfigurationsdatei und suchen Sie den Schlüssel, der Modul und Ressource verbindet. Wenn Sie diesen Zusammenhang einmal selbst nachvollzogen haben, ist die Datei danach kein Rätsel mehr, sondern ein Inhaltsverzeichnis.

10:28 Drei Punkte, alle rund um die Konfigurationsdatei. Erstens: Es ist YAML, und YAML ist empfindlich — mit Leerzeichen einrücken, keine Tabulatoren. Das ist eine Fehlerquelle, die man einmal hat und danach nie wieder. Zweitens: Zeigt der Ressourcenpfad ins Leere, lädt das Frontend nicht, und zwar ohne dramatische Fehlermeldung — Sie sehen einfach ein leeres Panel.

10:51 Und drittens der Punkt von eben: Die App-Kennung nicht von Hand ändern. Sie wird verwaltet, und ein handgeschriebener Wert bricht die Verbindung zu Ihrer registrierten App.

React-Komponenten in Forge

11:02 Und jetzt kommt endlich React ins Spiel. Alles, was Sie in den vergangenen Modulen gelernt haben, lässt sich hier anwenden — mit einer bemerkenswerten Einschränkung, die zugleich die interessanteste Eigenheit von Forge ist. UI Kit ist Forges React-basiertes Framework. Sie schreiben echte React-Komponenten mit Hooks — Zustand, Props, alles wie gewohnt.

11:22 Der Unterschied: Statt HTML-Elementen verwenden Sie fertige Bausteine aus dem Forge-Paket. Es gibt kein `div` und kein `button`, sondern Komponenten mit denselben Namen wie im Atlassian-Design. Denken Sie an einen Baukasten mit vorgefertigten Teilen statt an Rohmaterial. Das begrenzt Sie und garantiert zugleich, dass Ihre App aussieht wie ein Teil des Produkts — und nicht wie ein Fremdkörper darin.

11:47 Vier Punkte. Sie arbeiten mit vertrauten React-Mustern — Komponenten, Props, Zustand; nichts davon müssen Sie neu lernen. Die Bausteine passen automatisch ins Atlassian-Design, was Ihnen die gesamte Gestaltungsarbeit abnimmt. Ein eigener Hook liefert Ihnen den Produktkontext, also etwa den Vorgang, an dem Ihre App gerade hängt — die Verbindung zur Umgebung.

12:09 Und der vierte Punkt ist die Notausgangstür, die man kennen sollte: Wenn UI Kit nicht reicht, gibt es Custom UI mit eigenem React in einem eingebetteten Rahmen. Volle Freiheit, dafür deutlich mehr Eigenarbeit. Schauen Sie sich das an — bis auf zwei Details ist das ganz normales React. Ein Zustand, eine Funktion zum Erhöhen, ein anklickbares Element.

12:30 Der erste Unterschied steht in der Importzeile: Sowohl die Bausteine als auch die Hooks kommen aus dem Forge-Paket. Der zweite steht ganz unten — statt in ein HTML-Element zu rendern, übergeben Sie Ihre App an den Forge-Renderer, der sie in die Produktoberfläche einsetzt. Das ist die Entsprechung zum Wurzelknoten aus dem Grundlagenmodul, nur dass die Wurzel hier bei Atlassian liegt.

12:53 Bauen Sie eine kleine interaktive Komponente mit eigenem Zustand und einer Reaktion auf einen Klick — dieselbe Übung wie ganz am Anfang der Schulung, nur jetzt im echten Produkt. Erfolgskriterium: Ein Klick im Panel verändert sichtbar den angezeigten Wert. Nehmen Sie sich außerdem fünf Minuten, um die verfügbaren Bausteine in der Dokumentation zu überfliegen.

13:14 Es ist gut zu wissen, was der Baukasten hergibt, bevor man anfängt, etwas nachzubauen, das es schon gibt. Drei Punkte, die im Alltag zählen. Erstens, der wichtigste: HTML-Elemente gibt es hier nicht. Wer aus gewohnter React-Arbeit kommt, tippt reflexhaft ein `div` und wundert sich. Zweitens: Nach Frontend-Änderungen müssen Sie neu bereitstellen oder den Tunnel nutzen — sonst sehen Sie im Produkt weiterhin den alten Stand und suchen den Fehler im Code, der längst richtig ist.

13:43 Und drittens: UI Kit und Custom UI gehören nicht in dasselbe Modul. Das sind zwei Ansätze; man entscheidet sich pro Modul für einen. Kurz zu den Werkzeugen, und ich mache es bewusst knapp, weil die Fußzeile die eigentliche Antwort ist: Nehmen Sie die Umgebung, die Sie kennen. Forge schreibt keine vor. Visual Studio Code funktioniert gut, mit Erweiterungen für YAML sowie den üblichen Prüf- und Formatierwerkzeugen.

14:08 IntelliJ bringt starke JavaScript-Unterstützung und ein integriertes Terminal mit, was praktisch ist, weil die Forge-Befehle ohnehin dort laufen. Wirklich empfehlen möchte ich nur eines: eine YAML-Prüfung für die Konfigurationsdatei. Die erspart Ihnen den Einrückungsfehler, über den wir eben gesprochen haben.

Deployment und Testing

14:26 Jetzt der Weg ins Produkt. Drei Befehle bestimmen Ihren Alltag mit Forge — und ihre Reihenfolge ist wichtiger, als sie zunächst wirkt. Drei Schritte, drei Bedeutungen. Bereitstellen baut die App und lädt sie in eine Umgebung — Entwicklung, Test oder Produktion. Installieren verknüpft sie mit einem konkreten Atlassian-Standort, also mit dem Jira oder Confluence, in dem sie auftauchen soll.

14:50 Und der Tunnel führt Ihren lokalen Code aus, während die App im Produkt läuft. Man kann sich das so vorstellen: Bereitstellen ist das Einlagern ins Regal, Installieren das Aufstellen im Schaufenster, und der Tunnel ist die Möglichkeit, hinter dem Schaufenster live umzudekorieren. Vier Punkte. Drei getrennte Umgebungen trennen Experiment, Test und Produktion — das ist Standard und ersparte schon vielen einen sehr unangenehmen Nachmittag.

15:15 Der Tunnel spiegelt Änderungen sofort und erspart Ihnen das Bereitstellen bei jedem Versuch, was den Unterschied zwischen zähem und flüssigem Arbeiten ausmacht. Eine statische Prüfung findet Fehler in Konfiguration und Code, bevor Sie bereitstellen. Und die Protokollausgabe zeigt Ihnen Laufzeitfehler der Backend-Funktionen — die laufen bei Atlassian, Sie haben also sonst keinen Einblick.

15:38 Fünf Schritte in genau dieser Reihenfolge: prüfen, bereitstellen, installieren, im Tunnel testen, bei Fehlern die Protokolle lesen. Die Fußzeile nennt den Punkt, der am häufigsten schiefgeht: erst bereitstellen, dann installieren. Installieren allein reicht nicht, denn es verknüpft nur — es lädt keinen Code hoch. Wer diese Reihenfolge dreht, installiert einen alten Stand und sucht anschließend an einer Stelle, die längst korrigiert ist.

16:03 Merken Sie sich diese eine Sache, sie spart Ihnen mit Sicherheit einmal eine halbe Stunde. Vier Zeilen, die Ihren Arbeitsalltag mit Forge ausmachen. Prüfen, bereitstellen mit ausdrücklicher Angabe der Umgebung, installieren mit Angabe des Standorts, und dann der Tunnel für die eigentliche Arbeit. Worauf es ankommt: Der Umgebungsschalter hat einen Standardwert, nämlich die Entwicklungsumgebung — trotzdem empfehle ich, ihn hinzuschreiben.

16:28 Es ist eine dieser kleinen Gewohnheiten, die dafür sorgen, dass man nicht eines Tages versehentlich in die Produktion liefert, weil man in der falschen Konsole stand. Bringen Sie Ihre App jetzt ins Produkt: bereitstellen, installieren, im Tunnel testen. Erfolgskriterium ist doppelt — die App erscheint im Produkt, und sie reagiert auf Ihre Änderungen im laufenden Tunnel.

16:49 Nehmen Sie sich einen Moment für diesen zweiten Teil: Ändern Sie eine Beschriftung, laden Sie die Seite neu und sehen Sie die Änderung. Das ist der Moment, in dem Forge sich zum ersten Mal angenehm anfühlt — und der Punkt, ab dem Sie tatsächlich flüssig entwickeln können. Der erste Punkt ist die Reihenfolge, die wir eben besprochen haben.

17:09 Der zweite ist subtiler und erwischt fast jeden einmal: Wenn Sie in der Konfiguration neue Rechte eintragen, genügt das Bereitstellen nicht — die App muss erneut installiert werden, weil ein Administrator die zusätzlichen Rechte bestätigen muss. Sonst scheitert der Zugriff, obwohl in der Konfiguration alles richtig steht. Und drittens: Der Tunnel braucht eine parallel installierte App.

17:31 Er ersetzt die Installation nicht, er hängt sich in sie hinein. Bevor wir selbst bauen, ein Blick auf das, was üblicherweise entsteht. Ein Panel am Jira-Vorgang, das Zusatzinformationen direkt dort anzeigt, wo gearbeitet wird. Ein Makro, das eigene Inhalte in eine Confluence-Seite einbettet. Ein Dashboard-Element, das Kennzahlen aus einem anderen System holt.

17:53 Und Automatisierungen, die auf Ereignisse im Produkt reagieren. Was diese vier verbindet, steht in der Fußzeile: Jeder Modultyp in der Konfiguration steht für einen solchen Anwendungsfall. Die Modulliste ist also gewissermaßen ein Katalog dessen, was möglich ist — ein guter Ort für Ideen.

Gemeinsames Forge-Projekt

18:12 Und damit zum Abschluss der ganzen Schulung: Wir bauen gemeinsam eine App, die alles zusammenbringt, was wir in den letzten Modulen besprochen haben. Wir bauen ein Panel am Jira-Vorgang, das eine kurze Notiz speichert. Klingt bescheiden, ist aber genau richtig gewählt: Es berührt alle drei Schichten. Vorn eine React-Oberfläche mit UI Kit, hinten ein Resolver als Backend-Logik, und dazwischen der Forge-Speicher für dauerhafte Daten.

18:36 Damit haben Sie in einer kleinen, überschaubaren App den vollständigen Kreislauf einmal selbst gebaut — und das ist eine deutlich bessere Grundlage für eigene Projekte als eine große Anwendung, bei der man die Hälfte nur abgetippt hat. Vier Punkte. Sie gehen den ganzen Ablauf am Stück durch — anlegen, programmieren, bereitstellen, installieren, testen.

18:57 Frontend und Backend spielen zum ersten Mal zusammen, und diese Verbindung ist der eigentlich neue Teil. Der Speicher zeigt, wie Daten die Sitzung überdauern, was den Unterschied zwischen einer Demo und einer Anwendung ausmacht. Und viertens, ganz pragmatisch: Am Ende steht ein vorzeigbares Ergebnis in einem echten Jira.

19:16 Das ist mehr wert, als es klingt — es ist die Vorlage, an der Sie sich beim ersten eigenen Projekt entlanghangeln. Fünf Schritte: Projekt aus der Panel-Vorlage anlegen, das Frontend anpassen, den Resolver für Lesen und Schreiben ergänzen, bereitstellen und installieren, im Vorgang testen. Wir gehen das gemeinsam durch, und zwar in kleinen Schritten — lieber fünfmal kurz prüfen als am Ende einen großen Fehler suchen.

19:41 Genau dafür ist der Tunnel da, wie die Fußzeile sagt. Wenn Sie an einer Stelle nicht mitkommen, sagen Sie es sofort; die Schritte bauen aufeinander auf, und hinterherzuholen ist mühsamer als kurz zu warten. Das ist der Backend-Teil, und er ist erfreulich kompakt. Ein Resolver ist im Kern eine Sammlung benannter Funktionen, die das Frontend aufrufen darf.

20:02 Hier sind es zwei: eine zum Speichern, eine zum Laden. Der Speicher selbst verhält sich wie ein einfacher Schlüssel-Wert-Speicher. Ganz unten werden die Definitionen nach außen gegeben, damit die Plattform sie kennt. Worauf es ankommt, steht in der Fußzeile: Das Frontend ruft diese Funktionen über eine eigene Brücke auf — und zwar über genau den Namen, der hier steht.

20:24 Jetzt bauen Sie es selbst zu Ende. Das Erfolgskriterium ist schön eindeutig: Ihr Panel speichert eine Eingabe und zeigt sie nach dem Neuladen wieder an. Genau dieses Neuladen ist der Test — vorher wissen Sie nicht, ob die Daten wirklich gespeichert sind oder nur im Zustand hängen. Wer schneller ist, ergänzt eine zweite Aktion zum Löschen oder holt sich zusätzlich Daten aus der Produkt-Schnittstelle.

20:46 Damit hätten Sie dann auch die Freigabe für ausgehende Aufrufe einmal in der Konfiguration gesetzt. Drei Punkte, die Ihnen bei dieser Übung begegnen werden. Erstens: Das Speichern ist asynchron. Wenn Sie das Versprechen nicht zurückgeben oder darauf warten, meldet die Funktion Erfolg, bevor irgendetwas gespeichert ist — und die Daten sind nach dem Neuladen weg.

21:08 Zweitens: Das Speicherrecht muss in der Konfiguration stehen und danach neu installiert werden; das ist genau der Fall aus dem vorigen Kapitel. Und drittens ein Klassiker: Der Name im Frontend muss zeichengenau dem im Resolver entsprechen. Ein Tippfehler äußert sich als Aufruf, der ins Leere geht. Schauen wir zurück. Forge hostet, sichert und skaliert Ihre App — Sie liefern den Code, und das ist für kleinere Teams ein erheblicher Gewinn.

21:35 Das Kommandozeilenwerkzeug, die Konfigurationsdatei und die Vorlagen tragen den gesamten Lebenszyklus; wenn Sie diese drei beherrschen, beherrschen Sie die Plattform. UI Kit bringt React ins Produkt, Resolver und Speicher liefern die Logik dahinter. Der nächste Schritt liegt bei Ihnen: eine eigene Idee als Forge-Modul umsetzen.

21:54 Und Sie haben ab heute alle Teile dafür beisammen.

Danke!

21:58 Damit sind wir am Ende — nicht nur dieses Moduls, sondern der ganzen Schulung. Wir sind von den JavaScript-Grundlagen über TypeScript und React bis in eine laufende App im echten Produkt gekommen, und das ist eine ordentliche Strecke. Alle Materialien liegen in der Freigabe, und ich möchte Ihnen wirklich ans Herz legen, die Übungen in den nächsten Tagen noch einmal nachzubauen — solange es frisch ist.

22:20 Bei Fragen erreichen Sie uns jederzeit unter der angegebenen Adresse. Vielen Dank für Ihre Aufmerksamkeit, Ihre Fragen und das Mitmachen.