Abra a pasta
Escolha a pasta do projeto como a pasta de trabalho de um novo chat e selecione Ask first, para que toda alteração que grava um arquivo aguarde sua decisão. Coloque o arquivo ABI nessa pasta antes de começar.
Fluxos de trabalho
Crie um dApp de uma pasta vazia até uma tela testada
03
Comece com uma pasta de projeto vazia
Para criar um dApp, comece com uma pasta que contenha apenas o arquivo ABI do seu próprio contrato. Abra essa pasta como a pasta de trabalho de um novo chat, selecione Ask first e descreva a página que deseja: um botão para conectar a carteira, um saldo e uma linha de status de transação. O agente mapeia a pasta, propõe os arquivos como diffs e cria a página apenas após você aceitar cada alteração. Decida antes de começar onde o projeto será executado. Uma rede local no seu próprio PC é adequada para uma primeira tentativa, porque as moedas nela não têm valor, e uma rede de teste pública é o próximo passo assim que a página funcionar. Use contas descartáveis em ambos os casos, nunca uma conta que contenha fundos reais, e mantenha todas as chaves privadas e frases semente fora da pasta, do chat e do repositório. O resultado é uma página pequena, testada e um README que outra pessoa poderia seguir.
Descreva a tela
Escreva quais dados a página exibe e quais estados de transação ela deve lidar, em frases simples. Nomeie a função do contrato que ela chama e a rede com a qual ela se comunica, por exemplo, sua rede local.
Revise cada diff
Leia toda alteração de arquivo proposta no chat, depois aceite ou rejeite com uma nota curta. Expanda um cartão quando quiser ver o diff completo e rejeite qualquer coisa que você não possa explicar em uma frase.
Execute e verifique
Deixe o Shell executar seu comando de build e seu comando de teste, e leia o código de saída em cada cartão. Abra a página contra a rede local e compare o que ela mostra com o que você espera. Corrija o que falhar antes de adicionar o próximo recurso.
Um pequeno arquivo ABI para começar
Leia balanceOf na ABI e mostre o resultado na página.
- read_file
balance-abi.jsonloaded - write_file
app.jssaved - edit_file
index.html+4 lines - Shell
your build commandexit 0
aguardando sua aprovação antes da próxima etapaRejeitarAceitar
balance-abi.json
[
{
"type": "function",
"name": "balanceOf",
"stateMutability": "view",
"inputs": [{ "type": "address", "name": "account" }],
"outputs": [{ "type": "uint256" }]
}
]Este fragmento JSON descreve uma função apenas de leitura, balanceOf, a função de leitura de saldo que tokens ERC-20 usam. Ela recebe um endereço chamado account e retorna um uint256. Um front-end usa uma ABI como esta para chamar o contrato, e o arquivo não contém chave nem segredo. Salve-o como balance-abi.json na pasta do projeto e substitua-o pela ABI completa do seu próprio contrato assim que a página funcionar, já que um contrato real geralmente tem muitas outras funções.
Tutoriais para um primeiro dApp
Mapeie a pasta e leia a ABI
Uma boa maneira de começar a aprender web3 é ler um pequeno arquivo ABI antes de escrever qualquer coisa. Peça ao agente para abrir balance-abi.json. read_file mostra o arquivo, list_dir mostra o que mais há na pasta e grep confirma o nome exato da função. O agente então explica no chat que balanceOf é uma função view: ela lê dados e não envia transação, portanto, chamá-la não altera nada na rede. Nada é escrito ainda. Ela também lista o que a página precisará, a saber, uma conexão com um nó, o endereço do contrato implantado e uma conta para consultar. Verifique cada afirmação contra o JSON no cartão, porque um modelo pode interpretar mal um tipo ou nomear uma função que o arquivo não contém, e peça uma correção antes de continuar.
Conecte a página a uma rede local
Peça uma página que leia o saldo de uma conta de teste descartável. write_file cria app.js com uma chamada para sua rede local via JSON-RPC, e edit_file adiciona uma linha de script ao index.html. Você só precisa de ferramentas cross chain para um dApp quando ele se comunica com várias redes; um primeiro projeto em uma única rede local não precisa delas, então deixe-as de fora. No modo Ask first, ambas as alterações aguardam como diffs. Leia-as e aceite-as. O Shell então executa seu comando de build, e o cartão mostra o código de saída real. Abra a página, compare o número que ela mostra com o número que sua rede local relata para a mesma conta e peça ao agente para corrigir a página se os dois diferirem. Mantenha o endereço da rede em um só lugar, para que alterar a rede posteriormente signifique editar uma única linha.
Gerencie os estados de transação
A transição de web2 para web3 como dev significa principalmente adicionar uma carteira, uma rede e um estado de transação às telas que você já sabe construir. Peça ao agente para adicionar uma linha de status com 5 estados: não enviado, aguardando a carteira, pendente, confirmado e falhou. edit_file altera o script e a folha de estilos, e grep encontra qualquer lugar onde um estado ainda esteja faltando. A carteira assina; seu código nunca toca uma chave privada ou uma frase semente. Peça também mensagens para uma carteira faltando, a rede errada e uma assinatura rejeitada, porque um usuário real as encontrará em algum momento. Execute a página em uma rede de teste com uma conta descartável, rejeite uma assinatura propositalmente e verifique se o estado falhado aparece com uma mensagem clara.
Teste, depois documente o projeto
Peça ao agente para escrever um teste de front-end para cada estado e um README curto que explique como executar o projeto. write_file cria ambos os arquivos, o Shell executa seu comando de teste e o cartão relata o código de saída real. Um desenvolvedor de dApp que retorne ao projeto um mês depois lerá esse README primeiro, então verifique se ele nomeia apenas comandos que você realmente usa e se ele diz qual rede a página espera. Use o modo Plan only primeiro se quiser ver a lista de etapas antes que qualquer arquivo seja criado, depois mude para Ask first para executá-la. Leia cada diff, execute os testes você mesmo uma vez em uma rede de teste com contas descartáveis e mantenha o README ao lado do arquivo ABI para que ambos permaneçam sincronizados.
