VisualEditor pt BR

Editor visual (VS Code)

🌐 Esta página em: English · Português

Uma extensão de primeira parte para o VS Code que transforma o SDK num ambiente de desenvolvimento visual: uma tela renderiza ao lado do arquivo que a produz, a partir do buffer que você está digitando, e cada elemento renderizado sabe qual expressão C# o construiu.

O preview é o realizador web real rodando o módulo compilado real. Não é um sósia, e é esse o ponto: um preview que renderiza é prova de que a página renderiza. Nada novo desenha pixels.

Estado. O host de design e o mecanismo de identidade já saem e têm testes. A extensão em si está no começo — ela é construída a partir do código, não instalada pelo Marketplace, e só o preview e a identidade por span de código estão prontos. Editar pela tela vem depois. O Track E no Roadmap tem os marcos.

O host de design

Desde 0.2.0-preview.30

eqdesign é um processo de vida longa que segura a compilação Roslyn do projeto e compila o buffer do editor — não o arquivo em disco. Essa distinção é a razão inteira de ele existir: o eqc lê arquivos e o serviço de hot reload observa o sistema de arquivos, então nenhum dos dois consegue te mostrar o texto que você está olhando agora, só o que você salvou por último.

Ele fala JSON delimitado por linha sobre stdio. Nenhuma porta para escolher, nada para autorizar, nada sobrando escutando se a janela morrer, e funciona igual sobre Remote-SSH porque o host da extensão roda na máquina remota de qualquer forma.

Medido no samples/DefaultUIDashboard (16 arquivos de código, 316 referências):

Passo	Tempo
Montar a compilação, uma vez na ativação	271 ms
Compilar uma edição (PaymentsPage, 662 linhas, quente)	p50 293 ms
Só diagnósticos (bind, sem transpilar)	36 ms

Daí as duas cadências: os erros são reconferidos depois de 150 ms de pausa na digitação, o preview recompila depois de 400 ms. Um erro de C# interrompe a compilação antes de qualquer emissão — o Roslyn analisa de forma tolerante, então uma chave faltando ainda produz uma árvore que o transpilador percorreria, gerando um módulo que monta e lança, o que chega na tela como um quadro em branco sem nada que explique.

O host se recusa a iniciar se a lista de referências estiver vazia, em vez de compilar contra um modelo incompleto. Essa falha é invisível de outro jeito: sem o modelo semântico, argumentos nomeados são emitidos na ordem sintática, e a tela renderiza com os valores nos lugares errados e nenhum erro em canto nenhum.

Modo de design: um nó lembra do C# que o construiu

Desde 0.2.0-preview.30

VisualNode carrega um Origin — o span de código da expressão que o construiu, ou null, que é o que todo build publicado é. Uma compilação em modo de design preenche isso:

var compiler = new ComponentCompiler { DesignMode = true };
// Toda construção de nó é emitida envolvida, então o nó construído lembra de onde veio:
//   $eq.origin(UI.text(…), "…/PaymentsPage.cs|28:12|28:73")

Os dois realizadores levam isso para o DOM como data-eq-origin, anexado no despacho único de cada um:

<div data-eq-origin="/src/Screens/PaymentsPage.cs|27:8|34:10">
  <span data-eq-origin="/src/Screens/PaymentsPage.cs|28:12|28:73">Count: 0</span>
</div>

O formato é caminho|linhaInicial:colunaInicial|linhaFinal:colunaFinal, base zero — as coordenadas do próprio editor.

Por que não source maps. A resposta óbvia não funciona. O corpo inteiro do Build é convertido numa única string achatada e emitido por uma só chamada, então a posição mais fina que um mapa V3 consegue nomear é o início do método: um módulo publicado tem uma linha de 942 caracteres. Um origin é exato — e por ser uma string simples no nó abstrato, o track nativo (Photon) herda o mesmo mecanismo no dia em que quiser.

Só construções são carimbadas, nunca referências. Carimbar uma variável onde ela é apenas mencionada sobrescreveria o origin da construção com o span de um uso, e selecionaria a linha errada. Um nó construído dentro de um foreach carrega o span da única expressão que o constrói — que é a única coisa editável ali, de qualquer forma.

O modo de design fica desligado por padrão e nunca ligado num build do SDK: o envoltório é código emitido de verdade, e publicá-lo colocaria a preocupação de uma ferramenta de design no bundle de todo mundo. Um render de produção não contém nenhum data-eq-origin, e o teste de fingerprint de SSR/hidratação garante isso.

Rodando hoje

A extensão é construída a partir do código e aponta para o host de design no mesmo checkout:

cd extensions/vscode && npm install && npm run compile

Depois abra uma página ou componente C# e rode eQuantic UI: Open Preview. O projeto precisa ter sido construído uma vez — o preview se apoia na saída de um build comum (a lista de referências que o SDK escreve, e o wwwroot/_equantic/runtime.js), então "construa o projeto uma vez" é a instrução honesta quando falta alguma peça.

O que ainda não faz

• Não edita pela tela. Seleção e inspeção vêm primeiro; escrever propriedades de volta e a paleta de componentes são as fases seguintes.
• Sem preview nativo. A identidade já está resolvida no Photon (LayoutNode carrega o nó, os limites absolutos e um caminho estável); falta só levar os quadros para dentro de um webview.
• Sem chamadas a [ServerAction]. Os ids das ações vêm de uma varredura de assembly na inicialização, então uma classe de preview improvisada nunca está no registro.
• O tema baseline. Um app escolhe o tema dele na inicialização, e ler isso de volta significa rodar a raiz de composição do app. Formas e layout são exatos; uma paleta rebrandeada ainda não aparece.

Veja também

• Depuração — o logger e o overlay de erro que o preview reaproveita.
• Compilador — como o C# vira o módulo que o preview roda.
• Roadmap — o Track E e o que vem antes dele.