Stage Talks

Before flying out from SFO to Denver, I went through the event schedule and hand-picked the talks I wanted to attend. I was pleasantly surprised by the diverse range of topics such as ZK, AI agents, memecoins, and even non-Ethereum subjects like Bitcoin Ordinals. I also appreciated that there were beginner-friendly talks since I had friends with me who were new to crypto.

However, most stage talks were capped at 25 minutes, which felt too short for many speakers to cover their content effectively. Some sessions felt rushed, with speakers having to skip crucial details. One example was a session on building a full-stack decentralized application on Ethereum. The speaker did an excellent job summarizing the process, but for newcomers, it was a lot to absorb in such a short time. Fortunately, all stage talks were recorded and uploaded to X and YouTube, so attendees (and those who missed out) can revisit them. Still, I wish the talks had been slightly longer to allow for a more engaging and well-paced delivery.

Booths

After the opening ceremony on February 27th, the expo floor officially opened, revealing a massive space filled with company booths. Given the recent market downturn and the Bybit hack, I was surprised to see such a strong presence from so many companies. It was encouraging to see their continued enthusiasm despite the challenging conditions.

The creativity behind many of the booths was impressive. Some companies, such as Arbitrum, focused on aesthetics with bright neon lighting, while others designed interactive experiences to engage visitors. One of the most memorable booths belonged to EigenLayer, which featured an AI-powered robot that sketched portraits while providing information about the company’s technology.

Walking through the booths was a great way to meet people and learn about different projects. Many companies were eager to share insights about their products and upcoming developments. Of course, there was also an abundance of free merchandise, including stickers, tote bags, T-shirts, and sweatshirts.

Side Events

Although these events are referred to as side events, they felt like the main attraction. They were some of the most enjoyable and memorable moments of the conference.

The first event I attended was a game night at the Denver Aquarium. We were given 500 starter chips to play poker, roulette, craps, and blackjack, which made for a fun and competitive evening. In addition to the games, we had full access to explore the aquarium, making it an exciting way to start the trip.

The second event was Lmeow Wolf, which took place at Meow Wolf, an immersive art exhibition. The experience felt futuristic and surreal, almost like stepping into a scene from Back to the Future. We spent time exploring the fourth floor’s exhibits, which were packed with interactive elements and creative installations.

Both events included free food and drinks, which made them even better. If you ever attend ETHDenver, I highly recommend looking into the side events. They offer some of the best opportunities to connect with people while enjoying unique experiences.

My Thoughts

ETHDenver 2025 was an incredible experience. My friends and I learned a lot from the talks, discovered exciting projects while exploring the booths, and had a great time at the side events. For anyone looking to network within the crypto space, this conference provides endless opportunities to meet people, from industry veterans to developers and investors. Even for those with different goals, it is still worth attending, especially since most of the events are free. Lastly, if you ever need a break from the conference itself, downtown Denver has plenty of great bars and restaurants to explore.

AI for Generating Tests

One of the most impactful ways AI improves development is by generating tests. If you’ve written a fair amount of tests, you’ve probably felt the frustration of writing them after implementing a feature. Sometimes, you put it off until the end of the project—or worse, skip it entirely. Writing robust tests requires careful thought:

• What are the key scenarios that need to be covered?

• What edge cases should be tested?

• How should test data be structured?

• Are there third-party dependencies that need mocking?

These questions make test writing a mentally laborious process, and it’s easy to see why many developers struggle with it. But this is where AI can make a huge difference.

Let me share a recent experience. While developing a Sudoku game in Go, I wrote a function to generate an initial puzzle. To ensure its correctness, I needed a unit test that verified multiple conditions:

• Were the expected number of zeroes present?

• Did the board have exactly one valid solution?

• Were empty cells editable by the user?

On top of these considerations, I had to manually craft all 81 (9×9) cells as test data, which felt incredibly tedious. Instead of spending hours writing boilerplate test cases, I used o3-mini via Cursor, which generated a unit test that met all my requirements in seconds. Of course, I still reviewed and refined the AI-generated test, but this approach saved me significant time. Instead of getting bogged down in writing tests, I could move on and work on implementing other features.

AI for Naming Things

Naming variables, functions, and classes is a fundamental but often underestimated part of software development. A well-chosen name should clearly convey the purpose of the entity while remaining concise and easy to use. However, getting this balance right is tricky. Without clear naming conventions, inconsistency creeps into the codebase, making it harder to read and maintain.

I've spent a fair amount of time getting stuck on naming decisions. Instead of overthinking it, I’ve started asking AI for suggestions. Since AI models have been trained on massive amounts of code, they can suggest widely accepted, intuitive names almost instantly.

Sure, AI-generated names aren’t always perfect, but they provide a strong starting point. More importantly, using AI in this way has encouraged me to write smaller, more modular functions—because when functions are focused on a single task, AI has an easier time understanding their behavior and suggesting relevant names.

Learning from AI-Generated Code

Sometimes, when I need to implement a feature but don’t know where to start, I turn to AI for guidance. It not only provides step-by-step explanations but also introduces new concepts and techniques that I might not have considered. More often than not, the AI’s responses include ideas worth exploring further, turning a simple query into an opportunity for deeper learning.

For instance, while working on my Sudoku game, I wanted to implement a timer. I asked o3-mini to generate the code, and while reviewing it, I noticed an unfamiliar syntax. Curious as a novice Go programmer, I asked follow-up questions and quickly learned that it was using Go channels—a concurrency feature I hadn’t encountered before.

Instead of just copying and pasting the AI’s output, I treated it as a learning opportunity. By engaging with the AI’s response, asking further questions, and reading related documentation, I gained a much deeper understanding of how channels work.

Disable Autocompletion

This might just be a personal preference, but I always turn off autocompletion in Cursor. While many developers love it for speeding up coding, I find that it disrupts my thought process. When I’m writing code, I sometimes pause briefly to recall what I had planned to write next. But with autocompletion enabled, suggestions constantly appear, pulling my attention away and interrupting my flow.

Autocompletion undoubtedly has its benefits, but I believe it should be used strategically rather than relied on blindly. Overdependence on it can make it harder to write code independently, and in extreme cases, developers may struggle to recall syntax or structure without AI assistance. That’s why I prefer to keep it off—if I need help, I’d rather ask AI explicitly than have it continuously predict my next move.

Final Thoughts

AI is a powerful technology that will continue to improve over time. That said, AI is a tool—not a replacement for understanding how software works. Relying on it too much can accelerate development but might come at the cost of deeper learning and problem-solving skills.

Ultimately, the key is balance. Use AI where it adds the most value, but ensure that it aligns with your goals as a developer. Whether you want to speed up your workflow or enhance your learning, AI is most effective when used thoughtfully and deliberately.

Agile Software Development

I've been continuing my journey through "Agile Software Development: Principles, Patterns, and Practices." This week, I delved deeper into design principles and a few key patterns. For the purpose of this TWIL series, let’s quickly explore the SOLID principles and a crucial truth about software engineering.

SOLID Principles

The SOLID principles are a foundational set of guidelines in software development, comprising:

• Single-Responsibility Principle: A class should have only one reason to change.

• Open-Closed Principle: Software entities should be open for extension but closed for modification.

• Liskov Substitution Principle: Subtypes should be substitutable for their base types.

• Interface Segregation Principle: Clients should not be forced to depend on methods they do not use.

• Dependency Inversion Principle:

  • High-level modules should not depend on low-level modules. Both should depend on abstractions.

  • Abstractions should not depend on details. Details should depend on abstractions.

There’s plenty of resources available online to dive deeper into these principles, so you’ll have no trouble finding detailed explanations and examples.

However, my personal advice is not just to understand what these principles are, but also to know when to apply them. In real-world scenarios, you might need to balance these principles against each other or against other considerations. Being aware of the potential trade-offs and the alternatives available can make a big difference in your decision-making process.

Don't Blame the Requirements, Blame Your Code

Besides the SOLID principles, another key takeaway was the realization that software requirements rarely stay constant—they often evolve, and that's completely normal. This means that software needs to be designed with flexibility in mind, able to adapt to changing requirements.

While this might sound obvious, I had a handful of guilty moments reflecting on past experiences where I found myself frustrated with the rigidity of code structures I had written. At times, I even caught myself grumbling about the constantly changing requirements. Moving forward, I’m committed to keeping this truth top of mind and striving to write more maintainable, adaptable code.

The Everything Token

I finished reading "The Everything Token" by Steve Kaczynski and Scott Duke Kominers. It’s a solid resource for understanding the principles behind successful NFTs, with plenty of real-world examples. If you’re interested in exploring what NFTs can bring to the business table, this book is a good place to start. I'll be sharing a more detailed review in an upcoming post, so stay tuned!

Conclusion

That’s it for this week! I haven’t decided whether I’ll stay in “Read-For-Fun” mode or switch back to “build mode,” but either way, stay tuned for the next post of the TWIL series. Happy hacking! ☕️

As I mentioned in my previous post, I’ll continue writing one TWIL post each week, but the content might shift a bit. Instead of diving deep into a couple of technical topics, I’ll provide a high-level overview of what I’ve learned. While these posts might be shorter than before, they’ll still offer enough insight to get you started or to spark your interest. For those of you eager for a deeper dive, don’t worry—I’ll be creating separate, detailed posts on specific topics. So, stay tuned for those!

Now, with that out of the way, let’s jump into what I’ve been exploring this week.

NPM Packages

While scrolling through my X feed, I stumbled upon an announcement from OnchainKit about adding a React component to their NPM package. Intrigued, I decided to check out their GitHub repository and see if I could contribute. As I browsed through their docs, I noticed a couple of issues that seemed easy to fix. Following their contribution guidelines, I forked the repository, cloned it to my local machine, and started exploring. In the process, I discovered several packages I hadn’t encountered before. Let’s quickly go over them.

Vite

A front-end build tool and development server designed for speed and efficiency. It offers features like dependency pre-bundling and hot module replacement. If you’re interested in learning more, I recommend checking out their official docs.

Vitest

A testing tool tailored for Vite, with an interface similar to Jest. If you’re already using or planning to use Vite, this is worth a look.

Changeset

A versioning tool for multi-package repositories, making it easy to bump project versions and create changelogs. For those working with multi-package repos, their README is a good starting point.

MDX

JSX with markdown capabilities, allowing you to use JSX in markdown files with .mdx extension. I believe it’s particularly useful for creating interactive documentation. See the official doc for more.

Vocs

A documentation framework powered by React and Vite. Follow their project structure, and you can quickly generate a documentation website complete with rich features, including navbar, sidebar, and search functionality. It even supports markdown and MDX. For more information, check out their official doc.

I haven’t had the chance to dive deep into each of these yet, but I hope this overview gives you a good starting point to explore further.

Agile Software Development

Lately, I’ve been reading "Agile Software Development: Principles, Patterns, and Practices" by Uncle Bob, and it’s quickly become one of my favorite books. I’m only up to chapter seven, but it’s already packed with insights not just on Agile development, but on software development in general. Here are a couple of key takeaways as appetizers.

First Test, Then Implementation

I used to underestimate the benefits of Test-Driven Development (TDD), thinking it was inefficient to write tests before implementation. However, this book opened my eyes to how TDD can guide better software design by forcing me to think from the perspective of a customer (i.e. person who will use my code). I’m eager to try this approach in my next project.

Design for Now, Not Later

This advice is straightforward. If you notice a repeating pattern, apply design principles or patterns to improve it. If not, keep it simple. Overcomplicating your design with unnecessary abstractions can make it harder for others (and even yourself) to understand. I’ll be keeping this in mind in my future development work.

Once I finish the book, I’ll definitely write a separate post to share all the insights I’ve gained.

Wrapping Up

That’s it for this week! This TWIL post ended up being a bit lengthy, but I hope you found it helpful. Wishing you all a great week ahead and happy hacking! ☕️

What's Next?

You might be wondering, "What's next?" Well, that's a question I've been asking myself too. Although my plans aren't entirely concrete yet, I’m excited to give you a glimpse into what I’m considering.

Blogging

So far, my blogging efforts have mostly revolved around the TWIL (This Week I Learned) series. However, I haven't been as consistent as I’d like, often pushing articles to the following week. I owe an apology to those of you following the series. I’ve been playing catch-up, but I’m back on track now. With more control over my schedule, I’m committed to delivering one TWIL article per week moving forward.

In addition to TWIL, I'm considering an idea of starting a new series called "Onchain Study." This series would focus on deep dives into technical learnings and discoveries within the web3 space. Given the depth of the content, these posts will likely be more sporadic than the TWIL entries, but they’ll be rich with insights.

You might wonder if there will be overlap between the TWIL and Onchain Study series. Don't worry, I'll do my best to differentiate the content, possibly even tweaking the structure of TWIL to keep things distinct. Stay tuned for more on that front.

Open Source Contributions

Throughout my software engineering journey, I’ve often heard the advice to contribute to open source projects. For a long time, I didn’t feel ready. I preferred to stay within my comfort zone, focusing on building my own applications. That changed when I joined Meta, where I had the chance to contribute to an open source project called Lexical, a text editor framework with a range of extensible plugins. Even though my contribution was a single commit, the experience of merging a PR into a project I initially felt unqualified to touch was unforgettable.

Now, without the demands of a full-time engineering role, I’m eager to step out of my comfort zone and dive into more open source contributions. I’m sure I’ll encounter some “newbie” moments along the way, but I believe these experiences will help me grow into a stronger engineer.

Mastering Design Principles

During my time at Ourkive, my focus was primarily on shipping new features fast, which left little room for exploring design principles and best practices. Now, I’m excited to dedicate time to learning these concepts in-depth. Understanding design principles is more than just knowing what they are. It’s about grasping the pros and cons so that I can apply them effectively in the right contexts. I plan to start with some classics by Uncle Bob, and I’m eager to see how these new insights will influence my engineering skills.

Reading for Fun (RFF)

I’ve realized that I need to make more time for reading purely for pleasure. To that end, I’m committing to setting aside a block of time each day to dive into a good book. The genres will vary, but I’m hopeful this will become a refreshing and stress-relieving habit, especially as I navigate this transition.

An Important Intermission

As I take this “intermission,” my ultimate goal is to find a new software engineering role that truly excites me. Before diving back into the job hunt and interview prep, I want to take this time to reflect on my past experiences, strengthen my engineering foundation, and immerse myself in projects alongside brilliant minds. This period of growth and self-discovery will be pivotal as I prepare for the next steps in my career.

Thanks for sticking with me on this TWIL series. Happy hacking! ☕️

Open-Closed Principle

The Open-Closed Principle (OCP) is one of the five object-oriented programming principles known as SOLID. The essence of OCP is that a class should be open for extension but closed for modification. Instead of just describing what this means, let’s look at some code to illustrate.

Consider this example:

enum DrinkType {
  COKE,
  SPRITE,
  WATER
}

class IngredientAnalyzer {
  sugarAmount(drinkType: DrinkType) {
    if (drinkType === DrinkType.COKE) {
      return 64;
    } else if (drinkType === DrinkType.SPRITE) {
      return 51;
    } else if (drinkType === DrinkType.WATER) {
      return 0;
    }

    throw new Error("Not a valid drink type");
  }
}

Seems straightforward, right? But what happens when we introduce another drink type? We’d have to update the enum and modify the sugarAmount method by adding another if case:

enum DrinkType {
  COKE,
  SPRITE,
  WATER,
  FANTA
}

class IngredientAnalyzer {
  sugarAmount(drinkType: DrinkType) {
    if (drinkType === DrinkType.COKE) {
      return 64;
    } else if (drinkType === DrinkType.SPRITE) {
      return 51;
    } else if (drinkType === DrinkType.WATER) {
      return 0;
    } else if (drinkType === DrinkType.FANTA) {
      return 66;
    }

    throw new Error("Not a valid drink type");
  }
}

This works, but what if there’s a way to add new drink types without modifying the sugarAmount method? This is where the OCP comes in.

By converting each enum value into its own class and using an abstract class with the sugarAmount method, we can apply OCP. Here’s how:

abstract class Drink {
  sugarAmount() {
    return 0;
  }
}

class Coke extends Drink {
  sugarAmount() {
    return 61;
  }
}

class SPRITE extends Drink {
  sugarAmount() {
    return 61;
  }
}

class FANTA extends Drink {
  sugarAmount() {
    return 66;
  }
}

class IngredientAnalyzer {
  sugarAmount(drink: Drink) {
    return drink.sugarAmount();
  }
}

Now, if you want to add a new drink type, simply create a new class that inherits from Drink, without touching the IngredientAnalyzer.

But What About Functional Programming?

I had the same question until I came across an article by Alex Nault, which explains how OCP can be expressed through composition. Here’s an example using React components:

function Text() {
  return <p>Hi Builders!</p>;
}

function Page() {
  return <Text />;
}

What if you want to render a Glimmer component while fetching data from an API? One way is to early return Glimmer within Text:

type Props = {
  isFetching: boolean;
}

function Glimmer() {
  return <div>This is a glimmer component</div>;
}

function Text({ 
  isFetching
}: Props) {
  if (isFetching) {
    return <Glimmer />  
  }

  return <p>Hi Builders!</p>;
}

function Page({
  isFetching
}: {
  isFetching: boolean
}) {
  return <Text isFetching={isFetching} />;
}

However, instead of the code above, we can apply OCP here by using the children prop:

type Props = {
  isFetching: boolean;
  children: React.ReactNode;
}

function Glimmer({
  isFetching,
  children 
}: Props) {
  if (isFetching) {
    return <div>This is a glimmer component</div>;
  }

  return children;
}

function Text() {
  return <p>Hi Builders!</p>;
}

function Page({
  isFetching
}: {
  isFetching: boolean
}) {
  return (
    <Glimmer isFetching={isFetching}>
      <Text />
    </Glimmer>
  );
}

This approach introduces the Glimmer component without modifying the Text component. As it turns out, OCP through composition is widely used in React components, such as the Suspense component.

Is It Actually Beneficial?

This is a valid question. At first glance, you might think that OCP requires more code, and in simple cases, the benefits might not be immediately apparent. However, as your application grows in complexity, the ability to extend functionality without modifying existing, working code becomes increasingly valuable. In such scenarios, OCP is a principle worth considering.

That’s it for this week! I hope this deep dive into OCP helps you in designing better code. Happy hacking ☕️

Create vs. Create2

In Solidity, create and create2 are opcodes used for deploying smart contracts. Here's a quick breakdown of their differences:

• Create: Requires the deployer's address and nonce.

• Create2: Requires 0xff, the deployer's address, a salt, and the bytecode of the smart contract.

Introduced in ERC-1014, create2 allows for deterministic contract address generation. This means that if you provide the same arguments to create2 twice, you'll get the same contract address both times. This deterministic feature isn't possible with create since it depends on the nonce, which is unique to each transaction made by the sender on the blockchain.

Here are some additional insights:

• When you instantiate a smart contract using the new keyword in Solidity, you're using create under the hood.

• State channels often use counterfactual smart contracts, which rely on create2.

• The 0xFF constant in create2 is used to differentiate it from the create opcode.

I'll dive deeper into state channels and counterfactual smart contracts in a future article. For now, let's move on to another Solidity tip.

Solidity Constant Variable Getter

In Solidity, you can initialize a constant variable like this:

contract Example {
    uint96 public constant K = 10;
}

But what if you need to create an interface IExample for the Example contract? How do you write the Solidity code in the interface so that other contracts using IExample can access it?

If you guessed it involves a single line of code, you'd be right. You just need to add a function declaration:

interface IExample {
    function K() external view returns (uint96);
}

And, of course, you can call this from another contract like so:

contract Caller {
    IExample example;

    constructor(IExample _example) {
        example = _example;
    }

    function getK() public view returns (uint96) {
        return example.K();
    }
}

Public state variables work the same way as constants in this regard.

That's it for this week! I've shared some random facts about Solidity, and I hope they help you in some way. Happy hacking! ☕️

Multi-Sig Contracts: An Overview

As the name implies, the core feature of a multi-sig contract is to require multiple signatures to authorize a transaction. Here’s a typical workflow:

1. Submission: One of the contract owners submits a transaction onchain.

2. Approval: Other owners approve the submitted transaction.

3. Execution: Once the transaction receives enough approvals (i.e., meets a set threshold), one of the owners executes it.

When submitting a transaction, the smart contract must know the essential details, such as the contract address and the encoded function data. The encoded function data can be generated with the following code:

function getEncodedFunctionData() {
  const Contract = await ethers.getContractFactory("<contract-name>");
  const contract = await Contract.attach("<deployed-contract-address>");

  return contract.interface.encodeFunctionData(
    "<function-name>", 
    [/* args in order */]
  );
}

With the contract address and encoded function data in hand, the transaction is processed using this line of code:

(bool success, bytes memory returnData) = transaction.to.call{
  value: transaction.value
}(transaction.data);

Here’s a breakdown:

• transaction.to points to the contract address.

• call is a low-level method used to interact with another smart contract. If you're familiar with Solidity, you've likely seen it used for sending native tokens to an address. Now, how I'm using it here isn't generally recommended due to several potential issues, but I opted to use call over delegatecall to maintain the context of the called contract.

• value is the native token amount being sent, often 0 if not required.

• transaction.data is the encoded function data being passed along.

The returnData is useful for two purposes:

1. Handling data returned by the called function.

2. Capturing errors from the callee contract, though some reverts may not bubble up correctly.

Universal Upgradeable Proxy Standard

The Universal Upgradeable Proxy Standard (UUPS) is a method for upgrading smart contracts. It's similar to the Transparent Proxy Pattern but has key differences in where the authorization and upgrading logic are located.

Here’s an example using OpenZeppelin's UUPSUpgradeable contract:

import {OwnableUpgradeable} from "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import {UUPSUpgradeable} from "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";

contract Example is OwnableUpgradeable, UUPSUpgradeable {
    function initialize(
        address owner
    ) public initializer {
        __Ownable_init(owner);
    }

    // ...

    function _authorizeUpgrade(address) internal override onlyOwner {}
}

Let's take a closer look:

• The Example contract inherits UUPSUpgradeable from OpenZeppelin.

• Override the _authorizeUpgrade method from UUPSUpgradeable to include custom authorization logic, such as the onlyOwner modifier, ensuring only the owner can upgrade the contract.

I applied this template to all our smart contracts, ensuring that our multi-sig contract is the only way to authorize upgrades. This means upgradeability authorization relies on the multi-sig mechanism, preventing any single entity from compromising our smart contracts.

That's it! This brief overview hopefully provides a starting point for understanding how multi-sig contracts are implemented and how they can serve as an upgradeability medium. I plan to write a more detailed technical blog on multi-sig contracts in the future. For now, happy hacking! ☕️

Smart Contract Address Conflict

While refactoring code from the OCS Buildathon, I stumbled upon an unexpected issue: an onboarded artist reported seeing music he didn’t own on his profile page. Knowing the specific API route in question, I delved into the API route handler to identify the problem. Initially, my database query seemed straightforward—fetch all music data where the music NFT smart contract address matches the user's owned contracts. However, our platform supports both Polygon PoS and Base, which complicated matters.

Upon searching for the same smart contract address on both Polygonscan and Basescan, I discovered two distinct smart contracts, each deployed on a different chain. This revealed a critical oversight: smart contract addresses can be identical across different blockchains. For those familiar with how smart contract addresses are generated, this might seem obvious, but it caught me off guard while adding Base support.

Smart contract addresses are generated using the deployer’s address and a nonce, explaining why the two conflicting contracts shared the same address—they had the same deployer and nonce but were on different chains. The lesson here is clear: a smart contract address is unique within a single blockchain but not across different EVM-compatible blockchains.

To resolve the issue, I modified the query to include the blockchain type alongside the smart contract address, ensuring Prisma queries only the correct contract. With this newfound knowledge, we can avoid this pitfall in the future, or at least understand it better if it happens again.

OpenZeppelin Defender + Safe Wallet

Since we had some spare time for maintenance work, I decided to migrate from a company EOA to a multi-sig account. The rationale was simple: sharing our sole private key with an expanding team of developers would be highly imprudent. Our expectations for the new multi-sig account were clear:

• Upgrading smart contracts requires multiple owners' approval

• Certain smart contract methods can only be invoked if approved by multiple owners

• Seamless support for upgrading smart contracts inheriting OpenZeppelin's upgradeable contracts

For the multi-sig component, Safe wallet came to mind. It's a well-known multi-sig wallet with a web app for easy interaction. However, Safe's app lacked UIs for smart contract upgrades. This led me to discover OpenZeppelin Defender, a SaaS product for smart contract development. It offers features like code inspection, auditing, deployment, and most importantly for us, UIs for deploying and upgrading smart contracts via Safe wallet. To evaluate its suitability, I experimented with deploying and upgrading smart contracts on multiple testnets.

During this testing phase, I encountered several issues:

1. Safe wallet isn't yet supported on both Polygon Amoy and Base Sepolia, which are critical for us.

2. Defender's app felt clunky, with long UI loading times and no error messages for failed processes, making debugging difficult.

3. The Professional tier pricing is quite steep for an early startup. Although the free tier had no limitations on deploying and upgrading, the pricing page indicated a cap of 5 transactions, which is insufficient.

Despite these downsides, which are understandable given OpenZeppelin's fairly recent public launch of Defender V2, we also identified a few problems with Safe wallet for our purposes:

• Safe doesn't have Polygon Amoy support on their roadmap yet. Although it's just a testnet, setting it up again with an EOA incurs significant testnet Matic costs for redeployment if the EOA is compromised.

• Safe app lacks fine-grained access control. For instance, requiring a specific EOA for transaction approvals isn't possible since it only supports threshold-based approvals.

Given these challenges, I decided against using both Safe wallet and OpenZeppelin Defender. Instead, I opted to implement our own multi-sig smart contract for access controls. I'll discuss this in detail in the next TWIL article. For now, happy coding, everyone ☕️

Alchemy Webhook Integration

Previously, artists on our web app followed these steps to mint a music NFT:

1. Click the "Release" button.

2. The button handler mints an NFT for the artist, approves the NFT marketplace smart contract to transfer the NFT, and lists the NFT on the marketplace.

3. The artist waits for all transactions to be validated.

4. Once validated, MongoDB is updated with relevant transaction details, such as the transaction hash.

This process was problematic because some artists would leave the page before transaction validation was complete. To address this issue, we needed a way to trigger a database update automatically in the background once the transaction was validated.

Fortunately, our web app uses Alchemy as the primary node provider. I discovered that Alchemy supports webhooks for various on-chain activities, such as address activity and NFT metadata updates. I opted for the NFT activity webhook, which sends transaction data to an API I created whenever an NFT transfer occurs.

I set up a webhook via the Alchemy web app so that once an NFT is minted, the transaction data is sent to the API. The API then extracts the necessary information from the request and updates the database. As a result, the new user flow is as follows:

1. Click the "Release" button.

2. The button handler mints an NFT for the artist, approves the NFT marketplace smart contract to transfer the NFT, and lists the NFT on the marketplace.

That's it! Artists no longer need to wait for transaction validation. An optimistic update is performed on the client side, while the Alchemy webhook handles transaction validation and database updates in the background.

There are other types of Alchemy webhooks available, so be sure to check out their official documentation for more details.

Solidity Custom Error

Starting from version 0.8.4, Solidity supports custom errors, which can be thrown using the revert keyword. Here's an example:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Test {
  error NotOwner(address notOwner);

  address owner;

  constructor() {
    owner = msg.sender;
  }

  function checkAndGetOwner(
    address addr
  ) 
    public 
    view 
    returns (address)
  {
    if (owner != addr) {
      revert NotOwner(addr);
    }

    return owner;
  }
}

The benefits of using a custom error are twofold: it is more gas-efficient and allows for the creation of dynamic error messages.

To test this code, you can use the revertedWithCustomError method from Chai.

import { ethers } from "hardhat";
import { expect } from "chai";

describe("Test", () => {
  it("should throw error", async () => {
    const [deployer, account] = await ethers.getSigners();

    const test = await ethers.deployContract("Test");

    await expect(test.checkAndGetOwner(account.address))
      .to.be.revertedWithCustomError(test, "NotOwner")
      .withArgs(account.address);
  });
});

That's a wrap for this week! We've successfully completed and submitted our Onchain Summer Buildathon application. In the coming week, our focus will shift to refactoring a substantial amount of code. Stay tuned for more updates and happy hacking! ☕️

EOA with Smart Wallet Integration

Our platform already had artists using EOAs to mint music NFTs, so migrating them entirely to Smart Wallets wasn't feasible. Instead, we had to adapt our client-side code to support both Smart Wallet accounts and EOAs. This involved implementing conditional logic to handle each type of account using the useCapabilities hook.

Here's an example of how we managed batch transactions for both account types:

const Component = () => {
  const { data: capabilities } = useCapabilities({
    account,
  });

  const isSmartWallet = Object.keys(capabilities).length > 0;

  const methodOne = {
    // args...
  }

  const methodTwo = {
    // args...
  }

  const { writeContractsAsync } = useWriteContracts();
  const { writeContractAsync } = useWriteContract();

  const { data: methodOneData } = useSimulateContract(methodOne);
  const { data: methodTwoData } = useSimulateContract({ 
    ...methodTwo, 
    skipSimulation: true 
  });

  const handler = async () => {
    if (isSmartWallet) {
      await writeContractAsync({
        contracts: [methodOne, methodTwo]
      });
      return;
    }

    const hash = await writeContractAsync(methodOneData);
    await waitForTransactionReceipt(config, { hash });
    await writeContractAsync(methodTwoData);
  }
}

Key Learnings and Highlights

1. Detecting Smart Wallet vs. EOA: We used the useCapabilities hook to check if the user has capabilities associated with a Smart Wallet. If capabilities has at least one key-value pair, it indicates a Smart Wallet; otherwise, it’s an EOA. The isSmartWallet variable serves as this indicator.

2. Handling Simulation and Execution: Include skipSimulation: true on the second useSimulateContract argument if the methodTwo transaction depends on methodOne being executed and confirmed. This avoids errors during simulation. Additionally, invoke waitForTransactionReceipt to ensure the first transaction is confirmed before executing the second one.

Hardhat Network Variable

The Hardhat npm package provides many useful variables, including network, which tells you which chain you're executing your script on at runtime. This is particularly useful if you have identical smart contracts deployed on multiple blockchains. Here’s a handy way to get smart contract addresses across supported blockchains:

// main.ts

import { network } from "hardhat";

enum EthereumSCAddresses {
  NFT = "<smart-contract-address>"
}

enum BaseSCAddresses {
  NFT = "<smart-contract-address>"
}

function getContractAddress() {
  switch (network.name) {
    case "ethereum":
      return EthereumSCAddresses
    case "base":
      return BaseSCAddresses;
    default:
      throw new Error("Invalid network name");
  }
}

function main() {
    const nftAddress = getContractAddress().NFT;
}

When you run npx hardhat run main.ts --network ethereum, getContractAddress will return EthereumSCAddresses, and .NFT will return the corresponding smart contract address.

Wrapping Up

That’s it for this week! As we head into the final week of the Onchain Summer Buildathon, we'll continue to fix issues and build new features. Happy hacking everyone ☕️!

Sign in with Ethereum (SIWE)

Sign in with Ethereum (SIWE) is a popular authentication method that allows decentralized applications (dapps) to remember their users. Our website leverages this method via the siwe npm package. Initially, I assumed that integrating Smart Wallet, a new smart contract wallet from Coinbase, would be straightforward. However, I encountered an unexpected technical hurdle.

Smart Wallet requires dapps to be compatible with EIP-6492, which outlines the signature validation for a pre-deployed smart contract account. Unfortunately, the siwe package doesn’t support this validation yet, meaning it can't validate Smart Wallet’s signature out-of-the-box.

Thankfully, the community already had an answer to this problem. Someone responded to a GitHub issue with a small package that supports both EIP-1271 and EIP-6492 signature validations. This package offers a verifyMessage function that enables us to validate signatures from Smart Wallet seamlessly. If your dapp needs to support SIWE for Smart Wallet, you can use AmbireTech's signature-validator package.

USDC Permit

Beyond SIWE, our dapp also supports EIP-2612, which allows ERC20 tokens to be approved and transferred within a single transaction. Since USDC has already implemented EIP-2612, our dapp could use a permit function within our NFT marketplace smart contract. However, EIP-2612 doesn't support EIP-1271, meaning a Smart Wallet account signature isn't supported on EIP-2612.

Fortunately, Smart Wallet supports batch transactions. To address this, I separated the permit function logic into approve and transfer transactions and batched them using the useWriteContracts hook from the Wagmi package. Here’s an example code snippet:

import { useWriteContracts } from "wagmi/experimental";

function Component() {
  const usdcApprove = {
    address: "<usdc-contract-address>",
    abi,
    functionName: "approve",
    args: ["<spender-address>", "<amount>"]
  }

  const usdcTransfer = {
    address: "<usdc-contract-address>",
    abi,
    functionName: "transferFrom",
    args: ["<from-address>", "<to-address>", "<amount>"]
  }

  const { writeContracts } = useWriteContracts();

  const handleUsdc = () => {
    writeContracts({
      contracts: [usdcApprove, usdcTransfer]
    });
  }
}

Although externally owned accounts (EOAs) will have to go through two separate transactions, Smart Wallet accounts will enjoy a simpler user experience with just one click of transaction confirmation.

That’s it for this week. With two weeks left in the OCS Buildathon, I'll continue building and sharing my progress. Happy hacking, everyone! ☕️

Caveats When Upgrading Web3 Packages

Wagmi V1 -> V2

I had to upgrade Wagmi from version V1 to V2. While the complete list of changes is documented here, the information on handling TypeScript types was somewhat lacking in detail.

Wagmi Core Method Types

Besides React hooks, Wagmi also provides regular async methods, such as sendTransaction, powered by a package called viem. In V2, you can also import and use TypeScript types for parameters and return types. However, you need to specify the config type you're using for the generics. Here's an example:

import { type SendTransactionParameters, sendTransaction } from "@wagmi/core";

const config = createConfig({
  // ...
});

export default async function sendWagmiTransaction(
  args: SendTransactionParameters<typeof config>,
) {
  const hash = await sendTransaction(config, args);
  return hash;
}

useWaitForTransactionReceipt Type

Parsing transaction receipt logs is a common task for dapps, and I've been using useWaitForTransactionReceipt, the hook to retrieve the transaction receipt. In V2, you can use WaitForTransactionReceiptData, which is the data type returned by useWaitForTransactionReceipt. Here's how to use it:

const chains = [
  mainnet,
  sepolia,
  goerli,
  polygon,
  polygonAmoy,
  base,
  baseSepolia,
] as const;

const chainIds = chains.map(({ id }) => id);

type ChainIds = typeof chainIds;

const config = createConfig({
  // ...
});

async function parseTxReceiptData(
  data: WaitForTransactionReceiptData<typeof config, ChainIds[number]>
) {
  // ...
}

async function main() {
  const { data } = useWaitForTransactionReceipt({ hash: "<tx-hash>" });
  const parsedData = await parseTxReceiptData(data);
}

Instead of just passing in config, you also need to pass in a union of all the chain IDs that config supports.

Ethers V5 -> V6

Ethers is another package I had to upgrade due to a conflict with Next 14. I was setting up a JSON RPC provider for all the chains we support, but it kept giving me an error message: Could not detect network. I discovered that ethers V5 has an issue with Next 14, which left me with two options:

• Keep ethers V5 and implement a temporary workaround

• Upgrade to ethers V6 and make the necessary changes to the codebase

Since I was using wagmi, there wasn't much use of ethers in the codebase, so I chose the second option. If you ever need to use ethers with Next 14, make sure your ethers package is V6 or higher.

That's it for this week. For the next few weeks, I'll be deeply focused on modifying and building new features for the Buildathon. After that, I'll share what I've learned. Happy hacking, everyone ☕️

Solidity Immutable Variable

While I was skimming through Base's tutorials on gas optimization, I noticed the usage of an immutable variable. Since I was curious, I did a bit of research on what it does.

What is it?

As the name suggests, an immutable variable cannot be changed after the contract is deployed. You can assign a value while declaring it or within the constructor, but it cannot be accessed until the contract is deployed. In other words, it is not accessible within the constructor; it can only be assigned a value. Here's an example of how it's used:

contract Example {
    address immutable addressOne;

    address immutable addressTwo = address(0);

    address immutable addressThree;

    address immutable addressFour;

    constructor(address _anotherOwner) {
        addressOne = msg.sender;
        addressThree = _anotherOwner;
        // The line below will throw an error
        // addressFour = addressOne;
    }
}

Vs. Constant Variable

Here's a brief table that explains the differences:

Stuck Transaction

When using Hardhat to interact with the Polygon PoS network, I frequently faced issues with transactions getting stuck due to low gas prices. This occurred because Polygon Labs set a minimum gas price of 30 gwei to mitigate spam transactions. To prevent transactions from getting stuck, you can use one of the following methods:

1. Set an explicit gas price for all transactions: If you're using Hardhat, you can set it in hardhat.config.ts:

    const config: HardhatUserConfig = {
      // ...
      matic: {
        // ...
        gasPrice: Number(ethers.parseUnits("30", "gwei"))
      }
    }
   

2. Set an explicit gas price for a specific transaction:

    contract Example {
        address immutable owner;
        constructor() {
            owner = msg.sender;
        }
   
        function setOwner(address newOwner) external {
            owner = newOwner;
        }
    }
   

    async function main() {
        const example = await ethers.deployContract("Example");
        await example.waitForDeployment();
   
        const txOptions = {gasPrice: ethers.parseUnits("30", "gwei")};
        const tx = await example.setOwner(ethers.ZeroAddress, txOptions);
        await tx.wait();
        // ...
    }
   
    main();
   

If you want to resolve a stuck transaction, you need to provide the nonce of the stuck transaction as well.

async function main() {
    const example = await ethers.deployContract("Example");
    await example.waitForDeployment();

    const signer = new ethers.Wallet(
        `<account-private-key>`,
        ethers.provider,
    );
    const nonce = await ethers.provider.getTransactionCount(
        signer.address,
        "latest",
    );

    const txOptions = {gasPrice: ethers.parseUnits("30", "gwei"), nonce};
    const tx = await example.setOwner(ethers.ZeroAddress, txOptions);
    await tx.wait();
    // ...
}

main();

That wraps up this week's TWIL. Happy hacking! ☕️

Hardhat Gas Reporter Plugin

This plugin is essential if you're developing with Hardhat, Truffle, or any other smart contract development tool that supports it. When you run tests, it automatically creates a table of stats, showing the average gas used for each method in your smart contracts. The installation is quick and easy:

1. Run npm install -D hardhat-gas-reporter

2. Add the following to hardhat.config.ts:

    import "hardhat-gas-reporter";
    // other imports...
   
    const config: HardhatUserConfig = {
      // other configs...
      gasReporter: {
        enabled: true,
      },
    };
   

3. Once you write your smart contract and test code, run npx hardhat test, and you'll see a table of stats.

With the resulting report, you can see how much gas is used for each transaction. This helps you estimate the cost of each transaction and decide if you need to optimize the smart contract code for better gas efficiency.

Solidity Optimizer

This helps optimize your Solidity code for gas efficiency. To use it, add the following to hardhat.config.ts:

const config: HardhatUserConfig = {
  solidity: {
    // ...
    settings: {
      optimizer: {
        enabled: true,
        runs: <number>,
      },
    },
  },
};

Here, <number> depends on your preference. If <number> is high, the optimizer focuses on making the Solidity code more gas-efficient for each method execution, but it costs more to deploy the smart contract. If <number> is low, the deployment cost of the smart contract will be lower, but each method will cost more to execute.

Usage of unchecked

Looking at many Solidity smart contracts deployed on various mainnets, I noticed the use of the unchecked keyword in several instances, especially within for loops. I looked it up on Google and read this Stack Overflow answer. In simple terms, it is a gas-efficient way of handling arithmetic operations by ignoring any possible underflow or overflow errors. In other words, if you know that underflow and overflow will never occur for an arithmetic operation, wrapping it with the unchecked keyword will use less gas than the default checked operation. Here's a quick example:

contract SmartContract {
    uint[] public intArray;

    function contractMethod() external {
        require(intArray.length < 5, "Length must be less than 5");
        for (uint i; i < intArray.length;) {
            // perform some operation...

            unchecked {
                i++;
            }
        }
    }
}

OpenZeppelin's Proxy Admin Issue

While upgrading and deploying several smart contracts using Hardhat, I encountered an error: Proxy admin is not the one registered in the network manifest. I searched online for a solution but found none, except for deleting the entire manifest file in the .openzeppelin directory.

Instead, here's how I resolved it:

1. I went to Polygonscan, searched for the contract I was trying to upgrade, and retrieved the proxy admin contract's address by interacting with the website.

2. I then checked the .openzeppelin > polygon.json file and noticed that the address under admin was different from the one I got from Polygonscan.

3. I replaced the address in the polygon.json file with the one from Polygonscan.

4. Finally, I reran the code to upgrade the smart contract, and it worked.

So, if you encounter the same issue, find the proxy admin's address from the relevant block explorer and replace the one in the .openzeppelin > <network>.json file with it.

USDC Permit Domain Name

USDC supports ERC-2612, enabling USDC holders to approve a payout without requiring a native token as a transaction fee. I decided to utilize this feature for setting up an NFT purchasing process, but I faced an error message stating EIP2612: invalid signature on the mainnet. It functioned correctly on the testnet, so I wasn't certain about the cause of this problem until I examined their smart contracts on both the testnet and mainnet Etherscans:

• Sepolia Etherscan

• Mainnet Etherscan

If you select the name dropdown, you'll observe that Sepolia Etherscan presents "USDC" while the mainnet Etherscan displays "USD Coin". This distinction is crucial because the permit method utilizes the name field to authenticate the USDC holder's signature on-chain. My issue stemmed from using a constant string "USDC" instead of retrieving it directly from the contract. Therefore, if you encounter a similar problem, ensure to provide the accurate name based on the blockchain type.

const name = await getUsdcName(chainId);
const signature = await signTypedData({
    domain: {
      name,
      version,
      chainId,
      verifyingContract,
    },
    // ...
});

async function getUsdcName(chainId: number) {
    // Fetch the name value from the USDC contract
}

Typechain

Since I started developing smart contracts, I've been using Hardhat as a tool for deploying and managing smart contracts. However, it wasn't until this week that I discovered typechain. This amazing library automatically creates TypeScript types for each smart contract, making it very simple to know which types are required when working with smart contracts. One way to use this library is by creating a helper function for deploying a smart contract:

import { ethers } from "hardhat";
import { SmartContractA__factory } from "/path/to/typechain/dir";

async function deploySmartContractA(
    deployer: HardhatEthersSigner,
    ...params: Paramters<SmartContractA__factory>
) {
    const smartContractA = await new SmartContractA__factory(owner)
        .deploy(...params);
    await smartContractA.waitForDeployment();
    return smartContractA;
}

async test() {
    const [owner] = await ethers.getSigners();
    const args = [];
    const smartContractA = await deploySmartContractA(owner, ...args);

    // Assume SmartContractA has setOwner(address owner) external method
    await smartContractA.setOwner(owner.address);

    // This will be caught by a linter
    // since the argument type is already known
    await smartContractA.setOwner(owner);
}

Now you know precisely which types are needed for each method!

Smart Contract Size Limit

As I added more methods and tested a smart contract, I noticed all my test cases failing because of the same problem - ProviderError: Error: Transaction reverted: trying to deploy a contract whose code is too large. I soon realized that deploying the smart contract used up more than the default block gas limit (30,000,000). This meant I had to split it into multiple contracts.

I chose to create another contract with a specific purpose: a storage contract. It will store all the on-chain states related to a similar context, along with the getters and setters, but nothing more. Other contracts can access these states by calling the getters and setters through composition. Essentially, the storage contract functions like a database. Here's a simplified example:

contract Storage is OwnableUpgradeable {
    address public nft;

    function initialize(address nftAddr) public initializer {
        __Ownable_init();
        nft = nftAddr;
    }

    function setNft(address nftAddr) external onlyOwner {
        require(
            nftAddr != address(0),
            "NFT address cannot be the zero address"
        );
        nft = nftAddr;
    }
}

contract PaymentController is 
    OwnableUpgradeable, 
    ReentrancyGuardUpgradeable 
{
    Storage public controllerStorage;

    function initialize(address storageAddr) public initializer {
        __Ownable_init();
        controllerStorage = Storage(storageAddr);
    }

    function setControllerStorage(
        Storage newStorage
    ) external onlyOwner {
        require(
            address(newStorage) != address(0),
            "New storage address cannot be the zero address"
        );
        controllerStorage = newStorage;
    }

    function payNftOwner() external nonReentrant {
      require(address(this).balance >= 1 ether, "Not enough balance");
      address nftAddr = controllerStorage.nft();
      uint256 nftBalance = IERC721(nftAddr).balanceOf(msg.sender);
      if (nftBalance > 0) {
          (bool paid, ) = payable(msg.sender).call{value: 1 ether}("");
          require(paid, "Failed to pay");
      }
    }
}

As you can see, I connected these two contracts using composition instead of inheritance to make the Storage contract's states reusable.

What is ReturnType?

ReturnType allows you to easily create a type that represents whatever a function returns. Let's look at an example:

function f() {
  return { a: 1, b: 2, }
}

// F is now { a: 1, b: 2 } type
type F = ReturnType<typeof f>;

Pretty simple, right? Well, what's the use case of ReturnType? Let's now look at a simple use case for it.

Reduces Type Maintenance Cost

The power of ReturnType comes into play when we're invoking a same function multiple times in various locations and multiple other functions rely on the values returned by that function. Let's look at an example:

function getPosts() {
    return [
        {
            title: "Title 1",
            author: "Author 1",
            content: "Content 1",
        },
        {
            title: "Title 2",
            author: "Author 2",
            content: "Content 2",
        }, 
        {
            title: "Title 3",
            author: "Author 3",
            content: "Content 3",
        }
    ]
}

function removeContent(
    posts: {
        title: string;
        author: string;
        content: string;
    }[]
) {
    return posts.map(({content, ...rest}) => rest);
}

function addDisplayOrder(
    posts: {
        title: string;
        author: string;
        content: string;
    }[]
) {
    return posts.map((post, index) => ({ ...post, displayOrder: index }));
}

function combineTitleAuthor(
    posts: {
        title: string;
        author: string;
        content: string;
    }[]
) {
    return posts.map(({title, author, content}) => ({ titleAuthor: `${title} - ${author}`, content }));
}

function main() {
    const posts = getPosts();

    const postsWithoutContent = removeContent(posts);
    const postsWithDisplayOrder = addDisplayOrder(posts);
    const combinedTitleAuthorPosts = combineTitleAuthor(posts);

    // ...
}

What's "wrong" with this code? If you have keen eyes, you would've already spotted, but we actually have a repeating code, which is the type of posts used as an argument for removeContent, addDisplayOrder and combineTitleAuthor. So here's an improved code:

function getPosts() {
    return [
        {
            title: "Title 1",
            author: "Author 1",
            content: "Content 1",
        },
        {
            title: "Title 2",
            author: "Author 2",
            content: "Content 2",
        }, 
        {
            title: "Title 3",
            author: "Author 3",
            content: "Content 3",
        }
    ]
}

type Posts = {
    title: string;
    author: string;
    content: string;
}[];

function removeContent(posts: Posts) {
    return posts.map(({content, ...rest}) => rest);
}

function addDisplayOrder(posts: Posts) {
    return posts.map((post, index) => ({ ...post, displayOrder: index }));
}

function combineTitleAuthor(posts: Posts) {
    return posts.map(({title, author, content}) => ({ titleAuthor: `${title} - ${author}`, content }));
}

function main() {
    const posts = getPosts();

    const postsWithoutContent = removeContent(posts);
    const postsWithDisplayOrder = addDisplayOrder(posts);
    const combinedTitleAuthorPosts = combineTitleAuthor(posts);

    // ...
}

Much better! But what happens when we add number of views for each post? Let's take a look:

function getPosts() {
    return [
        {
            title: "Title 1",
            author: "Author 1",
            content: "Content 1",
            views: 1,
        },
        {
            title: "Title 2",
            author: "Author 2",
            content: "Content 2",
            views: 2,
        }, 
        {
            title: "Title 3",
            author: "Author 3",
            content: "Content 3",
            views: 3,
        }
    ]
}

type Posts = {
    title: string;
    author: string;
    content: string;
    // Need to add views field
    views: number;
}[];

function removeContent(posts: Posts) {
    return posts.map(({content, ...rest}) => rest);
}

function addDisplayOrder(posts: Posts) {
    return posts.map((post, index) => ({ ...post, displayOrder: index }));
}

function combineTitleAuthor(posts: Posts) {
    return posts.map(({title, author, content}) => ({ titleAuthor: `${title} - ${author}`, content }));
}

function main() {
    const posts = getPosts();

    const postsWithoutContent = removeContent(posts);
    const postsWithDisplayOrder = addDisplayOrder(posts);
    const combinedTitleAuthorPosts = combineTitleAuthor(posts);

    // ...
}

Once we added views field to each post, we had to add views: number; to Posts type. If you're used to construct a type this way, you may think that it's the best we can do. However, you can actually improve this further by utilizing ReturnType.

function getPosts() {
    return [
        {
            title: "Title 1",
            author: "Author 1",
            content: "Content 1",
            views: 1,
        },
        {
            title: "Title 2",
            author: "Author 2",
            content: "Content 2",
            views: 2,
        }, 
        {
            title: "Title 3",
            author: "Author 3",
            content: "Content 3",
            views: 3,
        }
    ]
}

type Posts = ReturnType<typeof getPosts>

function removeContent(posts: Posts) {
    return posts.map(({content, ...rest}) => rest);
}

function addDisplayOrder(posts: Posts) {
    return posts.map((post, index) => ({ ...post, displayOrder: index }));
}

function combineTitleAuthor(posts: Posts) {
    return posts.map(({title, author, content}) => ({ titleAuthor: `${title} - ${author}`, content }));
}

function main() {
    const posts = getPosts();

    const postsWithoutContent = removeContent(posts);
    const postsWithDisplayOrder = addDisplayOrder(posts);
    const combinedTitleAuthorPosts = combineTitleAuthor(posts);

    // ...
}

We've switched from using { title: string; author: string; content: string; views: number; }[] to ReturnType<typeof getPosts>. You might wonder why. Before, the Posts and the return type of getPosts function were not aligned, meaning any changes in getPosts' return type had to be manually updated in Posts. Now, with the current code, Posts and getPosts are in sync, ensuring that any changes in the return type of getPosts are automatically reflected in Posts. This might seem trivial, but it's quite beneficial, especially as your codebase grows. A larger codebase means longer type-checking times by your linter, and this synchronization reduces the need for additional iterations, which can be quite impactful.

Conclusion

Utilizing TypeScript's ReturnType simplifies code management by automatically syncing type definitions, reducing manual updates and maintenance overhead. This not only enhances consistency across the codebase but also streamlines development, particularly in large-scale projects. Happy hacking 👨‍💻!

1. They're simpler for doing basic looping with arrays.

2. They allow method chaining, resembling the builder design pattern, enhancing coding flexibility.

Problem

However, there's a catch when using TypeScript's filter. Consider the following code:

const posts = [
    {id: 0, title: "Title 1", content: "Content 1"},
    {id: 1, title: "Title 2", content: "Content 2"},
    {id: 2, title: "Title 3", content: "Content 3"},
    null,
    undefined
];

const filteredPosts = posts.filter(post => post != null);

Surprisingly, TypeScript infers filteredPosts as a mix of valid posts and null values (i.e. ({id: number, title: string, content: string} | null)[]). How can we ensure TypeScript infers the correct type?

Type Guard

Fortunately, TypeScript offers a solution through type guards, expressions that perform runtime checks, ensuring correct type inference. Let's see it in action:

// Constructed this type for convenience
type Post = {id: number, title: string, content: string};

const posts = [
    {id: 0, title: "Title 1", content: "Content 1"},
    {id: 1, title: "Title 2", content: "Content 2"},
    {id: 2, title: "Title 3", content: "Content 3"},
    null,
    undefined
];

const filteredPosts = posts.filter((post): post is Post => post != null);

Now, TypeScript understands filteredPosts as an array containing only Post (i.e. {id: number, title: string, content: string}[]).

Improving Reusability

Let's level up our function's versatility using generics and TypeScript's NonNullable utility type:

const posts = [
    {id: 0, title: "Title 1", content: "Content 1"},
    {id: 1, title: "Title 2", content: "Content 2"},
    {id: 2, title: "Title 3", content: "Content 3"},
    null,
    undefined
];

const chooseNonNullable = <T>(arg: T): arg is NonNullable<T> => arg != null;

const filteredPosts = posts.filter(chooseNonNullable);

Now, you can export chooseNonNullable and use it as a callback to any filter methods to remove both null and undefined.

Addressing an Alternative

You might wonder about using the as keyword instead of type guards. While possible, it's less reliable as it assumes a type without verification, leading to potential errors. Stick with type guards for accuracy and safety!