AlphaWeft
Przepływy pracy

Stwórz dApp od pustego folderu do przetestowanego ekranu

03
Generowanie projektu

Zacznij od pustego folderu projektu

Aby stworzyć dApp, zacznij od folderu, który zawiera tylko plik ABI Twojego własnego kontraktu. Otwórz ten folder jako folder roboczy nowego czatu, wybierz Ask first i opisz stronę, której chcesz: przycisk łączenia z portfelem, saldo i wiersz statusu transakcji. Agent skanuje folder, proponuje pliki jako różnice (diffs) i tworzy stronę dopiero po Twojej akceptacji każdej zmiany. Zdecyduj przed rozpoczęciem, gdzie będzie działał projekt. Lokalna sieć na Twoim własnym komputerze dobrze sprawdza się jako pierwsze podejście, ponieważ monety na niej nie mają wartości, a publiczna sieć testowa jest kolejnym krokiem, gdy strona już działa. Używaj kont jednorazowych w obu przypadkach, nigdy konta z prawdziwymi środkami, i trzymaj każdy klucz prywatny i frazę seed z dala od folderu, czatu i repozytorium. Wynikiem jest mała, przetestowana strona i plik README, który osoba trzecia mogłaby łatwo odtworzyć.

01

Otwórz folder

Wybierz folder projektu jako folder roboczy nowego czatu i wybierz Ask first, dzięki czemu każda zmiana zapisująca plik będzie czekała na Twoją decyzję. Umieść plik ABI w tym folderze przed rozpoczęciem.

02

Opisz ekran

Napisz, jakie dane strona wyświetla i jakie stany transakcji musi obsługiwać, używając prostych zdań. Wymień funkcję kontraktu, którą wywołuje, oraz sieć, z którą się komunikuje, na przykład Twoją lokalną sieć.

03

Przejrzyj każdą różnicę

Przeczytaj każdą proponowaną zmianę pliku w czacie, a następnie zaakceptuj ją lub odrzuć krótką notatką. Rozwiń kartę, gdy chcesz zobaczyć pełną różnicę, i odrzuć wszystko, czego nie możesz wyjaśnić w jednym zdaniu.

04

Uruchom i sprawdź

Pozwól Shell uruchomić polecenie budowania i polecenie testu, a następnie przeczytaj kod wyjścia na każdej karcie. Otwórz stronę przeciwko lokalnej sieci i porównaj to, co wyświetla, z tym, czego się spodziewasz. Napraw to, co nie działa, zanim dodasz kolejną funkcję.

Mały plik ABI, od którego warto zacząć

balance-abi.json
[
 {
  "type": "function",
  "name": "balanceOf",
  "stateMutability": "view",
  "inputs": [{ "type": "address", "name": "account" }],
  "outputs": [{ "type": "uint256" }]
 }
]

Ten fragment JSON opisuje jedną funkcję tylko do odczytu, balanceOf, funkcję odczytu salda, której używają tokeny ERC-20. Przyjmuje adres o nazwie account i zwraca uint256. Front-end używa ABI w tym stylu do wywoływania kontraktu, a plik nie zawiera klucza ani sekretu. Zapisz go jako balance-abi.json w folderze projektu i zamień go na pełne ABI swojego własnego kontraktu, gdy strona już działa, ponieważ prawdziwy kontrakt zwykle ma znacznie więcej funkcji.

Przewodniki dla pierwszej dApp

Zmapuj folder i odczytaj ABI

Dobrym sposobem na naukę web3 jest odczytanie jednego małego pliku ABI przed napisaniem czegokolwiek. Poproś agenta o otwarcie balance-abi.json. read_file pokazuje plik, list_dir pokazuje, co jeszcze jest w folderze, a grep potwierdza dokładną nazwę funkcji. Agent wyjaśnia następnie w czacie, że balanceOf to funkcja widoku: odczytuje dane i nie wysyła transakcji, więc jej wywołanie nic nie zmienia w łańcuchu. Nic nie jest jeszcze zapisane. Wymienia również, czego będzie potrzebować strona, mianowicie połączenia z węzłem, adresu wdrożonego kontraktu i konta do sprawdzenia. Sprawdź każde stwierdzenie przeciwko JSON na karcie, ponieważ model może źle odczytać typ lub nazwać funkcję, której plik nie zawiera, i poproś o poprawkę, zanim przejdziesz dalej.

Połącz stronę z lokalną siecią

Poproś o stronę, która odczytuje saldo konta testowego jednorazowego. write_file tworzy app.js z wywołaniem do Twojej lokalnej sieci przez JSON-RPC, a edit_file dodaje linię skryptu do index.html. Narzędzia cross-chain potrzebujesz do dApp tylko wtedy, gdy komunikuje się ona z wieloma sieciami; pierwszy projekt na jednej lokalnej sieci ich nie wymaga, więc je pomiń. W trybie Ask first obie zmiany czekają jako różnice (diffs). Przeczytaj je i zaakceptuj je. Shell następnie uruchamia Twoje polecenie budowania, a karta pokazuje rzeczywisty kod wyjścia. Otwórz stronę, porównaj liczbę, którą wyświetla, z liczbą, którą Twoja lokalna sieć raportuje dla tego samego konta, i poproś agenta o naprawę strony, jeśli te dwie się różnią. Trzymaj adres łańcucha w jednym miejscu, więc zmiana sieci później oznacza edycję pojedynczej linii.

Obsłuż stany transakcji

Przejście z web2 do web3 jako deweloper to głównie dodanie portfela, sieci i stanu transakcji do ekranów, które już umiesz budować. Poproś agenta o dodanie linii statusu z 5 stanami: nie wysłano, oczekiwanie na portfel, oczekująca, potwierdzona i nieudana. edit_file zmienia skrypt i arkusz stylów, a grep znajduje każde miejsce, gdzie stan wciąż brakuje. Portfel podpisuje; Twój kod nigdy nie dotyka klucza prywatnego ani frazy seed. Poproś również o komunikaty dla brakującego portfela, złej sieci i odrzuconego podpisu, ponieważ prawdziwy użytkownik spotka się z nimi prędzej czy później. Uruchom stronę na sieci testowej z kontem jednorazowym, celowo odrzuć podpis i sprawdź, czy stan nieudany pojawia się z jasnym komunikatem.

Przetestuj, a następnie udokumentuj projekt

Poproś agenta o napisanie testu front-end dla każdego stanu i krótkiego README, który wyjaśnia, jak uruchomić projekt. write_file tworzy oba pliki, Shell uruchamia Twoje polecenie testu, a karta raportuje rzeczywisty kod wyjścia. Deweloper dApp, który wróci do projektu za miesiąc, najpierw przeczyta ten README, więc sprawdź, czy wymienia tylko polecenia, z których faktycznie korzystasz i czy mówi, jakiej sieci oczekuje strona. Użyj trybu Plan only najpierw, jeśli chcesz zobaczyć listę kroków przed utworzeniem jakiegokolwiek pliku, a następnie przełącz się na Ask first, aby to wykonać. Przeczytaj każdą różnicę, uruchom testy samemu raz na sieci testowej z kontami jednorazowymi i trzymaj README obok pliku ABI, aby oba pozostały w synchronizacji.

AlphaWeft dla systemu Windows

Rozpocznij swój pierwszy folder projektu

Pobierz AlphaWeft ↗