D DOKUBASIS

Ext JS mit KI weiterentwickeln, ohne die vertraute MVVM-Struktur aufzugeben

Sencha Architect war für viele Ext-JS-Projekte lange der zentrale Ort, an dem Oberflächen, Controller und ViewModels entstanden sind. Das Werkzeug gibt eine klare Struktur vor und nimmt einem einen Teil der manuellen Arbeit ab. Gleichzeitig wird es zum Engpass, sobald Änderungen schneller, gezielter oder mit Unterstützung durch KI umgesetzt werden sollen.

Genau an diesem Punkt setzt der ExtJS Code Navigator an. Mein Ziel war nicht, die vorhandene Anwendung in ein neues Framework zu migrieren oder eine zweite Projektstruktur einzuführen. Die vom Architect erzeugte MVVM-Struktur sollte erhalten bleiben. View, Controller, ViewController, Model, ViewModel und Store sollten weiterhin dort liegen, wo erfahrene Ext-JS-Entwickler sie erwarten.

Der Unterschied liegt im Arbeitsablauf: Statt Änderungen zuerst im Architect zu modellieren und daraus JavaScript-Dateien generieren zu lassen, wird direkt mit den bestehenden Quelldateien gearbeitet. Dadurch kann auch ein KI-Assistent das Projekt wesentlich schneller analysieren und weiterentwickeln, ohne dass die vertraute Struktur verloren geht.

Was das Projekt technisch ist

Der ExtJS Code Navigator ist eine kleine, browserbasierte Anwendung zum Navigieren, Durchsuchen und Bearbeiten eines bestehenden Ext-JS-app-Verzeichnisses. Er ist bewusst kein neuer Ext-JS-Compiler und kein Ersatz für den Sencha-Compiler.

Technisch besteht die Anwendung aus statischem HTML, CSS und JavaScript. Ein JavaScript-Build-Schritt ist nicht erforderlich. Für die Bereitstellung liegt ein Dockerfile auf Basis von Nginx bei.

Im Browser wird über die File System Access API ein lokales Verzeichnis mit Lese- und Schreibrechten geöffnet. Erwartet wird typischerweise das Verzeichnis resources/static/app. Danach liest die Anwendung die vorhandene Struktur rekursiv ein und stellt die JavaScript-Dateien als navigierbaren Projektbaum dar.

Unterstützt werden insbesondere die bekannten Bereiche:

  • controller
  • model
  • store
  • view

Weitere Verzeichnisse und JavaScript-Dateien werden ebenfalls angezeigt. Die Anwendung legt dabei keine neue Projektstruktur an, verschiebt keine Dateien und erzeugt keine Kopien. Beim Speichern wird direkt die zuvor ausgewählte Originaldatei aktualisiert.

Das ist für den gewählten Ansatz entscheidend: Die bestehende Datei- und Ordnerstruktur bleibt die Source of Truth.

MVVM bleibt erhalten

Eine Ext-JS-View besteht in der Praxis selten nur aus einer einzelnen Datei. Zu einer View gehören häufig ein Controller und ein ViewModel, bei älteren oder gemischten Projekten zusätzlich ein Model oder ein ViewController.

Der Navigator erkennt typische Namenskonventionen wie:

Customer.js
CustomerController.js
CustomerModel.js
CustomerViewController.js
CustomerViewModel.js

Auch eine vom Architect erzeugte Struktur mit eigenen Unterordnern wird berücksichtigt:

Customer.js
CustomerController/CustomerController.js
CustomerViewModel/CustomerViewModel.js

Diese Dateien werden in der Oberfläche zu einer gemeinsamen View-Gruppe zusammengefasst. Wichtig ist, dass diese Gruppierung nur virtuell stattfindet. Auf der Festplatte wird nichts umbenannt oder verschoben.

Damit bleibt das mentale Modell des bestehenden Projekts erhalten. Wer das Projekt bereits kennt, findet sich weiterhin über View, Controller und ViewModel zurecht. Gleichzeitig bekommt ein KI-Assistent einen klaren Kontext darüber, welche Dateien gemeinsam betrachtet werden sollten.

Neben der Dateistruktur wertet der Navigator bestehende Ext.define-Blöcke aus. Er erkennt die Basisklasse aus extend und listet Konfigurationsbereiche auf der obersten Ebene auf.

Bei einer View wie dieser:

Ext.define("MyApp.view.customer.Customer", {
    extend: "Ext.panel.Panel",
    xtype: "customer",

    controller: "customer",

    viewModel: {
        type: "customer"
    },

    items: [],

    listeners: {
        afterrender: "onAfterRender"
    }
});

werden beispielsweise xtype, controller, viewModel, items und listeners als Abschnitte angeboten. Ein Klick auf einen Abschnitt springt direkt zur entsprechenden Stelle in der Datei.

Zusätzlich bietet die Anwendung:

  • eine projektweite Textsuche über die eingelesenen JavaScript-Dateien
  • Syntaxhervorhebung für den Lesemodus
  • einen integrierten Quelltexteditor
  • Speichern mit Schaltfläche oder Ctrl+S beziehungsweise Cmd+S
  • Warnungen vor dem Verwerfen ungespeicherter Änderungen
  • Neuladen der Projektstruktur nach externen Änderungen
  • Kopieren des relativen Dateipfads für Prompts oder andere Werkzeuge

Der Navigator macht aus einer großen Ext-JS-Codebasis damit kein neues Projekt. Er macht die vorhandene Codebasis lediglich schneller zugänglich.

Wo die KI ins Spiel kommt

Die Anwendung selbst enthält aktuell kein Sprachmodell und keine direkte Verbindung zu einer KI-API. Das ist eine bewusste Trennung. Der Navigator stellt die Struktur dar und ermöglicht die kontrollierte Bearbeitung der Dateien. Die eigentliche KI-Unterstützung kann durch einen externen Coding-Assistenten erfolgen.

Ein typischer Arbeitsablauf sieht dann so aus:

  1. Das bestehende app-Verzeichnis wird im Navigator geöffnet.
  2. Die betreffende View und ihre Begleitdateien werden als gemeinsame Einheit identifiziert.
  3. Die relevanten Dateien oder Pfade werden einem KI-Assistenten als Kontext gegeben.
  4. Die KI erweitert beispielsweise Bindings, Formulas, Stores, Events oder Controller-Logik.
  5. Die Änderungen werden direkt in den bestehenden MVVM-Dateien geprüft und gespeichert.
  6. Die Anwendung wird mit den vorhandenen Sencha-Werkzeugen gebaut und getestet.

Der Geschwindigkeitsgewinn entsteht vor allem dadurch, dass kein neues Datenmodell für die Oberfläche gepflegt und anschließend wieder in JavaScript übersetzt werden muss. KI kann direkt auf dem Code arbeiten, den der Sencha-Compiler ohnehin verarbeitet.

Die klare Dateigruppierung hilft außerdem, typische isolierte Änderungen zu vermeiden. Eine neue Interaktion betrifft oft nicht nur die View, sondern ebenfalls den Controller und das ViewModel. Werden diese Dateien gemeinsam betrachtet, kann die Änderung konsistenter umgesetzt werden.

Was passiert mit Sencha Architect?

Der ExtJS Code Navigator macht ein Architect-Projekt technisch nicht unbrauchbar. Er entfernt keine Architect-Dateien und verändert auch nicht dessen Projektkonfiguration. Sencha Architect kann weiterhin gestartet werden.

Es gibt jedoch keinen verlustfreien Roundtrip.

Architect verwaltet ein eigenes Projekt- und Designer-Modell. Der Navigator bearbeitet dagegen direkt die daraus erzeugten JavaScript-Dateien. Änderungen an diesen Dateien werden nicht zurück in das interne Modell des Architects übertragen. Wenn Architect später dieselben Dateien erneut generiert, können die manuell oder mit KI vorgenommenen Änderungen überschrieben werden.

Deshalb muss beim Wechsel des Workflows eine klare Entscheidung getroffen werden:

Sobald die JavaScript-Dateien direkt weiterentwickelt werden, sollten sie die neue Source of Truth sein.

Architect kann danach weiterhin zur Orientierung oder für nicht betroffene Bereiche dienen. Für die erneute Generierung derselben Dateien sollte er jedoch nicht mehr eingesetzt werden, solange es keinen kontrollierten Weg zur Rücksynchronisation gibt. Versionskontrolle ist dabei unverzichtbar, ersetzt aber nicht die Entscheidung, welches System den maßgeblichen Stand verwaltet.

Diese Grenze ist kein spezielles Problem des Navigators. Sie entsteht grundsätzlich immer dann, wenn generierter Code außerhalb des ursprünglichen Generators weiterentwickelt wird.

Bewusst leichtgewichtige Analyse

Der Name des Repositorys legt einen vollständigen Parser nahe. Die aktuelle Implementierung arbeitet jedoch bewusst einfacher: Sie sucht nach Ext.define, liest extend aus und erkennt Konfigurationsabschnitte anhand ihrer Position und Klammertiefe.

Das reicht für viele klassisch aufgebaute Ext-JS-Dateien aus, ist aber kein vollständiger JavaScript-AST-Parser. Abhängigkeiten, Bindings oder Referenzen werden nicht semantisch aufgelöst. Auch die Zuordnung von View, Controller und ViewModel basiert auf den Dateinamen und nicht auf einer Analyse der Ext-JS-Konfiguration.

Der Navigator ersetzt daher weder eine IDE noch statische Codeanalyse. Seine Stärke ist die schnelle Orientierung in einer vorhandenen, regelmäßig aufgebauten Codebasis.

Technische Voraussetzungen

Für den direkten Zugriff auf lokale Dateien wird die File System Access API verwendet. In der Praxis bedeutet das:

  • Chrome oder Edge beziehungsweise ein anderer kompatibler Chromium-Browser
  • Ausführung über localhost oder HTTPS
  • Freigabe des gewählten Projektordners mit Schreibrechten
  • Internetzugriff für die aktuell extern geladenen Editor- und Syntax-Highlighting-Bibliotheken

Die Anwendung kann über das vorhandene Dockerfile gestartet werden:

docker build -t extjs-code-navigator .
docker run --rm -p 8000:80 extjs-code-navigator

Danach ist sie unter http://localhost:8000 erreichbar. Alternativ reicht grundsätzlich jeder statische Webserver, sofern die Browseranforderungen erfüllt sind.

Aktuelle Grenzen

Der derzeitige Stand konzentriert sich auf Navigation und direkte Bearbeitung. Einige Schutzmechanismen, die für einen größeren produktiven Einsatz sinnvoll wären, sind noch nicht enthalten:

  • keine Syntax- oder Ext-JS-Validierung vor dem Speichern
  • keine automatische Formatierung
  • keine Diffansicht oder Git-Integration
  • keine automatische Sicherung geänderter Dateien
  • keine semantische Auflösung von controller, viewModel, bind oder reference
  • keine Synchronisation mit Architect-Projektdateien
  • keine integrierte KI-Schnittstelle
  • keine Unterstützung für das Erstellen, Verschieben oder Löschen von Dateien

Das Werkzeug sollte deshalb zusammen mit Git und dem bestehenden Build- und Testprozess verwendet werden. Gerade KI-generierte Änderungen müssen wie jede andere Codeänderung geprüft werden.

Fazit

Der ExtJS Code Navigator verfolgt keinen radikalen Migrationsansatz. Er nutzt bewusst das, was in bestehenden Ext-JS-Projekten bereits funktioniert: die bekannte MVVM-Struktur, die vorhandenen Klassen und den etablierten Sencha-Build.

Neu ist der Weg, wie darin gearbeitet wird. Statt die Entwicklung an den Generator des Sencha Architects zu binden, werden die erzeugten JavaScript-Dateien zur direkt bearbeitbaren Codebasis. Dadurch können moderne Entwicklungswerkzeuge und KI-Assistenten eingesetzt werden, ohne View, Controller und ViewModel in eine neue Struktur überführen zu müssen.

Der Preis dafür ist eine klare Trennung vom bisherigen Generierungsworkflow. Architect bleibt technisch verfügbar, darf aber nicht mehr unkontrolliert dieselben Dateien neu erzeugen. Wenn diese Grenze akzeptiert und die JavaScript-Codebasis zur Source of Truth erklärt wird, lässt sich ein bestehendes Ext-JS-Projekt deutlich schneller weiterentwickeln, ohne seine vertraute Architektur aufzugeben.