D DOKUBASIS

Desarrollar Ext JS con IA sin renunciar a la estructura MVVM conocida

Durante mucho tiempo, Sencha Architect fue el lugar central donde se creaban las interfaces, los Controllers y los ViewModels de muchos proyectos Ext JS. La herramienta establece una estructura clara y reduce parte del trabajo manual. Al mismo tiempo, se convierte en un cuello de botella cuando los cambios deben implementarse de forma más rápida, específica o con ayuda de la IA.

Aquí es precisamente donde entra en juego ExtJS Code Navigator. Mi objetivo no era migrar la aplicación existente a un framework nuevo ni introducir una segunda estructura de proyecto. Debía conservarse la estructura MVVM generada por Architect. View, Controller, ViewController, Model, ViewModel y Store debían seguir donde los desarrolladores experimentados de Ext JS esperan encontrarlos.

La diferencia está en el flujo de trabajo: en lugar de modelar primero los cambios en Architect y dejar que este genere archivos JavaScript, se trabaja directamente con los archivos de código fuente existentes. De este modo, un asistente de IA también puede analizar y seguir desarrollando el proyecto mucho más rápido sin perder la estructura conocida.

Qué es técnicamente el proyecto

ExtJS Code Navigator es una pequeña aplicación para navegador destinada a navegar, buscar y editar un directorio app de Ext JS existente. De forma deliberada, no es un compilador nuevo de Ext JS ni un sustituto del compilador de Sencha.

Técnicamente, la aplicación se compone de HTML, CSS y JavaScript estáticos. No se necesita un paso de build de JavaScript. Para el despliegue se incluye un Dockerfile basado en Nginx.

En el navegador se abre un directorio local con permisos de lectura y escritura mediante la File System Access API. Normalmente se espera el directorio resources/static/app. A continuación, la aplicación lee recursivamente la estructura existente y presenta los archivos JavaScript como un árbol de proyecto navegable.

En particular, se admiten las áreas conocidas:

  • controller
  • model
  • store
  • view

También se muestran otros directorios y archivos JavaScript. La aplicación no crea una estructura de proyecto nueva, no mueve archivos ni genera copias. Al guardar, se actualiza directamente el archivo original seleccionado previamente.

Esto es decisivo para el enfoque elegido: la estructura existente de archivos y carpetas sigue siendo la source of truth.

MVVM se mantiene intacto

En la práctica, una View de Ext JS rara vez consta de un único archivo. Una View suele incluir un Controller y un ViewModel y, en proyectos más antiguos o mixtos, también un Model o un ViewController.

El Navigator reconoce convenciones de nombres habituales como:

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

También se tiene en cuenta una estructura generada por Architect con sus propios subdirectorios:

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

En la interfaz, estos archivos se agrupan en un grupo común de View. Es importante destacar que esta agrupación solo se realiza virtualmente. No se cambia el nombre ni se mueve nada en el disco.

Así se conserva el modelo mental del proyecto existente. Quienes ya conocen el proyecto pueden seguir orientándose mediante View, Controller y ViewModel. Al mismo tiempo, un asistente de IA recibe un contexto claro sobre qué archivos deben examinarse juntos.

Además de la estructura de archivos, el Navigator analiza los bloques Ext.define existentes. Reconoce la clase base indicada en extend y enumera las secciones de configuración del nivel superior.

En una View como esta:

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

    controller: "customer",

    viewModel: {
        type: "customer"
    },

    items: [],

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

se ofrecen, por ejemplo, xtype, controller, viewModel, items y listeners como secciones. Al hacer clic en una sección se accede directamente al punto correspondiente del archivo.

Además, la aplicación ofrece:

  • una búsqueda de texto en todo el proyecto entre los archivos JavaScript cargados
  • resaltado de sintaxis para el modo de lectura
  • un editor de código fuente integrado
  • guardado mediante un botón o con Ctrl+S o Cmd+S
  • advertencias antes de descartar cambios no guardados
  • recarga de la estructura del proyecto después de cambios externos
  • copia de la ruta relativa del archivo para prompts u otras herramientas

Por tanto, el Navigator no convierte una gran base de código Ext JS en un proyecto nuevo. Simplemente permite acceder más rápido a la base de código existente.

Dónde entra en juego la IA

Actualmente, la propia aplicación no contiene ningún modelo de lenguaje ni una conexión directa con una API de IA. Esta separación es deliberada. El Navigator representa la estructura y permite editar los archivos de forma controlada. La asistencia de IA propiamente dicha puede proporcionarla un asistente de programación externo.

Un flujo de trabajo habitual sería el siguiente:

  1. Se abre el directorio app existente en el Navigator.
  2. La View en cuestión y sus archivos complementarios se identifican como una unidad común.
  3. Los archivos o rutas relevantes se proporcionan como contexto a un asistente de IA.
  4. La IA amplía, por ejemplo, bindings, formulas, Stores, eventos o la lógica del Controller.
  5. Los cambios se revisan y se guardan directamente en los archivos MVVM existentes.
  6. La aplicación se construye y se prueba con las herramientas de Sencha existentes.

La mejora de velocidad se debe principalmente a que no es necesario mantener un modelo de datos nuevo para la interfaz y después volver a traducirlo a JavaScript. La IA puede trabajar directamente con el código que el compilador de Sencha procesa de todos modos.

La agrupación clara de archivos también ayuda a evitar los típicos cambios aislados. Una interacción nueva no suele afectar solo a la View, sino también al Controller y al ViewModel. Si estos archivos se examinan juntos, el cambio puede implementarse de forma más coherente.

¿Qué ocurre con Sencha Architect?

ExtJS Code Navigator no hace que un proyecto de Architect resulte técnicamente inutilizable. No elimina archivos de Architect ni modifica su configuración del proyecto. Sencha Architect puede seguir iniciándose.

Sin embargo, no existe un proceso de ida y vuelta sin pérdidas.

Architect gestiona su propio modelo de proyecto y de diseño. En cambio, el Navigator edita directamente los archivos JavaScript generados a partir de ese modelo. Los cambios en estos archivos no se transfieren de vuelta al modelo interno de Architect. Si Architect vuelve a generar más adelante los mismos archivos, los cambios realizados manualmente o con IA pueden sobrescribirse.

Por eso, al cambiar el flujo de trabajo debe tomarse una decisión clara:

En cuanto los archivos JavaScript se sigan desarrollando directamente, deben convertirse en la nueva source of truth.

Después, Architect puede seguir sirviendo para orientarse o para áreas no afectadas. Sin embargo, no debe volver a utilizarse para generar los mismos archivos mientras no exista una forma controlada de resincronizarlos. El control de versiones es indispensable, pero no sustituye la decisión sobre qué sistema gestiona el estado de referencia.

Este límite no es un problema específico del Navigator. Surge siempre que se sigue desarrollando código generado fuera del generador original.

Análisis deliberadamente ligero

El nombre del repositorio sugiere un parser completo. Sin embargo, la implementación actual adopta deliberadamente un enfoque más sencillo: busca Ext.define, lee extend y reconoce las secciones de configuración según su posición y la profundidad de los paréntesis.

Esto es suficiente para muchos archivos Ext JS con una estructura clásica, pero no constituye un parser AST completo de JavaScript. Las dependencias, los bindings y las referencias no se resuelven semánticamente. La asociación de View, Controller y ViewModel también se basa en los nombres de los archivos y no en un análisis de la configuración de Ext JS.

Por tanto, el Navigator no sustituye ni a un IDE ni al análisis estático de código. Su fortaleza es permitir una orientación rápida en una base de código existente y estructurada de forma regular.

Requisitos técnicos

Para acceder directamente a archivos locales se utiliza la File System Access API. En la práctica, esto significa:

  • Chrome o Edge, u otro navegador compatible basado en Chromium
  • ejecución mediante localhost o HTTPS
  • autorización del directorio de proyecto seleccionado con permisos de escritura
  • acceso a Internet para las bibliotecas del editor y de resaltado de sintaxis que actualmente se cargan desde fuentes externas

La aplicación puede iniciarse mediante el Dockerfile incluido:

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

A continuación, está disponible en http://localhost:8000. Como alternativa, en principio basta cualquier servidor web estático siempre que se cumplan los requisitos del navegador.

Límites actuales

El estado actual se centra en la navegación y la edición directa. Todavía no se incluyen algunos mecanismos de protección que serían útiles para un uso más amplio en producción:

  • no hay validación de sintaxis ni de Ext JS antes de guardar
  • no hay formato automático
  • no hay vista de diferencias ni integración con Git
  • no hay copia de seguridad automática de los archivos modificados
  • no hay resolución semántica de controller, viewModel, bind o reference
  • no hay sincronización con los archivos de proyecto de Architect
  • no hay una interfaz de IA integrada
  • no se admite la creación, el movimiento ni la eliminación de archivos

Por tanto, la herramienta debe utilizarse junto con Git y el proceso existente de build y pruebas. En especial, los cambios generados por IA deben revisarse como cualquier otro cambio de código.

Conclusión

ExtJS Code Navigator no sigue un enfoque de migración radical. Utiliza deliberadamente lo que ya funciona en los proyectos Ext JS existentes: la conocida estructura MVVM, las clases existentes y el build consolidado de Sencha.

La novedad es la forma de trabajar con ello. En lugar de vincular el desarrollo al generador de Sencha Architect, los archivos JavaScript generados se convierten en una base de código que puede editarse directamente. Esto permite utilizar herramientas de desarrollo modernas y asistentes de IA sin tener que trasladar View, Controller y ViewModel a una estructura nueva.

El precio es una separación clara del flujo de generación anterior. Architect sigue estando técnicamente disponible, pero ya no debe regenerar los mismos archivos de forma descontrolada. Si se acepta este límite y se declara la base de código JavaScript como source of truth, un proyecto Ext JS existente puede seguir desarrollándose mucho más rápido sin renunciar a su arquitectura conocida.