Z-institues Web3 前端開發實戰-第四週技術筆記

Web3 前端實戰開發課程-第四週複習筆記

React 專案初始化

React 初始化
npx create-react-app my-app --template typescript

React + Next.js
npx create-next-app@latest --ts
or
yarn create next-app --typescript

React + Rainbow Kit
npm init @rainbow-me/rainbowkit@latest
or
yarn create @rainbow-me/rainbowkit@latest
or
pnpm create @rainbow-me/rainbowkit@latest

建立快速的 project，兩個好用服務

Codesendbox
有虛擬機的概念，直接建立一個新的 VM，可以直接建立各式各樣模板，例如：React, Next.js…
可以直接在 Dependencies 上直接輸入直接安裝 npm package
在左側的 GitHub 標籤，可以直接傳到 GitHub 上建立一個 Repo
Gitpod
可以直接連接 GitHub 的 Repo 之後直接建立一個 VM 去 Run 他，
編輯界面是一個線上的 VS code 環境，還可以執行終端機跑 Linux 指令。
如果前端加上合約的 Repo 是整合在一起的話，那要做線上測試就可以使用 GitPod 環境，否則就是建立一個 VM 然後從本地端連上去做測試。
npm run dev 或是 run start, GitPod 會自動將那虛擬機的 port 轉接的自己的機器上面去。

Ethers.js & Web3.js

基本上是很相似的東西，後來語法上大家比較偏好 ethers.js，包括後來 React 裡面的RainbowKit，RainbowKit 的底層就是去綁 ethers.js 去連接區塊鏈資料跟連接錢包跟執行錢包(perform action)的動作。
長期在用的底層套件還是往 ethers.js，雖然兩者功能一樣，但 ethers.js 的開法者跟範例都比較多。

開發專案或產品時建議使用整合好的環境

例如：Next.js + ethers.js，點開連結在 GitHub 上按下鍵盤上. 可以直接開啟 vs code 的 preview 模式。
因為已經串接好底層連接錢包的相關功能，在後續更改會比較快。

還有RainbowKit

RainbowKit 算是目前連上各種錢包跟相關功能最好用的工具。

RainbowKit 是屬於純前端的，如果要新增相關 Contract 的功能，有幾個不同的策略，其中一種範例：Mango Market UI
Maongo Market 原為區塊鏈上的 Defi 交易所，他本身就有開源他用的 Contract 和 UI，如果對這種比較大型的系統可以看 Mango 的東西
Mango 原始碼
已經將不同結構拆開，分別：

mongo-v3 contract
mongo-client-v3 (銜接資料跟 API)
mongo-ui-v3

大型專案適合這樣分離度高的作法，小一點的專案則是可以混在一起。

簡單看一下 mongo-ui-v3

Next.js 是 React 的 framework
將 router 的東西都處理完了，直接在 page 建立一個 newName.tsx 的檔案，他就會自動把./page/newName.tsx 的 route 建立出來就不用再處理 react-route 相關的東西，這是比較偏 Front-End 的部分
但像是在 stores 的資料夾，他會將資料層的部分抽離出來，他就是管理資料的中介狀態，傳統上的 store 有兩種方式：
有點像 redux 的方式來做管理，他會把所有資料層都收攏在一起，再去廣播這些變動
另一種 dapp 的模式請往下看。
那在區塊鏈這邊，會看到一個實踐方式，就是他把資料的部分抽成 hooks，那在區塊鏈上要 pull 資料或是 pull API 其實是滿非同步的，如果包成 hooks 的方式，再將這個 react 的屬性匯出到上一層來做使用會是一個比較好的方法。

例如：useFees 裡面就會負責把所有跟 Fees 相關的東西抓到，然後變成一個 reactive 的屬性，自動渲染，然後前端渲染的時候，就 export makerFee 是多少，takeFee 是多少…
然後透過 command + shift + f 來搜尋 object 的名稱，可以找到在 Component 裡的 MarketFee.tsx 引入了 useFees()，初始化這個 react 的屬性，有點像是每個 hooks 都是一個小的 store，但也更容易去分辨用途。
再來是串接到 Contract 的部分，有些 hooks 還會跟串接 Contract 再分開，可能會單獨整理出 function 再來去做串接（Ethers, RainbowKit…），在由 hooks 去做引用。
最後再去串上區塊鏈的資料
結構分析 1. UI 層只做事覺化呈現 2. 在資料 / API 層，要想到在包裝完後，假設我用 useFees，我就只能取到 fee，而不要去想要怎麼串接 Contract，而這些 API 可能會定時去呼叫 Hooks 然後去更新資料，在回應資料給 UI。 3. 串接 contract 的部分，則是直接去想我在鏈上取得資料玩後的處理跟包裝成 React 的一個 function，再用 Hooks 去做處理。

較小型專案建議模式

假設用 Hardhat，你是前端的 project 想要把 front-end 的 code 跟合約相關的 code 全部放在一起，也是有這種 template，在做小 project 會比較好用。
Scaffold-eth 算是滿典型的範例。
Scaffold-eth，本身就有 hardhat 的工具在裡頭，他會直接 initial 一個 front-end 資料夾，裡面裝了 next.js or vite。
裝在一起有一個好處，會比直接管理或是串接要到抽象化那麼多層來的方便一些，但是檔案管理上就比較沒有那麼乾淨，如果是在大型的 project 就會相對混亂。
在範例中，可以看到 hardhat 資料夾中直接把 contract 放進去，或是裡面一些測試用的 code，都會放在 hardhat 這資料夾內
假設這些都是在同一個 Repo 裡面，hardhat 編譯完合約後會自動產生 ABI，通常我們就會直接將這些 ABI，直接放到外層資料夾，當你的 front-end 是在同個資料夾裡面時，就可以直接去引用這個 hardhat 編譯出來的 ABI，所以等於説在同一個專案裡面就可以同時去跑完 contract 的測試，然後去做一些相關的串接，譬如：中間要接 ABI 或引用合約的時候，都可以直接去 hardhat 的資料夾，把編譯完的資料直接丟到外層的 abi 資料夾去做引用，這樣就等於不用分兩邊更新，可以全部都弄在一起。
一樣會用 hooks 的方式去把 ABI 引進來，然後在 Hooks 裡面把一些基礎的邏輯處理掉，包括他的串接、Connection…。

Wagmi 跟 RainbowKit

Wagmi 也是一個不錯的 React 相關的 hooks，專們是給 Ethereum 用的，他等於也是給 Ethers 用的一個語法糖，它包括的語法糖就比 RainbowKit 多一些

RainbowKit 主要還是在處理 Connect Wallet 這部分。
Wagmi 的話，他主要是幫你把相關的其他的東西都包起來，譬如說，useAccount, useConnect, useDisconnect…
如果 RainbowKit 只處理到 Provider 的部分，那 Wagmi 這邊就直接幫你把一些 Address, isConnected, disConnect, …甚至其他東西都包好成 function 會比較好使用。
算是包裝的比較好，Doc 也寫得比較完整的其中一個，在 Doc 中可以看到很多相關範例，在做一些操作的時候就不需要用 ethers 去做互動，比 ethers 在稍微方便一點點。

想了解 Ether 底層運作的，可以去找 Ether.js 的相關範例，之後的部分就會以 Wagmi or RainbowKit 稍微再包裝過一層的東西來去做示範跟做 project 會比較快。

邊撸鐵健身邊學Code的Dhal