Going forward, I’ll sometimes refer to the app as airswap-debugger.

Since I started contributing to AirSwap, this was the second major app that I worked on from its inception, and the first web app that I’ve pushed most of the code to GitHub!

airswap-debugger is a web app that helps AirSwap market-makers debug their API connections.

GitHub: https://github.com/airswap/airswap-debugger

App: https://check.airswap.eth.limo/

What is the AirSwap Debugger?

To understand this app, first you must understand what a “maker” is. AirSwap makers are liquidity providers for the trading platform.

Makers run web servers that implement APIs like RFQ and LastLook. To build these APIs, makers provide JSON objects with certain values.

To learn more about makers, RFQ and LastLook, read the official documentation.

airswap-debugger is a web app where AirSwap makers can debug their JSON objects and server URLs. This will be covered in more detail later in this blog post.

Tech Stack

This app is built using TypeScript, JavaScript, React, and TailwindCSS, with blockchain connections facilitated by the viem and wagmi libraries. The app was initialized with Vite.

viem and wagmi provide hooks and functions that make it easy to connect your app to EVM blockchains like Ethereum. For more details on how these libraries work, check out some of my old blog posts like “Creating Seamless Web3 Wallet Connections in Your DApp Using Wagmi Hooks”.

How The Debugger App Works

There are 2 main functions in the app: validateJson and check.

1. validateJson: this is a JavaScript function that uses TypeScript. This checks a user’s JSON input on the front-end of the application. If these validations fail, the check function won’t run.

2. check: this function exists on the AirSwap SwapERC20 smart contract, and requires 11 different inputs to run without errors. This is the function that checks whether or not a JSON is valid.

Validate JSON function

validateJson is a JavaScript function that uses TypeScript to validate the shape and contents of the user’s JSON input. If these validations fail, the check function won’t run.

For non-developers, errors returned by check can be vague if any values are missing. This is why the validateJson was implemented on the front-end app.

validateJson has 3 major checks:

• JSON must be in valid syntax

• Specific JSON key-value pairs are present

• JSON values are in the correct format. For example, some values must be a valid ERC20 addresses. validateJson checks this by using the isAddress function, which is imported into the React component from the viem library

validateJson has several if..else code blocks which run validations. If any part of the JSON is invalid, an error gets pushed into an array called errorsList and returned by the function.

If there are no errors, validateJson returns false. Otherwise it returns a list of errors. We’ll revisit this errorsList variable later in the post.

Check Function

The check function lives on the AirSwap SwapERC20 smart contract. airswap-debugger is just a UI that makes it easier to use this function.

check validates the following inputs:

1. nonce

2. expiry

3. signer wallet

4. signer token

5. signer amount

6. sender token

7. sender amount

8. sender wallet

9. transaction signatures (3 separate values: “v”, “r” and “s”)

The AirSwap protocol collects revenue from trading fees, so it’s critical that makers are able to validate their technical setups.

UI Components

The main React components include: App, Toggle, JsonForm, UrlForm, Errors, Selector and Dialogue. There are some smaller components that aren’t important to go over, for example the header.

App

This is the main entry point of the app. Here’s a breakdown of the different sections of the App component.

Imports:

At the top of the component you’ll see various imports from React, Wagmi, @airswap/libraries, and various hooks and components from other files.

React State Hooks

airswap-debugger utilizes React’s useState hook. Here’s an overview of each state variable:

• inputType: this can either be json or url. Depending on which value it is, different forms will render, and different functions will run.

• jsonString: when a user pastes a JSON, it’s a string that gets saved to this variable. Later on, jsonString gets parsed into a valid JSON object, and stored in a different variable.

• urlString: when a user pastes a server URL into the form, it gets saved into this variable. This variable gets passed as a prop down to the Toggle component, and used in a click handler.

• parsedJson: This variable gets set after a user presses the submit input button. The JSON gets parsed in the native JavaScript function JSON.parse.

• decompressedJson: when a user enters a server URL, the app decompresses it into a JSON object and saves it into this variable. This takes place in the Dialog component.

• swapContractAddress: this variable stores the smart contract address of AirSwap’s SwapERC20 address. We need the correct address so that wagmi is able to call the correct contract functions.

• selectedChainId: if a user selects a chain ID from the selector, it will be stored here. This is different than if a user hard-codes a chain ID into a JSON object. This will be covered in more detail later in the Selector component section.

• errors: this is a list of errors if a JSON or server URL is invalid.

• isEnabledCheck: this is a boolean value that serves as an on/off switch for the check function. It helps prevents the app from rendering outdated data.

• isNoErrors: this is a boolean value that gets set to true if no errors were found. If true, and if isEnabledCheck is also true, a special message will be displayed to the user. If isEnabledCheck is false, then the check function hasn’t yet run. In this case we show the user nothing until they run the debugger.

Custom Hooks

useDecompressedOrderFromUrl: this hook was build to convert a server URL into JSON. The library @airswap/util library has a function called decompressFullOrderERC20. This accepts a server URL string and converts it to human-readable JSON.

useJsonValues: This function takes in a JSON as an object. It parses the JSON, converts each of its vales into the correct format, and returns its individual values in an object. The correct formats are determined by what the check function require.

Smart Contract Interaction:

useContractRead hook from wagmi is utilized 5 times. The first time is in the check function.

The other 4 return values are: protocolFee, domainName, domainChainId, and domainVersion. These values are specific to the deployed SwapERC20 contract. SwapERC20 is deployed on various chains, including Mainnet, BSC, Avalanche, and others. On different chains, domainChainId would change. Upgraded contract versions might have different domainVersion values.

If a user’s JSON object has errors, it’s possible that the JSON is not using the correct value for one of these 4 values. This feedback is returned to the user.

checkFunctionArgs:

This is a list of inputs that we pass into the args property of useContractRead for the check function.

Event Handlers:

There are 2 handlers that control the forms on the app: handleChangeTextAreaJson and handleChangeTextAreaUrl. These function similarly, and get called on each of the textarea HTML elements within the JsonForm, and UrlForm. There’s also the handleSubmit, which will be explained next.

Submit Function (handleSubmit)

Several smaller functions and hooks make up the submit function. The function begins by initializing the following useState hooks to their default values: setParsedJson, setIsEnabledCheck, setErrors, setIsNoErrors.

The following functions make up the handleSubmit function:

validateInputs

This checks for blank inputs. If inputs are blank, handleSubmit returns nothing and ends.

handleJsonSubmission

If input type is json, this function runs and parses a JSON string into valid JSON format. It then sets the parsedJson variable equal to this value. Lastly, it runs the function checkSmartContractError.

checkSmartContractError

This accepts in an argument errorCheck, which gets returned from the check function. This function handles unreadable errors returned from the smart contract, and makes them more human-readable.

handleUrlSubmission

This is similar to handleJsonSubmission, but for server URLs.

validateInputs

This function checks that a user input isn’t blank. Otherwise the smart contract check function won’t run.

useEffect Hook #1

There are 2 useEffect hooks in the App component. Here’s how the first one works:

1. The hook first gets triggered when the parsedJson value changes. Recall that running handleSubmit updates parsedJson.

2. At the start of this useEffect hook, the validateJson function runs. validateJson returns a boolean value. If the value returned is true, there are errors which will get pushed into the errors array.

3. Next, the function getOutputErrorsList runs. This takes in an argument checkFunctionData, which is an array of errors returned from the check function. These errors are unreadable, in hex format. getOutPutErrorsList maps over this array of hex values, then uses the hexToString function, which is imported from viem, to decode the hex formats into human-readable strings.

4. Next in the useEffect hook is the function displayErrors. This parses errors returned from the smart contract, and makes them human-readable. For example, if an error contains 'NonceAlreadyUsed', then displayErrors will switch that into the error message: 'Nonce: the nonce entered is invalid'.

5. Next is the function handleFormattedListErrors. This cleans up any errors returned from the smart contract that have too much blank space. These errors get pushed as strings into the errors array.

6. Lastly, the useEffect hook checks if there are no errors in the errors array. If no errors, the state variable isNoErrors gets set to true.

useEffect Hook #2

This hook checks for a change in chainId, the blockchain network ID. When a change is detected, the function getAddress from the AirSwap SwapERC20 contract gets called, and sets the correct address in the swapContractAddressvariable. swapContractAddress gets passed into the useContractRead hook from wagmi, which is used to call the check smart contract function.

Forms & Toggle

We have 2 forms on the app: jsonForm and urlForm. Each form lives in separate React components. Both forms correspond to the relevant functions mentioned above. The Toggle component contains 2 buttons, which lets you select the form you want to use.

Errors

This component’s purpose is to render errors that are returned from the smart contract, or any of the following functions: validateJson, checkSmartContractErrors, or displayErrors.

The Errors component either displays nothing, a list of errors, or a message that reads “🎊 No errors found! 🎊”.

airswap-debugger is mobile responsive. On tablets and larger screen, there are 2 columns: forms on the left, and Errors on the right. On mobile devices, the UI displays 1 column: forms on top, and Errors on the bottom.

Selector

The selector has several blockchain networks (chain IDs) a user can choose. Users can choose a chainId from the selector, or optionally hard-code it into their JSON objects. If chainId is hard-coded into a JSON, it’ll override the selector option, but not vice-versa.

Building the selector was fun and challenging. Styling a native HTML selector with CSS is more difficult than it looks. For this reason, I ended up using the RadixSelect component from Radix-UI. Radix-UI is easy to use, and is compatible with TailwindCSS!

Dialog Component

dialog is a modern HTML element, and its common use case is for building modals. I built the dialog for when users enter a server URL. The JSON from the decompressed URL gets rendered onto the dialog, as seen in the image above.

Challenges I Faced While Building The AirSwap Debugger

Managing state among React components

As the app grew in complexity, it became hard to manage the errors array state variable. Various functions, hooks, and components update errors, and sometimes I had issues with duplicate values being pushed into the array. Other times the array wasn’t being reset to a blank array when I wanted it to.

These issues happened over the development cycle of the app. At this point I cannot recall every time it happened. To fix these issues, I used console.log a lot.

A common process I use to track down bugs is locate the function that is causing the error. Within that function, I’ll put console.log statements after every line, then hunt down the exact issue. Simple, yet effective!

Error: Buffer: buffer not found

This was an error that came up, and similar ones as well. It was related to Vite not having polyfills. In JavaScript, polyfills are scripts that ensure cross-browser compatibility. Some older browsers may lack support for certain features, and polyfills bridge the gap, allowing newer features to function in these legacy browsers.

To fix this error, I found an npm called vite-plugin-node-polyfills. I added this to my project, and updated my vite.config.js file like so:

export default defineConfig({
  plugins: [
    react(),
    nodePolyfills({
      include: ['path', 'stream', 'util'],
      exclude: ['http'],
      globals: {
        Buffer: true,
        global: true,
        process: true,
      },
      overrides: {
        fs: 'memfs',
      },
      protocolImports: true,
    }),
  ],
});

Designing the UX

Other than small personal projects, this was the first time I designed an entire UX! I took inspiration from existing AirSwap apps, and used similar color schemes and design patterns.

I took into account different screen sizes, and the best way to display data to the user. One example was deciding between displaying the decompressed JSON to the user in a prompt, or a dialog. Prompts are harder to close than dialogs, so I opted for a dialog. The design was more congruent with the rest of the app, and the dialog opens and closes smoothly.

Navigating a project solo, start to finish

Typically I prefer to work with a group. When I originally took on this project, I expected it to be a simple app that would take a week or 2. Instead, it out to be a good 6 week challenge!

The journey of building this app came with a lot of self-doubt. At times I thought that I wouldn’t be able to finish it by myself. Other people would have helped me if I needed, but I wanted to challenge myself and see what I was capable of.

My confidence as a software developer has improved because of this. Building the airswap-debugger app from the ground up is my proudest coding achievement so far.

Conclusion

This blog post is a technical write-up of a debugger app that I built for AirSwap. It’s a DeFi tool to help AirSwap makers debug their servers.

If you’ve read this far, thank you for your time. I wrote this blog post for several reasons:

• Enhance my writing skills

• Build my personal brand, showcase my abilities, and build in public

• Improve my ability to organize thoughts

• Create valuable resources for others

• Establish future sentimental value (it'll be enjoyable reading this post in 5 years)

During the writing process, I reviewed each line of code, allowing me to audit my work and identify areas for improvement.

Now that my thoughts are written down, it’ll be easier to talk about this project in person (ask me about it next time you see me!)

Check out the GitHub repository for a deeper look into the code: https://github.com/airswap/airswap-debugger

Here’s the deployed app. https://check.airswap.eth.limo/

1. Introduction

2. What is Wagmi

3. Component Structure

   1. Main

   2. WalletConnection

   3. WalletConnectionModal

   4. UserAccountDetail

4. Main Config Hooks

5. WalletConnection Component

6. WalletConnectionModal Component

7. Rabby Wallet

8. Conclusion

Introduction

For a Web3 application, a wallet connection is essential. It's the equivalent of a user signing in with a username and password, except using a wallet as a form of identification. By connecting your wallet to an app, you have the ability to sign transactions and interact with the app in a meaningful way.

This blog post will cover how to implement a Web3 wallet connection. It’s how it was implemented on the AirSwap Member Dashboard app.

With this setup, a user clicks the “CONNECT” button, which opens a Modal containing various wallets for a user to chose from. This setup relies on TypeScript, React, and the Wagmi library for Ethereum connections.

What is Wagmi

Wagmi is a collection of React Hooks containing everything you need to start working with Ethereum. It makes it easy to "Connect Wallet," display ENS and balance information, sign messages, interact with contracts, and much more — all with caching, request deduplication, and persistence. You can see more on the official docs: https://wagmi.sh

Component structure

There are 4 major components involved:

1. Main - Code. This is the main React component of the project, but it contains 2 hooks with important configuration data.

2. WalletConnection - Code. This component is responsible for rendering the “CONNECT” button, and contains logic for whether or not to render the Wallet Connection Modal.

3. WalletConnection Modal - Code. This component is responsible rendering a selection of wallets that a user can use to connect to the application.

4. UserAccountDetail - Code. This component it’s mostly for aesthetic purposes. It’s used to render a user’s ENS avatar, and a disconnect button.

Main config hooks

In our main React file, Main.tsx, there are 2 main hooks that we use to set up our configuration, and 1 wrapper that we place around our entire app.

configureChains

The first hook is called configureChains. This allows you to set up specific chains you want your app to use, as well as setting up your RPC providers. There’s also optional functionality in this hook that lets you setup batched multi-calls, but that’s beyond the scope of this blog post.

const { chains, publicClient, webSocketPublicClient } = configureChains(
  [mainnet, goerli, avalanche, bsc, polygon],
  [
    infuraProvider({ apiKey: import.meta.env.VITE_INFURA_API_KEY || "" }),
    publicProvider(),
  ],
);

In the code snippet above, configureChains takes in arguments of an array of chains, and an array of RPC providers. The array of chains includes values like mainnet, goerli, and avalanche. This means that our app will support those chains. The value infuraProvider configures our app to use Infura as an RPC provider.

configureChains returns several values which get passed into the createConfighook.

createConfig

createConfig is a hook where you can setup more options, such as the connectors you want to use. “Connectors” in this context is a technical term for wallets. You can pass in popular options such as MetaMask and Coinbase Wallet. createConfig also allows you to select options such as auto-connect, or to pass in a web socket connection.

const config = createConfig({
  autoConnect: true,
  publicClient,
  webSocketPublicClient,
  queryClient,
  connectors: [
    new MetaMaskConnector({ chains }),
    new InjectedConnector({ chains }),
    new CoinbaseWalletConnector({
      chains,
      options: {
        appName: "AirSwap Member Dashboard",
        appLogoUrl: AirSwapLogo,
      },
    }),
    new WalletConnectConnector({
      chains,
      options: {
        projectId: import.meta.env.VITE_WALLETCONNECT_ID,
      },
    }),
  ],
});

WalletConnection Component

The variable name of this component is WalletConnection. It renders 3 things:

1. A “connect” button when the user isn’t connected. If the user is connected, the button shows the wallet address or ENS name.

2. WalletConnectionModal, which contains is where the user can select a wallet to connect.

{showConnectionModal && (
   <WalletConnectionModal
      setShowConnectionModal={setShowConnectionModal}
   />
)}

showConnectionModal gets set to true when a user clicks the “connect” button, but isn’t yet connected to the app.

1. It renders UserAccountDetail if the user’s wallet is connected. Wagmi has a hook called useAccount, which returns a boolean value isConnected. We can use the variable isConnected to show or hide things in our JSX code.

{isConnected && (
   <UserAccountDetail
      setShowUserAccountDetail={setShowUserAccountDetail}
      showUserAccountDetail={showUserAccountDetail}
   />
)}

**handleShowConnectionModal**

This function gets called when a user isn’t yet connected, clicks the “connect” button, but hasn’t yet connected to a chosen wallet. This function changes the values of showConnectionModal and showUserAccountDetail. These 2 variables control the visibility of WalletConnectionModal and UserAccountDetail, respectively.

const handleShowConnectionModal = () => {
   !isConnected
      ? setShowConnectionModal(true)
      : setShowUserAccountDetail(!showUserAccountDetail);
};

WalletConnectionModal Component

This component will be displayed after a user clicks the “connect” button. It displays various wallets that a user can use to connect to the application.

Within the JSX code of WalletConnectionModal, there’s an unnamed function that loops over an array of connectors. connectors is an array containing all the wallets that users can connect to, such as MetaMask or Coinbase Wallet.

{connectors
   .filter(
      (connector) =>
         connector.ready &&
         // Don't show inject if it's MetaMask (we're already showing it)
         !(connector.id === "injected" && connector.name === "MetaMask"),
      )
      .map((connector: Connector) => {
         const isInjected = connector.id === "injected";
         return (
            <button
               className="flex flex-row items-center rounded border border-gray-800 bg-gray-900 p-4 hover:bg-gray-800 disabled:cursor-not-allowed font-medium",
               )}
               disabled={!connector.ready}
               onClick={() => connect({ connector })}
               key={connector.id}
             >

The primary aspect of the function involves a map function that iterates over the connectors array and renders each one onto its own button.. Within this function there’s extra logic that checks if it’s an “injected” connector. More on injected connectors in the next section.

Rabby Wallet

Rabby is a competing wallet to MetaMask. It has more advanced features such as security warnings, and the ability to import multiple private keys into 1 installation. However, enabling Rabby presented some challenges that I’ll cover below.

What is an Injected Connector?

An injected connector refers to a user's default wallet. It's the wallet that a DApp will use if no other wallet is connected. If you're using Rabby, there's a switch you can toggle that sets it to your injected connector.

If you look again at the code in WalletConnectionModal, you’ll see 3 different things related to the injected connector:

1. A boolean value called injectedIsMetamask, which is a React state variable. This value gets set in a useEffect after checking whether or not Rabby wallet is active. If injectedIsMetaMask is true, Rabby will be shown instead of MetaMask on the connection modal.

2. A useEffect hook checking if the connecting wallet is using Rabby. Here’s the code used for that check:

useEffect(() => {
    const rabbyConnector = connectors.find(
      (connector) => connector.name.toLowerCase() === "rabby wallet",
    );
    if (rabbyConnector && !rabbyConnector.options.getProvider()._isRabby) {
      // Rabby is forwarding to metamask
      setInjectedIsMetaMask(true);
    }
  }, [connectors]);

Note that on the rabbyConnector object, if the getProvider method does not contain _isRabby, then we set the value is injectedIsMetaMask to be true.

1. In the JSX before the map function, we filter through the connectors array before looping over it with the map method. Here, we’re filtering to see if MetaMask is the injected wallet connector. It gets filtered out, because in our main.tsx component, we’re adding in MetaMask to our connectors array in the createConfig hook. (Scroll up the section “Main config hooks” to see that code snippet).

Additional logic in WalletConnectionModal

There’s another useEffect hook in this component:

useEffect(() => {
    isConnected && setShowConnectionModal(false);
    // close modal when WalletConnect or Coinbase modal is open
    pendingConnector && setShowConnectionModal(false);
  }, [isConnected, pendingConnector, setShowConnectionModal]);

This code was added after a small bug was discovered with WalletConnect, Coinbase Wallet, and any other wallet that uses its own modal.

When connecting to WalletConnect, we found that the WalletConnectionModal was overlaying:

The code snippet above fixed this bug, so WalletConnect (and Coinbase Wallet) rendered correctly like so:

UserAccountDetail Component

This component is mostly for aesthetic purposes. There are 2 functional aspects worth mentioning:

1. Disconnect function: This utilizes the Wagmi hook useDisconnect. Here’s the code: const { disconnect } = useDisconnect();. Calling the disconnect function on the button will log out the user.

2. ENS Avatar: this is a nice touch if a user has an ENS name associated with an address. It builds familiarity and trust with the app. Here’s the code:

const { data: ensName } = useEnsName({ address, chainId: 1 });
const { data: avatarUrl } = useEnsAvatar({
   name: ensName,
   chainId: 1,
});

With this code in place, we can use avatarUrl (which is returned from the useEnsAvatar hook, to render a user’s avatar:

Video Demo

https://vimeo.com/877284150?share=copy

Conclusion

In this post we covered a technical explanation of how to implement a Web3 wallet connection using Wagmi hooks and React.

We explored key components such as the Main Config Hooks, Wallet Connection Component, and Wallet Connection Modal, each playing a vital role in creating a seamless and secure user experience within decentralized applications.

This demonstrates the simplicity of the implementation. Let me know if my explanation wasn’t simple enough, or what I can do to improve. Thanks for reading!

App: https://dao.airswap.eth.limo

1. Intro

2. Video Demo

3. Tech stack used

4. The Staking flow - how it works

5. Components and functions used

6. How to build a modal with React

7. Zustand store

8. Wagmi hooks

9. Controlling variables

10. Transaction Tracker

11. Action Buttons

12. Summary

13. Conclusion

Intro

This article is a technical write-up about the token staking feature for the AirSwap Member Dashboard app. The majority of my time working on this app was spent on this feature.

Users can stake tokens into the AirSwap Staking smart contract, which gives them access to voting on proposals, then claim rewards from the AirSwap Pool smart contract. This article will detail the logic on how I built the staking feature.

Video demo

https://vimeo.com/874258804

https://vimeo.com/manage/videos/877284150

Tech stack used

The app is built using React, TypeScript, and TailwindCSS. All smart contract interactions use a library called Wagmi. Here’s a brief overview:

• React is a popular JavaScript library for building user interfaces. Docs.

• TypeScript is a superset of JavaScript that adds static typing to the language. Docs.

• TailwindCSS is a CSS framework that allows you to write CSS classes directly into HTML, or JSX in the case of React. Some love it, some hate. I’m among those who love it. Docs.

• Wagmi: Wagmi is a collection of React hooks that make it simple to interact with Ethereum and EVM blockchains. Docs.

The Staking flow - how it works

If you hold AirSwap Token, (AST), you can use this app to stake your tokens. Here’s the flow of how staking works:

1. Approve: To stake tokens, first you have to approve the AirSwap Staking contract to spend your AST tokens. This is done by calling the approve function, and is a feature in most smart contracts.

2. Stake: After you’ve approved the spending of your token, you can call the stake function. When you stake your tokens, you’ll receive sAST tokens in exchange for locking up your AST tokens in the smart contract. sAST is kind of like an IOU for AST tokens that you receive from the smart contract. It’s an IOU, but your sAST balance is also used to calculate your voting power.

3. Unstake: Calling the unstake function lets you unlock your tokens from the smart contract. Note that when you stake AST tokens, your tokens unlock linearly over time.

Components and functions used

This section covers various components and functions in the Staking feature. Every function won’t be described here, but feel free to view all the code on GitHub if you’re curious.

How to build a modal with React

The Modal component in the app utilizes the HTML dialog element. The dialog element is a modern, elegant way to create a modal. It comes with built-in JavaScript methods, such as showModal and close.

To create a modal, use the JSX tag <dialog />, and pass it a ref. For the ref, we can utilize the useRef hook. useRef is a React hook that persists a value between renders. Since the value persists, it means that our modal can remain open (or closed) when we want it to.

Here’s a code sample of the Modal component:

import { useKeyboardEvent } from "@react-hookz/web";
import { useEffect, useRef } from "react";

export const Modal = ({
  // omitted code
  isClosable = true,
  onCloseRequest,
}: {
  // omitted code
  isClosable?: boolean;
  onCloseRequest: () => void;
}) => {
  const modalRef = useRef<HTMLDialogElement>(null);

  useKeyboardEvent("Escape", () => {
    if (!isClosable) return;
    onCloseRequest && onCloseRequest();
    modalRef.current?.close();
  });

  useEffect(() => {
    if (modalRef.current && !modalRef.current.hasAttribute("open")) {
      modalRef.current.showModal();
    }
  }, [modalRef]);

  return (
    <dialog ref={modalRef} >
    // omitted code
    </dialog>
  );
};

In the code above, first we create a ref object called modalRef, which gets passed into the dialog. We also have a hook called useKeyboardEvent, which gets returned from the react-hookz library. useKeyboardEvent returns a callback function that closes the modal when the user presses the “escape” key.

Note that close is a method which gets called on modalRef. Since the dialog node has a ref of modalRef, the ref object now can access the JavaScript functions that are associated with the HTML dialog element, and pass it along to the dialog.

The useEffect hook checks whether the dialog is open. The Modal component opens when a user clicks on a button in another component, but I’ve omitted that code from this blog post. Opening the Modal component would give it an attribute of open.

Zustand store

Zustand is a lightweight alternative to Redux. We chose Zustand over Redux because the app is relatively small in size. Redux would’ve been overkill for our needs on this app.

We store values in the Zustand store so these values persist across component re-renders and various stages of the staking cycle. It’s possible to use React “prop-drilling” to pass values from parent to children components, but using Zustand produces cleaner code.

Another cool feature of Zustand is that it comes with persist middleware. This middleware makes it easy to “persist” data into local storage. This middleware isn’t used for the staking modal, but some other features in the app utilize it.

Wagmi hooks

In the Staking feature, there are main 4 custom hooks which call Wagmi hooks:

1. useApproveAst.ts - calls smart contract “write” function to approve the spending of AST token

2. useAstAllowance.ts - calls a smart contract “read” function to return the amount of AST tokens held in a connected wallet

3. useStakeAst.ts - calls smart contract “write” function to stake AST

4. useUnstakeSast.ts - calls smart contract “write” function to unstake AST

These hooks are mostly similar, so for brevity I’ll only cover useStakeAst in detail.

Staking hook - useStakeAst

This hook returns a function that users can use to stake tokens. It calls 3 Wagmi hooks:

1. usePrepareContractWrite. This hook prepares an object called config. This object later gets passed into useContractWrite, which is explained below. usePrepareContractWrite accepts several arguments:

   1. Address - the smart contract address of the contract you want to use.

   2. ABI - an interface of the smart contract.

   3. Function - the function on the ABI you want to call. In our case, stake.

   4. Arguments - an optional array of arguments to be passed into the function want to call.

   5. Enabled - an optional boolean value. If false, the function will not run. Using this can optimize the performance of the app. For this purpose, variable called canStake was used. canStake is a boolean value that checks that the transaction type is “stake”, that needsApproval is false, and that the input the user entered is valid.

2. useContractWrite - This hook is used to call smart contract functions. It returns several values that were utilized:

   1. write - this is the function that writes to the blockchain when it gets called. When a user clicks the “stake” button, this “write” function gets called.

   2. data - this object returns data about the transaction after write gets called. It contains useful info such as the transaction hash.

   3. reset- After a transaction completes, the status of the transaction will persist until it changes, or the user refreshes the page. The code will look like this: status === 'success'. Calling reset will reset the transaction status and prevent UX pitfalls.

3. useWaitForTransaction - we use this hook primarily to get the status of a transaction, and its transaction hash.

   • status can either be: “error”, “idle”, “success”, or “loading. These values change during the course of a transaction’s lifetime.

   • data is a return object that contains a transaction hash. We use the transaction has to link users to an etherscan link with their transaction data.

Controlling variables

Several variables used in the main StakingModal component are used to control the flow of certain hooks. For example, the following boolean variables: needsApproval, canStake, and canUnstake. If needsApproval is true, the hook useApproveAst will be enabled, and the hook useStakeAst will be disabled. For canStake to be true, needsApproval must be false.

Here are a few code snippets with explanations below:

const needsApproval =
    txType === TxType.STAKE &&
    Number(astAllowance) < Number(stakingAmountFormatted) * 10 ** 4 &&
    validNumberInput;

const canStake =
  txType === TxType.STAKE && !needsApproval && validNumberInput;

const {
    writeAsync: approveAst,
    data: dataApproveAst,
    reset: resetApproveAst,
    isLoading: approvalAwaitingSignature,
  } = useApproveAst({
    stakingAmountFormatted: Number(stakingAmountFormatted) || 0,
    enabled: needsApproval,
  });

Check if a user can approve tokens or not:

needsApproval is a boolean value with a few checks. The user must toggle the “stake” option, the user’s allowance must be less than the amount they entered to stake, and the number inputted to the form must be valid.

Transaction Type

Let’s look at the following code: txType === TxType.STAKE. The txType variable is stored in the Zustand store. (Code is not shown above). The value of txType changes when you click on the STAKE/UNSTAKE toggle.

TxType is a TypeScript enum with the following shape:

export enum TxType {
  STAKE = "stake",
  UNSTAKE = "unstake",
}

Check if a user can stake or not:

canStake checks that the user has toggled the “stake” option, that needsApproval is false, and that a valid number has been inputted into the staking form.

Loading transaction variable:

const txIsLoading =
  approvalAwaitingSignature ||
  stakeAwaitingSignature ||
  unstakeAwaitingSignature ||
  txStatus === "loading";

This variable is a boolean that changes depending on the current transaction status. This value gets passed into the Modal component as a prop called isClosable. If isClosable is true, the close button in the modal will be disabled.

<Modal
  className="w-full max-w-none xs:max-w-[360px] text-white"
  heading={modalLoadingStateHeadlines}
  isClosable={!txIsLoading}
  onCloseRequest={() => setShowStakingModal(false)}
>

Above is a code snippet that shows the Modal component accepting txIsLoading as a prop for the isClosable variable

We want to disable the close button when a transaction is processing because closing the modal will make a user confused about the status of an active blockchain transaction. It’s bad UX when this happens. Blockchain users usually want a status update on their transaction and will often look at their screen until they see a “success” (or “failed”) confirmation of a completed transaction.

Transaction Tracker

This component was designed to be as generic as possible and to display the current state of transaction data. It’s used for the staking feature, as well as the claims feature (which will not be covered in this post).

The tracker takes in several props, including a transaction hash. This is a hash that gets passed into the Wagmi hook useWaitForTransaction, which returns the status of a transaction. The status is either: idle, loading, successful, or failed. The values of these status variables are used to determine which text and images to display in the transaction tracker. This provides users with feedback on their current stage in the staking and unstaking process.

Action Buttons

The staking modal has 1 main button to handle user actions. These actions include: approve, stake, unstaking. There’s also a toggle where users can switch between staking and unstaking.

actionButtonsObject is a function that takes in 4 arguments and returns an object. The return object takes the shape of ActionButton, which returns button labels and callback functions. 3 of these arguments are functions that were returned from Wagmi hooks.

type ActionButton = {
  afterSuccess: { label: string; callback: () => void };
  afterFailure: { label: string; callback: () => void };
}; 

Here are some examples of how the button would change:

• After successfully calling the “approve” function, the button label will read “Continue”, and clicking on it would call the function resetApproveAst, which resets the status of the function. At this point, the user is permitted to stake tokens.

• After a failed attempt at calling the "approve" function, the button label will read “Try again”, and clicking on it would also call resetApproveAst. The status of the approval function will reset, but the user will still be required to approve token spending before staking is allowed.

The staking modal component also has a function called actionButtonLogic. This checks the status of various staking actions and returns a value based on which staking action is true. The return value of actionButtonLogic gets passed as props into the TransactionTracker component. The value that gets passed into the Transaction Tracker is what the user will see on the button.

The following code snippet shows how the TransactionTracker component is called in the StakingModal component.

<TransactionTracker
  actionButtons={actionButtonLogic()}
  successContent={
    <span>
      You successfully {verb}{" "}
      <span className="text-white">{stakingAmountFormatted} AST</span>
    </span>
  }
  failureContent={"Your transaction has failed"}
  signatureExplainer={
    isApproval
      ? "To stake AST you will first need to approve the token spend."
      : undefined
    }
    txHash={currentTransactionHash}
  />

signatureExplainer is a prop in TransactionTracker. It pops up when a user has initiated a transaction, but has not yet signed the transaction in his or her wallet (for example MetaMask). The explainer is used to tell the user the next steps in the Staking flow.

Summary

Here’s a video demo of the staking flow in action:

https://vimeo.com/874258804

This article covers many of the functions that make up the staking modal, but there are several details I skipped over. Dive into the code on GitHub to see the rest of it. Here’s a high-level recap of how the staking modal works:

• First, a user must approve the smart contract to spend AST tokens. In the StakingModal component, the boolean variable needsApproval checks whether or not a user can approve.

• If needsApproval is true, the custom hook useApproveAst is enabled. Now, when a user clicks the “Approve” button in the TransactionTracker component, useApproveAst returns a callback function that writes the "approve" transaction to the blockchain.

• After successfully approving, needsApproval should be set to false. Now the boolean value canStake determines whether a user can stake tokens or not.

• If canStake is true, the custom hook useStakeAst will return the Wagmi callback function stakeAst (the original function name returned from Wagmi is writeAsync, but I renamed it in the staking Modal component). This process is similar to the token spending approval process, and unstaking tokens is similar to the token staking process.

• useApproveAst, useStakeAst, useUnstakeSast all return objects called data, which contain a transaction hash (or undefined). These hooks also return the status of transactions: "idle", "loading", "success", or "failed".

• These status variables and transaction hashes are passed into the TransactionTracker component, and give users feedback on their transactions.

The AirSwap Member Dashboard has more features than Staking, but I want to keep this blog post specific and won’t go into the other features today.

Conclusion

Developing this Staking feature was one of my most challenging projects. I did countless refactors and put in many hours of work to make sure it came out as expected. I was fortunate to work alongside a more senior developer on this app. The guidance and mentorship were priceless.

Here’s an incomplete list of some of my learning lessons from building this feature:

• It’s almost impossible to refactor code too much. Continuously refactoring code can seem tedious, but in the end, it makes you a more skilled developer.

• Often the cause of bugs is having too much code, rather than too little. If there are bugs that are hard to fix, it can help to remove code until there aren’t any bugs. Once you reach the point of having no bugs, add in code until you can isolate exactly what was causing the original bugs.

• Working with a mentor (or mentee) is priceless. Even if you’re building stuff that works, it’s nice to get other perspectives and hear of ways to improve your code.

• Conducting code reviews for others can enhance your learning by providing insights into their coding structure.

I take pride in the work I've accomplished on this app, and I hope this blog post effectively conveys my enthusiasm during its development. Feel free to explore the app and test the staking feature. If you're interested, drop me a message for some Goerli AST to try it out. While there are areas for optimization, I am open to any feedback you may have

If you’ve read this far, I’d like to thank you for your attention.

GitHub: https://github.com/airswap/airswap-voter-rewards.

Demo: http://dao.airswap.eth.limo.

1. Introduction

2. What is the AirSwap Voter Rewards App?

3. App Features I Developed

4. Mentorship

5. Code Reviews

6. TypeScript

7. Wagmi Library

8. Custom React Components

9. Variable Naming

10. Regressions

11. Launch Day

12. Putting Apps into Production

13. Conclusion

Introduction

In this post, I'll share my experience and the key lessons I learned while building the AirSwap Member Dashboard app. This app provides users with the ability to stake AST tokens, vote on proposals that influence the AirSwap protocol, and claim rewards for participating in votes.

As a core contributor to the frontend development of this application, I'll take you through my journey and the valuable insights gained along the way.

What is the AirSwap Member Dashboard App?

The Main Functionalities of the App Include:

1. Users can stake and unstake AST tokens to the staking smart contract.

2. Users have the ability to vote on proposals that influence the AirSwap protocol.

3. Users can claim rewards from a pool smart contract.

How it Works: When a user stakes AST tokens, their address gains voting rights on proposals. By voting on proposals, you become eligible to claim rewards from a pool once a month. The more tokens a user has staked, the greater their voting power. These rewards are protocol fees that get collected from swaps made on the AirSwap web app.

App Features I Developed

I built the following major features of the app:

• Staking Flow: A set of components where the user can approve, stake, and unstake tokens to the AirSwap staking smart contract. GitHub.

• Wallet connection: The buttons and modals in this feature that allow users to connect and disconnect to the app. GitHub.

There were several other smaller features that I built, such as the accordion component. I won’t go into details about these features in this blog post. However, I plan to write a technical post about how I built the staking modal.

Mentorship

Receiving mentorship was a major benefit for me working on this project. Working alongside the co-founder and another experienced developer was great. I was able to get feedback on my code and ask for guidance when needed.

I was exposed to critical pieces of software development, such as CI/CD. I helped with the CI/CD process by creating a .yaml file with GitHub actions. After changes are merged with the main branch, these GitHub actions automatically run a build, deploying the code to production.

I also learned a lot about caching data in local storage. Caching is a key aspect of frontend development, but it's something that most newer developers probably haven't encountered much.

In this app, we used Zustand, which is a lightweight alternative to Redux. I learned that you can import 'persist,' which is Zustand middleware that saves state changes into local storage. While local storage and caching aren’t exactly the same thing, they share a similar concept.

Code Reviews

Having my code constantly reviewed pushed me to design better solutions. Some of my pull requests (PRs) took weeks to merge due to necessary refactors. These refactors forced me to contemplate the "why" behind my code choices and find more efficient ways of accomplishing tasks.

I asked hundreds of questions, which proved immensely valuable. Mentorship is a two-way street; the mentor benefits from reinforcing their own knowledge and honing their communication skills.

Many new developers may feel hesitant to seek mentorship, fearing they have little to offer in return. This is a misconception. I've had many mentors on my software journey and plan to pay it forward to others someday.

TypeScript

The best way for me to learn is through continuous, repeated exposure to something. While I had been exposed to TypeScript enums and records while working on the AirSwap Web app, the additional practice I gained while working on AirSwap Member Dashboard helped solidify my understanding and finally made it all click.

An enum is a data type with named constant values, ideal for finite options. Before enums, I used type-casted objects. Enums enhance readability and type safety, especially for finite value sets.

In TypeScript, a record defines the structure of an object with specific key-value pairs. Records improve code readability and maintainability compared to type-casted objects.

Here's an example from the repo:

export enum ContractTypes {
  AirSwapToken,
  AirSwapStaking,
  AirSwapPool,
}

type ContractList = { [k in ContractTypes]?: `0x${string}` };

export const contractAddressesByChain: Record<number, ContractList> = {
  1: {
    [ContractTypes.AirSwapToken]: "0x27054b13b1B798B345b591a4d22e6562d47eA75a",
    [ContractTypes.AirSwapStaking]:
      "0x9fc450F9AfE2833Eb44f9A1369Ab3678D3929860",
    [ContractTypes.AirSwapPool]: "0xEEcD248D977Fd4D392915b4AdeF8154BA3aE9c02",
  },
  5: {
    [ContractTypes.AirSwapToken]: "0x1a1ec25DC08e98e5E93F1104B5e5cdD298707d31",
    [ContractTypes.AirSwapStaking]:
      "0x51F372bE64F0612532F28142cECF8F204B272622",
    [ContractTypes.AirSwapPool]: "0xa55CDCe4F6300D57831b2792c45E55a899D8e2a4",
  },
};

This code showcases an enum, ContractTypes, and a record, contractAddressesByChain. Enums define contract types, and the record associates contract addresses with chain IDs. This setup ensures validation and prevents unexpected bugs, a crucial aspect in blockchain applications.

Wagmi Library

Wagmi is a React library of hooks that simplifies EVM blockchain connections. While I had prior experience with this library, working on this app deepened my understanding of its features. Tooling for blockchain connections is becoming increasingly user-friendly.

Although I focused on the frontend, connecting the UI to smart contract functions provided valuable exposure to AirSwap's smart contracts. Reading smart contract functions has been a fantastic way to expand my knowledge of crypto and blockchain.

Variable Naming

Consistent and clear variable names are crucial. Poor naming not only makes it challenging for future contributors but also complicates maintenance for the author. Confusing variable names can lead to unexpected bugs.

This situation arose when I attempted to change the name of a variable that a hook returned. Later, when I used the hook in another part of the code, I had to revert the variable's name back to its original form.

Variable names might seem clear to you when you create them, but if they are not descriptive, they can become a source of confusion later on. Ironically, sometimes I'd ask ChatGPT to review a code snippet, and it would highlight issues with my variable names. I've been making a conscious effort to improve them.

Regressions

In software development, "regression" refers to an undesirable behavior that emerges in an app, which previously worked fine, due to a code update or fix. I hadn't considered this before, but it became evident when we were striving to ensure everything worked correctly for the app's launch. Regressions are particularly common when working under tight deadlines.

Launch Day

Participating in a product launch is a fascinating experience. Users eagerly anticipate a great product, and it's a mix of excitement and mild stress. Fortunately, in our case, it was mostly excitement.

We built this app because AirSwap relied on third-party software for users to stake tokens and claim rewards. When the third-party service announced its shutdown, we had a 65-day deadline to develop and launch our app, bringing this functionality in-house.

Perfection in app development is elusive. In most cases, apps will have some minor cosmetic bugs to address at a minimum. What matters most is that the core features function correctly, and critical bugs are absent. In the lead-up to the launch, we worked diligently to test the core features and ensure that everything operated as intended.

We met the deadline, shipping an MVP of the app, and the community's initial response was overwhelmingly positive!

Putting Apps into Production

Apps in production often reveal overlooked bugs from the development phase. This was also the case with the Member Dashboard app, but fortunately, these issues were manageable. User feedback is invaluable in identifying areas for improvement and addressing any lingering bugs.

Conclusion

These are just some of the lessons I learned while working on the AirSwap Member Dashboard app. Collaborating closely with an experienced developer provided me with insights that are challenging to encapsulate in a single blog post. Witnessing how he built features and organized code felt like completing an entire university course.

Now that the app is live, it's in maintenance mode. I take pride in having my name associated with this product and will continue working on it as a maintainer.

My time at AirSwap over the past five months has been a highlight of my professional journey, and I look forward to building more exciting products in the future!

App: https://dao.airswap.eth.limo/.

Here’s the GitHub: https://github.com/airswap/airswap-voter-rewards.

What is Radix-UI?

Radix-UI is an open-source library boasting ready-to-use components. These components are functional out-of-the-box but come unstyled, allowing for greater design flexibility. Radix effectively handles the underlying JavaScript, freeing you to focus on styling. If you’re without design guidelines, Radix's documentation provides some style suggestions.

You can install the Radix-UI accordion into your project with:

npm install @radix-ui/react-accordion
# or
yarn add @radix-ui/react-accordion

The documentation has many more components you can use.

Radix Accordion Component

Start by importing the Accordion:

import * as Accordion from '@radix-ui/react-accordion';

The Accordion has various segments, including Root, Item, Header, Trigger, and Content. For an in-depth understanding of these, refer to the Radix-UI Radix-UI documentation.

The Accordion supports numerous props for enhanced control. A notable one is the type prop, which allows selections of either "single" or "multiple", determining if one or multiple accordion items can be open simultaneously. For a comprehensive list of props, the Radix-UI docs have you covered. Below is my implementation of the component, with a brief explanation thereafter::

import * as RadixAccordion from '@radix-ui/react-accordion';
import { ReactNode, useState } from "react";
import { MdChevronRight } from "react-icons/md";

interface AccordionProps {
  rootStyles: string;
  type?: "single" | "multiple";
  itemId: string;
  trigger: ReactNode;
  content: ReactNode;
}

export const Accordion = ({
  rootStyles,
  type = "multiple",
  itemId,
  trigger,
  content,
}: AccordionProps) => {
const [isAccordionOpen, setIsAccordionOpen] = useState<boolean>(false);
const toggleAccordion = () => setIsAccordionOpen((isAccordionOpen) => !isAccordionOpen);

return (
    <RadixAccordion.Root className={rootStyles} type={type}>
      <RadixAccordion.Item value={itemId} className="flex flex-col overflow-hidden">
        <RadixAccordion.Header>
          <div className="flex border p-2">
            {trigger}
            <RadixAccordion.Trigger />
              <div onClick={toggleAccordion}>
                  {!isAccordionOpen ? (
                    <MdChevronRight size={32} className="rotate-90 transition-transform duration-150"
                  />
                ) : (
                  <MdChevronRight size={32} className="-rotate-90 transition-transform duration-150"
                  />
                )}
              </div>
            </RadixAccordion.Trigger>  
          </div>
        </RadixAccordion.Header>
        <RadixAccordion.Content>{content}</RadixAccordion.Content>
      </RadixAccordion.Item>
    </RadixAccordion.Root>
  );
};

Breaking Down the Code:

TypeScript Types (AccordionProps):

This interface encapsulates a set of props, catering to scenarios where the Accordion component might be invoked multiple times with varied data.

• rootStyles: Directs styling for the Root component, accepting TailwindCSS classes.

• type: Specifies if the accordion operates in “single” or “multiple” mode.

• itemId: A unique identifier for the Item.

• trigger: It's positioned outside of the <RadixAccordion.Trigger /> to ensure only the MdChevronRight icon, when clicked, initiates the accordion's action.

• content: A ReactNode type defining the content within <RadixAccordion.Content> nodes.

Arrow Icon Behavior

Clicking the arrow icon (MdChevronRight) toggles the accordion's state. The isAccordionOpen state starts as false, with the accordion defaulting to a closed position.

Design Philosophy

The Accordion is intentionally kept versatile, with trigger and content props as ReactNode, facilitating potential reuse. Avoiding excessive inline styling makes the component more maintainable.

Conclusion

My experience with Radix-UI was enlightening, and I foresee further engagements. While I've worked with component libraries like Chakra-UI that offer pre-styled components, the customization process can be daunting, especially with specific brand guidelines in play.

Feel free to share your thoughts or questions regarding my Accordion component implementation below!

GitHub: https://github.com/airswap/airswap-voter-rewards/blob/main/src/features/common/Accordion.tsx.

My introduction to AirSwap dates back to 2017 during the ICO boom. The project's resilience and its part in the Consensys ecosystem piqued my interest. Encouraged by AirSwap's open-source philosophy, I considered contributing to its growth.

As a software enthusiast, my path led me to front-end development. The allure of instant feedback and the real-time reflection of JavaScript code sparked my interest in this field. For this reason, I joined as a front-end developer.

Understanding AirSwap

AirSwap's primary product is a decentralized exchange (DEX) allowing for peer-to-peer swaps. Its unique model circumvents common issues such as slippage and front-running, typically associated with fully on-chain exchanges like UniSwap. The platform's ability to facilitate trades against institutional market makers adds to its appeal. Recently, AirSwap also launched a white-labelled NFT marketplace.

Why AirSwap?

Before AirSwap, I was with RaidGuild, building apps in startup type of environments. Seeking a new challenge on a larger scale led me to AirSwap. With a substantial user base, a robust treasury, and a stimulating community, AirSwap became my chosen destination.

Acclimating to AirSwap

Exploring the Codebase of AirSwap

Comprehending AirSwap's extensive codebase was an initial hurdle. A week of rigorous code perusal helped me understand the structure of its components. The process involved meticulous code scrutiny, peer consultations, and leveraging tools like ChatGPT and StackOverflow. Also diving deep into its documentations and reading its smart contract code was important for understanding what was happening.

The New Feature: Network Selector

Web3's interoperability, enabling apps to function across different blockchains, gives users the power to choose their preferred blockchain. Given that AirSwap's smart contracts are written in Solidity, they can be deployed on any EVM-compatible chain.

Multiple Chains, One Selector

The ChainSelectionPopover and ChainSelector components are the feature's core. The ChainSelector button reveals a popover listing user-selectable chains.

Here are key code snippets and explanations illustrating the feature's core functionality:

import addEthereumChain from "../../../helpers/addEthereumChain";
import switchToChain from "../../../helpers/switchToChain";

const addAndSwitchToEthereumChain = async (chainId: number) => {
  const chainNotAddedCode = 4902;

  await switchToChain(chainId).catch((error: any) => {
    if (error.code === chainNotAddedCode) {
      addEthereumChain(chainId);
    }
  });
};

export default addAndSwitchToEthereumChain;

addAndSwitchToEthereumChain function: This function is designed to either switch the user to a specified chain or, if the chain hasn't been added to their MetaMask wallet, add it. If the chain switch fails with a specific error code (indicating the chain hasn't been added), it triggers the addition of the chain.

import { CHAIN_PARAMS } from "../constants/supportedNetworks";

// https://eips.ethereum.org/EIPS/eip-3085

const addEthereumChain = (chainId: number): Promise<null> => {
  return window.ethereum.request({
    method: "wallet_addEthereumChain",
    params: [
      {
        chainId: `0x${CHAIN_PARAMS[chainId].chainId.toString(16)}`,
        rpcUrls: CHAIN_PARAMS[chainId].rpcUrls,
        chainName: CHAIN_PARAMS[chainId].chainName,
      },
    ],
  });
};

export default addEthereumChain;

addEthereumChain function: This function adds a specified chain to the user's MetaMask wallet. The function uses the wallet_addEthereumChain method from the Ethereum Provider API to add the chain and requires parameters such as chainId, rpcUrls, and chainName. These details are fetched from CHAIN_PARAMS constant, which presumably contains all the necessary information about the supported networks.

import nativeCurrency from "../

constants/nativeCurrency";

const switchToChain = (chainId = 1): Promise<null> => {
  return window.ethereum.request({
    method: "wallet_switchEthereumChain",
    params: [
      {
        chainId: `0x${nativeCurrency[chainId].chainId.toString(16)}`,
      },
    ],
  });
};

export default switchToChain;

switchToChain function: This function switches the currently active chain in the MetaMask wallet to a specified chain. The function uses the wallet_switchEthereumChain method from the Ethereum Provider API to switch chains. The chainId parameter is used to specify which chain to switch to.

Styling the Network Selector

AirSwap employs React Styled-Components for styling. These are CSS-in-JS tools that enable traditional CSS writing in JavaScript files. In our codebase, these Styled-Components are imported into other components, creating a structured, maintainable, and reusable styling scheme. This modular architecture enhances code maintainability and improves the development workflow.

Making the Feature Mobile Responsive

Ensuring mobile responsiveness is critical in today's digital age. AirSwap follows a "mobile-first" design approach, which means we design for the smallest screen first, then progressively enhance the design for larger screens.

To ensure mobile responsiveness, we used CSS breakpoints. These are points where a website's content responds to provide the user with the best possible layout. By using CSS breakpoints, we managed to define different styles for different devices according to their screen size. This ensured that our new feature looked good and functioned correctly across all devices, maintaining the usability and overall aesthetic.

Conclusion

Contributing to AirSwap has been a profoundly educational journey into the realm of decentralized finance (DeFi). The opportunity to delve into its documentation and smart contracts has provided me with invaluable insights and learning experiences.

While my contributions thus far have focused primarily on front-end development, I'm enthusiastic about expanding my role as I enhance my Solidity skills. The prospect of contributing to smart contract work excites me, as it opens a new avenue of impact and learning.

One aspect of open-source work that truly appeals to me is its transparency. Having my contributions publicly displayed, and my name now associated with the AirSwap project, is a source of pride and motivation.

Looking forward, my excitement to contribute to AirSwap goes beyond its core DEX product. I anticipate lending my skills and efforts to further enhance the platform, fostering innovation, and bolstering user experiences across the board. The journey thus far has been enriching, and I am enthusiastic about the opportunities that lie ahead.

This article is not a tutorial. It's my thoughts and notes about my experience building an app that wraps and unwraps Ether. The app is called WrapETH.

What is WrapETH?

WrapETH is an app that allows you to wrap and unwrap ETH, (or another EVM chain's native asset). The current app version supports 7 different blockchains. The app is a front-end that communicates with the Wrapped Ether smart contract.

The Wrapped Ether (WETH) smart contract is decentralized code that exists on the Ethereum blockchain. It's not owned, or even affiliate with WrapETH the app. Other EVM chains also have a smart contract to wrap its native asset. For example, Polygon has WMATIC (Wrapped Matic). The WMATIC smart contract is a fork of the original WETH contract.

Funds are never in the custody of WrapETH. The app is only a front-end that calls functions on the smart contracts. The only 2 functions called are deposit and withdraw. You can view the code in the "contract" tab, and see what other functions are built into the contract.

Replacing Web3Modal with RainbowKit and WAGMI

My first major task was to replace Web3Modal with RainbowKit. Web3Modal is a JavaScript library that lets you connect apps to the blockchain. It makes it easy to connect your wallet to an app. It's makes developers' lives easier.

RainbowKit is similar to Web3Modal, but with a better UX for both users and developers. You can easily add in support for new EVM chains and various wallets. The "Connect Wallet" modal comes pre-built and styled, and you can customize it as desired.

What Are WAGMI Hooks?

"WAGMI makes it easy to "Connect Wallet," display ENS and balance information, sign messages, interact with contracts, and much more — all with caching, request deduplication, and persistence." (from the docs).

It's a library of pre-made hooks that uses Ethers.js under the hood. Ethers.js is a JavaScript library that lets you connect to the Ethereum blockchain. It has more features that you knew existed. WAGMI is an abstraction of Ethers.js.

An example of a WAGMI hook is useAccount. This returns an object that has details like the connected address, as well as boolean values such as isConnected.

Another useful hook is useBalance. The gets data about the connected wallet's account balance. It has a boolean property called watch, which updates the connected balance at every new block.

This hook saved me from writing many extra lines of code.

Another set of hooks I used were usePrepareContractWrite, useContractWrite and useWaitForTransaction. If you want to call "read" and "write" functions on a contract, the WAGMI docs suggest using these hooks together.

usePrepareContractWrite is used to prepare an instance of a smart contract. It returns an object that has a key called config. config can get passed into the useContractWrite hook, which is used to call smart contract functions that were extracted from usePrepareContractWrite.

useWaitForTransaction extracts data from useContractWrite and returns various data such as a hash of a successful transaction.

Implementing these hooks was challenging. I've only scratched the surface of what WAGMI hooks can do. Check out the WAGMI docs to learn more.

Refactoring Code And Building Custom Hooks

It was my first time using the WAGMI library. To get used to the hooks, I first placed everything into the main app component in my Next.js directory. This quickly became messy.

I tried prop drilling to pass hooks to child components of app, but this quickly becme messy, and introduced bugs to my code. I also tried calling hooks within a useEffect hook, but learned that you cannot nest hooks within other React hooks.

Like magic, refactoring all WAGMI hooks into custom hooks, within a /hooks directory, helped fix many of my bugs. Placing hooks into their own files made my code more readable and easier to maintain.

The idea of build custom React hooks used to intimidate me, but hooks are simple. Basically hooks are functions with the word use at the start of its name.

Replacing Formik With React-Hook-Form

This was my second major task of the project. It was also the most challenging for me. React-Hook-Form is a JavaScript library that helps manage forms, form state and validations.

React-form-hook has some funky syntax, but the documentation is well written and has good video explanations.

The form on WrapETH only has 1 input, but it takes in a monetary value that gets sent to a smart contract. When money is involved, it's critical that strict validations are in place. A bug in the front-end can cause an unexpected loss of funds.

People will track you down and send hate mail if they lose money in your app.

Integrating React-Hook-Form with Raid Guild Design System

Raid Guild has a Design System, which is built with Storybook and custom Chakra UI style components. Each design component aligns with the branding aesthetic that Raid Guild has in place.

My tasks were to upgrade some of the existing components and to create new ones. Chakra UI comes with pre-made React components, but it's also highly customizable.

One of my major challenges was setting up the NumberInput component, and integrating it with react-hook-form with it.

NumberInput takes in a spread of props from react-hook-form. If you're not used to Chakra, it can be confusing to figure out the correct syntax. After lots of practice and frustration, I eventually figured it out.

I received lots of help on this task. Since finishing the WrapETH project, I've been working on another project and still creating custom Chakra UI components. After more practice, I feel confident going back to Raid Guild Design-System and creating new components with less trouble.

Passing numeric values smart contracts

Another challenge I faced was passing data from the form to the usePrepareContractWrite WAGMI hook. The numeric value of Ether that users pass into the form get passed into this hook. If using JavaScript, passing numerical data to EVM blockchains is complicated.

Ethereum processes numbers in units of wei, (1 Ether is equal to 10^18 wei (source). Due to limitations that JavaScript has on integers, you need to use BigNumer to correctly pass numerical values to Ethereum smart contracts.

Figuring out the correct conversions took a bit of tinkering, but eventually I figured it out.

Other UX improvements

An important part of front-end development is giving users feedback when they perform an action. For example, if you click "submit", you probably want confirmation that the form was actually submitted

Feedback especially matters when money is involved. Your heart will skip a beat if you transfer funds, but don't get confirmation that the transaction actually gets sent.

With this in mind, I added a "toast" feature that alerts a user after a transaction has been initiated, and completed.

Chakra UI has a built in hook that triggers a toast. I changed its style on Raid Guild's Design System, and added the toast to WrapETH.

Here's how I implemented the toast hook:

A toast gets fired off in the following scenarios:

• pending deposit

• pending withdrawal

• successful deposit

• successful withdrawal

There are custom hooks in the app called useDeposit and useWithdraw. Within these hooks, I added the WAGMI hooks useContractWrite and useWaitForTransaction.

useContractWrite is used to write transactions to a contract. The WAGMI docs recommend using it with usePrepareContractWrite. This prepares an instance of a contract and takes in parameters such as address and abi.

After a transaction has been initiated with useContractWrite, you can use built-in logic to determine if the transaction is pending or not. The hook returns a function called onSuccess; this gets invoked when the hook fetches data.

Within the custon useDeposit hook, when onSuccess gets called, the useCustomToast hook from Design-System will be invoked. useCustomToast displays the alert you see in the upper right corner of the following image:

Similar logic is used within the useWaitForTransaction hook. This waits for a transaction to be processed, then returns an onSuccess function. onSuccess displays the "success" toast seen above.

TypeScript

This was my first time using TypeScript. It took me a while to get used to the syntax, but with practice I got the hang of it. This project was a great opportunity to "learn by doing." I prefer this to following tutorials nonstop.

At first I didn't know how to fix type errors, so I'd set the type to be any. This can work to troubleshoot unrelated problems, but it negates the benefits of using TypeScript in the first place.

As I got more experience with TypeScript, it grew to like it more. It seems useful for maintaining code, especially as your codebase grows, and more people contribute.

Since finishing the WrapETH project, I've continued using TypeScript in other apps. With more practice, it'll become second nature.

Local Environment Issues

Most new developers don’t think about their development environments. If you're new to tech, you likely don't even know what an environment is. I didn't.

Towards the end of this project, random package manager issues appeared. These were major blockers. I didn’t even know where begin troubleshooting. Thanks to a mentor, I was able to get help troubleshooting these issues. (More on mentors later in this post).

I cannot remember all of the bugs I fixed, but here are some of my notes:

Make sure to work on the same Node version as the most recent version of the app.

The first iteration of WrapETH was build using Node version 16.15. I was using Node version 18. Using different versions lead to bugs that were hard to troubleshoot. This can best avoided by… using different versions of Node.

Node Version Manager (NVM) solves this.

With NVM, you can run multiple versions of Node in separate terminals. For example, if you're building a new project, “Project A, ”you might want to run Node version 18. If you’re simultaneously working on “Project B,” you might want Node version 16. Without NVM, it’ll be a pain to manage different versions.

Check that your Path is setup correctly.

Path ($PATH) is a list of directories that your system uses, to search for anything that you type on the command line. I cannot explain this topic deeply because I don't fully understand it yet.

After troubleshooting bugs that were related to my dependency tree, it was determined that deleting and reinstalling my OS was a logical next step.

How'd I even get into this mess?

When I first started learning software development, I followed many YouTube tutorials. Often I’d install things that altered my path, and I didn’t know why. Often times these changes didn't solve my issues. This lead to a Path file so confusing, Satoshi Nakamoto wouldn't even make sense of it.

Reinstalling Mac OS fixed many of the dependency issues I was facing. This helped me understanding some of the reasons why many developers use a virtual machine for their projects. You can change your virtual machine environment in isolation from your regular computer's setup.

After reinstalling everything, I followed this guide ”Setting Up a New MacBook for JavaScript Development which worked well.

Git issues

Merge conflicts and other git issues are a pain point for me (and most developers).

Another person and I sometimes worked on the same branch. This caused merge conflicts. Git gave feedback that I needed to rebase. I botched some of the rebases, but I managed to work around it by switching between branches and copy pasting. This got messy and wasn't ideal.

The person who mentored me through this project recommended I try Git Tower, a visual tool for git. In the future I might write about this tool after using it more.

Git Stash

Before working on WrapETH I've never used git stash. Sometimes Git recommends this command if you're trying to commit changes, but your branch isn't up to date with the latest changes.

git stash saves the current version of your working branch. You can later apply your changes from the stash onto whatever branch you'd like.

Pro-tip (for git newbies): Name your stashes with the command: git stash save 'name-stash'. Naming a stash isn't required, but if you have too many stashes saved, you’ll get confused.

I learned that VS Code has a tab on the left side called 'Source Control'. This has visual helpers such as: commits, branches, remotes, stashes and more.

If you click the 'STASHES' dropdown, you'll see your stashes. Right clicking on a stash will give you several options, for example 'apply stash'.

My Apprenticeship At Raid Guild

This project was part of my apprenticeship at Raid Guild. Before becoming a full member of the DAO, you must be an apprentice first. The purpose of the apprenticeship is to gauge skill level, and alignment with other members. Once a full member, you can vote on proposals that affect the direction of the DAO.

To learn about my earlier experience at Raid Guild, read my article: "My Experience as a Raid Guild Apprentice".

The apprenticeship has certain terms on it. For example, the apprenticeship must last a minimum of 60 days before becoming a full member, as well as complete a project.

One of the most valuable parts my apprenticeship experience is receiving mentorship. This has lowered my learning curve. Having access to a mentor is a time saver because you can ask for help when you’re stuck. I ask a lot of questions, but I'm always working to balance asking for help, vs. struggling to find a solution by myself.

The Benefits Of Mentorship:

Mentorship is a use case for DAOs. I encourage all beginner (and all level) developers to join a DAO for this reason. Mentorship is a 2 way street. The mentee learns faster, and the mentor gains a better understand by explaining to someone else.

Raid Guild is a strong network of talented people who are on the cutting-edge of Web3. Learn more about Raid Guild here.

Conclusion

Working on WrapETH was both challenging and a great learning experience. I got practice reading documentation, implementing new libraries and building interesting tools.

By using many different libraries for the first time, I realized that many libraries are similar; it's all JavaScript. If you understand data types and data structures, you can figure out most libraries.

WrapETH currently supports these networks: Ethereum mainnet, Gnosis (XDAI), Polygon, Arbitrum, Optimism, Goerli and Sepolia testnets.

There are no fees (other than network fees), so try it out next time you need to wrap and unwrap ETH. I've used it several times on Ethereum mainnet, which was the most rewarding part of the experience.

WrapETH GitHub.

“If you want to go fast, go alone. If you want to go far, go together...”

My journey as a software developer started about 15 months ago. Coming from a non-technical background in marketing, I didn't know many engineers.

Knowing the right people won't make you smarter, but they can point you in the right direction and you'll learn more efficiently. Having a strong network of people is half the battle to success.

In January, 2022 I started a 15 week software engineering program at Flatiron School. My goal was to eventually work for a blockchain project, or to start my own.

During my bootcamp, I met somebody who worked at Consensys. His advice for me, to break into web3, was to join a DAO and contribute to open source projects. He recommended joining Raid Guild as a place to start.

When I completed the engineering bootcamp, I filled out an application for an apprenticeship at Raid Guild. A couple months later I got an email from the Guild.

Who am I?

I've been interested in crypto and blockchain for years. Starting out, I only speculated on prices. Eventually I became interested in how crypto actually works, so I began reading documentation such as the Bitcoin white paper and "Mastering Ethereum."

I understood that learning tech would give me a huge advantage in life. I didn't have much of a technical background growing up, but I was determined to learn as much as I could about crypto.

In 2021 I began learning how to code. My end goal was to break into the blockchain industry and become a professional in the space. I purchased a Solidity course on Udemy and got started.

Most Solidity tutorials I watched had a section about React. I didn't understand JavaScript, so I felt confused. This lead me down a rabbit hole into learning front-end development. In hindsight, I could have continued without knowing any JavaScript.

During this time, my main focus in life was rock climbing and mountaineering. An overuse injury in my elbow forced me to take time off from climbing. Sitting at home with nothing to do, I began spending all of my time learning JavaScript.

Unexpectedly, I actually enjoyed writing code. Coding also seemed to give my life a new sense of fulfillment outside of climbing. During this time, the voice inside my head was telling me that that I was the type of person who could succeed at this type of work.

After studying JavaScript for months and building an app (a simple game of blackjack built with vanilla JS), I decided to take a software engineering bootcamp. I chose a bootcamp that had a full-stack developer curriculum that focused on JavaScript, React, Ruby and Ruby on Rails.

Taking a bootcamp is a great way to lower your learning curve, but you can learn the same content from YouTube if you're motivated enough.

After I completed the bootcamp, I joined a few hackathons (organized by ETH Global) and focused on improving my front-end development skills. I felt prepared to work for a DAO after the hackathons.

What is a DAO?

Taken from Ethereum.org:

"DAOs" are decentralized autonomous organizations. These groups leverage Ethereum technology to facilitate organization and collaboration. For instance, for controlling membership, voting on proposals, or managing pooled assets. While DAOs are still experimental, they offer opportunities for you to find groups that you identify with, find collaborators, and grow your impact on the Ethereum community

Typically DAOs don't have a physical location (with exceptions like Empire DAO). Communication mostly happens on Discord. There’s no official boss or CEO and people can come and go as they wish. The more work you put into a DAO, the more you get back.

Most DAOs will require you to own shares, or assets such as a tokens or an NFT to gain access. This is analogous to owning shares in a company. In theory, by owning an asset related to the DAO, holders of these assets should feel incentivized to contribute their own resources (labor) to improve the organization.

Other DAOs worth exploring:

Some DAOs create open-source software that can be used as public or common goods. Public goods might also include tools that the DAO has created for its own use. For example, a staking contract for humans seeking membership in an organization.

Some other DAOs worth exploring are Developer DAO, dOrg, YAPDAO, Moloch DAO, MakerDAO and Yearn Finance. Each of these DAOs serve a different purpose, but some of them have overlap.

Developer DAO is like a social club where developers and non-developers work together on open source projects. It’s a great place to meet like-minded people and expand your network.

YAPDAO is another service DAO that focuses on non-technical work for DeFi projects, such as marketing and communication. YAPDAO is a friendly fork of Raid Guild.

Both MakerDAO and Yearn Finance are DeFi projects that are also DAOs. If you own tokens for these projects, you have the right to vote with your tokens. For example, if a new proposal is made about a major change in the direction of the project, you have the right to vote on the decision.

In theory this allows anybody who feels passionately about these projects to have a voice in how the project should move forward. If you disagree with the direction a project is going, you can sell your tokens and remove yourself from the governance process, or ragequit.

The first DAO was formed in 2016 and had a catastrophic failure (which resulted in millions of dollars getting hacked). Onboarding new members to a DAO is one of the biggest problems that people are working to solve.

My experience with Raid Guild

Today marks the start of my 4th week as an apprentice. DAO’s are still a new concept and are evolving rapidly. My experience will likely be vastly different from yours, if you decide to become a Raid Guild apprentice.

The onboarding experience

My journey with Raid Guild started by filling out an application here: https://www.raidguild.org/join. A month or 2 later I was contacted about an upcoming cohort.

During the first week of the apprenticeship, we met over voice calls in the Discord. We introduced ourselves, our backgrounds and interests in web3 (and beyond web3). We were filled in on what to expect by joining a DAO. It was mostly educational and focused on team building.

In the second week it was time to start working on projects. By this point, about half of the original cohort had dropped out and fell victim to Moloch (the demon God of human coordination failure). Many of us worked together on an existing open-source project called “Rite of Moloch.” It was an internal Raid Guild project that had been started, but not yet completed.

For the apprenticeship, the purpose of this project was to give us a taste of what to expect if we became full Raid Guild members. It also gave us a chance to see how well we worked together as a team. It was up to us to figure out what still needed to be built, with minimal guidance.

In a DAO there’s no boss. Nobody assigns you work, so it’s up to you to take ownership of a task and make sure you complete what you said you will.

Another major task during the second week was for all cohort members to acquire the DAO’s native token, $RAID, and stake it into the Rite of Moloch smart contract. The purpose of staking tokens was to show commitment to the process, but also to form a sub-DAO for the cohort. This novel idea was taken from the Moloch DAO framework.

Requiring cohort members to stake tokens into a smart contract gives a sense of commitment and ownership towards the DAO. At least it does for me.

My technical experience with Raid Guild:

Working on the “Rite of Moloch” project was a fun learning experience. My contributions were mostly with front-end development. The UI was built mostly with Next.js, Chakra UI and Ethers.js.

My biggest contribution so far has been creating a new route on Next.js called deploy-cohort. I built a controlled form with React, styled it with Chakra UI components, and built a function that uses Ethers.js to connect to the blockchain.

This feature is a template that allows anybody to create their own DAO and customize its settings. After the cohort has been deployed and people stake their tokens into the contract, they’ll receive a soul bound token.

Education:

One of the most valuable parts of being in a DAO is that you can ask other people for help. There’s a high chance that somebody with more experience can point you in the right direction.

Sometimes people will generously give a technical lecture to anybody who wants to listen. I was able to attend a smart contract developer walking us through a contract, and a product designer teaching us the basics of UX design.

Benefits I’ve gained during my apprenticeship at Raid Guild

I’ve already covered some of these, but here’s a list of benefits that come to mind by joining a DAO:

• Learn about crypto and web3 by working on cutting-edge projects

• Grow your network and build connections with industry veterans. Some people in the DAO have been working in the space for years. Having access to these people is priceless, especially if you're new to the space

• Improve your developer skills by contributing to open-source projects

• Make friends. We usually talk about work-related topics, but we also have a good time

• If you’re transitioning to a new career in software development, joining a DAO is an easy “foot in the door.” Working for a DAO is challenging, but getting in is easy because you don’t need to send in a resume and have formal interviews. As a recent web2 bootcamp graduate with no professional background in tech, all I can say is that it’s VERY difficult to go from zero-to-one and get your first job in tech. Joining a DAO is a hack which lowers your barrier to entry, if you want professional experience

• On the topic of starting a new career in tech: you will probably make little or no money working for a DAO at the start. This should not be an issue if you’re job-seeking. My bootcamp at Flatiron School gave me access to a career coach for 6 months from my graduation date. My coach has even advised me to work an unpaid internship or apprenticeship as a means to get experience. My experience as an apprentice at Raid Guild is something I’ve highlighted on my resume.

• Free technical education. So far I’ve attended technical discussions about Solidity and UX design. Someday I’d like to give back and lead my own technical discussion

• Joining a DAO is somewhat of an entrepreneurial pursuit. It’s for self-starters who have clear goals and don’t need external motivation to get things done. This is not a good path for everyone, but it might be perfect for you?

• Improve at non-technical skills. Web3 needs people skilled in project management, technical writing, accounting and more. In fact, I received some feedback from DAO members before publishing this article!

My future plans with Raid Guild

My primary plan is to continue slaying Moloch

So far I’ve been enjoying my time with the guild. I plan to continue contributing where I can, whether it’s code for an open source project, or writing articles like this (which is essentially marketing for Raid Guild and for myself). As my software developer skills improve, I plan to join official “Raids”, where I’ll get paid for my work. I also plan to get a full time job working in web3, while simultaneously giving value back to the Guild, which has already given me so much.

My next project is another hackathon. It's not directly for the DAO, but I formed a team with people that I met here and we'll be representing Raid Guild at the hackathon.

Conclusion

Joining a DAO is great way to learn about web3 and gain professional-level experience. It takes time and dedication to be successful within a DAO, but you’ll reap great rewards for your efforts.

Raid Guild stands out from other DAO’s because of the cohort experience onboarding process. Most people who go through the cohort process feel a sense of ownership, pride and camaraderie. You’ll improve your skills as a developer, (or whatever skills you contribute) and build new connections within the web3 industry.

If you’re looking to break into a new career in tech, this is one of the best paths you can take. Improve your skills and make a positive impact on the world.

If you're interested in joining Raid Guild, read more about it on https://www.raidguild.org/.