As web3 applications scale in size and complexity, the chain that supports these apps must scale as well. The early years of Ethereum were mostly dominated by ERC-20 contracts, but the new rise in popularity of NFTs drew in a good amount of attention from the market. Because of this, new standards like the ERC-721 and the recent ERC-1155 developed, each with different properties. 

Today, I will show you the differences between each ERC standard and the benefits to using a specific one.

## What actually are ERCs?

ERC officially stands for "Ethereum Request for Comment." They are guidelines that all Ethereum based tokens (built through smart contracts) must follow if using a specific standard. We will be talking an in depth look into the ERC-20, ERC-721, and the ERC-1155 standards.

## The ERC-20 Token

The ERC-20 standard was first originally proposed by developers Fabian Vogelsteller and Vitalik Buterin as an EIP (Ethereum Improvement Proposal) in 2015 and was eventually implemented into the Ethereum blockchain in 2017. Some popular tokens that follow the ERC-20 standard are Chainlink (LINK), Enjin Coin (ENJ), and Aave (AAVE).

ERC-20 smart contracts can hold upwards to millions of tokens that can be created and distributed to owners. An owner can have multiple tokens and each token have the same value, making them interchangeable. Usually, there is a fixed number of tokens in supply to avoid inflating the value of the token.

ERC-20 tokens are **fungible** tokens; fungibility is the idea that 2 different ERC-20 tokens can be of the same value or worth. These tokens allow users to interact with each other (by trading them) run various decentralized applications (dApps), decentralized finance (DeFi), decentralized autonomous organizations (DAOs), and much more.

## The ERC-721 Token

Just like its cousin ERC-20, ERC-721 was also introduced as an EIP in 2017 by Dieter Shirley and was implemented into the chain in 2018. Some popular NFT collections that follow the ERC-721 standard are the [Bored Ape Yacht Club](https://opensea.io/collection/boredapeyachtclub), [CryptoPunks](https://opensea.io/collection/cryptopunks), and [Crypto Kitties](https://opensea.io/collection/cryptokitties).

> If you want to buy an NFT, I highly recommend going to [OpenSea](https://opensea.io/) or [Rarible](https://rarible.com/); they are 2 of the most popular NFT Marketplaces to date

The main difference between an ERC-721 token and an ERC-20 token is that ERC-721 tokens are **unique**; each token has its own specific metadata. One ERC-721 token can't replace another because they have different properties. This uniqueness also shows the rarity of each token, which is factor in determining its worth and how much the token will sell for.

The individuality of each token is why ERC-721 became the golden standard for NFTs (Non-Fungible Tokens); the whole reason why NFTs are non-fungible is because one NFT can't be replaced with another.

## The ERC-1155 Token

The ERC-1155 standard was actually developed by Enjin Games in 2019, and it's basically a middle ground between the ERC-20 and ERC-721 tokens. 

ERC-1155 tokens can be both fungible and non-fungible; a contract that uses this standard has tokens that you can think of as their own contracts, and each one of those contracts has a supply that is distributed. This new idea of having fungible and non-fungible items has become extremely popular in the blockchain gaming industry.

ERC-1155s can also do something called **batch transfers**, which is sending multiple assets (fungible or non-fungible) in one transaction. These types of transactions significantly reduce traffic on the Ethereum network, which helps decrease gas prices on chain. 

For example, if a player in a game wanted to sell all their leather armor to another player, they can use the ERC-1155's batch transfer feature to send all the assets they want to sell in one transaction.

**Safe transaction rules** are another new addition to the ERC-1155 standard. If that player accidentally sold their diamond armor instead of their leather armor, the transaction can be reverted, and the assets can be returned back to the sender. This and other safety features help prevent exploiting any potential bugs in an ERC-1155 contract.

## Making These Contracts

Now that we have talked about the different types of contracts, you are probably wondering how to make these types of contracts. My answer to that is [Thirdweb](https://thirdweb.com/). They have amazing SDKs, pre-built contracts, documentation, and guides that will help build you build amazing smart contracts for your web3 dApps.

<hr />

***Thank you so much for reading! Signing off 👋***

This is an in depth look at the different ERC standards on the Ethereum Blockchain.

A Primer on the Different ERC Standards

It has been almost 2 years since I started my journey as a developer, and today, I just want to reflect on all the things I've done and learned over that period of time.

## Starting Out

The first time I was exposed to computer science was when I was in my middle school computer science class. Although I didn't pay much attention in class, the entire coding phenomenon was quite interesting to me at the time. 

The following year, I decided to take AP Computer Science Principles, and that decision literally changed the course of my entire life. Part of the final exam in that class is a programming project, and although it was language agnostic, my teacher taught us Python using CMU CS Academy. 

I wasn't a particular fan of CMU's graphics library, so I decided to search up "python tutorial" on YouTube, and what ensued afterwards was me being sucked into a hole many call ***tutorial hell***.

## My First Programming Project

Throughout most of the time I took AP CSP, I went through Tech With Tim's Python programming tutorials, specifically the ones relating to the pygame module. This allowed me to build my first programming project using Python: a guessing game!

Although it wasn't much, building the project was quite the fun and difficult process. Through that project and really the entire AP CSP course, I realized that I could legitimately create an entire career out of this. After what I now call a monumental moment, I went all in into this amazing field.

## From Python to Web Development

After working with Python and pygame for a while, it soon occurred to me that creating terminal apps is something I don't want to do; I want to build something I can show off to everyone. To do this, I started learning basic HTML and CSS on this amazing place called [freeCodeCamp](https://www.freecodecamp.org/) by taking their now legacy Responsive Web Design course.
 
Learning how to build an actual website was really exciting for me; so exciting that I jumped off in the middle of the course to start learning the language I use almost every day now: JavaScript. I learned JavaScript through many YouTube tutorials from channels like [Web Dev Simplified](https://www.youtube.com/c/WebDevSimplified), [Clever Programmer](https://www.youtube.com/c/CleverProgrammer), and again, [freeCodeCamp](https://www.youtube.com/c/Freecodecamp).

Looking back, learning all HTML, CSS, and JavaScript concurrently was a really bad idea because I didn't really learn that much; consuming tutorials non-stop didn't actually help me learn that much.  I now know that I was at that time enjoying my stay at **tutorial hell**.  

> If you are going to learn a new technology, stick to it! That'll help you learn that technology better.

## How I Changed My Learning Style

Being in tutorial hell sucked a lot, and I didn't even know that I was in it at that time. The way I got out of tutorial hell was **building projects**. Now I don't mean clicking out of all those tutorials, opening up a new VS Code window, and start trying to build a new social media app; start small, then work your way up.

I first started looking at and doing project-based tutorials (I recommend [Sonny Sangha](https://www.youtube.com/c/SonnySangha) and [JavaScript Mastery](https://www.youtube.com/c/JavascriptMastery) for web dev project videos). Now you may think this isn't any different from consuming any regular web dev tutorial, but here is the difference; you need to **build new things on top of these projects**. Just blindly following the tutorial didn't do me any good, and it certainly won't do you any good; building new features for the app is something that can get you accustomed to the developing experience.

For example, if you are watching a video or reading an article on how to mint an NFT collection, you could try and add dynamically created NFT images on mint instead of using the existing assets the author of said video or article provides. This allows you to not only have a finished product (in this case, the NFT collection), but also learn something new (in this case, using dynamic image metadata to mint the NFT).

## The Developer Mindset and My Reflection

Being a developer is way more difficult than I thought it would've been when I first decided to go all in, but it's also been an amazing journey. Spending hours upon hours trying to fix a bug is a not a fun but extremely well-worth experience. Seeing the red text go away or seeing that confetti when you deploy your app on Vercel makes me feel something that I just can't express in words.

If you asked me what quality all developers have, I'd say these two things: *perseverance* and *determination*.

<hr />

***Thank you so much for reading! Signing off 👋***

A quick reflection on what I've done over the past 2 years as a developer.

Looking Back at My Developer Journey

## 7 TypeScript Utility Types That Will Make Your Life Easier

TypeScript has arguably been the greatest thing that I have ever come across as a developer because of the way it revolutionized my experience as a developer. I want to help make using TypeScript even better for you by showing you how to use 7 built in utility types that will make your life much easier.

I will be using the following interface throughout the article to demonstrate the various types:

```ts
export interface Book {
  name: string;
  author: string;
  datePublished: Date;
  price: number;
  numSales?: number;
  seriesName?: string;
}
```

## Omit and Pick

The `Omit` type allows you to "omit" (i.e. remove) certain properties from an interface and construct a new type out of it. The first argument it takes is the interface you want to remove properties from, and the second argument is a list of parameters.

For example, if you want to make a `BookProfile` type, which just has all the properties of the book needed to identify itself, you would use the `Omit` as follows:

```ts
type BookInfo = Omit<Book, "price" | "numSales">;
```

This type would be equivalent to our `Book` interface except it wouldn't have the `price` or `numSales` properties. You can also create it with the interface keyword as follows:

```ts
interface IBookInfo extends Omit<Book, "price" | "numSales"> {}
```

The `IBookInfo` interface would work the same way the `BookInfo` type would, but I personally prefer using the type version due to its cleaner implementation.

The `Pick` type has quite literally the opposite function of the `Omit` type; the `Pick` type allows you to "pick" certain properties of the interface that is passed in and construct a new type out of that.

If we were to make the `BookInfo` type using the `Pick` type, here is how it would look:

```ts
type BookInfo = Pick<Book, "name" | "author" | "datePublished" | "seriesName">;
```

Because these 2 types are so similar, an important question arises. "In which cases should I use `Omit` or `Pick`?" I think it actually comes down to personal preference.

If you were to add new properties to the `Book` type, it would automatically be added to the `BookInfo` type using `Omit` and cut off from the type using `Pick`, so it really depends on the scenario.

Generally, if you have a bunch of properties you need to remove, or if you need to remove more properties than you need to use, I'd use the `Pick` type; otherwise, I'd use `Omit`.

## Partial and Required

Just like `Omit` and `Pick`, `Partial`, and `Required` are also related in terms of functionality.

In our `Book` interface, there are 4 required properties and 2 optional properties.

The `Partial` type will make all the properties on the interface passed in optional; this means that all 6 properties on the `Book` interface would become required.

```ts
type BookPartial = Partial<Book>;
```

The `Required` type does the exact opposite of what `Partial` does; it makes all the properties on the interface passed in required. This would make all 6 properties on `Book` required.

```ts
type BookRequired = Required<Book>;
```

These types are usually extended to include some exceptions. For example, we could make the `name` property required on the `BookPartial` type by extending it as follows:

```ts
type BookPartial = Partial<Book> & { name: string };
```

## Record

The `Record` type allows you to create an object where you can define the key and the type. Lets say we had the following object below:

```ts
const myObj = {
  a: 1,
  b: 2,
};
```

This object follows a strict pattern where every key is a string and every value is a number. We can type this object using the `Record` type as follows:

```ts
const myObj: Record<string, number> = {
  a: 1,
  b: 2,
};
```

All the `Record` type does is say what the types are for the key-value pair of an object. If you want to represent a shelf with different books (with the `Book` interface), you can now easily do that with `Record` as follows:

```ts
const shelf: Record<number, Book> = {
  0: {
    name: "Into Thin Air",
    author: "Jon Krakauer",
    datePublished: new Date(1997, 1),
    price: 14,
  },
  1: {
    name: "1984",
    author: "George Orwell",
    datePublished: new Date(1949, 6),
    price: 12,
  },
};
```

## Parameters and ReturnType

The `Parameters` type creates an array type based on a function's arguments. For example, let's say we had the following function:

```ts
function createPost(caption: string, image?: string) {
  return { caption, image };
}
```

If you wanted to create a type that contained all the arguments of `createPost`, you would do it as follows:

```ts
type CreatePostInput = Parameters<typeof createPost>;
```

Here is how the type would be used in action:

```ts
const post: CreatePostInput = ["Nice", "https://bit.ly/3OOiIaC"];
createPost(...post);
```

The reason why you have to use the spread operator with the `post` array is because the elements of the array correspond to the various arguments of the function; the array itself isn't a function argument.

The `ReturnType` creates a type based on what a function returns. The syntax is very similar to that of `Parameters`:

```ts
type CreatePostReturn = ReturnType<typeof createPost>;
```

This is equivalent to:

```ts
type CreatePostReturn = {
  caption: string;
  image: string | undefined;
};
```

If a function returns a promise, you can wrap the `ReturnType` around the `Awaited` utility type, which will effectively do the same thing the `await` keyword does. It will allow you to have access to the object's (that is wrapped in the Promise) properties again.

```ts
type CreatePostReturn = Awaited<ReturnType<typeof createPost>>;
```

## Next Steps

Now that you have learned just how powerful some of these types are, I highly reccomend refactoring some of your old code to use these types or even implement these types in a new app your building!

**Thank you for reading!**

Signing off 👋

### Useful Links

- [TypeScript Docs](https://www.typescriptlang.org/docs/handbook/utility-types.html)
- [Github Repo](https://github.com/rkazi103/ts-utility-types)


These are 7 utility types in TypeScript that have made my life much easier as a developer by using them

Rayan Kazi

Student | Techincal Writer | Fullstack Developer

My Tech Stack

Next JS as my frontend framework

TypeScript as my main language

Tailwind CSS as my styling framework

tRPC as my API framework

Latest Posts

A Primer on the Different ERC Standards

Looking Back at My Developer Journey

7 Extremely Useful TypeScript Utility Types