Aprire la cartella
Scegli la cartella del progetto come cartella di lavoro per una nuova chat e seleziona Ask first, in modo che ogni modifica che scrive un file attenda la tua decisione. Inserisci il file ABI in quella cartella prima di iniziare.
Flussi di lavoro
Creare un dApp da una cartella vuota a una pagina testata
03
Partire da una cartella di progetto vuota
Per creare un dApp, inizia con una cartella che contiene solo il file ABI del tuo contratto. Apri quella cartella come cartella di lavoro per una nuova chat, scegli Ask first e descrivi la pagina che vuoi: un pulsante per connettere il wallet, un saldo e una riga di stato della transazione. L'agente mappa la cartella, propone i file come diff e crea la pagina solo dopo che accetti ogni modifica. Decidi prima di iniziare dove verrà eseguito il progetto. Una chain locale sul tuo PC è adatta per un primo tentativo, perché le monete su di essa non hanno valore, e una rete di test pubblica è il passo successivo una volta che la pagina funziona. Usa account usa e getta su entrambi, mai un account che contiene fondi reali, e tieni ogni chiave privata e frase di recupero fuori dalla cartella, dalla chat e dal repository. Il risultato è una pagina piccola, testata e un README che un'altra persona potrebbe seguire.
Descrivere la schermata
Scrivi quali dati mostra la pagina e quali stati di transazione deve gestire, in frasi semplici. Indica la funzione del contratto che chiama e la rete a cui si connette, ad esempio la tua chain locale.
Rivedere ogni diff
Leggi ogni modifica proposta al file nella chat, poi accettala o rifiutala con una breve nota. Espandi una scheda quando vuoi vedere la diff completa e rifiuta tutto ciò che non puoi spiegare in una frase.
Eseguire e verificare
Fai eseguire a Shell il tuo comando di build e il tuo comando di test, e leggi il codice di uscita su ogni scheda. Apri la pagina contro la chain locale e confronta ciò che mostra con ciò che ti aspetti. Correggi ciò che fallisce prima di aggiungere la funzionalità successiva.
Un piccolo file ABI da cui partire
Leggi balanceOf dall'ABI e mostra il risultato nella pagina.
- read_file
balance-abi.jsoncaricato - write_file
app.jssalvato - edit_file
index.html+4 righe - Shell
your build commandexit 0
in attesa della tua approvazione prima del passaggio successivoRifiutaAccetta
balance-abi.json
[
{
"type": "function",
"name": "balanceOf",
"stateMutability": "view",
"inputs": [{ "type": "address", "name": "account" }],
"outputs": [{ "type": "uint256" }]
}
]Questo frammento JSON descrive una sola funzione di sola lettura, balanceOf, la funzione di lettura del saldo utilizzata dai token ERC-20. Prende un indirizzo chiamato account e restituisce un uint256. Un front-end utilizza un ABI come questo per chiamare il contratto e il file non contiene chiavi né segreti. Salvalo come balance-abi.json nella cartella del progetto e sostituiscilo con l'ABI completo del tuo contratto una volta che la pagina funziona, poiché un contratto reale di solito ha molte altre funzioni.
Guide pratiche per un primo dApp
Mappare la cartella e leggere l'ABI
Un buon modo per iniziare a imparare web3 è leggere un piccolo file ABI prima di scrivere qualsiasi cosa. Chiedi all'agente di aprire balance-abi.json. read_file mostra il file, list_dir mostra cos'altro è nella cartella e grep conferma il nome esatto della funzione. L'agente spiega poi nella chat che balanceOf è una funzione view: legge i dati e non invia transazioni, quindi chiamarla non cambia nulla sulla chain. Nulla viene scritto ancora. Elenca anche ciò di cui avrà bisogno la pagina, ovvero una connessione a un nodo, l'indirizzo del contratto distribuito e un account da cercare. Verifica ogni affermazione contro il JSON sulla scheda, perché un modello potrebbe leggere male un tipo o nominare una funzione che il file non contiene, e chiedi una correzione prima di procedere.
Connettere la pagina a una chain locale
Chiedi una pagina che legga il saldo di un account di test usa e getta. write_file crea app.js con una chiamata alla tua chain locale tramite JSON-RPC, e edit_file aggiunge una riga di script a index.html. Ti servono strumenti cross-chain per un dApp solo quando parla con più chain; un primo progetto su una singola chain locale non ne ha bisogno, quindi lasciali perdere. In modalità Ask first entrambi i cambiamenti attendono come diff. Leggile e accettale. Shell esegue poi il tuo comando di build e la scheda mostra il vero codice di uscita. Apri la pagina, confronta il numero che mostra con il numero che la tua chain locale riporta per lo stesso account e chiedi all'agente di correggere la pagina se i due differiscono. Tieni l'indirizzo della chain in un unico punto, in modo che cambiare rete in futuro significhi modificare una singola riga.
Gestire gli stati delle transazioni
Passare da web2 a web3 come sviluppatore significa principalmente aggiungere un wallet, una rete e uno stato di transazione alle schermate che già sai costruire. Chiedi all'agente di aggiungere una riga di stato con 5 stati: non inviata, in attesa del wallet, in corso, confermata e fallita. edit_file modifica lo script e il foglio di stile, e grep trova qualsiasi punto in cui manca ancora uno stato. Il wallet firma; il tuo codice non tocca mai una chiave privata o una frase di recupero. Chiedi anche messaggi per un wallet mancante, la rete sbagliata e una firma rifiutata, perché un utente reale li incontrerà prima o poi. Esegui la pagina su una rete di test con un account usa e getta, rifiuta una firma apposta e controlla che lo stato fallito appaia con un messaggio chiaro.
Testare, poi documentare il progetto
Chiedi all'agente di scrivere un test front-end per ogni stato e un breve README che spiega come eseguire il progetto. write_file crea entrambi i file, Shell esegue il tuo comando di test e la scheda riporta il vero codice di uscita. Uno sviluppatore dApp che torna al progetto un mese dopo leggerà prima quel README, quindi controlla che indichi solo i comandi che usi effettivamente e che indichi quale rete si aspetta la pagina. Usa la modalità Plan only prima se vuoi vedere l'elenco dei passaggi prima che venga creato qualsiasi file, poi passa a Ask first per eseguirlo. Leggi ogni diff, esegui i test tu stesso una volta su una rete di test con account usa e getta e tieni il README accanto al file ABI in modo che entrambi rimangano sincronizzati.
