D DOKUBASIS

Develop Ext JS with AI without giving up the familiar MVVM structure

For many Ext JS projects, Sencha Architect was long the central place where interfaces, controllers, and ViewModels were created. The tool provides a clear structure and takes care of some of the manual work. At the same time, it becomes a bottleneck as soon as changes need to be implemented faster, more selectively, or with AI support.

This is exactly where ExtJS Code Navigator comes in. My goal was not to migrate the existing application to a new framework or introduce a second project structure. The MVVM structure generated by Architect was to remain intact. View, Controller, ViewController, Model, ViewModel, and Store were to stay where experienced Ext JS developers expect to find them.

The difference lies in the workflow: instead of first modeling changes in Architect and having it generate JavaScript files, you work directly with the existing source files. This also allows an AI assistant to analyze and develop the project much faster without losing the familiar structure.

What the project is technically

ExtJS Code Navigator is a small browser-based application for navigating, searching, and editing an existing Ext JS app directory. It is deliberately neither a new Ext JS compiler nor a replacement for the Sencha compiler.

Technically, the application consists of static HTML, CSS, and JavaScript. No JavaScript build step is required. A Dockerfile based on Nginx is included for deployment.

In the browser, a local directory is opened with read and write permissions through the File System Access API. Typically, the expected directory is resources/static/app. The application then reads the existing structure recursively and presents the JavaScript files as a navigable project tree.

In particular, the familiar areas are supported:

  • controller
  • model
  • store
  • view

Other directories and JavaScript files are displayed as well. The application does not create a new project structure, move files, or generate copies. When saving, it directly updates the original file selected earlier.

This is crucial to the chosen approach: the existing file and folder structure remains the source of truth.

MVVM remains intact

In practice, an Ext JS View rarely consists of just one file. A View often includes a Controller and a ViewModel and, in older or mixed projects, also a Model or a ViewController.

The Navigator recognizes typical naming conventions such as:

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

A structure generated by Architect with its own subdirectories is also taken into account:

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

These files are grouped into a shared View group in the interface. Importantly, this grouping takes place only virtually. Nothing is renamed or moved on disk.

This preserves the mental model of the existing project. Anyone already familiar with the project can continue to navigate it through View, Controller, and ViewModel. At the same time, an AI assistant receives clear context about which files should be considered together.

In addition to the file structure, the Navigator evaluates existing Ext.define blocks. It recognizes the base class from extend and lists top-level configuration sections.

For a View like this:

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

    controller: "customer",

    viewModel: {
        type: "customer"
    },

    items: [],

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

For example, xtype, controller, viewModel, items, and listeners are offered as sections. Clicking a section jumps directly to the corresponding location in the file.

The application also provides:

  • full-project text search across the loaded JavaScript files
  • syntax highlighting for read mode
  • an integrated source code editor
  • saving with a button or Ctrl+S or Cmd+S
  • warnings before discarding unsaved changes
  • reloading the project structure after external changes
  • copying the relative file path for prompts or other tools

The Navigator therefore does not turn a large Ext JS codebase into a new project. It simply makes the existing codebase accessible more quickly.

Where AI comes into play

The application itself currently contains neither a language model nor a direct connection to an AI API. This separation is intentional. The Navigator presents the structure and enables controlled editing of the files. The actual AI support can be provided by an external coding assistant.

A typical workflow then looks like this:

  1. The existing app directory is opened in the Navigator.
  2. The relevant View and its accompanying files are identified as a shared unit.
  3. The relevant files or paths are provided to an AI assistant as context.
  4. The AI extends bindings, formulas, Stores, events, or Controller logic, for example.
  5. The changes are reviewed and saved directly in the existing MVVM files.
  6. The application is built and tested with the existing Sencha tools.

The speed gain comes mainly from not having to maintain a new data model for the interface and then translate it back into JavaScript. AI can work directly on the code that the Sencha compiler processes anyway.

The clear file grouping also helps prevent typical isolated changes. A new interaction often affects not only the View but also the Controller and the ViewModel. When these files are considered together, the change can be implemented more consistently.

What happens to Sencha Architect?

ExtJS Code Navigator does not make an Architect project technically unusable. It does not remove Architect files or alter its project configuration. Sencha Architect can still be launched.

However, there is no lossless round trip.

Architect maintains its own project and designer model. The Navigator, by contrast, directly edits the JavaScript files generated from it. Changes to these files are not transferred back into Architect’s internal model. If Architect later generates the same files again, changes made manually or with AI may be overwritten.

For this reason, switching workflows requires a clear decision:

As soon as the JavaScript files are developed directly, they should become the new source of truth.

After that, Architect can still be used for orientation or for unaffected areas. However, it should no longer be used to regenerate the same files unless there is a controlled way to synchronize them back. Version control is indispensable, but it does not replace the decision about which system manages the authoritative state.

This boundary is not a problem specific to the Navigator. It arises whenever generated code is developed further outside the original generator.

Deliberately lightweight analysis

The repository name suggests a complete parser. However, the current implementation deliberately takes a simpler approach: it searches for Ext.define, reads extend, and identifies configuration sections based on their position and bracket depth.

This is sufficient for many conventionally structured Ext JS files, but it is not a complete JavaScript AST parser. Dependencies, bindings, and references are not resolved semantically. The association of View, Controller, and ViewModel is also based on file names rather than an analysis of the Ext JS configuration.

The Navigator therefore replaces neither an IDE nor static code analysis. Its strength is rapid orientation within an existing, regularly structured codebase.

Technical requirements

The File System Access API is used for direct access to local files. In practice, this means:

  • Chrome or Edge, or another compatible Chromium-based browser
  • running via localhost or HTTPS
  • granting the selected project directory write permissions
  • Internet access for the editor and syntax-highlighting libraries currently loaded from external sources

The application can be started with the included Dockerfile:

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

It is then available at http://localhost:8000. Alternatively, any static web server is generally sufficient as long as the browser requirements are met.

Current limitations

The current state focuses on navigation and direct editing. Some safeguards that would be useful for broader production use are not yet included:

  • no syntax or Ext JS validation before saving
  • no automatic formatting
  • no diff view or Git integration
  • no automatic backup of modified files
  • no semantic resolution of controller, viewModel, bind, or reference
  • no synchronization with Architect project files
  • no integrated AI interface
  • no support for creating, moving, or deleting files

The tool should therefore be used together with Git and the existing build and test process. AI-generated changes in particular must be reviewed like any other code change.

Conclusion

ExtJS Code Navigator does not pursue a radical migration approach. It deliberately uses what already works in existing Ext JS projects: the familiar MVVM structure, the existing classes, and the established Sencha build.

What is new is the way work is done within it. Instead of tying development to Sencha Architect’s generator, the generated JavaScript files become a directly editable codebase. This allows modern development tools and AI assistants to be used without having to transfer View, Controller, and ViewModel into a new structure.

The price is a clear separation from the previous generation workflow. Architect remains technically available, but it must no longer regenerate the same files in an uncontrolled manner. If this boundary is accepted and the JavaScript codebase is declared the source of truth, an existing Ext JS project can be developed much faster without giving up its familiar architecture.