DEV Community: Apperside

Stop Playing "Where's Waldo?" with Your React Components

Apperside — Tue, 24 Jun 2025 15:42:59 +0000

Instantly locate any component's source file from your browser's inspector with this game-changing Babel plugin

We've all been there. You're debugging a React application, staring at the browser's developer tools, and you see a mysterious <div> with some styling issues. You think to yourself: "Which component is rendering this? What file is it in? What line number?"

You start the tedious process of:

Searching through your codebase
Guessing which component might be responsible
Adding temporary console.log statements
Refreshing and hoping you found the right one

What if I told you there's a better way?

Meet babel-plugin-locate-source

This Babel plugin automatically adds source location information to every JSX element in your React application during development. No more guessing games, no more wasted time hunting through files.

What It Does

The plugin adds three crucial data attributes to every JSX element:

data-at: The exact file and line numbers (e.g., "Button.tsx:42-45")
data-is: The component name (e.g., "Button")
data-in: The parent component where this JSX appears (e.g., "Header")

Before and After

Your original JSX:

// src/components/Button.jsx
export const Button = ({ children, ...props }) => {
  return <button className="my-button" {...props}>{children}</button>
}

What gets rendered in development:

<button 
  data-in="Button" 
  data-is="button" 
  data-at="Button.jsx:3" 
  className="my-button">
  Click me
</button>

Now when you inspect any element, you instantly know:

Where it's defined (file and line)
What component it is
Which parent component contains it

The Real Game-Changer: Clickable Source Locations

But wait, it gets better! The plugin includes an optional devTools feature that lets you click on any element to open its source file directly in your IDE.

Here's how it works:

Enable the devTools option in your Babel config
Include the provided CSS and JavaScript files
Hover over any component to see its source information
Click the tooltip to jump straight to the code in your editor

The devTools feature supports:

VS Code (default)
IntelliJ IDEA
Atom
Sublime Text
Cursor

It even includes an interactive element picker mode - just click the target icon (🎯) and then click any element on your page to instantly navigate to its source code.

Installation & Setup

Getting started is incredibly simple:

Install the Plugin

npm install --save-dev babel-plugin-locate-source

For Vite + React Projects

Update your vite.config.js:

import react from "@vitejs/plugin-react";
import { defineConfig } from "vite";

export default defineConfig({
  plugins: [
    react({
      babel: {
        plugins: [
          ["babel-plugin-locate-source", { 
            enabled: true,
            devTools: true  // Enable clickable source locations
          }],
        ],
      },
    }),
  ],
});

For Next.js Projects

Create or update your .babelrc:

{
  "presets": ["next/babel"],
  "env": {
    "development": {
      "plugins": [
        ["babel-plugin-locate-source", { "devTools": true }]
      ]
    }
  }
}

Enable Clickable Features (Optional)

To enable the click-to-open functionality, include these files in your project:

<!-- In your HTML or component that loads globally -->
<link rel="stylesheet" href="node_modules/babel-plugin-locate-source/debug-styles.css">
<script src="node_modules/babel-plugin-locate-source/dev-tools.js"></script>

Why This Changes Everything

🎯 Instant Component Location

No more searching through dozens of files. Inspect the element and immediately see exactly where it's defined.

🏗️ Component Hierarchy Clarity

Understand parent-child relationships at a glance with the data-in attribute showing which component contains each element.

🚀 Zero Production Impact

The plugin automatically disables itself in production builds, so there's no performance overhead or extra attributes in your production HTML.

🔧 Universal Compatibility

Works with React, Next.js, and any Babel-based project. Set it up once and forget about it.

💡 Developer Experience

The optional devTools feature transforms debugging from a tedious search process into a single click operation.

Real-World Example

Imagine you're working on a complex dashboard with nested components:

<!-- What you see in dev tools -->
<div data-in="Dashboard" data-is="Card" data-at="Card.jsx:14-24" class="card">
  <div data-in="Card" data-is="div" data-at="Card.jsx:15" class="card-header">
    <h3 data-in="Card" data-is="h3" data-at="Card.jsx:16">Analytics</h3>
  </div>
  <div data-in="Card" data-is="div" data-at="Card.jsx:18" class="card-body">
    <p data-in="Card" data-is="p" data-at="Card.jsx:19">Revenue: $12,345</p>
  </div>
  <div data-in="Card" data-is="div" data-at="Card.jsx:21" class="card-footer">
    <button data-in="Button" data-is="button" data-at="Button.jsx:7" class="button">
      View Details
    </button>
  </div>
</div>

In seconds, you can see:

The main card is from Card.jsx lines 14-24
It's rendered inside the Dashboard component
The button is from Button.jsx line 7
Each element's exact location and hierarchy

Advanced Features

Visual Debug Mode

The plugin includes CSS styles that add visual indicators when you enable debug mode:

// Add this to your component
function toggleDebugMode() {
  document.body.classList.toggle('debug-mode');
}

This highlights all elements with source information and shows tooltips on hover.

Element Picker

Use the interactive picker to quickly identify any element's source:

Click the target icon (🎯) in the bottom-right corner
Click any element on your page
Instantly navigate to its source code

IDE Integration

The devTools feature works seamlessly with popular editors. You can configure your preferred IDE through a settings panel that appears when you include the devTools scripts.

Performance Considerations

Development Mode Only

By default, the plugin only runs when process.env.NODE_ENV === 'development', ensuring zero impact on production builds.

Minimal Overhead

The plugin adds a few small data attributes - the performance impact during development is negligible.

Smart Filtering

The plugin automatically skips processing files in node_modules, focusing only on your source code.

Why Every React Developer Needs This

Time Savings: What used to take 5-10 minutes of searching now takes 5 seconds.

Reduced Frustration: No more guessing which component is causing issues.

Better Code Understanding: Especially helpful when working with unfamiliar codebases or large teams.

Improved Debugging Workflow: The click-to-open feature creates a seamless development experience.

Zero Learning Curve: Install it once and it just works. No new commands to remember or workflows to learn.

Try It Today

Ready to eliminate the "Where's Waldo?" game from your React development workflow?

npm install --save-dev babel-plugin-locate-source

Check out the GitHub repository for complete documentation, examples, and more advanced configuration options.

Conclusion

In a world where developer productivity is paramount, tools that eliminate friction in our daily workflows are invaluable. babel-plugin-locate-source is one of those tools - simple to install, powerful in practice, and transformative for your debugging experience.

The next time you're staring at a mysterious DOM element in your browser's dev tools, instead of playing detective, you'll know exactly where to look. And with the devTools feature, you'll be there with a single click.

Have you tried babel-plugin-locate-source? How has it changed your debugging workflow? Share your experience in the comments below!

Want to see more tools that improve developer experience? Follow me for more posts about React development, debugging techniques, and productivity tools.

Creating a web3 DApp with a NX Monorepo - 3 of 5: Create backend app with NestJS

Apperside — Mon, 05 Aug 2024 09:40:06 +0000

The original baluni app had a backend implemented with ExpressJS that was doing some things:

it was calling some smart contract
it stores some data in a sqlite database
it exposes some endpoint to retrieve some data
it runs periodic tasks to update that data.

It's not in the scope of this article to analyze the what and the why of this backend, for now we just need to migrate in our brand new monorepo the old project.

This backend has just few non protected endpoints, so the porting should not be so complicated.

I am a fan of NestJS, so I decided to create the backend with it.

NX has a generator that can be used to quickly bootstrap a NestJS app in our monorepo.

The first thing to do is to install the generator

nx add @nx/nest

after installing it we can create the project

nx g @nx/nest:app baluni-backend

it will spin-up a bare bone NestJS app, with just one controller and one service (it is not in the scope of this document to enter in the technicale details of NestJS, you can learn more on their extensive docs)

Understanding the project

The original backend project comes from the baluni-ui package, which was also a monorepo itself.
This was the original structure:

I started by analyzing the index.ts file

import { fetchUnitPrices } from "./fetchUnitPrices";
import { fetchTotalValuation } from "./fetchTotalValuation";
import { fetchInterestEarned } from "./fetchInterestEarned";
import { dcaExecutor } from "./dcaExecutor";
import { reinvestEarnings } from "./reinvestEarnings";
import { rebalancePools } from "./rebalancePools";
import { fetchHyperPools } from "./fetchHyperPools";
import { deleteOldRecords } from "./deleteOldRecords";
import "./server";

var Table = require("cli-table");

async function main() {
  console.log("✔️ Starting main execution...");

  const tasks = [
    { name: "Fetching unit prices", func: fetchUnitPrices },
    { name: "Fetching total valuation", func: fetchTotalValuation },
    { name: "Fetching total interest earned", func: fetchInterestEarned },
    { name: "Executing DCA", func: dcaExecutor },
    { name: "Reinvesting earnings", func: reinvestEarnings },
    { name: "Rebalancing pools", func: rebalancePools },
    { name: "Fetching hyper pools data", func: fetchHyperPools },
    { name: "Deleting old records", func: deleteOldRecords },
  ];

  const table = new Table({
    head: ["Task", "Status"],
    colWidths: [50, 10],
  });

  for (const task of tasks) {
    try {
      console.log(`🚀 ${task.name}...`);
      await task.func();
      table.push([task.name, "✅"]);
    } catch (error) {
      console.error(`❌ Error in ${task.name}:`, error);
      table.push([task.name, "❌"]);
    }
    console.log("🎉 Done");
    await new Promise(resolve => setTimeout(resolve, 5000));
  }

  console.log(table.toString());
}

(async () => {
  const interval = Number(process.env.INTERVAL) || 3600000; // Default to 1 hour if INTERVAL is not defined
  setInterval(() => {
    main().catch(error => console.error("❌ Error in main execution:", error));
  }, interval);
  main().catch(error => console.error("❌ Error in main execution:", error));
})();

It was looking quite weird.

This was the app's entry point and what it was doing is scheduling some recurring tasks and running the server by importing the ./server file.

We can do a lot better.

Next I started exploring the server.ts file

import express from "express";
import path from "path";
import { open } from "sqlite";
import sqlite3 from "sqlite3";
import { calculateStatistics } from "./calculateStatistics";

const cors = require("cors");

const app = express();
const PORT = process.env.PORT || 3001;

app.use(
  cors({
    origin: "*", // Replace with your frontend's domain
    methods: "GET,HEAD,PUT,PATCH,POST,DELETE",
    allowedHeaders: "Content-Type,Authorization",
  }),
);

app.use(express.json());

const dbPromise = open({
  filename: path.join(__dirname, "..", "baluniData.db"),
  driver: sqlite3.Database,
});

// Endpoint per ottenere tutti i dati da hyperPoolsData
app.get("/api/hyperpools-data", async (req, res) => {
  try {
    const db = await dbPromise;
    const hyperpoolsData = await db.all("SELECT * FROM hyperPoolsData");
    res.json(hyperpoolsData);
  } catch (error) {
    res.status(500).json({ error: "Failed to fetch hyper pools data" });
  }
});

app.get("/api/valuation-data", async (req, res) => {
  try {
    const db = await dbPromise;
    const valuations = await db.all("SELECT * FROM totalValuations");
    res.json(valuations);
  } catch (error) {
    res.status(500).json({ error: "Failed to fetch valuation data" });
  }
});

app.get("/api/totalInterestEarned-data", async (req, res) => {
  try {
    const db = await dbPromise;
    const results = await db.all("SELECT * FROM totalInterestEarned");
    res.json(results);
  } catch (error) {
    res.status(500).json({ error: "Failed to fetch total interest data" });
  }
});

app.get("/api/unitPrices-data", async (req, res) => {
  try {
    const db = await dbPromise;
    const results = await db.all("SELECT * FROM unitPrices");
    res.json(results);
  } catch (error) {
    res.status(500).json({ error: "Failed to fetch unit prices data" });
  }
});

app.get("/api/statistics", async (req, res) => {
  try {
    const statistics = await calculateStatistics();
    res.json(statistics);
  } catch (error) {
    res.status(500).json({ error: "Failed to fetch statistics data" });
  }
});

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

Ok, this one looks much more clear: a very basic ExpressJS server listening on a bunch of routes each returning data fetched from the database.

Let's start bringing things in.

Integrating the code - sqlite support

The project was using a sqlite database, so I started looking for a way to integrate sqlite in a NestJS app and found this:

@homeofthings/nestjs-sqlite3 - npm

HomeOfThings - NestJs Sqlite3: Sqlite3 module for NestJs based on 'sqlite3orm'. Latest version: 2.0.2, last published: 7 months ago. Start using @homeofthings/nestjs-sqlite3 in your project by running `npm i @homeofthings/nestjs-sqlite3`. There are no other projects in the npm registry using @homeofthings/nestjs-sqlite3.

npmjs.com

It was quite straightforward to integrate, I just had to add it to my app.module.ts

And wherever I need access to the sqlite connection I can inject it like this

@Injectable()
export class MyService {
  constructor(connectionManager: ConnectionManager) {}
}

Integrating the code - controller/service/repository

At this stage my main goal is to make things work as they are, without over engineering things or refactoring code more than necessary.

For this reasons I decided to use the app.controller.ts that NestJS already created (instead of creating a dedicated controller/service/repository), and using app.service.ts to call the functions implemented in a repository class that I created, stats.repository.ts, responsible for performing the queries that was in the original project. For example:

The ConnectionManager class is injected from the sqlite package integration mentioned above.

In app.service.ts I just implemented specular methods:

An finally created the routes in app.controller.ts:

So, the only new thing I added for now was the repository class from where performing the queries, and then just used the controller and service to "forward" the requests.
In this way I encapsulated data access and provided modularity (for example, it would be easy to replace sqlite with anything else) without changing this too much.

Integrating the code - recurring tasks

The original codebase had a few files containing some business logic that was ran at regular intervals from index.ts.
Those file are the ones that in the original repository are implemented in this files:

Those files, in addition to the functions with the business logic, had some aspects in common.
For example, one of those files was looking like this:

let's analyze it:

In all files there was a call to dotenv.config() (like in line 15)
in all files there were those 2 constants:

const provider = new ethers.providers.JsonRpcProvider(String(process.env.RPC_URL));
const signer = new ethers.Wallet(String(process.env.PRIVATE_KEY), provider);

In all files there were, at some points, a call to this function (like at line 45)

registryCtx = await setupRegistry(provider, signer);

this is what setupRegistry was doing

import contracts from "baluni-contracts/deployments/deployedContracts.json";
import baluniRegistryAbi from "baluni-contracts/artifacts/contracts/registry/BaluniV1Registry.sol/BaluniV1Registry.json";

import { ethers } from "ethers";

export async function setupRegistry(provider: ethers.providers.JsonRpcProvider, signer: ethers.Signer) {
  const chainId = await provider.getNetwork().then((network: { chainId: any }) => network.chainId);

  let registryCtx;

  if (chainId === 137) {
    const registryAddress = contracts[137].BaluniV1Registry;
    if (!registryAddress) {
      console.error(`Address not found for chainId: ${chainId}`);
      return;
    }
    registryCtx = new ethers.Contract(registryAddress, baluniRegistryAbi.abi, signer);
  }

  return registryCtx;
}

So what I did was the following:

1- Added 2 custom providers to my app.module.ts

2- Create a new class called BaseWeb3Task:

import { Inject, Injectable } from '@nestjs/common';
import { ethers } from 'ethers';
import { baluniContracts } from 'baluni-contracts';
import { BaseTask } from './base.task';

@Injectable()
export abstract class BaseWeb3Task extends BaseTask {
  registryCtx: any;
  constructor(
    @Inject('rpcProvider') protected provider,
    @Inject('wallet') protected signer
  ) {
    super()
  }

  async setupRegistry(
    provider: ethers.providers.JsonRpcProvider,
    signer: ethers.Signer
  ) {
    const chainId = await provider
      .getNetwork()
      .then((network: { chainId: any }) => network.chainId);

    let registryCtx;

    if (chainId === 137) {
      const registryAddress =
        baluniContracts.baluniDeploiedContracts[137].BaluniV1Registry;

      if (!registryAddress) {
        console.error(`Address not found for chainId: ${chainId}`);
        return;
      }
      registryCtx = new ethers.Contract(
        registryAddress,
        baluniContracts.baluniRegistryAbi.abi,
        signer
      );
    }

    return registryCtx;
  }

  async initRegistry() {
    this.registryCtx = await this.setupRegistry(this.provider, this.signer);
  }

  abstract execute(...args: any[]): Promise<any>;
}

This is BaseTask.ts class

import { Injectable } from '@nestjs/common';

@Injectable()
export abstract class BaseTask {
  constructor() {}

  abstract execute(...args: any[]): Promise<any>;
}

and in each implementation I moved the logic under the execute method.

For example, the original file fetchUnitPrices.ts changed from this:

import baluniPoolAbi from "baluni-contracts/artifacts/contracts/pools/BaluniV1Pool.sol/BaluniV1Pool.json";
import baluniPoolRegistryAbi from "baluni-contracts/artifacts/contracts/registry/BaluniV1PoolRegistry.sol/BaluniV1PoolRegistry.json";
import baluniVaultRegistryAbi from "baluni-contracts/artifacts/contracts/registry/BaluniV1YearnVaultRegistry.sol/BaluniV1YearnVaultRegistry.json";
import baluniVaultAbi from "baluni-contracts/artifacts/contracts/vaults/BaluniV1YearnVault.sol/BaluniV1YearnVault.json";
import dotenv from "dotenv";
import { Contract, ethers } from "ethers";
import path from "path";
import { open } from "sqlite";
import sqlite3 from "sqlite3";
import baluniDCAVaultAbi from "baluni-contracts/artifacts/contracts/vaults/BaluniV1DCAVault.sol/BaluniV1DCAVault.json";
import baluniDCAVaultRegistryAbi from "baluni-contracts/artifacts/contracts/registry/BaluniV1DCAVaultRegistry.sol/BaluniV1DCAVaultRegistry.json";
import { setupRegistry } from "./setupRegistry";
import { formatUnits } from "ethers/lib/utils";

dotenv.config();

const provider = new ethers.providers.JsonRpcProvider(String(process.env.RPC_URL));
const signer = new ethers.Wallet(String(process.env.PRIVATE_KEY), provider);

let registryCtx: Contract | null | undefined = null;

async function fetchAndStoreUnitPrice(contract: Contract, address: string, db: any) {
  try {
    const unitPrice = await contract.unitPrice();
    const unitPriceData = {
      timestamp: new Date().toISOString(),
      unitPrice: unitPrice.toString(),
      address: address,
    };

    await db.run(
      "INSERT INTO unitPrices (timestamp, unitPrice, address) VALUES (?, ?, ?)",
      unitPriceData.timestamp,
      formatUnits(unitPriceData.unitPrice, 18),
      unitPriceData.address,
    );

    console.log("Unit Price data updated:", unitPriceData);
  } catch (error) {
    console.error(`Error fetching unit price for address ${address}:`, error);
  }
}

export async function fetchUnitPrices() {
  registryCtx = await setupRegistry(provider, signer);

  if (!registryCtx) {
    return;
  }

  const db = await open({
    filename: path.join(__dirname, "..", "baluniData.db"),
    driver: sqlite3.Database,
  });

  await db.exec(`
    CREATE TABLE IF NOT EXISTS unitPrices (
      id INTEGER PRIMARY KEY AUTOINCREMENT,
      timestamp TEXT NOT NULL,
      unitPrice TEXT NOT NULL,
      address TEXT NOT NULL
    )
  `);

  try {
    const poolRegistry = await registryCtx.getBaluniPoolRegistry();
    const poolRegistryContract = new ethers.Contract(String(poolRegistry), baluniPoolRegistryAbi.abi, provider);
    const pools = await poolRegistryContract.getAllPools();

    for (const pool of pools) {
      const poolContract = new ethers.Contract(pool, baluniPoolAbi.abi, provider);
      await fetchAndStoreUnitPrice(poolContract, pool, db);
    }
  } catch (error) {
    console.error("Error processing pool registry:", error);
  }

  try {
    const vaultRegistry = await registryCtx.getBaluniYearnVaultRegistry();
    const vaultRegistryContract = new ethers.Contract(String(vaultRegistry), baluniVaultRegistryAbi.abi, provider);
    const vaults = await vaultRegistryContract.getAllVaults();

    for (const vault of vaults) {
      const vaultContract = new ethers.Contract(vault, baluniVaultAbi.abi, provider);
      await fetchAndStoreUnitPrice(vaultContract, vault, db);
    }
  } catch (error) {
    console.error("Error processing vault registry:", error);
  }

  try {
    const dcaVaultRegistry = await registryCtx.getBaluniDCAVaultRegistry();
    const dcaVaultRegistryContract = new ethers.Contract(
      String(dcaVaultRegistry),
      baluniDCAVaultRegistryAbi.abi,
      provider,
    );
    const dcaVaults = await dcaVaultRegistryContract.getAllVaults();

    for (const vault of dcaVaults) {
      const vaultContract = new ethers.Contract(vault, baluniDCAVaultAbi.abi, provider);
      await fetchAndStoreUnitPrice(vaultContract, vault, db);
    }
  } catch (error) {
    console.error("Error processing DCA vault registry:", error);
  }

  await db.close();
}

To this:

import { ConnectionManager } from '@homeofthings/nestjs-sqlite3';
import { Inject, Injectable } from '@nestjs/common';
import { baluniVaultAbi, baluniVaultRegistryAbi } from 'baluni-contracts';
import { Contract, ethers } from 'ethers';
import { formatUnits } from 'viem';
import { baluniContracts } from 'baluni-contracts';
import { BaseWeb3Task } from './base-web3.task';

@Injectable()
export class UnitPriceTask extends BaseWeb3Task {
  constructor(
    private connectionManager: ConnectionManager,
    @Inject('rpcProvider') protected provider,
    @Inject('wallet') protected signer
  ) {
    super(provider, signer);
  }
  async fetchAndStoreUnitPrice(contract: Contract, address: string, db: any) {
    try {
      const unitPrice = await contract.unitPrice();
      const unitPriceData = {
        timestamp: new Date().toISOString(),
        unitPrice: unitPrice.toString(),
        address: address,
      };

      await db.run(
        'INSERT INTO unitPrices (timestamp, unitPrice, address) VALUES (?, ?, ?)',
        unitPriceData.timestamp,
        formatUnits(unitPriceData.unitPrice, 18),
        unitPriceData.address
      );

      console.log('Unit Price data updated:', unitPriceData);
    } catch (error) {
      console.error(`Error fetching unit price for address ${address}:`, error);
    }
  }

  async execute() {
    await this.initRegistry();

    if (!this.registryCtx) {
      return;
    }

    const db = await this.connectionManager.getConnectionPool().get();

    await db.exec(`
      CREATE TABLE IF NOT EXISTS unitPrices (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        timestamp TEXT NOT NULL,
        unitPrice TEXT NOT NULL,
        address TEXT NOT NULL
      )
    `);

    try {
      const poolRegistry = await this.registryCtx.getBaluniPoolRegistry();
      const poolRegistryContract = new ethers.Contract(
        String(poolRegistry),
        baluniContracts.baluniPoolRegistryAbi.abi,
        this.provider
      );
      const pools = await poolRegistryContract.getAllPools();

      for (const pool of pools) {
        const poolContract = new ethers.Contract(
          pool,
          baluniContracts.baluniPoolAbi.abi,
          this.provider
        );
        await this.fetchAndStoreUnitPrice(poolContract, pool, db);
      }
    } catch (error) {
      console.error('Error processing pool registry:', error);
    }

    try {
      const vaultRegistry =
        await this.registryCtx.getBaluniYearnVaultRegistry();
      const vaultRegistryContract = new ethers.Contract(
        String(vaultRegistry),
        baluniVaultRegistryAbi.abi,
        this.provider
      );
      const vaults = await vaultRegistryContract.getAllVaults();

      for (const vault of vaults) {
        const vaultContract = new ethers.Contract(
          vault,
          baluniVaultAbi.abi,
          this.provider
        );
        await this.fetchAndStoreUnitPrice(vaultContract, vault, db);
      }
    } catch (error) {
      console.error('Error processing vault registry:', error);
    }

    try {
      const dcaVaultRegistry =
        await this.registryCtx.getBaluniDCAVaultRegistry();
      const dcaVaultRegistryContract = new ethers.Contract(
        String(dcaVaultRegistry),
        baluniContracts.baluniDCAVaultRegistryAbi.abi,
        this.provider
      );
      const dcaVaults = await dcaVaultRegistryContract.getAllVaults();

      for (const vault of dcaVaults) {
        const vaultContract = new ethers.Contract(
          vault,
          baluniContracts.baluniDCAVaultAbi.abi,
          this.provider
        );
        await this.fetchAndStoreUnitPrice(vaultContract, vault, db);
      }
    } catch (error) {
      console.error('Error processing DCA vault registry:', error);
    }

    await db.close();
  }
}

So basically the idea is to create an implementation of BaseWeb3Task class, and passing in the super constructor the injected signer and provider and expose them as protected class members.

Then, when it is needed, we can call the initRegistry method declared in the parent class:

this function will make use of the injected signer and provider

Once ported all the files under this pattern, scheduling them was quite straightforward with NestJS's builtin scheduling feature.
I just needed to create a class called RecurringTasksService and create a method decorated with:

@Cron(CronExpression.EVERY_5_MINUTES)

The final file is this:

import { Injectable, Logger } from '@nestjs/common';
import { Cron, CronExpression } from '@nestjs/schedule';
import { Contract } from 'ethers';
import { DcaTask } from './impl/dca.task';
import { DeleteAllRecordsTask } from './impl/delete-old-records.task';
import { HyperPoolsTask } from './impl/hyper-pools.task';
import { InterestEarnedTask } from './impl/interest-earned.task';
import { PoolRebalanceTask } from './impl/pool-rebalance.task';
import { ReinverstEarningsTask } from './impl/reinvest-earnings.task';
import { TotalValuationTask } from './impl/total-valuation.task';
import { UnitPriceTask } from './impl/unit-price.task';

@Injectable()
export class RecurringTasksService {
  registryCtx: Contract | null | undefined = null;

  constructor(
    private interestEarnedTask: InterestEarnedTask,
    private poolRebalanceTask: PoolRebalanceTask,
    private reinverstEarningsTask: ReinverstEarningsTask,
    private totalValuationTask: TotalValuationTask,
    private unitPriceTask: UnitPriceTask,
    private dcaTask: DcaTask,
    private deleteRecordsTask: DeleteAllRecordsTask,
    private hyperPoolsTask: HyperPoolsTask
  ) {}
  private readonly logger = new Logger(RecurringTasksService.name);

  @Cron(CronExpression.EVERY_5_MINUTES)
  async handleCron() {
    const tasks = [
      { task: this.unitPriceTask, name: 'unit prices' },
      { task: this.totalValuationTask, name: 'total valuation' },
      { task: this.interestEarnedTask, name: 'interest earned' },
      { task: this.dcaTask, name: 'DCA' },
      { task: this.reinverstEarningsTask, name: 'reinvest earnings' },
      { task: this.poolRebalanceTask, name: 'pool rebalance' },
      { task: this.hyperPoolsTask, name: 'hyper pools data' },
      { task: this.deleteRecordsTask, name: 'delete old records' },
    ];

    for (const task of tasks) {
      try {
        await task.task.execute();
      } catch (err) {
        this.logger.error(`Error fetching ${task.name}:`, err);
      }
    }
  }
}

Adding dependencies

It is time now to add the project dependencies.
For the previous project I decided to add dependencies to the specific project and not hoisting them.
This decision was mainly taken because there were some web3 related dependencies using different versions in different projects (like ethers that was used with version 6.x.x in baluni-contracts and 5.x.x in other projects), and it was not in the scope of this iteration to standardize the libraries versions, also because I don't know much those tools (as I don't have yet much experience with web3 developement), so I opted for a conservative approach.

In this project, however, I am entering a field where I fill much more comfortable as I have a lot of experience with Express.js and NestJS.

So, this time I added the original project dependencies to the monorepo's root package.json

Running and building the project

As this is a quite simple project, I don't expect much to do in order to make things work.
I just had to verify if the .sqlite file coming from the original project was being taken in consideration in this NestJS project.

I saw that the NestJS project created by NX already has a folder called assets that was already configured with webpack

webpack.config.js

const { NxAppWebpackPlugin } = require('@nx/webpack/app-plugin');
const { join } = require('path');

module.exports = {
  output: {
    path: join(__dirname, '../../dist/packages/baluni-backend'),
  },
  plugins: [
    new NxAppWebpackPlugin({
      target: 'node',
      compiler: 'tsc',
      main: './src/main.ts',
      tsConfig: './tsconfig.app.json',
      assets: ['./src/assets'],
      optimization: false,
      outputHashing: 'none',
    }),
  ],
};

So I ran the project :

run baluni-backend:serve --configuration=development

and once fixed some typescript issue and making things to be imported from baluni-core, it worked as expected.

You can find the full final code here

In the next chapters we'll see how to integrate the web project and how to create the CLI app.

I will be very happy to answer to any question you will leave in the comments.

If you liked this article and would like to support my work, you can leave a like or follow me here on dev.to.

Creating a web3 DApp with a NX Monorepo - 2 of 5: Create the core library

Apperside — Fri, 02 Aug 2024 15:21:30 +0000

This is the third episode of a series about the work I've done to create a web3 DApp in a NX monorepo.

Check the previous articles to have a better context understanding.

BALUNI CORE

Creating the project

Once we have created the previous 2 projects with the contracts, we can start building the core library of our DApp.
This library will need to expose an "api" to consumers to allow them to perform common operations.

We will start by adding a new library to our monorepo

npx nx g @nx/js:lib baluni-core

Main goal ⚽

One of the mail goal here is to provide a good developer experience by offering a well organized set of import paths.
At the moment, the actual project is used like this:

import something from "baluni/dist/some/path

Note the dist piece in the import path, is so ugly!

We want instead to import things in a nicer way

import something from "baluni/feature1"
import somethingElse from "baluni/feature2"
// and so on

Importing the code

This is the original project's main code structure

I have to say my friend, quite messy, but I forgive you

Since digging in the code is not in the scope of this article, the goal was to bring in the monorepo the things as they are now.

So here I just did 2 things:

I copy/pasted core and api folders under the new library's src folder
copied all the dependencies from package.json the the library's package.json and prevented the hoisting as we did previously

This is the new library structure:

After importing the dependencies and the code (this project has no assets) I tried to build the project but I had to fix some typescript configurations that NX has set by default.

The first one was related to the fact that we are importing json files (the contracts).

I fixed this by setting "resolveJsonModule":true in the root tsconfig.base.json, typescript also made me set "esModuleInterop":true

With this in place, I was able to use this kind of import in baluni-core

import factoryAbi from 'baluni-contracts/artifacts/contracts/orchestators/BaluniV1AgentFactory.sol/BaluniV1AgentFactory.json'

After fixing that the project built successfully, let's see the output:

as we can see, this output contains the src folder, which makes it impossible to use the import as we wish.

Organizing import paths

As I said previously, we want to provide good developer experience by proving clear an well organized import paths.
Moreover, I'd like to do it without modifying the existing code.

By analyzing the actual used imports from outside, I decided to provide this imports

baluni-core: should export everything from the core folder
baluni-core/api: should export everything from api folder
baluni-core/utils: should export everything from core/utils folder
baluni-core/types: should export everything from core/types

In order to do that, we first need to add this to baluni-core's package.json

"exports": {
    ".": "./index.js",
    "./types": "./src/core/types/index.js",
    "./api": "./src/api/index.js",
    "./utils": "./src/core/utils/index.js"
  },

This is the final package.json

it will define additional entry points for our library as we wish.

Now we need to instruct NX to output the content of the source src folder to dist/packages/baluni-core instead of dist/packages/baluni-core/src

to make this we need to edit project.json:

After I had set the flag "rootDir": "packages/baluni-core/src", the build output was changed to this:

Now we have the proper build output so also this package is ready to be deployed on npm.

On the next articles we'll se how to create a cli, a backend and a NextJS app using this library.

You are very welcome to leave a comment, I will be happy to answer to all your questions.

Creating a web3 DApp with a NX Monorepo - 1 of 5: Libraries with solidity contracts

Apperside — Fri, 02 Aug 2024 13:40:06 +0000

This is the second episode of a series about the work I've done to create a web3 DApp in a NX monorepo.

Check the previous article to have a better context understanding

BALUNI CONTRACTS and BALUNI HYPERVISOR CONTRACTS

I started the migration with these 2 projects because they are at the bottom most of the dependency chain.

Creating the NX package

These 2 projects are not runnable ones, but they are libraries, so I went through the vast collection of templates that NX offers (you can find the full list here).

From that list, the library generator seemed the most reasonable choice, so I ran the command provided in the docs

npx nx g @nx/js:lib baluni-contracts

it inrectactively asked me some questions:

In the last prompt, I chose the second option, and it told me that this option is going to be deprecated in the near future in favor of this syntax:

nx g @nx/js:library baluni-contracts --directory packages/baluni-contracts

This is less dev friendly so I don't understand why they remove this.

After making all the choices, NX quickly generated the project

It is a bare bone project with a pre-configured entry point (index.ts) that exports from the lib folder

So far, so good.

I wont dig into every single file otherwise it would become an endless article.

When you generate a library with NX, you can’t “run” it, you can just build it or include it in other projects, so I tried to build it to see what the output is

I didn’t like much that the build contains an src folder but for the moment I ignored it and went forward to integrate the rest of the project.

Importing files

I don't have any knowledge about smart contracts, solidity, hard etc, but I have enough experience to know that a project is made of

configuration files (like .eslintrc, .prettierrc, tsconfig.ts etc..),
source code
assets
dependencies.

For The first ones we'll use the ones NX has generated for us, so we need to import all the rest from the old project.

Let's start from the dependencies.

Integrate package.json dependencies

NX created the project with a package.json specific for the library, this makes sense as it comes handy when we compile it to publish on npm.

I always knew that the rule of thumb in NX projects is to add dependencies to the root package.json, but when I analyzed the original projects I saw different versions of the the same libraries (like hardhard, ehers and others) across projects, so I decided to take a conservative approach and added them to baluni-contracts's package.json and instruct yarn to not hoist dependencies for this project, as they would clash later when adding the other projects.

Avoid hoisting

To instruct yarn to not hoist dependencies for this project I found a useful setting on yarn's documentation.
So I had to add this:

`baluni-contracts/package.json`

  "installConfig": {
    "hoistingLimits": "dependencies"
  },

`snippet of baluni-contracts/package.json`

After running yarn I was sad to see that al node_modules have all been hoisted at the root, except few. Not as expected

After struggling I bit, I understood that flag is for more recent versions of yarn, and I was using yarn 1.

So I switched to the last version of yarn:

yarn set version stable

and ran yarn again.

This time, after an apparently successfully operation, the node_modules folder didn't exist at all 🤔

After some more research, I found that it was because recent versions of yarn use, by default, a different mechanism for handling modules, but I don't know how to use it and this is not the moment to learn it (but I would like to learn it, maybe I'll speak about it in the future).

To make things work with node_modules, I had to add this to the file .yarnrc.yml(it was created by yarn when we upgraded it).

The created file was this:

yarnPath: .yarn/releases/yarn-4.3.1.cjs

But I had to add this:

yarnPath: .yarn/releases/yarn-4.3.1.cjs
+ nodeLinker: node-modules

it tells to yarn to use the node_modules way to save modules.

Now after running yarn from the monorepo root I can successfully see all the needed dependencies under packages/baluni-contracts/node_modules

GREAT 💪

Integrate assets

Now it's time to integrate the source code and the assets (and few configs) in the new codebase.

The original project structure was this:

At a first sight, it looks we need to bring in all the folders in the project root and some configuration file, so in the end I decided to bring in the root of the new project everything from the original one except:

.github folder (I will handle actions in a later iteration)
.yarn folder (we have our own)
cache
typechain-types (they are auto generated from build scripts)
all configuration files (eslint, pretties, tsconfig ecc..), except for **.solhint.json** (needed by solidity), **hardhat.config.ts**,

And the final thing was to bring in the package.json's scripts

 "scripts": {
    "account": "hardhat run scripts/listAccount.ts",
    "chain": "hardhat node --network hardhat --no-deploy",
    "compile": "hardhat compile",
    "deploy": "hardhat deploy",
    "fork": "MAINNET_FORKING_ENABLED=true hardhat node --network hardhat --no-deploy",
    "generate": "hardhat run scripts/generateAccount.ts",
    "lint": "eslint --config ./.eslintrc.json --ignore-path ./.eslintignore ./*.ts ./deploy/**/*.ts ./scripts/**/*.ts ./test/**/*.ts",
    "lint-staged": "eslint --config ./.eslintrc.json --ignore-path ./.eslintignore",
    "test": "REPORT_GAS=true hardhat test --network hardhat",
    "verify": "hardhat etherscan-verify",
    "hardhat-verify": "hardhat verify"
  },

At this point, the only thing left to do is to verify if we can compile the contracts:

cd packages/baluni-contracts
yarn compile

This is the output

➜  ~/dev/temp/baluni-monorepo git:(main) cd packages/baluni-contracts                                                            [9:54:01]
➜  ~/dev/temp/baluni-monorepo/packages/baluni-contracts git:(main) ✗ yarn compile                                                [9:56:08]
Solidity 0.8.25 is not fully supported yet. You can still use Hardhat, but some features, like stack traces, might not work correctly.

Learn more at https://hardhat.org/hardhat-runner/docs/reference/solidity-support

Warning: Unnamed return variable can remain unassigned. Add an explicit return with value to all non-reverting code paths or name the variable.
   --> contracts/pools/BaluniV1Pool.sol:691:75:
    |
691 |     function getAssetReserve(address asset) public view override returns (uint256) {
    |                                                                           ^^^^^^^


Warning: Unused function parameter. Remove or comment out the variable name to silence this warning.
   --> contracts/pools/BaluniV1Pool.sol:870:32:
    |
870 |     function generateTokenName(address[] memory _assets) internal pure returns (string memory) {
    |                                ^^^^^^^^^^^^^^^^^^^^^^^^


Warning: Unused try/catch parameter. Remove or comment out the variable name to silence this warning.
   --> contracts/vaults/BaluniV1YearnVault.sol:257:22:
    |
257 |             } catch (bytes memory reason) {
    |                      ^^^^^^^^^^^^^^^^^^^


Warning: Function state mutability can be restricted to pure
  --> contracts/mock/MockRebalancer.sol:93:5:
   |
93 |     function checkRebalance(
   |     ^ (Relevant source part starts here and spans across multiple lines).


Warning: Function state mutability can be restricted to pure
   --> contracts/mock/MockRebalancer.sol:101:5:
    |
101 |     function getBaluniRouter() external view returns (address) {
    |     ^ (Relevant source part starts here and spans across multiple lines).


Warning: Contract code size is 30854 bytes and exceeds 24576 bytes (a limit introduced in Spurious Dragon). This contract may not be deployable on Mainnet. Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.
  --> contracts/orchestators/BaluniV1Router.sol:58:1:
   |
58 | contract BaluniV1Router is
   | ^ (Relevant source part starts here and spans across multiple lines).


Warning: Contract code size is 33507 bytes and exceeds 24576 bytes (a limit introduced in Spurious Dragon). This contract may not be deployable on Mainnet. Consider enabling the optimizer (with a low "runs" value!), turning off revert strings, or using libraries.
  --> contracts/pools/BaluniV1Pool.sol:54:1:
   |
54 | contract BaluniV1Pool is
   | ^ (Relevant source part starts here and spans across multiple lines).


Generating typings for: 76 artifacts in dir: typechain-types for target: ethers-v6
Successfully generated 224 typings!
Compiled 71 Solidity files successfully (evm targets: cancun, istanbul).
➜  ~/dev/temp/baluni-monorepo/packages/baluni-contracts git:(main) ✗

BAM!🎉
Even with some warning (that was present also in the original project) it worked, so all the tools and dependencies are working.

Making it publishable

The final thing was to make it publishable, and it means that it need to have the source and built contracts in the published package.

If we try do build the project now, the build folder will be like this:

but that's not what we want, we also need the contracts and artifacts folders.

Let's configure the project for that:

we need just to tell nx to include those assets in the build target configuration, so we need to modify packages/baluni-contracts/project.json.
The file content generated by NX was this

{
  "name": "baluni-contracts",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "sourceRoot": "packages/baluni-contracts/src",
  "projectType": "library",
  "tags": [],
  "targets": {
    "build": {
      "executor": "@nx/js:tsc",
      "outputs": ["{options.outputPath}"],
      "options": {
        "outputPath": "dist/packages/baluni-contracts",
        "main": "packages/baluni-contracts/src/index.ts",
        "tsConfig": "packages/baluni-contracts/tsconfig.lib.json",
        "assets": ["packages/baluni-contracts/*.md"]
      }
    }
  }
}

for our purposes we need to edit the assets to include what we need

Let's try to build the project now to see what the output looks like:

Amazing!

You will notice that we have that src folder that does actually nothing because the library just exposes contracts and to not contains code, we leave this folder there for now.
Apart from this, in our build folder we have a package.json and our assets, this build output seems perfect to be published to npm as a standalone package.

Job 1 Done! 🎉

An identical approach has been used to bring in the other project containing contracts (baluni-hypervisor-contracts).

In the following articles we'll see the integration of baluni-core that will consume the 2 library project we just created

Creating a web3 DApp with a NX Monorepo

Apperside — Fri, 02 Aug 2024 10:12:29 +0000

This is a story about how I turned this, this, this and this projects into this NX monorepo containing a full web3 Dapp.

At the end of the story we'll turn this process into a web3 dapp starter kit repository.

I will not drill down to the details of the code, as it is not the focus of this series (and actually needs to be strongly refactored), rather than I want to highlight the main challenges and the problems I encountered (and how I solved them ), and the approach I used to quickly make this migration starting from a never seen before codebases and without any web3 development knowledge.

Let’s start by giving a little bit of context:

A friend of mine asked me to help him with an opensource web3 project, called Baluni, he is working on. This project helps balancing assets in your portfolio, but talking about this is not in the article's scope.

He his a brillant solidity developer with quite good programming skills, but he does not identify him self as a professional developer (he is a musician actually) even though he can code much better than a lot of people that identify them self as professional developers 😁.

He asked me to join the project to help him giving a more professional and maintainable structure to the project that, at that moment, was actually quite bad structured as it consisted of the following distinct projects:

BALUNI CORE (link): It is the project that contains the core functionalities plus it has been somehow configured to run as a kind of cli, we'll see it later.
BALUNI CONTRACTS (link) and BALUNI HYPERVISOR CONTRACTS (link): These 2 projects are the projects with the core smart contracts and they must be consumed by other projects in the form of an npm library
BALUNI UI (link): this project is a monorepo itself, and it contains an ExpressJs server and a NextJS app

I hadn't any doubt about the fact that a monorepo was absolutely needed here, and either I hadn't any doubt about the tool to use: NX.
I used it in the past for small projects, but I was really impressed of it, so I was excited to use it for this job.

Even if, as I said, I don't have any knowledge about web3 development, I was able to analyze the projects, understand their dependencies and the relationships between the project. I planned the migration to be implemented as a monorepo with the following projects:

baluni-contracts: library with contracts
baluni-hypervisor-contracts: library with contracts
baluni-core: core functionalities extracted from baluni project
baluni-cli: the cli was badly inglobated in the core, I'll make a dedicated project for it
baluni-web: extracted from baluni-ui monorepo
baluni-backend: extracted from baluni-ui monorepo

So basically the idea is the following:

Make a library out of the projects containing the contracts
Make the baluni-core library which will use the contracts libraries (and exposes them)
Make the baluni CLI application which uses baluni-core
Make the baluni backend which uses baluni-core
Make the baluni web app which uses baluni-core and baluni-backend

So, stop talking and let's make our hands dirty.

CREATING THE MONOREPO

Before all, I started a blank NX project following their guidelines, so I just executed the following command:

npx create-nx-workspace

It started an interactive cli asking me about some preferences, like this

I choose to don’t use any preset as I want to start as clean as possible and and project one by one and keep track of the process. Let's go ahead

At this point I choose the first one.

For the curious ones, this is the difference between these options (taken from their docs):

Standalone Application - A repository with a single application
Package-Based Repository - A repository with multiple projects that depend on each other via package.json and often have nested node_modules
Integrated Repository - A repository with multiple projects that depend on each other via typescript imports and often employ a single version policy

I choose the first option because my app is not a stand alone one and I didn’t want to enter the “single version policy” world at this stage.

Here I went straight and choose to do it later as I don’t want to care about it for now

They try to onboard you to their cloud services, I don’t care now about it, maybe I will write a dedicated article about it

At this point NX will work a bit and will download and setup the project.

As I didn’t selected any preset it was quite quick, but if you choose a preset it will need to download and install all the related dependencies.

Ok, now the project is created

Since we have chose to start with a blank project, tt contains a bare bone application with nothing much to talk about.

Things will get interesting along the way and you will discover the power of NX when we'll start adding projects.

Along the way, we'll see nice things about NX, like

how to create typescript libraries with NX and how to make them publishable on npm
how to add custom assets to libraries
how to avoid hoisting dependencies for a single project
how to generate a package.json in the build output with the used dependencies used by the package
how to create and easily run a CLI application inside an nx monorepo

and many more things.

This serie or article will follow with the following articles:

Baluni Contracts: creating a npm library in a NX Monorepo
Baluni Core: creating a typescript library (baluni-core) in an nx monorepo that depends on other packages
Baluni CLI: creating a CLI application in an NX project
Baluni Backend: creating a NestJS backend in an NX monorepo
Baluni Web: creating a web3 NextJS application in an NX monorepo

You are very welcome to leave your comments, like the post and follow me if you liked this article and are interested in the following ones