Développer Ext JS avec l'IA sans renoncer à la structure MVVM familière

Pour de nombreux projets Ext JS, Sencha Architect a longtemps été le lieu central où étaient créés les interfaces, les Controllers et les ViewModels. L’outil impose une structure claire et réduit une partie du travail manuel. En même temps, il devient un goulot d’étranglement dès que les modifications doivent être réalisées plus rapidement, de manière plus ciblée ou avec l’aide de l’IA.

C’est précisément là qu’intervient ExtJS Code Navigator. Mon objectif n’était pas de migrer l’application existante vers un nouveau framework ni d’introduire une seconde structure de projet. La structure MVVM générée par Architect devait être conservée. View, Controller, ViewController, Model, ViewModel et Store devaient rester là où les développeurs Ext JS expérimentés s’attendent à les trouver.

La différence réside dans le flux de travail : au lieu de commencer par modéliser les modifications dans Architect et de lui faire générer des fichiers JavaScript, on travaille directement avec les fichiers source existants. Un assistant IA peut ainsi analyser et faire évoluer le projet beaucoup plus rapidement, sans perdre la structure familière.

Ce qu’est techniquement le projet

ExtJS Code Navigator est une petite application basée sur le navigateur qui permet de parcourir, rechercher et modifier un répertoire app Ext JS existant. Ce n’est délibérément ni un nouveau compilateur Ext JS ni un substitut au compilateur Sencha.

Techniquement, l’application se compose de HTML, CSS et JavaScript statiques. Aucune étape de build JavaScript n’est nécessaire. Un Dockerfile basé sur Nginx est fourni pour le déploiement.

Dans le navigateur, un répertoire local est ouvert avec des droits de lecture et d’écriture au moyen de la File System Access API. Le répertoire attendu est généralement resources/static/app. L’application lit ensuite récursivement la structure existante et présente les fichiers JavaScript sous la forme d’une arborescence de projet navigable.

Les zones bien connues sont notamment prises en charge :

• controller
• model
• store
• view

Les autres répertoires et fichiers JavaScript sont également affichés. L’application ne crée aucune nouvelle structure de projet, ne déplace aucun fichier et ne génère aucune copie. Lors de l’enregistrement, le fichier original précédemment sélectionné est directement mis à jour.

C’est essentiel pour l’approche choisie : la structure existante des fichiers et des dossiers reste la source of truth.

La structure MVVM est conservée

Dans la pratique, une View Ext JS se compose rarement d’un seul fichier. Une View comprend souvent un Controller et un ViewModel et, dans les projets plus anciens ou mixtes, également un Model ou un ViewController.

Le Navigator reconnaît les conventions de nommage courantes telles que :

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

Une structure générée par Architect avec ses propres sous-répertoires est également prise en compte :

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

Dans l’interface, ces fichiers sont regroupés au sein d’un groupe View commun. Il est important de noter que ce regroupement est uniquement virtuel. Rien n’est renommé ni déplacé sur le disque.

Le modèle mental du projet existant est ainsi préservé. Les personnes qui connaissent déjà le projet continuent à s’y repérer grâce à View, Controller et ViewModel. En même temps, un assistant IA dispose d’un contexte clair sur les fichiers qui doivent être examinés ensemble.

Navigation au sein d’une classe Ext JS

Outre la structure des fichiers, le Navigator analyse les blocs Ext.define existants. Il reconnaît la classe de base indiquée dans extend et répertorie les sections de configuration de premier niveau.

Pour une View comme celle-ci :

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

    controller: "customer",

    viewModel: {
        type: "customer"
    },

    items: [],

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

xtype, controller, viewModel, items et listeners sont par exemple proposés comme sections. Un clic sur une section permet d’accéder directement à l’emplacement correspondant dans le fichier.

L’application propose également :

• une recherche textuelle dans l’ensemble du projet parmi les fichiers JavaScript chargés
• la coloration syntaxique en mode lecture
• un éditeur de code source intégré
• l’enregistrement à l’aide d’un bouton ou de Ctrl+S ou Cmd+S
• des avertissements avant l’abandon de modifications non enregistrées
• le rechargement de la structure du projet après des modifications externes
• la copie du chemin relatif du fichier pour des prompts ou d’autres outils

Le Navigator ne transforme donc pas une vaste base de code Ext JS en un nouveau projet. Il rend simplement la base de code existante plus rapidement accessible.

Où intervient l’IA

L’application elle-même ne contient actuellement aucun modèle de langage ni aucune connexion directe à une API d’IA. Cette séparation est intentionnelle. Le Navigator représente la structure et permet une modification contrôlée des fichiers. L’assistance IA proprement dite peut être fournie par un assistant de programmation externe.

Un flux de travail typique se présente alors comme suit :

1. Le répertoire app existant est ouvert dans le Navigator.
2. La View concernée et ses fichiers associés sont identifiés comme une unité commune.
3. Les fichiers ou chemins pertinents sont fournis à un assistant IA comme contexte.
4. L’IA étend par exemple les bindings, formulas, Stores, événements ou la logique du Controller.
5. Les modifications sont vérifiées et enregistrées directement dans les fichiers MVVM existants.
6. L’application est construite et testée avec les outils Sencha existants.

Le gain de vitesse vient surtout du fait qu’il n’est pas nécessaire de maintenir un nouveau modèle de données pour l’interface, puis de le retraduire en JavaScript. L’IA peut travailler directement sur le code que le compilateur Sencha traite de toute façon.

Le regroupement clair des fichiers aide également à éviter les modifications isolées typiques. Une nouvelle interaction ne concerne souvent pas seulement la View, mais aussi le Controller et le ViewModel. Lorsque ces fichiers sont examinés ensemble, la modification peut être mise en œuvre de manière plus cohérente.

Que devient Sencha Architect ?

ExtJS Code Navigator ne rend pas techniquement inutilisable un projet Architect. Il ne supprime aucun fichier Architect et ne modifie pas non plus sa configuration de projet. Sencha Architect peut toujours être lancé.

Il n’existe toutefois aucun aller-retour sans perte.

Architect gère son propre modèle de projet et de conception. Le Navigator, en revanche, modifie directement les fichiers JavaScript générés à partir de ce modèle. Les modifications apportées à ces fichiers ne sont pas retransmises au modèle interne d’Architect. Si Architect génère à nouveau les mêmes fichiers par la suite, les modifications effectuées manuellement ou avec l’IA peuvent être écrasées.

Le changement de flux de travail exige donc une décision claire :

Dès que les fichiers JavaScript sont développés directement, ils doivent devenir la nouvelle source of truth.

Architect peut ensuite continuer à servir de repère ou être utilisé pour les zones non concernées. Il ne doit toutefois plus servir à régénérer les mêmes fichiers tant qu’il n’existe aucun moyen contrôlé de les resynchroniser. Le contrôle de version est indispensable, mais il ne remplace pas la décision quant au système qui gère l’état de référence.

Cette limite n’est pas un problème propre au Navigator. Elle apparaît systématiquement lorsque du code généré continue à être développé en dehors du générateur d’origine.

Une analyse délibérément légère

Le nom du dépôt suggère un parser complet. L’implémentation actuelle adopte toutefois délibérément une approche plus simple : elle recherche Ext.define, lit extend et reconnaît les sections de configuration en fonction de leur position et de la profondeur des parenthèses.

Cela suffit pour de nombreux fichiers Ext JS de structure classique, mais il ne s’agit pas d’un parser AST JavaScript complet. Les dépendances, bindings ou références ne sont pas résolus sémantiquement. L’association entre View, Controller et ViewModel repose également sur les noms de fichiers et non sur une analyse de la configuration Ext JS.

Le Navigator ne remplace donc ni un IDE ni l’analyse statique du code. Sa force réside dans l’orientation rapide au sein d’une base de code existante et structurée de manière régulière.

Prérequis techniques

La File System Access API est utilisée pour accéder directement aux fichiers locaux. En pratique, cela implique :

• Chrome ou Edge, ou un autre navigateur compatible basé sur Chromium
• une exécution via localhost ou HTTPS
• l’autorisation d’écrire dans le répertoire de projet sélectionné
• un accès à Internet pour les bibliothèques d’édition et de coloration syntaxique actuellement chargées depuis des sources externes

L’application peut être lancée à l’aide du Dockerfile fourni :

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

Elle est ensuite accessible à l’adresse http://localhost:8000. Tout serveur web statique suffit en principe comme alternative, à condition que les exigences du navigateur soient respectées.

Limites actuelles

L’état actuel se concentre sur la navigation et la modification directe. Certains mécanismes de protection utiles pour une utilisation plus large en production ne sont pas encore inclus :

• aucune validation de la syntaxe ou d’Ext JS avant l’enregistrement
• aucun formatage automatique
• aucune vue des différences ni intégration Git
• aucune sauvegarde automatique des fichiers modifiés
• aucune résolution sémantique de controller, viewModel, bind ou reference
• aucune synchronisation avec les fichiers de projet Architect
• aucune interface d’IA intégrée
• aucune prise en charge de la création, du déplacement ou de la suppression de fichiers

L’outil doit donc être utilisé avec Git et le processus de build et de test existant. Les modifications générées par l’IA, en particulier, doivent être vérifiées comme toute autre modification de code.

Conclusion

ExtJS Code Navigator ne poursuit pas une approche de migration radicale. Il utilise délibérément ce qui fonctionne déjà dans les projets Ext JS existants : la structure MVVM familière, les classes présentes et le build Sencha établi.

La nouveauté réside dans la manière d’y travailler. Au lieu de lier le développement au générateur de Sencha Architect, les fichiers JavaScript générés deviennent une base de code directement modifiable. Les outils de développement modernes et les assistants IA peuvent ainsi être utilisés sans devoir transférer View, Controller et ViewModel vers une nouvelle structure.

Le prix à payer est une séparation nette avec l’ancien flux de génération. Architect reste techniquement disponible, mais il ne doit plus régénérer les mêmes fichiers de manière incontrôlée. Si cette limite est acceptée et que la base de code JavaScript est déclarée source of truth, un projet Ext JS existant peut évoluer beaucoup plus rapidement sans renoncer à son architecture familière.