Forem: Geller MIcael

Part 2: Building a Decentralized Exchange with Solidity and React

Geller MIcael — Thu, 09 Jun 2022 05:03:26 +0000

Welcome back frens!

In Part One we got to setting up our base project and our constructor function for the DEX. Today we'll be working on our first token swap function and exploring testing with hardhat.

Here's a live github repo of the project to keep-up with the article and video series.

To understand more about PancakeRouter integration for this project, watch Gabi's breakdown

First Swap Function - $BNB

In our very first function, we'll be allowing the user to send Binance native tokens $BNB to the smart contract for exchange, giving the Router permission to transact the token for the swap, performing the actual token swap and emitting an event which says "Hey! Just swapped my BNB for some select tokens!"

First, we need to declare an event which will be emitted when token swaps are successfully complete…

event SwapTransfer (address from, address to, address tokenIn, address tokenOut, uint256 amountIn, uint256 amountOut);

but why?

Turns out, events are Solidity's way of logging transaction details in smart contracts. Essentially, we declare an event that accepts certain parameters, and then we emit it in a function after a certain transaction has occurred. The event is basically an EVM dispatch signal we can listen to on the client side, with information about whatever transaction triggers it.

Next, we declare our function body,

function swapExactBNBForTokens(uint amountOutMin, address tokenOut) external payable {
}

external? this indicates a function that can only by called by external parties, and not within the same smart contract.

payable? this modifier is used to indicate that a function can transact (receive and send) within a contract.

Inside this function, we'll declare a fixed-size array that holds two addresses. The first address being that of the token we are trading in, and the second address being that of the token we would be receiving in return.

function swapExactBNBForTokens(uint amountOutMin, address tokenOut) external payable {
address[] memory path = new address[](2);
path[0] = pancakeRouter.WETH();  // technically wrappedBNB
path(1) =  tokenOut;   // address of selected token on frontend
}

Next, we approve the Router to transact our token so it can perform the swap. For this, we'll need a dependency, the IERC20 approve() function which allows another contract to transact tokens for a user.

Here's what the IERC20 approval function looks like

approve(address spender, uint265 amount);

Navigate to your terminal and install this dependency

npm install @openzeppelin/contracts

Then import this line at the top of your contract

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";

Back in our function, we'll implement this function using our Router

IERC20(pancakeRouter.WETH()).approve(address(pancakeRouter), msg.value);
// technically wrappedBNB

This line means, the "wrapped" token-$BNB is approving pancakeRouter to transact a user provided amount of tokens . msg.value represents the user inputted amount.

Note: WETH here means wrapped $ETH, but since we're on the Binance Smart Chain, it represents wrapped $BNB, the native token of BSC.
Now we write the swap!

pancakeRouter.swapExactETHForTokens{value: msg.value}(amountOutMin, path, msg.sender, block.timestamp + 60 * 10);

// technically its swapExactBNBForTokens

We call the function in pancakeRouter to swap our exact amount of BNB tokens for any other token we want. Let's examine the interface of this function to understand the parameters it accepts.

function swapExactETHForTokens(
uint amountOutMin,
address[] calldata path,
address to,
uint deadline
) external payable returns (uint[] memory amounts);

the amountOutMin represents the minimum amount of tokens sent back to the user.
the path array holds the addresses of both tokens being swapped.
the address to refers to the destination of the token after it's swapped.
the deadline is a specified time limit in which a transaction fails, to avoid long pending transactions and inaccurate prices.
But holdon! There's a certain piece of syntax lost on us - {value: msg.value}

This represents solidity's way of sending a blockchain's native token to a payable function. Without the payable keyword, this transaction will revert. So this is how we send the user's BNB to the contract.

Moving On…

The next thing we need to do is get the amountsOut from the router, we do so using an internal pancakeRouter function that accepts the user's input, the path array and returns two amounts - the number of tokens sent in and number of tokens sent back to the user.

uint256[] memory amounts = pancakeRouter.getAmountsOut(msg.value, path);

We then log our token swap using the emit keyword and passing arguments to the event we created earlier.

emit SwapTransfer(address(pancakeRouter), msg.sender, pancakeRouter.WETH(), tokenOut, msg.value, amounts[1]);

Marvelous work! We've effectively sent BNB to our contract, approved the contract to transact our tokens, swapped the tokens and logged that transaction from the blockchain!

Your function should look like this now.

Testing our first Function with Hardhat and Moralis

We're ready to test our function and see it in action. So head over to the folder named tests in your project directory and open sample.js. In there, you should find some sample test functions that come by default with a hardhat project.

We'll be changing the file name to TestDexter.js and updating the function descriptions inside the describe block.

...
describe("Dex Testing", () => {

  it("Should accept user's BNB and swap for Cake", async () => { }
}

Next, we'll setup our constants, including parameters for the swap function and then a beforeEach method to deploy the smart contract so we can run the swap function.

For our swap function, recall we need the contract address of both tokens.

*Note - in production, these token addresses are automatically fetched by the DEX after user picks what token they wish to exchange for. But for the purpose of writing tests, we need to provide these addresses ourselves. *

Head over to pancakeswap docs and copy the contract address for the PancakeRouter.

And retrieve the contract address of the $cake token over here.

Once you're done setting up constants, the next line you need is getting a signer with ethers.

const accounts = await ethers.getSigners();

owner = accounts[0]

A Signer in Ethers.js is an object that represents an Ethereum account. It's used to send transactions to contracts and other accounts. Here we're getting a list of the accounts in the node we're connected to, which in this case is Hardhat Network, and only keeping the first/owner account for our test purposes - source is Hardhat documentation on testing

Next, we create a contract factory for any instances of our exchange we need to deploy

const DexterExchangeContract = await ethers.getContractFactory("DexterExchange");

This line basically says, "from our smart contract, generate a factory and store in a variable" - this makes it easy to run tests on instances of the same smart contract.

read up on the factory pattern in OOP to gain more insight.

After creating the factory, we deploy the smart contract with ethers and log the address of the contract to the console.

...

dexterExchange = await DexterExchangeContract.deploy(pancakeRouterAddress); 
await dexterExchange.deployed();
console.log(`dexterExchange deployed at ${dexterExchange.address}`);

For the actual test block,

it("Should accept user's BNB and swap for Cake", async () => {
     const bnb_cake_swap_tx = await dexterExchange.connect(owner).swapExactBNBForTokens
(0, 
cakeTokenAddress,
{value: ethers.utils.parseEther("500")});  
});

This code snippet gets the connect method from our exchange to connect the owner to the contract, then tests the swap function we wrote.

For our function parameters, we will pass in zero as theamountOutMin parameter, pass in the cakeTokenAddress for the tokenOut parameter and pass in the amount of tokens we wish to send to the contract using the utils.parseEther method.

At this point, your entire test file should look like this.

Up Next: Setting up Hardhat Config

Head over to your hardhat.config.js file and replace the existing module.exports object with this

...
module.exports = {
  solidity: "0.8.4",
  networks: {
    hardhat: {
      chainId: 31337,
    },
    localhost: {
      url: "https://localhost:8545",
      chainId: 31337,
    },
  },
};

This sets up our hardhat local chain id and sets up localhost as the destination url for the forked version of the BSC mainnet.

Forking Binance Smartchain Mainnet From Moralis

Next, you want to head to moralis, create an account and head over to the admin dashboard. On the bottom-left side of the dashboard, click on "speedy nodes". This will give you a list of options.

On the Binance Smart Chain, click on the button that says endpoints and it should reveal a list of endpoints.

Copy the url to the "mainnet archive", head back to your project terminal and enter the following command

npx hardhat node --fork "paste mainnet archive url here"

This command will complete a fork of the BSC mainnet and you should see the following result in your terminal.

Congrats! You now have a local running node of the Binance Smart Chain.

Setting up Local Blockchain in Metamask

Now, we get to add our mainnet fork to Metamask so we can view changes in token amounts after running our test swaps.

If you haven't already, head over to the download page and install metamask for your web browser of choice. Once you're done setting installing and setting up a wallet, head over to settings, click on networks and hit add network. This should open up the following page

Enter the following details next...

You might encounter an error here since we entered the values AFTER running the node. To fix this, close your current running node in the terminal and run the command again

npx hardhat node --fork "paste mainnet archive url here"

Then re-enter your chain id in the field and click "save".

Voila! Your own local binance chain is running and recognized by metamask. You should be able to see all your wallet information now with the currency $BNB.

Import a Wallet

To import one of the available free accounts on the BSC localhost fork, right click on the account button in the metamask extension.

head to the terminal in your project and copy the private key from the first account and paste in the 'private key' field.

Running our Tests

Whew! Finally!

To run your test function, type this command into the terminal

npx hardhat test --network localhost

If all's well, this should be your result!

Now head back to your metamask wallet and notice your native BNB balance is no longer 10,000 but now

Wait! Where's the token I swapped for? Where's my CAKE?!!!!!

Well...see, we lied...

Turns out you need to import a token for your wallet to recognize it.

So, on your wallet page, click "import token", head over to coinmarketcap and copy the contract address for the $CAKE token.

Paste it into your import form and it should automatically recognize the token.

Great work! You've officially performed the sexiest token swap in DeFi history, on your own local smart chain. Here's my result!

Tweet us about it!

Rounding up - Next Lesson Preview

Hey! I know this was a much longer lesson but you did amazing, if you have any questions or would simply like to keep up with the series, reach myself or Gabi.

In the next lesson, we'll be writing and testing more swap functions for various types of tokens and discussing advanced solidity patterns. Thanks for joining us!

Part One: Building a Decentralized Exchange with Solidity and React

Geller MIcael — Sun, 05 Jun 2022 20:16:36 +0000

Hello Degens!

Welcome to the birth of a new series, I'm super excited to take you through this marvelous project as we look to up our skills in full-stack web 3 engineering.

This article-tutorial series is built in partnership with Gabi, AKA CleverBlocks on youtube, a Fullstack Engineer at Weave Financial.

The video code content on his channel will be broken down more explicitly via these articles, as we seek to put more emphasis on the more complex topics in smart contract engineering.

Before diving into build mode, let's have a brief overview of what decentralized exchanges are and how they work.

What is a DEX?

A decentralized exchange (DEX) is an automated medium for the user-driven exchange of digital tokens. The term user-driven indicates a lack of intermediaries; meaning, users get to transact directly with each other and can do so without the need of a third-party such as a bank, broker, or other forms of centralized authority.

How does this all work?

Well, DEXes are smart-contract powered; meaning, a piece of code living on the blockchain dictates the rules of these token swaps between users and automates transactions. On the back-end, users can also stake their funds as liquidity - meaning, "Hey, I'll put my funds down as some sort of collateral for transactions, and in return, I earn a % return on these transactions". This entire structure creates a trustless ecosystem where digital assets can be securely and consistently transacted.

A few examples of such exchanges are uniswap, sushiswap, pancakeswap, and apeswap. Each of these platforms runs on native blockchain code and features a large list of compatible tokens for swapping.

As we get deeper in this series, we'll also detail the process of implementing liquidity pools and liquidity tokens, utilizing pancakeswap's Masterchef contract, and more!

At the end of this series, we'll be covering a lot more than simple solidity; this course goes into implementing smart contract inheritance, reentrancy securities, testing with hardhat, forking the mainnet blockchain with moralis, integrating our local blockchain with MetaMask, and writing custom solidity with detailed explanations, patterns, and documentation on every feature we implement!

Ready to get started? Let's get you all set up!

Setting up a local development environment

Head over to an IDE of your choice (I'll be using VSCode, which can be downloaded at "link"), open up a terminal, and type in the following command to initialize a project.

npm init

Following the prompts should generate a package.json file that contains information about your base project. After this, make your way to hardhat.org to get started installing the hardhat suite.

Copy the following command to your terminal

npm install - save-dev hardhat

Next, type in the following to run hardhat locally

npx hardhat

This command should present you with a short list of options, we'll stick with the first "Create a basic sample project" and hit enter.

Following the remaining prompts should get you set up with a gitignore and a project root folder.

Once you're done following the prompts and creating a hardhat project, we can get to importing smart contract dependencies and setting up our contracts folder!

PancakeRouter? Why?

The first dependency we need for our DEX is a Router contract. The router contains the core logic for swapping different token types, adding and removing liquidity , and functions that tell a user how many tokens they receive for their particular input amounts. It essentially acts as an intermediary between the users and other smart contracts.

We'll be writing our function implementations based on the interface for the PancakeRouter and connecting that to the pre-existing PancakeRouter contract on the Binance Smart Chain.

We'll also take a look at some transactions on the Binance Smart Chain to closely examine live examples of swap transactions.

Go ahead and open this link to view the different versions of PancakeRouter available.

For this series, we'll be using v1 and v2 as the base interfaces for our smart contracts. (learn how interfaces work in smart contracts here…)

Next Steps

Copy the contents of the v1 and v2 files and put them into a single file in your local directory named DexRouter.sol

Next, you should create a new file named DexterExchange.sol and import the interfaces in DexRouter.sol…at this point, your project should look like this.

Implementing Our Constructor

Congrats! We've learned a lot today. But before we round up, we'll be putting down a few lines of code and explaining what they do.

Navigate to your DexterExchange.sol and let's create our Router variable. This variable will be initialized to the address of PancakRouter currently active on the Binance Smart Chain. We'll be calling all the internal functions of the router via this variable.

...
import './DexRouter.sol'

contract DexterExchange {

       // declare state variable of type PancakeRouter02 interface
       IPancakeRouter02 public pancakeRouter;

      // the pancakeRouter variable will hold all internal methods of any contract with its      address specified in the constructor 
       constructor(address _pancakeRouter) {
           pancakeRouter = IPancakeRouter02(_pancakeRouter);
       }
}

Nice work! Now when we deploy DexterExchange, we'll pass in the address of pancakeRouter currently active on the Binance Smart Chain and run our Dex transactions with it!

Closing Remarks - Next Lesson Peek

Thanks for joining us today! I truly hope you find this guide helpful for getting started on building a DEX. In the next session, we'll be writing a function to swap BNB for an exact amount of tokens provided by the user.

We'll dive deep into payable functions, the IERC20 dependency, sending tokens to a contract, and granting our pancakeRouter permissions to transact tokens sent to payable functions. We'll also cover testing our first function with hardhat, forking the binance smart chain mainnet with Hardhat, and setting up our local chain with Metamask!

If you're looking to get ahead of the class, check out Gabi's Youtube for more videos on this course.

Catch up with Gabi and Me on Twitter for weekly solidity code review and request to join our dev discord!

What’s the 101? the useState Hook in React

Geller MIcael — Sat, 19 Feb 2022 10:34:31 +0000

My mentor always told me,

“for every new concept you learn, there's three major whys”.

Why does it work this way? why do we have to use it this way? why was it created? And in this junior dev thriller, I’ll be attempting to answer these questions about the useState hook in React.

To understand the purpose of hooks, we need to shed some light on React’s core principle — Rendering efficiency. The major difference between React’s behavior and Vanilla JavaScript is it’s interaction with the browser DOM. React implements a virtual DOM which interfaces with the real DOM tree to ensure an efficient updating process. Check for props and state changes in every component, update the DOM with observed changes, leave unchanged components the same(memoize).

What is the useState Hook?

The react way of storing the application state and updating the view elements. React simplifies storing and managing information about our application via the useState hook. This ensures the state is persisted within the component and updated with each re-render — a behavior we term statefulness!

How do we use it?

We start with destructuring the hook and setting a name for our variable and its setter method. Then we provide a default value to our variable on the right-hand side of the assignment operator.

This immediately gives us access to reading and updating our state via the returned variable and setter method.

How does React opt to reason about it?

“Well, let’s see…I need a way to SAFELY store and update information about my app, make that information local to the component it’s created in, then make sure it triggers a component re-render at the right time”.

React only lets us modify the state variable via a setter method, which ensures state values cannot be randomly reassigned or mutated without the setter method provided at declaration.

let’s take a look…

How was it designed?

To truly understand things, I end up needing to rebuild them myself. Examining the implementation of hooks outside the browser should make better sense of what’s going on under the hood.

Understanding stateful behavior

A core and often unexplained principle in software engineering is “state” and the derivative word “stateful”.

Statefulness refers to storing interactions and using the data in future interactions. Often, we need to implement operations that rely on data from a previous operation; so we store the data in “state” and update it with every new interaction.

In React, we enable this behavior at the component level via the useState hook.

Statefulness also ensures a “protected state”; meaning functions now have internal variables that can only be accessed within them and are “preserved” with every new call to that method. React hooks implements a protected state by providing a setter method as the only access point to the internal state.

In vanilla JavaScript, this behavior is enabled via “closures” (a more advanced topic I won’t be diving into here) — https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures

useState vs normal variable declarations

“why implement a separate way to manage local state? why don’t we just use regular variables like in Vanilla JavaScript? What’s the trade-off?”

In all fairness, we can use regular variable declarations within React, but the general rule of thumb is, “if it directly affects the view layer, hook into statefulness”.

This is because changes to state trigger re-renders in the view components, but changes in regular variables only change locations in memory, meaning relying on regular variables to handle the view-state will result in our application being out of sync.

Another reason is, with each call to the component and resulting re-render, there is an “update” to state — meaning values are “preserved within function calls, while for regular variable declarations, there is a “reset” to the initial value.

here’s an example

Use Cases

“When should I use the useState hook? when do we favor local variables instead? can it be used to implement global state?”

use Case #1 -> Parent-Child props

When passing state as props from parent to child components, we declare the state values in the parent component using the useState hook.

use Case #2 -> Internal Component State

When we need to create state that is bound to specific components in the view, we use the useState hook.

use Case #3 -> Custom Hooks

When we need to create local state variables for custom hooks, we can use the useState hook too!

use Case #4 -> Context Providers

When we need to create state values and pass them into a Global context object, we use a store component with internal useState variables and pass that as the value to the context provider.

use Case #5 -> Lazy Loading

"Load it when I need it!"

A performance optimization concept which lets us initialize expensive pieces of state only when the user is ready to consume it. Lazy-loading can be observed when reading through most news feeds; you notice images and long blocks of text only load-in as you scroll through.

Here's an example of implementing lazy-loading for a counter variable.

use Case #6 -> Grabbing Previous State

A super interesting part of the useState hook is how it gives us access to previous values of state when needing to perform operations on the current state!. We implement this by using a callback within the setter method.

My example will be the famous toggle pattern.

We initialize state to false, then the useState setter method let's us reference that initial value of state within a callback, which we use to determine the next state value. Pretty neat!

Non-use Case -> Accepting Parent props

A general rule of thumb is, when data is derived from props (parent components passing data to children), we use local variables to store said data. The reason is, changes to props from the parent component will trigger re-renders in the child component and state changes also trigger re-renders. We need to avoid unnecessary re-renders and only store data in state when it isn’t reliant on parent components.

I hope this article helped you gain some insights on the workings of the useState hook in React…here’s to curtains on this little deep-dive.

As always, I’m super open to correction and critique so let’s get educative conversations going!``

Feel free to contact me for more delightful conversations about React!

https://twitter.com/elixir_js
via email -> Gellera800@gmail.com
github -> Github.com/Geller99

Continuous improvement and a steady diet of growth

Geller MIcael — Sat, 30 Oct 2021 15:22:21 +0000

Hello Devs,

I'm currently looking to pool opinions and suggestions on an Saas platform I've been building, I'll be linking the repo and twitter channel at the end of this for those who wish to keep in touch.

A year ago, I stumbled across a picture which said, if you grew/learned or added to your knowledge base by one percent every day for a year, you'd make 30%+ progress. Now, even without ever verifying the math, I quickly understood the underlying message. Being good consistently is the ONLY sure fire recipe for greatness.

Following this path, I decided on tracking my growth over a year, making a daily snippet (day snip) and learning in public via my dev twitter (@Elixir_js).

Turns out, I made well over 30% growth in the last year in my field (UI engineering), secured a solid internship and successfully built a freelance client list to boot.

With this theme in mind, and my personal success story; I started building onePercent (twitter @on3Percent). A platform based on repetitive, public accountability.

The primary goal being to solve the problem of procrastination, along with building a public profile for yourself and your journey - a public journal of some sort.

Users contribute to a universal feed by creating daily accounts of what they've learned - each user gets one post a day; listing technology, topic, code snippet and a brief explanation of what they learned that day - accounting for their daily one percent.

The feed is public, other users can like, comment and share(outside) these short snippets or give accountability points.

Beyond solving procrastination, this platform also solves the problem of documentation for people who cannot blog about their experiences or have no affinity for technical writing - giving everyone a chance to be heard and noticed, and held accountable as they grow. Every week, your notes are compiled into a progress node and emailed to you...creating a form of personalized spaced repetition and giving you a sense of progression and achievement going into the next week.

At the moment, we're looking into more features and looking to hire QA engineers, a couple frontend engineers and a product manager to handle new features before official launch.

I'd love to hear your thoughts on this project and if this is something you'd love to add to your daily process(creating daily submissions of what you've learned), or be a part of.

The plan is to go open source in the near future, and make publicized modules for short contract roles to aid junior engineers in gaining paid experience while contributing to a project for the community.

Feel free to ask any questions to gain more insight about the features and suggest anything else you'd like to see added.

read more about continuous improvement here - https://jamesclear.com/continuous-improvement