Sviluppare Ext JS con l'IA senza rinunciare alla familiare struttura MVVM

Per molti progetti Ext JS, Sencha Architect è stato a lungo il punto centrale in cui venivano create interfacce, controller e ViewModel. Lo strumento impone una struttura chiara e riduce parte del lavoro manuale. Allo stesso tempo, diventa un collo di bottiglia quando le modifiche devono essere implementate in modo più rapido, mirato o con il supporto dell’IA.

È proprio qui che entra in gioco ExtJS Code Navigator. Il mio obiettivo non era migrare l’applicazione esistente a un nuovo framework né introdurre una seconda struttura di progetto. La struttura MVVM generata da Architect doveva rimanere invariata. View, Controller, ViewController, Model, ViewModel e Store dovevano continuare a trovarsi dove gli sviluppatori Ext JS esperti si aspettano di trovarli.

La differenza sta nel flusso di lavoro: invece di modellare prima le modifiche in Architect e lasciare che generi i file JavaScript, si lavora direttamente con i file sorgente esistenti. In questo modo, anche un assistente IA può analizzare e sviluppare il progetto molto più rapidamente, senza perdere la struttura familiare.

Che cos’è tecnicamente il progetto

ExtJS Code Navigator è una piccola applicazione basata sul browser per navigare, cercare e modificare una directory app Ext JS esistente. Non è volutamente un nuovo compilatore Ext JS né un sostituto del compilatore Sencha.

Dal punto di vista tecnico, l’applicazione è composta da HTML, CSS e JavaScript statici. Non è necessaria una fase di build JavaScript. Per la distribuzione è incluso un Dockerfile basato su Nginx.

Nel browser, tramite la File System Access API viene aperta una directory locale con permessi di lettura e scrittura. In genere è prevista la directory resources/static/app. L’applicazione legge quindi ricorsivamente la struttura esistente e presenta i file JavaScript come un albero di progetto navigabile.

In particolare, sono supportate le aree note:

• controller
• model
• store
• view

Vengono visualizzati anche altre directory e altri file JavaScript. L’applicazione non crea una nuova struttura di progetto, non sposta file e non genera copie. Al momento del salvataggio, viene aggiornato direttamente il file originale selezionato in precedenza.

Questo è fondamentale per l’approccio scelto: la struttura esistente di file e cartelle rimane la source of truth.

MVVM rimane invariato

Nella pratica, una View Ext JS raramente è composta da un solo file. Spesso una View comprende un Controller e un ViewModel e, nei progetti più vecchi o misti, anche un Model o un ViewController.

Il Navigator riconosce convenzioni di denominazione tipiche come:

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

Viene considerata anche una struttura generata da Architect con sottodirectory proprie:

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

Nell’interfaccia, questi file vengono raggruppati in un’unica View. È importante sottolineare che questo raggruppamento avviene soltanto virtualmente. Sul disco non viene rinominato o spostato nulla.

In questo modo si conserva il modello mentale del progetto esistente. Chi conosce già il progetto continua a orientarsi tramite View, Controller e ViewModel. Allo stesso tempo, un assistente IA riceve un contesto chiaro sui file che dovrebbero essere esaminati insieme.

Navigazione all’interno di una classe Ext JS

Oltre alla struttura dei file, il Navigator analizza i blocchi Ext.define esistenti. Riconosce la classe base indicata in extend ed elenca le sezioni di configurazione al livello superiore.

Per una View come questa:

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

    controller: "customer",

    viewModel: {
        type: "customer"
    },

    items: [],

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

vengono proposti, ad esempio, xtype, controller, viewModel, items e listeners come sezioni. Facendo clic su una sezione si passa direttamente al punto corrispondente nel file.

Inoltre, l’applicazione offre:

• una ricerca testuale sull’intero progetto nei file JavaScript caricati
• l’evidenziazione della sintassi in modalità di lettura
• un editor di codice sorgente integrato
• il salvataggio tramite pulsante oppure Ctrl+S o Cmd+S
• avvisi prima di scartare modifiche non salvate
• il ricaricamento della struttura del progetto dopo modifiche esterne
• la copia del percorso relativo del file per prompt o altri strumenti

Il Navigator, quindi, non trasforma una grande codebase Ext JS in un nuovo progetto. Rende semplicemente più rapido l’accesso alla codebase esistente.

Dove entra in gioco l’IA

Attualmente l’applicazione non contiene un modello linguistico né una connessione diretta a un’API di IA. È una separazione intenzionale. Il Navigator rappresenta la struttura e consente la modifica controllata dei file. Il supporto IA vero e proprio può essere fornito da un assistente di coding esterno.

Un flusso di lavoro tipico è il seguente:

1. La directory app esistente viene aperta nel Navigator.
2. La View interessata e i relativi file di supporto vengono identificati come un’unica unità.
3. I file o i percorsi rilevanti vengono forniti come contesto a un assistente IA.
4. L’IA estende, ad esempio, binding, formula, Store, eventi o logica del Controller.
5. Le modifiche vengono verificate e salvate direttamente nei file MVVM esistenti.
6. L’applicazione viene compilata e testata con gli strumenti Sencha esistenti.

Il guadagno di velocità deriva soprattutto dal fatto che non è necessario mantenere un nuovo modello dati per l’interfaccia e poi tradurlo nuovamente in JavaScript. L’IA può lavorare direttamente sul codice che il compilatore Sencha elaborerà comunque.

Il chiaro raggruppamento dei file aiuta inoltre a evitare le tipiche modifiche isolate. Una nuova interazione spesso non riguarda soltanto la View, ma anche il Controller e il ViewModel. Se questi file vengono esaminati insieme, la modifica può essere implementata in modo più coerente.

Che cosa succede a Sencha Architect?

ExtJS Code Navigator non rende tecnicamente inutilizzabile un progetto Architect. Non rimuove i file di Architect e non ne modifica la configurazione del progetto. Sencha Architect può continuare a essere avviato.

Tuttavia, non esiste un roundtrip senza perdite.

Architect gestisce un proprio modello di progetto e di progettazione. Il Navigator, invece, modifica direttamente i file JavaScript generati da tale modello. Le modifiche a questi file non vengono riportate nel modello interno di Architect. Se in seguito Architect genera nuovamente gli stessi file, le modifiche apportate manualmente o con l’IA potrebbero essere sovrascritte.

Quando si cambia flusso di lavoro, è quindi necessario prendere una decisione chiara:

Non appena i file JavaScript vengono sviluppati direttamente, dovrebbero diventare la nuova source of truth.

In seguito, Architect può ancora essere utilizzato come riferimento o per aree non interessate. Tuttavia, non dovrebbe più essere impiegato per rigenerare gli stessi file finché non esiste un metodo controllato di risincronizzazione. Il controllo di versione è indispensabile, ma non sostituisce la decisione su quale sistema gestisca lo stato di riferimento.

Questo limite non è un problema specifico del Navigator. Si presenta sempre quando il codice generato viene sviluppato ulteriormente al di fuori del generatore originale.

Un’analisi volutamente leggera

Il nome del repository suggerisce un parser completo. L’implementazione attuale, tuttavia, adotta volutamente un approccio più semplice: cerca Ext.define, legge extend e riconosce le sezioni di configurazione in base alla loro posizione e alla profondità delle parentesi.

Questo è sufficiente per molti file Ext JS dalla struttura classica, ma non costituisce un parser AST JavaScript completo. Dipendenze, binding e riferimenti non vengono risolti semanticamente. Anche l’associazione tra View, Controller e ViewModel si basa sui nomi dei file e non su un’analisi della configurazione Ext JS.

Il Navigator non sostituisce quindi né un IDE né l’analisi statica del codice. Il suo punto di forza è l’orientamento rapido all’interno di una codebase esistente e strutturata in modo regolare.

Requisiti tecnici

Per l’accesso diretto ai file locali viene utilizzata la File System Access API. In pratica, ciò significa:

• Chrome o Edge, oppure un altro browser compatibile basato su Chromium
• esecuzione tramite localhost o HTTPS
• autorizzazione alla directory di progetto selezionata con permessi di scrittura
• accesso a Internet per le librerie dell’editor e di evidenziazione della sintassi attualmente caricate da fonti esterne

L’applicazione può essere avviata tramite il Dockerfile incluso:

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

È quindi raggiungibile all’indirizzo http://localhost:8000. In alternativa, in linea di principio è sufficiente qualsiasi server web statico, purché siano soddisfatti i requisiti del browser.

Limiti attuali

Lo stato attuale si concentra sulla navigazione e sulla modifica diretta. Alcuni meccanismi di protezione che sarebbero utili per un impiego produttivo più ampio non sono ancora inclusi:

• nessuna validazione della sintassi o di Ext JS prima del salvataggio
• nessuna formattazione automatica
• nessuna vista diff o integrazione con Git
• nessun backup automatico dei file modificati
• nessuna risoluzione semantica di controller, viewModel, bind o reference
• nessuna sincronizzazione con i file di progetto Architect
• nessuna interfaccia IA integrata
• nessun supporto per creare, spostare o eliminare file

Lo strumento dovrebbe quindi essere utilizzato insieme a Git e al processo di build e test esistente. In particolare, le modifiche generate dall’IA devono essere verificate come qualsiasi altra modifica al codice.

Conclusione

ExtJS Code Navigator non persegue un approccio di migrazione radicale. Utilizza volutamente ciò che già funziona nei progetti Ext JS esistenti: la nota struttura MVVM, le classi presenti e la build Sencha consolidata.

La novità è il modo in cui si lavora al loro interno. Invece di vincolare lo sviluppo al generatore di Sencha Architect, i file JavaScript generati diventano una codebase direttamente modificabile. Ciò consente di utilizzare strumenti di sviluppo moderni e assistenti IA senza dover trasferire View, Controller e ViewModel in una nuova struttura.

Il prezzo è una netta separazione dal precedente flusso di generazione. Architect rimane tecnicamente disponibile, ma non deve più rigenerare senza controllo gli stessi file. Se si accetta questo limite e si dichiara la codebase JavaScript come source of truth, un progetto Ext JS esistente può essere sviluppato molto più rapidamente senza rinunciare alla sua architettura familiare.