Forem: kanta1207

How Browsers Parse a URL

kanta1207 — Sun, 20 Jul 2025 20:15:43 +0000

Step 1: Breaking Down the URL String

When a user enters a URL into the browser's address bar, such as:

https://example.com:443/path/page?query=1#hash

the browser parses this string into meaningful components. Each part plays a distinct role in how the browser handles the request:

Component	Example	Meaning
Scheme	`https`	Indicates the communication protocol (e.g., HTTP, HTTPS, FTP)
Host Name	`example.com`	The domain to be resolved via DNS
Port	`443`	The specific port on the server to connect to; defaulted if omitted
Path	`/path/page`	The location of the resource on the server
Query	`?query=1`	Additional parameters sent to the server
Fragment	`#hash`	Internal page reference; not sent to the server

Notes on Each Part

Scheme (https): Determines how the browser will communicate. For instance, https implies encrypted communication via TLS, default port 443, and a secure connection.
Host Name (example.com): Will be sent to the DNS resolver to be translated into an IP address.
Port (:443): Specifies the endpoint on the server. If omitted, browsers infer the default from the scheme.
Path (/path/page): Used to identify the specific resource being requested on the server.
Query (?query=1): Key-value pairs often used to send data like form inputs or filters.
Fragment (#hash): A client-side reference for in-page navigation. This part is not sent in the HTTP request.

In short: the browser transforms a flat string into a structured object that can inform each subsequent stage — from DNS resolution to sending an HTTP request.

Step 2: How Each Part Affects the Request Lifecycle

Once the URL is parsed, the browser begins to act on the parsed data:

🔐 Scheme

Determines whether the browser must establish a secure (TLS) connection or a regular connection.
Defines the default port (e.g., 443 for HTTPS, 80 for HTTP).
Influences protocol selection (HTTP, FTP, mailto, etc.).

🌐 Host Name

Used in the DNS resolution process to obtain an IP address.
The resolved IP becomes the basis of the TCP connection.
May affect routing or security checks (e.g., CORS or certificate validation).

🔌 Port

Tells the operating system which port to connect to on the server.
If omitted, defaults to the port defined by the scheme.
Rarely modified in everyday browsing, but crucial in development or proxy scenarios.

📂 Path

Specifies the exact resource requested on the server.
Interpreted by the server's routing logic (e.g., /about, /api/user/42).
May influence internal processing (e.g., returning different content based on path).

❓ Query

Supplies parameters or filters to the server-side application.
Commonly used in search, form submission, pagination, etc.
Appears in server logs and analytics.

🧭 Fragment

Handled entirely on the client-side — never sent to the server.
Used for jumping to sections within a document (e.g., #faq, #top).
Also used in some SPA frameworks for client-side routing (/#/home).

Understanding how each component drives downstream behavior is key to debugging issues and designing robust applications.

Next: In the following chapter, we’ll look at how the browser uses the parsed host name to perform DNS resolution, and how that process determines the IP address needed to continue the request.

Designing and implementing a Point System with Cash-Out Support using Event-Based Architecture, Hono, and DrizzleORM

kanta1207 — Fri, 04 Jul 2025 02:51:01 +0000

Introduction

About a year ago, I had the opportunity to design and implement a point reward system where points held real monetary value and could be used in various financially meaningful ways.

This wasn’t your typical loyalty system. The points had to be trackable, tamper-proof, and auditable, since they represented real economic value to users. They could be earned, transferred, or spent in ways that required full integrity and transparency.

To meet those requirements, I chose to structure the system around immutable event logs, inspired by Event Sourcing principles. In this article, I’ll share the architecture and reasoning behind it, and walk through how I handled challenges like FIFO consumption, expiration tracking, and real-time balance computation.

Why an Event-Based Architecture?

At first glance, a point system seems simple:

Users earn points
Users spend points
You show their current balance

But once you introduce cash-out, expiration, and transferability, complexity skyrockets.

In our case, we needed to support:

Multiple types of point acquisition (referral bonuses, visit rewards, promotional campaigns)
Peer-to-peer transfers between users
Cash-out requests with minimum thresholds
FIFO consumption — oldest points are used first
180-day expiration policy
Full transaction history and audit trail
Fraud prevention and balance validation

Trying to manage this with a single balance field would’ve been risky and error-prone:

It’s hard to ensure consistency with parallel operations
There’s no audit trail for how the balance changed
You lose the ability to reconstruct past states or investigate issues

Instead, I designed the system to:

Store every point-related event (both acquisition and usage) immutably.
The current balance is always derived — never stored.

This gave us a consistent, auditable, and extensible system that scaled well even as usage grew. In the next section, I’ll walk through the system's structure at a high level.

System Overview

The point system was part of a broader application where users could earn, send, and redeem points in various ways. Here's an overview of the main business flows:

✅ Point Earning

Users received points from actions like:
- Signing up (e.g., 500 points)
- Referring friends (e.g., 5,000 points for successful invites)
- Making in-store reservations or purchases
Each point reward had an expiration date (typically 180 days)

♻ Point Usage

Points could be:
- Sent to another user (peer-to-peer transfer)
- Used at participating stores
- Redeemed as real money through a bank transfer request
All point deductions followed a FIFO consumption strategy:
- The oldest unexpired points were used first

🧾 Audit & Integrity

Every point acquisition and usage event was logged immutably
The current balance was never stored — it was computed in real-time by subtracting total deductions from total acquisitions
The system supported:
- Real-time balance validation
- Transaction history views
- Strict referential integrity between event types

🔐 Atomic Transactions

All multi-step point operations (e.g., transfers, redemptions) were wrapped in DB transactions
Any failure during deduction or event logging would roll back the entire operation

Event Store Design: Modeling Points as Events

The core idea behind this system was simple:

Never store balances — only store events.

Instead of mutating a user’s total balance directly, we created a set of immutable, append-only event tables:

✅ 1. `point_credits` — Point Acquisition Events

Every time a user earned points, we inserted a row into point_credits.

{
  id: 101,
  userId: 1,
  amount: 500,
  expiresAt: '2025-12-01',
  createdAt: '2025-06-01',
  source: 'referral_bonus',
}

Each row is a single “credit event”
Points expire after a fixed period (e.g., 180 days)
No updates — only inserts

✅ 2. `point_usages` — Point Deduction Events

When users used points — for redemption, transfer, or purchase — we inserted a row into point_usages.

{
  id: 201,
  userId: 1,
  amount: 1000,
  reason: 'cashout_request',
  createdAt: '2025-06-15',
}

This records the intention to use N points for some action. But it doesn’t specify which earned points were used — that’s handled by the next table.

✅ 3. `point_consumption_log` — FIFO Breakdown of Usage

To enforce FIFO (first-in, first-out) consumption, we maintained a third table that linked each usage event to the specific credits it consumed.

{
  id: 301,
  usageId: 201,
  creditId: 101,
  amount: 500
}

This table represents the actual “application” of usage
It allows us to:
- Calculate remaining amounts on each credit
- Track exactly which points were consumed and when
- Handle expiration by ignoring expired credits during deduction

♻ Example Flow: Spending 1,000 Points

Let’s say a user has two credits:

500 points from referral (expires in 30 days)
1,000 points from a visit (expires in 180 days)

They spend 1,000 points.

Here’s what happens:

Insert into point_usages — usage of 1,000 points
FIFO logic triggers:
- 500 consumed from the first credit
- 500 from the second
Insert two rows into point_consumption_log reflecting this breakdown

🔒 Benefits of This Model

Auditability: Every transaction is traceable
Expiration support: Easy to filter out expired credits
Balance integrity: No risk of double-spending or mismatched states
Real-time computation: Balances are calculated on-the-fly from event logs

Balance Calculation & FIFO Logic

With all point events stored immutably, we needed a way to compute the current balance on the fly, accurately and efficiently. Here's how we approached it.

🧾 Balance Calculation from Events

The core formula is simple:

current_balance = sum(point_credits.amount) - sum(point_consumption_log.amount)

We only consider unexpired credits, and we join the tables to subtract what's already been used.

await db
  .select({
    userId: pointCredits.userId,
    balance: sql<number>`SUM(${pointCredits.amount}) - COALESCE(SUM(${pointConsumption.amount}), 0)`
  })
  .from(pointCredits)
  .leftJoin(pointConsumption, eq(pointCredits.id, pointConsumption.creditId))
  .where(gt(pointCredits.expiresAt, sql`CURRENT_TIMESTAMP`))
  .groupBy(pointCredits.userId)

♻ FIFO Deduction Algorithm (Drizzle ORM style)

export const generatePointConsumptionLog = (
  usageId: number,
  amount: number,
  availableCredits: { id: number; amount: number }[]
): InsertPointConsumption[] => {
  const result: InsertPointConsumption[] = []
  let remaining = amount

  for (const credit of availableCredits) {
    if (remaining <= 0) break

    const consume = Math.min(credit.amount, remaining)
    result.push({
      usageId,
      creditId: credit.id,
      amount: consume,
    })
    remaining -= consume
  }

  return result
}

⚖️ Why No Snapshots or CQRS?

We deliberately avoided introducing snapshots or separate query models, for a few reasons:

Simplicity
The real-time queries were fast enough at our expected scale. Adding snapshot logic would complicate maintenance.
Data freshness
Since the balance could change at any time, deriving it live guaranteed consistency without syncing snapshot states.
Auditability
With the full event trail, we could reconstruct any past state without needing snapshot checkpoints.

That said, we left the door open for future optimization using materialized views or caching — but we didn’t need them initially.

Conclusion

Designing a point system with real-world financial implications forced me to think beyond simple balance += x logic.

By treating each point action as an immutable event, I gained:

Confidence in data correctness
Transparency in user histories
Flexibility to extend features without breaking invariants

This was my first experience with an event-sourced model, and it taught me that you don’t need a full CQRS stack to get the core benefits. With a few well-designed tables and clean logic, even a modest team can build robust systems that stand up to financial scrutiny.

If you're building a system where integrity and auditability matter, I highly recommend thinking in events.

Thanks for reading! 🚀

A Practical Approach to Solving Performance Issues in React Apps with Large Lists #2

kanta1207 — Tue, 03 Jun 2025 18:09:30 +0000

In Previous post, I shared how we tackled performance issues in our React application by identifying and addressing unnecessary re-renders.

But in our case, we had a more specific challenge:

The page had up to 200 editable list items shown at once
Pagination wasn’t an option — users needed to interact with all items together
Even after optimizing rendering logic, we still couldn’t hit target performance metrics or deliver a smooth UX

So we started thinking:

Can we reduce the number of components rendered without breaking the user experience?

This led us to consider infinite scrolling and virtual scrolling.

What is Infinite Scroll?

Infinite scroll is a technique where more items are dynamically loaded as the user scrolls toward the end of the list.

How it works:

You initially render a small number of items (say 20).
As the user scrolls near the bottom, a trigger fires (e.g. intersection observer or scroll event).
A request is made to fetch the next batch of data.
The newly fetched items are appended to the existing list, increasing the number of DOM elements.

This approach is great when:

Users are browsing or consuming content (like a social feed)
Lazy loading is acceptable
The total number of items is unknown or very large

But the downside:

DOM keeps growing as you scroll — which can slow down the app over time
Doesn’t help if your users need to interact with the full list, not just browse

What is Virtual Scroll?

Virtual scroll, on the other hand, renders only what’s visible in the viewport (plus a small buffer), and dynamically mounts/unmounts items as the user scrolls.

How it works:

A container tracks the scroll position
Only the list items within (or near) the visible area are actually rendered in the DOM
As you scroll:
- Off-screen components are unmounted
- New components are mounted just-in-time as they enter view
The full height of the scrollable area is simulated using padding/spacers so the scroll bar still behaves like a normal long list

This technique is perfect when:

You have a long or infinite list
Performance and memory usage matter
You want to avoid bloating the DOM with hundreds of elements

But it’s not free:

It adds complexity, especially with interactive components like editable forms
State management between mounts/unmounts needs careful handling

Our Decision: Go with Virtual Scroll

For our use case, virtual scroll made way more sense:

We didn’t need to change backend API behavior — no offset/limit logic required
It gave us predictable performance regardless of scroll depth
Infinite scroll would have caused the DOM to grow endlessly, which is exactly what we were trying to avoid

It was the cleanest way to keep all 200 items usable on one page without actually rendering all 200 at once.

In the next post, I’ll share how we implemented virtual scrolling with TanStack Virtual, and what we learned while integrating it with editable form components.

Stay tuned!

supabase_vector_project container is not ready: unhealthy when using Rancher Desktop

kanta1207 — Sat, 17 May 2025 21:27:43 +0000

If you're using Rancher Desktop and ran into this error when running supabase start:

supabase_vector_project container is not ready: unhealthy

You're not alone — and here's what likely caused it (and how to fix it):

🔍 Problem

Supabase CLI uses Docker under the hood, and it expects to communicate with the Docker Engine via a well-behaved socket or TCP endpoint.

Rancher Desktop (especially with containerd or non-default networking setups) can cause issues with:

Port forwarding
DNS resolution
Health checks (like with the vector container)

This often results in the vector container going into an unhealthy state, crashing the entire setup.

✅ Solution

I recommend switching to Docker Desktop if you're planning to use Supabase CLI locally.

On Docker Desktop:

Supabase CLI is better supported and more stable
If needed, enable: "Expose daemon on tcp://localhost:2375 without TLS" (from Docker Desktop settings → General)

This change instantly fixed the issue for me.

Hope this saves someone hours of debugging. Feel free to comment if you've found a better way!

A Practical Approach to Solving Performance Issues in React Apps with Large Lists #1

kanta1207 — Sat, 12 Apr 2025 23:46:09 +0000

Performance issues in React apps are frustrating — and tricky. You make one small change and suddenly the page lags, clicks delay, or scrolling becomes janky. We recently ran into this exact situation, and I want to share not just what we did, but how we approached it — because the approach matters just as much as the fix.

Here’s how we tackled it.

Step 1: Recognize the Problem Early

Performance issues rarely hit all at once — they creep in as your app scales. That’s why it’s always worth asking early:

“It’s fast now… but what happens when this list grows to 100 or 200 items?”

In our case, we had a page displaying editable form items. Everything worked great — at first. But once the number of items grew, cracks started to show:

Around 100 items: it started to lag
At 500: noticeable slowdowns
By 1000: it was borderline unusable
Initial render was painfully slow
Scrolling lagged
User interactions were sluggish

One common solution here is pagination — but that didn’t work for us.

Why? Because our users needed to see and interact with the entire list at once. Breaking it up would have killed their workflow.

So we knew we had to fix the performance itself, not just hide it behind paging.

Step 2: Define What "Good" Looks Like

Before jumping into optimization, take a step back:

What does “solved” actually mean?

Performance is a rabbit hole — you could spend days tuning things that don't actually help users. So we aligned on two things:

Metrics that matter:

We used Web Vitals to set our success criteria.
- LCP (Largest Contentful Paint) under 2.5s
- INP (Interaction to Next Paint) under 200ms
Realistic usage scope:

We checked with stakeholders: would users really have 1000 items?

Answer: not likely. The real-world upper limit was closer to 200.

That helped us stay focused and avoid over-engineering.

✅ With clear metrics (LCP, INP) and realistic scope (200 items), we had a solid definition of “problem solved.”

Step 3: Investigate the Root Cause

Once we had our target and scope locked down, the next step was to figure out what's actually causing the slowness.

Frontend performance issues can come from many places:

Too many DOM nodes?
Inefficient state updates?
Large bundle size?
Layout shifts?
Expensive third-party components?
Or… unnecessary React re-renders?

We looked at all of those. But in React apps, unnecessary re-rendering is one of the most common — and often easiest — performance killers.

And thanks to tools like React Scan, it’s surprisingly quick to check.

Sure enough, React Scan showed a lot of wasteful re-renders — even small updates were triggering large parts of the UI to update. That gave us a clear direction for optimization.

Optimization: Minimizing Re-renders

Once we pinpointed where unnecessary re-renders were happening, we took action by applying a few common React techniques:

useCallback: This hook ensures that functions are not redefined unnecessarily, preventing components from re-rendering when their props haven’t changed. We used it to memoize event handlers and callbacks that were being redefined on every render.
useMemo and React.memo: Both of these were used to prevent unnecessary recalculations. We memoized expensive computations and wrapped functional components with React.memo to avoid unnecessary re-renders when props didn’t change.

These optimizations reduced the number of renders, kept the UI smoother, and ultimately helped us stay on top of performance.

Even after implementing these improvements, the application still felt rough when dealing with 100-200 items. While the app was smoother and we saw better metric scores, it wasn't quite there yet.

So what did we do next?

I’ll share our next steps — and how we introduced virtual scrolling — in the next post.

Tech Note: Type inference takes place when initializing variables and members

kanta1207 — Tue, 14 May 2024 20:24:28 +0000

This article is basically a tech note reflecting the things I got stack with.

What I got stuck with

When I was trying to use RPC for the first time with Hono, my hono client instance kept being inferred as type unknown, even though I was sure that I was exporting the correct type from the server.

I'll leave brief information about Hono & RPC.

What is Hono?

Hono is a web framework mainly for building APIs with TypeScript. It is designed to be simple,fast, and easy to use.
It's reckon as a modern alternative to Express.js.

Officail documentation

What is RPC?

RPC stands for Remote Procedure Call.
It is a protocol that one program can use to request a service from a program located in another computer in a network without having to understand the network's details.

In the context of web development, it is a way to call a function on a remote server as if it were a local function.
To be more specific & frank in here, it's a way to share API specifications between the server and the client.

RPC documentation in Hono

Here's step by step summary of what I did.

Step1: `Expenses` route for sample app.

I wrote a simple CRUD API for Expenses in the server side with Hono, as I used to do with Express.

// server/routes/expenses.routes.ts
import { zValidator } from '@hono/zod-validator';
import { Hono } from 'hono';
import z from 'zod';

const expenseSchema = z.object({
  id: z.number().int().positive().min(1),
  name: z.string().min(3).max(255),
  amount: z.number(),
});

type Expense = z.infer<typeof expenseSchema>;

const expenses: Expense[] = [
  { id: 1, name: 'Rent', amount: 1000 },
  { id: 2, name: 'Food', amount: 200 },
  { id: 3, name: 'Internet', amount: 50 },
];

const expensesRoute = new Hono();

expensesRoute.get('/', (c) => {
  return c.json({ expenses: [] });
});

expensesRoute.post('/', zValidator('form', createPostSchema), async (c) => {
  const expense = await c.req.json();

  expenses.push(expense);
  return c.json(expense);
});

expensesRoute.get('/:id', (c) => {
  const id = parseInt(c.req.param('id'));
  const expense = expenses.find((e) => e.id === id);

  if (!expense) {
    return c.notFound();
  }

  return c.json(expense);
});

expensesRoute.delete('/:id', (c) => {
  const id = parseInt(c.req.param('id'));
  const expense = expenses.find((e) => e.id === id);

  if (!expense) {
    return c.notFound();
  }

  const index = expenses.indexOf(expense);
  const deletedExpense = expenses.splice(index, 1);

  return c.json(deletedExpense);
});

export { expensesRoute };

Step2: Exporting the API type from server

// sever/index.ts
import { Hono } from 'hono';
import { expensesRoute } from './routes/expenses.routes';
// ...
const app = new Hono();
// ...
const apiRoutes = app.route('/expenses', expensesRoute);

export default app;
export type ApiRoutes = typeof apiRoutes;

Step3: Configuring the paths in client side

// client/tsconfig.json
{
  "compilerOptions": {
   /// ...

    "paths": {
      "@/*": ["./src/*"],
      "@server/*": ["../server/*"]
    },

    /// ...
  },
  "include": ["src"]
}

// client/vite.config.ts
import path from 'path';
import react from '@vitejs/plugin-react';

import { defineConfig } from 'vite';

export default defineConfig({
  /// ...
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
      '@server': path.resolve(__dirname, '../server'),
    },
  },
});

Step4: Importing the API type in the client

In this step, I found out that hono client instance was inferred as type unknown.

// client/src/lib/api.ts
// I configured the
import { type ApiRoutes } from '@server/src';
import { hc } from 'hono/client';

const API_URL: string = import.meta.env.DEV
  ? 'http://localhost:8787'
  : import.meta.env.VITE_API_URL;

const client = hc<ApiRoutes>(API_URL);

The Problem & Solution

The problem was in the step 1.
I defined each route indiviually and imperatively , like I used to do with Express.js.
The API itself was working fine with this way, but the type wasn't inferred correctly.

Bad 👎

const expensesRoute = new Hono();

expensesRoute.get('/', (c) => { ... });
expensesRoute.post('/', zValidator('form', createPostSchema), async (c) => { ... });
expensesRoute.get('/:id', (c) => { ... });
expensesRoute.delete('/:id', (c) => { ... });

export { expensesRoute };

I should have defined the routes declaratively, using method chain, as It's suggested in Documentation

Good 👍

export const expensesRoute = new Hono()
  .get('/', (c) => { ... })
  .post('/', zValidator('form', createPostSchema), async (c) => { ... })
  .get('/total-spent', async (c) => { ... })
  .get('/:id', (c) => { ... })
  .delete('/:id', (c) => { ... });

After fixing this, the hono client instance was correcly inferred with all of the route definition.

Why it happened?

According to the TypeScript Documentation, type inference takes place when initializing variables and members, setting parameter default values, and determining function return types.
So when I defined the routes imperatively, and added it to expensesRoute, TypeScript couldn't infer each of the type correctly. This is probably why the hono client instance was inferred as type unknown.

Takeaways

Declarative over Imperative: When defining routes in Hono, it's better to use method chain to define the routes declaratively.
Type Inference: TypeScript infers types when initializing variables and members, setting parameter default values, and determining function return types. So, if you're having trouble with type inference, check if you're defining the types correctly in these places.

Consider if you can replace useEffect with event handler (We Might Not Need an Effect #2)

kanta1207 — Wed, 08 May 2024 19:43:46 +0000

What this article series are about 🔍

This article series are basically a summary of You Might Not Need an Effect, which is a React official documentation about the usage of useEffect hook in React.

The original article is really really good, for sure better than my summary. So, if you have time, I highly recommend you to read the original article.

My motivation is just to provide a quick summary both for myself and for others who might be busy or a bit lazy to read through the whole article.

Yeah, it's for you 😉 haha

This is the second article of the series. And the key takeaway is really simple.

Always consider if you can do it inside of event handler 💡

All of the example covered in this article are about how we can avoid using useEffect by moving the logic to the event handler.

I'm not covering Passing a data to the parent,
because it's rather about the flow of data in React.

Before diving into them, let's briefly make it clear why we need to reduce useEffect in the first place.

Why we need to reduce `useEffect` in the first place?

Re-render happens after each setState function in each of useEffect
Complexity. It's hard to understand the flow of the code if we have too many useEffect

So, let's see how we can avoid using useEffect by moving the logic to the event handler or just during rendering.

Example 1, Bad 👎

When we want to do some shared logic between multiple event handler function, we might be tempted to put the logic inside useEffect.
But we actually shoudn't do that.

// Let's assume this function is defined elsewhere
const addToCart = (product) => {
  product.isInCart = true;
};

function ProductPage({ product, addToCart }) {
  // 🔴 Avoid: Event-specific logic inside an Effect
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`Added ${product.name} to the shopping cart!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }

  function handleCheckoutClick() {
    addToCart(product);
    navigateTo('/checkout');
  }
  // ...
}

Example 1, Good 👍

If you want to create some shared logic between event handlers, just create a function.

function ProductPage({ product, addToCart }) {
  // ✅ Good: Event-specific logic is called from event handlers
  function buyProduct() {
    addToCart(product);
    showNotification(`Added ${product.name} to the shopping cart!`);
  }

  function handleBuyClick() {
    buyProduct();
  }

  function handleCheckoutClick() {
    buyProduct();
    navigateTo('/checkout');
  }
}

Example 2, Bad 👎

Again, if you can do it on event handler, just do it there rather than using useEffect.

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Good: This logic should run because the component was displayed, not because of an event
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  // 🔴 Avoid: Event-specific logic inside an Effect. You don't need a state and useEffect for that.
  const [jsonToSubmit, setJsonToSubmit] = useState(null);
  useEffect(() => {
    if (jsonToSubmit !== null) {
      post('/api/register', jsonToSubmit);
    }
  }, [jsonToSubmit]);

  function handleSubmit(e) {
    e.preventDefault();
    setJsonToSubmit({ firstName, lastName });
  }
  // ...
}

Example 2, Good 👍

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Good: This logic should run because the component was displayed, not because of an event
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  function handleSubmit(e) {
    e.preventDefault();
    // ✅ Good: Event-specific logic is in the event handler
    post('/api/register', { firstName, lastName });
  }
  // ...
}

Example 3, Bad 👎

It looks like we're using useEffect to chain multiple state update each other.

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);
  const [isGameOver, setIsGameOver] = useState(false);

  useEffect(() => {
    if (card !== null && card.gold) {
      setGoldCardCount((c) => c + 1);
    }
  }, [card]);

  useEffect(() => {
    if (goldCardCount > 3) {
      setRound((r) => r + 1);
      setGoldCardCount(0);
    }
  }, [goldCardCount]);

  useEffect(() => {
    if (round > 5) {
      setIsGameOver(true);
    }
  }, [round]);

  useEffect(() => {
    alert('Good game!');
  }, [isGameOver]);

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    } else {
      setCard(nextCard);
    }
  }
}

Example 3, Good 👍 (After we remove all unnecessary `useEffect`)

Let's see how we can remove unnecessary useEffect.

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);
  // const [isGameOver, setIsGameOver] = useState(false); // We don't need this state
  // Instead, ✅ calculate what you can during rendering
  const isGameOver = round > 5;

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    }

    // ✅ Calculate all the next state in the event handler, rather than in useEffect
    setCard(nextCard);
    if (nextCard.gold) {
      if (goldCardCount <= 3) {
        setGoldCardCount(goldCardCount + 1);
      } else {
        setGoldCardCount(0);
        setRound(round + 1);
        if (round === 5) {
          alert('Good game!');
        }
      }
    }
  }
}

Takeaway

(Almost) Never use useEffect for event-specific logic. Just call the logic directly from the event handler function.

I actually couldn't come up with any case where we have to use useEffect for event-specific logic, please tell me if you can think of any cases.

Reference

See you again in #3!

Consider if you can replace useEffect with event handler (We Might Not Need an Effect #2)

kanta1207 — Tue, 07 May 2024 20:17:31 +0000

What this article series are about 🔍

This article series are basically a summary of You Might Not Need an Effect, which is a React official documentation about the usage of useEffect hook in React.

The original article is really really good, for sure better than my summary. So, if you have time, I highly recommend you to read the original article.

My motivation is just to provide a quick summary both for myself and for others who might be busy or a bit lazy to read through the whole article.

Yeah, it's for you 😉 haha

This is the second article of the series. And the key takeaway is really simple.

Always consider if you can do it inside of event handler 💡

All of the example covered in this article are about how we can avoid using useEffect by moving the logic to the event handler.

I'm not covering Passing a data to the parent,
because it's rather about the flow of data in React.

Before diving into them, let's briefly make it clear why we need to reduce useEffect in the first place.

Why we need to reduce `useEffect` in the first place?

Re-render happens after each setState function in each of useEffect
Complexity. It's hard to understand the flow of the code if we have too many useEffect

So, let's see how we can avoid using useEffect by moving the logic to the event handler or just during rendering.

Example 1, Bad 👎

When we want to do some shared logic between multiple event handler function, we might be tempted to put the logic inside useEffect.
But we actually shoudn't do that.

// Let's assume this function is defined elsewhere
const addToCart = (product) => {
  product.isInCart = true;
};

function ProductPage({ product, addToCart }) {
  // 🔴 Avoid: Event-specific logic inside an Effect
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`Added ${product.name} to the shopping cart!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }

  function handleCheckoutClick() {
    addToCart(product);
    navigateTo('/checkout');
  }
  // ...
}

Example 1, Good 👍

If you want to create some shared logic between event handlers, just create a function.

function ProductPage({ product, addToCart }) {
  // ✅ Good: Event-specific logic is called from event handlers
  function buyProduct() {
    addToCart(product);
    showNotification(`Added ${product.name} to the shopping cart!`);
  }

  function handleBuyClick() {
    buyProduct();
  }

  function handleCheckoutClick() {
    buyProduct();
    navigateTo('/checkout');
  }
}

Example 2, Bad 👎

Again, if you can do it on event handler, just do it there rather than using useEffect.

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Good: This logic should run because the component was displayed, not because of an event
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  // 🔴 Avoid: Event-specific logic inside an Effect. You don't need a state and useEffect for that.
  const [jsonToSubmit, setJsonToSubmit] = useState(null);
  useEffect(() => {
    if (jsonToSubmit !== null) {
      post('/api/register', jsonToSubmit);
    }
  }, [jsonToSubmit]);

  function handleSubmit(e) {
    e.preventDefault();
    setJsonToSubmit({ firstName, lastName });
  }
  // ...
}

Example 2, Good 👍

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Good: This logic should run because the component was displayed, not because of an event
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  function handleSubmit(e) {
    e.preventDefault();
    // ✅ Good: Event-specific logic is in the event handler
    post('/api/register', { firstName, lastName });
  }
  // ...
}

Example 3, Bad 👎

It looks like we're using useEffect to chain multiple state update each other.

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);
  const [isGameOver, setIsGameOver] = useState(false);

  useEffect(() => {
    if (card !== null && card.gold) {
      setGoldCardCount((c) => c + 1);
    }
  }, [card]);

  useEffect(() => {
    if (goldCardCount > 3) {
      setRound((r) => r + 1);
      setGoldCardCount(0);
    }
  }, [goldCardCount]);

  useEffect(() => {
    if (round > 5) {
      setIsGameOver(true);
    }
  }, [round]);

  useEffect(() => {
    alert('Good game!');
  }, [isGameOver]);

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    } else {
      setCard(nextCard);
    }
  }
}

Example 3, Good 👍 (After we remove all unnecessary `useEffect`)

Let's see how we can remove unnecessary useEffect.

function Game() {
  const [card, setCard] = useState(null);
  const [goldCardCount, setGoldCardCount] = useState(0);
  const [round, setRound] = useState(1);
  // const [isGameOver, setIsGameOver] = useState(false); // We don't need this state
  // Instead, ✅ calculate what you can during rendering
  const isGameOver = round > 5;

  function handlePlaceCard(nextCard) {
    if (isGameOver) {
      throw Error('Game already ended.');
    }

    // ✅ Calculate all the next state in the event handler, rather than in useEffect
    setCard(nextCard);
    if (nextCard.gold) {
      if (goldCardCount <= 3) {
        setGoldCardCount(goldCardCount + 1);
      } else {
        setGoldCardCount(0);
        setRound(round + 1);
        if (round === 5) {
          alert('Good game!');
        }
      }
    }
  }
}

Takeaway

(Almost) Never use useEffect for event-specific logic. Just call the logic directly from the event handler function.

I actually couldn't come up with any case where we have to use useEffect for event-specific logic, please tell me if you can think of any cases.

Reference

See you again in #3!

We Might Not Need an Effect #1

kanta1207 — Mon, 06 May 2024 18:53:15 +0000

What this article series are about 🔍

This article series are basically a summary of You Might Not Need an Effect, which is a React official documentation about the usage of useEffect hook in React.

The original article is really really good, for sure better than my summary. So, if you have time, I highly recommend you to read the original article.

My motivation is just to provide a quick summary both for myself and for others who might be busy or a bit lazy to read through the whole article.

Yeah, it's for you 😉 haha

I summarized the content as short as possible, so we can get main idea quickly.
So don't forget to check the original article for more detailed information. Again, it's really good learning material.

When something can be calculated from the existing props or state, we don't need extra state and useEffect

Bad 👎

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // 🔴  Unnecessary extra state and useEffect
  const [fullName, setFullName] = useState('');
  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);
  //

  return (
    <div>
      <input
        value={firstName}
        onChange={(e) => setFirstName(e.target.value)}
        placeholder="First Name"
      />
      <input
        value={lastName}
        onChange={(e) => setLastName(e.target.value)}
        placeholder="Last Name"
      />
      <h1>{fullName}</h1>
    </div>
  );
}

Good 👍

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅  No extra state and useEffect
  const fullName = firstName + ' ' + lastName;

  return (
    <div>
      <input
        value={firstName}
        onChange={(e) => setFirstName(e.target.value)}
        placeholder="First Name"
      />
      <input
        value={lastName}
        onChange={(e) => setLastName(e.target.value)}
        placeholder="Last Name"
      />
      <h1>fullName</h1>
    </div>
  );
}

Takeaway

The point is to let re-render do the calculation, instead of doing it with extra state and useEffect.
When we call setFirstName or setLastName, we trigger a re-render, and then the next fullName will be calculated from the fresh data.

Reference

When we use `useEffect` just to update something only when some props or state is updated, what we really need is `useMemo`.

Bad 👎

getFilteredTodos is a function that filters todos based on the filter, and it is used to calculate visibleTodos.
Maybe you want to update visibleTodos only when todos or filter changes.

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');

  // 🔴  Unnecessary extra state and useEffect
  const [visibleTodos, setVisibleTodos] = useState([]);
  useEffect(() => {
    setVisibleTodos(getFilteredTodos(todos, filter));
  }, [todos, filter]);
 ...
}

Good 👍

function TodoList({ todos, filter }) {
  const [newTodo, setNewTodo] = useState('');

  // ✅  No extra state and useEffect, but efficient use of useMemo
  const visibleTodos = useMemo(
    () => getFilteredTodos(todos, filter),
    [todos, filter]
  );
}

Takeaway

If your motivation to use useEffect is just to update something only when some props or state is updated, what you really need is useMemo.

Reference

Caching expensive calculation

When we want to reset the state based on some prop change, we could do it witout `useEffect`

Bad 👎

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
  const [selectedItem, setSelectedItem] = useState(null);

  // 🔴 Avoid: resetting state on prop change in an Effect
  useEffect(() => {
    setSelection(null);
  }, [items]);
  // ...
}

Good 👍

function List({ items }) {
  const [isReverse, setIsReverse] = useState(false);
//   Change selectedItem to selectedItemId, so that we don't need to reset state on prop change
  const [selectedItemId, setSelectedItemId] = useState(null);

  // ✅  No extra state and useEffect, just calculate selectedItem when selectedItemId changes
  const selectedItem = useMemo(items.find((item) => item.id === selectedItemId);,[items, selectedItemId]);
}

Takeaway

When you adjusting or resetting the state based on some prop change, you better to think about the way to do it without useEffect

Reference

Adjusting some state when a prop changes

See you again in #2 !

SOLID Principal with React: Interface Segregation Principle

kanta1207 — Sat, 04 May 2024 21:52:01 +0000

Goal 🚀

Understand Interface Segregation Principle and how to apply it in React.

What is SOLID Principle?

SOLID is an acronym for five design principles intended to make software designs more understandable, flexible, and maintainable. These principles are a subset of many principles promoted by Robert C. Martin, also known as Uncle Bob. The SOLID principles are:

S ... Single Responsibility Principle
O ... Open/Closed Principle
L ... Liskov Substitution Principle
I ... Interface Segregation Principle
D ... Dependency Inversion Principle

What is Interface Segregation Principle? (Definition)

The Interface Segregation Principle states that a client should not be forced to implement an interface that it doesn't use.
This principle deals with the disadvantages of implementing big interfaces. When a class implements an interface,
it should not have to implement methods that it does not use. This principle is intended to prevent classes from becoming too large and to avoid the need to implement methods that are not used.

How to apply Interface Segregation Principle in React? 🤔

Let's say you have a User Interface

interface User {
  id: number;
  email: string;
  password: string;
  name: string;
  age: number;
  birthday: string;
}

And you have to implement a UserCard component that displays the user's name, email and birth date.

Here is an example of UserCard component, which doesn't follow Interface Segregation Principle.

interface UserCardBadExampleProps {
  user: User;
}

const UserCard: FC<UserCardBadExampleProps> = ({ user }) => {
  return (
    <div className="p-4 border rounded shadow">
      <h2 className="text-xl">{user.name}</h2>
      <p className="text-sm text-gray-500">{user.email}</p>
      <p className="text-sm text-gray-500">{user.birthday}</p>
    </div>
  );
};

In this example, UserCard component is using the User interface,
but it doesn't need all the properties of the User interface.
It only needs name,email, and birthDay properties.

This can possibley cause a problem when the User interface is updated.
For instance, if by any chance the birthDay property get renamed to birthDate,
UserCard component will break because it is still using the old property name birthDay.

This particular problem might sound like less likely to happen, but we also can't deny that UserCard component is unnecessarily dependent on the User interface.

To follow Interface Segregation Principle, you can modify the props of the UserCard component like this:

interface UserCardGoodExampleProps {
  name: string;
  email: string;
  birthday: string;
}

const UserCard: FC<UserCardGoodExampleProps> = ({ name, email, birthday }) => {
  return (
    <div className="p-4 border rounded shadow">
      <h2 className="text-xl">{name}</h2>
      <p className="text-sm text-gray-500">{email}</p>
      <p className="text-sm text-gray-500">{birthday}</p>
    </div>
  );
};

By doing this, you can prevent the UserCard component from implementing unnecessary properties,
and implement only the properties it needs. This makes the component less dependent on the User interface.

Advanced Example

Let's say User interface has another property posts like this 👇

interface Post {
  id: number;
  createdAt: string;
  updatedAt: string;
  title: string;
  content: string;
  user: User;
}

interface User {
  id: number;
  email: string;
  password: string;
  name: string;
  age: number;
  birthday: string;
  posts: Post[];
}

And you have to extend the UserCard component to display the user's post titles, created dates, updated dates.

Considering the Interface Segregation Principle, we would modify the UserCard component like this:

interface UserCardGoodExampleProps {
  name: string;
  email: string;
  birthday: string;
  posts: Post[];
}

const UserCard: FC<UserCardGoodExampleProps> = ({
  name,
  email,
  birthday,
  posts,
}) => {
  return (
    <div className="p-4 border rounded shadow">
      <h2 className="text-xl">{name}</h2>
      <p className="text-sm text-gray-500">{email}</p>
      <p className="text-sm text-gray-500">{birthday}</p>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>
            <h3>{post.title}</h3>
            <p>{post.createdAt}</p>
            <p>{post.updatedAt}</p>
          </li>
        ))}
      </ul>
    </div>
  );
};

My concern in this example is that the UserCard component is still dependent on the Post Interface.

To follow Interface Segregation Principle more strictly, we can modify the UserCard component like this:

interface UserCardGoodExampleProps {
  name: string;
  email: string;
  birthday: string;
  postTitles: string[];
  postCreatedDates: string[];
  postUpdatedDates: string[];
}

const UserCard: FC<UserCardGoodExampleProps> = ({
  name,
  email,
  birthday,
  postTitles,
  postCreatedDates,
  postUpdatedDates,
}) => {
  return (
    <div className="p-4 border rounded shadow">
      <h2 className="text-xl">{name}</h2>
      <p className="text-sm text-gray-500">{email}</p>
      <p className="text-sm text-gray-500">{birthday}</p>
      <ul>
        {postTitles.map((title, index) => (
          <li key={index}>
            <h3>{title}</h3>
            <p>{postCreatedDates[index]}</p>
            <p>{postUpdatedDates[index]}</p>
          </li>
        ))}
      </ul>
    </div>
  );
};

Or, we could divide the UserCard component into two components, UserCard and PostList.

interface UserCardGoodExampleProps {
  name: string;
  email: string;
  birthday: string;
  children: ReactNode;
}

const UserCard: FC<UserCardGoodExampleProps> = ({
  name,
  email,
  birthday,
  children,
}) => {
  return (
    <div className="p-4 border rounded shadow">
      <h2 className="text-xl">{name}</h2>
      <p className="text-sm text-gray-500">{email}</p>
      <p className="text-sm text-gray-500">{birthday}</p>
      {children}
    </div>
  );
};

interface PostProps {
  title: string;
  createdAt: string;
  updatedAt: string;
}

const Post: FC<PostProps> = ({ title, createdAt, updatedAt }) => {
  return (
    <li>
      <h3>{title}</h3>
      <p>{createdAt}</p>
      <p>{updatedAt}</p>
    </li>
  );
};

const SamplePage = () => {
  const user: User = await fetchUser();

  return (
    <UserCard name={user.name} email={user.email} birthday={user.birthday}>
      <ul>
        {user.posts.map((post) => (
          <Post
            key={post.id}
            title={post.title}
            createdAt={post.createdAt}
            updatedAt={post.updatedAt}
          />
        ))}
      </ul>
    </UserCard>
  );
};

I'm actually not sure if we should follow ISP this much stricltly tho 😅

Please let me know if you have any thoughts on this!!

Forem: kanta1207

How Browsers Parse a URL

Step 1: Breaking Down the URL String

Notes on Each Part

Step 2: How Each Part Affects the Request Lifecycle

🔐 Scheme

🌐 Host Name

🔌 Port

📂 Path

❓ Query

🧭 Fragment

Designing and implementing a Point System with Cash-Out Support using Event-Based Architecture, Hono, and DrizzleORM

Introduction

Why an Event-Based Architecture?

System Overview

✅ Point Earning

♻ Point Usage

🧾 Audit & Integrity

🔐 Atomic Transactions

Event Store Design: Modeling Points as Events

✅ 1. point_credits — Point Acquisition Events

✅ 2. point_usages — Point Deduction Events

✅ 3. point_consumption_log — FIFO Breakdown of Usage

♻ Example Flow: Spending 1,000 Points

🔒 Benefits of This Model

Balance Calculation & FIFO Logic

🧾 Balance Calculation from Events

♻ FIFO Deduction Algorithm (Drizzle ORM style)

⚖️ Why No Snapshots or CQRS?

Conclusion

A Practical Approach to Solving Performance Issues in React Apps with Large Lists #2

What is Infinite Scroll?

How it works:

What is Virtual Scroll?

How it works:

Our Decision: Go with Virtual Scroll

supabase_vector_project container is not ready: unhealthy when using Rancher Desktop

🔍 Problem

✅ Solution

A Practical Approach to Solving Performance Issues in React Apps with Large Lists #1

Step 1: Recognize the Problem Early

Step 2: Define What "Good" Looks Like

Step 3: Investigate the Root Cause

Optimization: Minimizing Re-renders

Tech Note: Type inference takes place when initializing variables and members

What I got stuck with

What is Hono?

What is RPC?

Step1: Expenses route for sample app.

Step2: Exporting the API type from server

Step3: Configuring the paths in client side

Step4: Importing the API type in the client

The Problem & Solution

Bad 👎

Good 👍

Why it happened?

Takeaways

Consider if you can replace useEffect with event handler (We Might Not Need an Effect #2)

What this article series are about 🔍

Always consider if you can do it inside of event handler 💡

Why we need to reduce useEffect in the first place?

Example 1, Bad 👎

Example 1, Good 👍

Example 2, Bad 👎

Example 2, Good 👍

Example 3, Bad 👎

Example 3, Good 👍 (After we remove all unnecessary useEffect)

Takeaway

Reference

See you again in #3!

Consider if you can replace useEffect with event handler (We Might Not Need an Effect #2)

What this article series are about 🔍

Always consider if you can do it inside of event handler 💡

Why we need to reduce useEffect in the first place?

Example 1, Bad 👎

Example 1, Good 👍

Example 2, Bad 👎

Example 2, Good 👍

Example 3, Bad 👎

Example 3, Good 👍 (After we remove all unnecessary useEffect)

✅ 1. `point_credits` — Point Acquisition Events

✅ 2. `point_usages` — Point Deduction Events

✅ 3. `point_consumption_log` — FIFO Breakdown of Usage

Step1: `Expenses` route for sample app.

Why we need to reduce `useEffect` in the first place?

Example 3, Good 👍 (After we remove all unnecessary `useEffect`)

Why we need to reduce `useEffect` in the first place?

Example 3, Good 👍 (After we remove all unnecessary `useEffect`)

When we use `useEffect` just to update something only when some props or state is updated, what we really need is `useMemo`.

When we want to reset the state based on some prop change, we could do it witout `useEffect`