D DOKUBASIS

Continuar a desenvolver Ext JS com IA sem abandonar a estrutura MVVM familiar

Durante muito tempo, o Sencha Architect foi, para muitos projetos Ext JS, o local central onde eram criados interfaces, Controllers e ViewModels. A ferramenta impõe uma estrutura clara e reduz parte do trabalho manual. Ao mesmo tempo, torna-se um estrangulamento quando é necessário implementar alterações de forma mais rápida, direcionada ou com o apoio de IA.

É precisamente neste ponto que entra o ExtJS Code Navigator. O meu objetivo não era migrar a aplicação existente para uma nova framework nem introduzir uma segunda estrutura de projeto. A estrutura MVVM gerada pelo Architect deveria ser mantida. View, Controller, ViewController, Model, ViewModel e Store deveriam continuar nos locais onde os programadores de Ext JS experientes esperam encontrá-los.

A diferença está no fluxo de trabalho: em vez de modelar primeiro as alterações no Architect e deixar que este gere ficheiros JavaScript, trabalha-se diretamente com os ficheiros de código-fonte existentes. Desta forma, um assistente de IA também pode analisar e continuar a desenvolver o projeto muito mais depressa, sem perder a estrutura familiar.

O que é o projeto do ponto de vista técnico

O ExtJS Code Navigator é uma pequena aplicação baseada no navegador para navegar, pesquisar e editar um diretório app de Ext JS existente. Deliberadamente, não é um novo compilador de Ext JS nem substitui o compilador Sencha.

Do ponto de vista técnico, a aplicação é composta por HTML, CSS e JavaScript estáticos. Não é necessário um passo de build de JavaScript. Para a disponibilização, está incluído um Dockerfile baseado em Nginx.

No navegador, é aberto um diretório local com permissões de leitura e escrita através da File System Access API. Normalmente, espera-se o diretório resources/static/app. Em seguida, a aplicação lê recursivamente a estrutura existente e apresenta os ficheiros JavaScript como uma árvore de projeto navegável.

São especialmente suportadas as áreas conhecidas:

  • controller
  • model
  • store
  • view

Também são apresentados outros diretórios e ficheiros JavaScript. A aplicação não cria uma nova estrutura de projeto, não move ficheiros nem gera cópias. Ao guardar, o ficheiro original anteriormente selecionado é atualizado diretamente.

Isto é decisivo para a abordagem escolhida: a estrutura existente de ficheiros e pastas continua a ser a source of truth.

O MVVM é mantido

Na prática, uma View de Ext JS raramente é constituída por um único ficheiro. Uma View inclui frequentemente um Controller e um ViewModel e, em projetos mais antigos ou mistos, também um Model ou um ViewController.

O Navigator reconhece convenções de nomenclatura típicas, tais como:

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

Também é considerada uma estrutura gerada pelo Architect com subdiretórios próprios:

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

Na interface, estes ficheiros são agrupados numa View comum. É importante salientar que este agrupamento ocorre apenas virtualmente. Nada é renomeado ou movido no disco.

Deste modo, mantém-se o modelo mental do projeto existente. Quem já conhece o projeto continua a orientar-se através de View, Controller e ViewModel. Ao mesmo tempo, um assistente de IA recebe um contexto claro sobre os ficheiros que devem ser analisados em conjunto.

Além da estrutura de ficheiros, o Navigator analisa os blocos Ext.define existentes. Reconhece a classe base indicada em extend e enumera as secções de configuração no nível superior.

Numa View como esta:

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

    controller: "customer",

    viewModel: {
        type: "customer"
    },

    items: [],

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

por exemplo, xtype, controller, viewModel, items e listeners são apresentados como secções. Um clique numa secção leva diretamente ao ponto correspondente no ficheiro.

Além disso, a aplicação disponibiliza:

  • uma pesquisa de texto em todo o projeto nos ficheiros JavaScript carregados
  • realce de sintaxe no modo de leitura
  • um editor de código-fonte integrado
  • guardar através de um botão ou de Ctrl+S ou Cmd+S
  • avisos antes de descartar alterações não guardadas
  • recarregamento da estrutura do projeto após alterações externas
  • cópia do caminho relativo do ficheiro para prompts ou outras ferramentas

Assim, o Navigator não transforma uma grande base de código Ext JS num novo projeto. Apenas torna a base de código existente mais rapidamente acessível.

Onde entra a IA

Atualmente, a própria aplicação não contém um modelo de linguagem nem uma ligação direta a uma API de IA. Esta separação é intencional. O Navigator representa a estrutura e permite a edição controlada dos ficheiros. O apoio de IA propriamente dito pode ser fornecido por um assistente de programação externo.

Um fluxo de trabalho típico é o seguinte:

  1. O diretório app existente é aberto no Navigator.
  2. A View em causa e os respetivos ficheiros auxiliares são identificados como uma unidade comum.
  3. Os ficheiros ou caminhos relevantes são fornecidos como contexto a um assistente de IA.
  4. A IA amplia, por exemplo, bindings, formulas, Stores, eventos ou a lógica do Controller.
  5. As alterações são verificadas e guardadas diretamente nos ficheiros MVVM existentes.
  6. A aplicação é compilada e testada com as ferramentas Sencha existentes.

O ganho de velocidade resulta sobretudo do facto de não ser necessário manter um novo modelo de dados para a interface e depois voltar a traduzi-lo para JavaScript. A IA pode trabalhar diretamente no código que o compilador Sencha irá processar de qualquer forma.

O agrupamento claro dos ficheiros também ajuda a evitar as típicas alterações isoladas. Muitas vezes, uma nova interação não afeta apenas a View, mas também o Controller e o ViewModel. Quando estes ficheiros são analisados em conjunto, a alteração pode ser implementada de forma mais consistente.

O que acontece ao Sencha Architect?

O ExtJS Code Navigator não torna tecnicamente inutilizável um projeto Architect. Não remove ficheiros do Architect nem altera a respetiva configuração do projeto. O Sencha Architect pode continuar a ser iniciado.

No entanto, não existe um roundtrip sem perdas.

O Architect gere um modelo próprio de projeto e de design. O Navigator, por sua vez, edita diretamente os ficheiros JavaScript gerados a partir desse modelo. As alterações a estes ficheiros não são transferidas de volta para o modelo interno do Architect. Se, posteriormente, o Architect voltar a gerar os mesmos ficheiros, as alterações efetuadas manualmente ou com IA poderão ser substituídas.

Por isso, ao mudar de fluxo de trabalho, é necessário tomar uma decisão clara:

Assim que os ficheiros JavaScript passarem a ser desenvolvidos diretamente, devem tornar-se a nova source of truth.

Depois disso, o Architect pode continuar a servir para orientação ou para áreas não afetadas. No entanto, não deve voltar a ser utilizado para gerar os mesmos ficheiros enquanto não existir uma forma controlada de ressincronização. O controlo de versões é indispensável, mas não substitui a decisão sobre qual sistema gere o estado de referência.

Este limite não é um problema específico do Navigator. Surge sempre que código gerado continua a ser desenvolvido fora do gerador original.

Uma análise deliberadamente leve

O nome do repositório sugere um parser completo. No entanto, a implementação atual adota deliberadamente uma abordagem mais simples: procura Ext.define, lê extend e reconhece secções de configuração com base na respetiva posição e profundidade dos parênteses.

Isto é suficiente para muitos ficheiros Ext JS com uma estrutura clássica, mas não constitui um parser AST de JavaScript completo. As dependências, os bindings e as referências não são resolvidos semanticamente. A associação entre View, Controller e ViewModel também se baseia nos nomes dos ficheiros, e não numa análise da configuração Ext JS.

Por conseguinte, o Navigator não substitui um IDE nem a análise estática de código. O seu ponto forte é a orientação rápida numa base de código existente e estruturada de forma regular.

Requisitos técnicos

Para o acesso direto a ficheiros locais, é utilizada a File System Access API. Na prática, isto significa:

  • Chrome ou Edge, ou outro navegador compatível baseado em Chromium
  • execução através de localhost ou HTTPS
  • autorização do diretório de projeto selecionado com permissões de escrita
  • acesso à Internet para as bibliotecas do editor e de realce de sintaxe atualmente carregadas a partir de fontes externas

A aplicação pode ser iniciada através do Dockerfile existente:

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

Em seguida, fica acessível em http://localhost:8000. Em alternativa, qualquer servidor Web estático é, em princípio, suficiente, desde que os requisitos do navegador sejam cumpridos.

Limites atuais

O estado atual concentra-se na navegação e na edição direta. Alguns mecanismos de proteção que seriam úteis para uma utilização mais ampla em produção ainda não estão incluídos:

  • nenhuma validação de sintaxe ou de Ext JS antes de guardar
  • nenhuma formatação automática
  • nenhuma vista de diferenças ou integração com Git
  • nenhuma cópia de segurança automática dos ficheiros alterados
  • nenhuma resolução semântica de controller, viewModel, bind ou reference
  • nenhuma sincronização com ficheiros de projeto do Architect
  • nenhuma interface de IA integrada
  • nenhum suporte para criar, mover ou eliminar ficheiros

Por isso, a ferramenta deve ser utilizada em conjunto com o Git e com o processo de build e testes existente. Em particular, as alterações geradas por IA têm de ser verificadas como qualquer outra alteração de código.

Conclusão

O ExtJS Code Navigator não segue uma abordagem de migração radical. Utiliza deliberadamente aquilo que já funciona nos projetos Ext JS existentes: a conhecida estrutura MVVM, as classes existentes e a build Sencha estabelecida.

A novidade está na forma de trabalhar com esses elementos. Em vez de associar o desenvolvimento ao gerador do Sencha Architect, os ficheiros JavaScript gerados tornam-se uma base de código diretamente editável. Isto permite utilizar ferramentas de desenvolvimento modernas e assistentes de IA sem ter de transferir View, Controller e ViewModel para uma nova estrutura.

O preço a pagar é uma separação clara do fluxo de geração anterior. O Architect continua tecnicamente disponível, mas deixa de poder voltar a gerar os mesmos ficheiros sem controlo. Se este limite for aceite e a base de código JavaScript for declarada como source of truth, um projeto Ext JS existente pode continuar a ser desenvolvido muito mais depressa sem abandonar a sua arquitetura familiar.