Sazzadur's blog

Soft Delete Is Easy. Data Consistency Is Not.

Sazzadur Rahman — Sat, 20 Dec 2025 15:01:34 GMT

You add a column like isDeleted, flip it to true, and suddenly life feels safer. No data loss. Easy rollback. No angry product manager asking why something is gone forever.

At first, it works beautifully.

Until your data starts depending on other data.

That’s when soft delete stops being a convenience and starts quietly breaking things. Not with errors or crashes, but with something worse: incorrect history.

The real problem isn’t that records are deleted. It’s that mutable data is being treated as historical truth.

I ran into this while working on a simple-looking system. Dormitories, rooms, beds, bookings. Nothing fancy. But one small change exposed a flaw that soft delete alone cannot fix.

This article is not about how to implement soft delete. It’s about what happens after you do.

The Illusion of Safety

Soft delete feels like the responsible choice.

Instead of removing rows from the database, you keep them around. You tell yourself this is safer. If something goes wrong, you can always bring the data back. Audits become easier. Mistakes feel reversible.

From a code perspective, it’s almost too easy:

isDeleted Boolean @default(false)

Then you update your queries to filter out deleted records, and you move on.

Most of the time, this works. Especially when your data is flat or loosely connected.

The illusion starts when you believe that keeping records automatically preserves correctness.

Soft delete protects existence, not meaning.

A deleted record still exists in the database, but the moment you stop treating it as part of the active system, you’ve changed how the rest of your data behaves. Relationships don’t disappear. They just become awkward.

And the more your data model relies on relationships, the faster this illusion breaks.

You won’t notice it during development.
You won’t see it in unit tests.
You’ll see it when someone asks a very simple question:

“Why does this old record look wrong?”

That’s usually when you realize something deeper is broken.

Where Things Start to Break

Soft delete works best when records are independent.

A user gets deleted.
A tag gets deleted.
A draft gets deleted.

No other piece of data needs them to explain the past.

Problems begin when records stop being standalone and start representing structure.

Structure is different. Other data relies on it to make sense.

Orders rely on products.
Bookings rely on rooms.
Seats rely on flights.
Beds rely on dormitories.

When you soft delete something structural, you’re not just hiding a row. You’re changing the shape of the system that older data was built on.

This is where data consistency starts leaking.

At first, it’s subtle. A missing label here. A null value there. A join that suddenly returns less data than expected.

So you patch it.

You add conditional checks. You show placeholders. You ignore deleted records in reports.

But none of this fixes the core issue. It only hides it.

Because historical data is still asking a very simple question:

“What did the world look like at the time this happened?”

And your system can no longer answer that honestly.

This becomes painfully clear when a structural change is made for a perfectly valid reason.

Which brings me to the dormitory problem.

The Dormitory Problem

Imagine a dormitory with 15 beds.

Each bed is a record in the database. Bookings reference beds. Everything is clean and relational.

Over time, a few guests stay in beds 13, 14, and 15. Their bookings are completed, paid for, and archived. This is now historical data.

Later, an admin decides to reduce the dormitory capacity to 10 beds. Maybe the room layout changed. Maybe regulations changed. It’s a valid business decision.

To reflect this, beds 11–15 are soft deleted.

No rows are removed. isDeleted is set to true. The system still “has” the data.

But now ask a simple question:

“What happens to the old bookings?”

Those bookings still point to beds 13, 14, and 15. Beds that no longer exist in the active system.

On the surface, nothing crashes.

But cracks start to show:

Booking history pages can’t display bed details properly
Reports skip deleted beds and show incomplete data
Admins see “missing” information and lose trust in the system
Developers add more conditions to patch the UI

The bookings are correct.
The beds existed.
The stays happened.

Yet the system can no longer describe that reality accurately.

That’s the real failure.

Why Soft Delete Isn’t the Real Problem

It’s tempting to blame soft delete here. But soft delete is just the messenger.

The real issue is treating mutable structure as historical truth.

Dormitory capacity is configuration.
Bed availability is configuration.
Room layout is configuration.

Bookings are not.

A booking is a fact. It already happened. It should never depend on something that can change later.

When a booking depends on live structural data, you’re asking the present to explain the past. And the present has already moved on.

Soft delete didn’t break your data.
Your mental model did.

Better Ways to Model This

There’s no single “correct” solution, but there are safer patterns.

1. Never Truly Remove Structural Entities

Beds don’t disappear. They become inactive.

You stop assigning them to new bookings, but you never treat them as gone. Historical records can still reference them without hacks or fallbacks.

This keeps joins simple and history intact.

2. Version Your Structure

Instead of one mutable dormitory, you create versions.

Bookings reference the version that was active at the time of booking. Capacity changes create a new version, not a rewrite of reality.

This is powerful, but heavier to implement.

3. Snapshot What Matters

For historical records, store what you actually need.

Instead of depending on joins:

Store bed number
Store room name
Store capacity at the time

This accepts duplication in exchange for truth.

History becomes self-contained.

The Rule I Follow Now

I don’t decide soft delete strategies first anymore.

I ask one question:

“Can this data change after something depends on it?”

If the answer is yes, history should not rely on it.

A few simple rules guide me now:

Historical records must survive structural changes
Soft delete is about visibility, not correctness
If data explains the past, freeze it or snapshot it

Closing Thoughts

Soft delete solves deletion.

It does not solve meaning.

If your system cannot explain what happened yesterday after a change today, the problem isn’t missing rows. It’s broken history.

And no amount of isDeleted = true can fix that.

The Right Way to Upload Files to S3 from a Serverless Backend

Sazzadur Rahman — Sat, 20 Sep 2025 04:05:39 GMT

Introduction

File uploads sound simple — until you try doing them in a serverless environment. Suddenly your “tiny upload feature” feels like it’s eating half your cloud budget.

On a normal server, you can just accept a file, push it to Amazon S3, and call it a day. But serverless backends (like AWS Lambda, Vercel Functions, or Netlify Functions) aren’t meant to babysit your uploads. They’re sprinters, not marathon runners.

That means:

Timeouts (big files take longer than your function’s max execution time).
High costs (you pay for every second your backend is stuck watching progress bars).
Unnecessary complexity (your backend turns into a middleman with trust issues).

The good news? There’s a better way. Instead of playing “file courier,” let your backend hand out a VIP pass (presigned URL) so clients can walk right into S3 themselves.

Traditional Approach: Uploading Through Backend

Here’s the old-school method:

Client uploads a file to your backend.
Backend temporarily holds it (like an awkward third wheel).
Backend uploads it to S3.

A simple Node.js + Multer setup might look like this:

// server.js
import express from "express";
import multer from "multer";
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const app = express();
const upload = multer({ storage: multer.memoryStorage() });
const s3 = new S3Client({
  credentials: {
    accessKeyId: process.env.ACCESS_KEY_ID,
    secretAccessKey: process.env.SECRET_ACCESS_KEY,
  },
  region: process.env.AWS_REGION,
});

app.post("/upload", upload.single("file"), async (req, res) => {
  const params = {
    Bucket: process.env.S3_BUCKET,
    Key: req.file.originalname,
    Body: req.file.buffer,
  };
  const params = {
    Bucket: process.env.S3_BUCKET,
    Key: req.file.originalname,
    Body: req.file.buffer,
    ContentType: req.file.mimetype,
  };

  try {
    const command = new PutObjectCommand(params);
    await s3Client.send(command);

    res.json({ message: "File uploaded successfully" });
  } catch (err) {
    res.status(500).json({ error: err.message });
  }
});

app.listen(3000);

Flow: Client → Backend → S3

The problems are obvious:

Scalability → Large files keep your serverless function awake way past its bedtime.
Costs → You’re billed while your backend plays middleman.
Bottleneck → Every upload has to squeeze through your backend first.

This is fine… until someone uploads a 2GB video. Then it’s not fine.

Alternative: External Upload Service

Some developers think: “Fine, I’ll just build a separate backend just for uploads!”

That means:

Spinning up EC2, ECS, or a dedicated Node server.
Letting it handle streams and send them to S3.

Pros:

Offloads work from your serverless functions.
Can be tuned for file streaming.

Cons:

You’ve now adopted another backend baby to feed and maintain.
Public upload endpoints can be dangerous if not locked down.
Still, your backend is just a fancier middleman.

So yes, this works — but it’s like renting a moving truck to deliver a pizza.

The Right Way: Using Presigned URLs

Enter the hero: presigned URLs.

Here’s the magic:

Client asks your backend for permission to upload.
Backend generates a presigned URL from S3.
Client uploads directly to S3.

Backend never touches the file. Everyone’s happy.

Backend: Generate Presigned URL

// getUploadUrl.js
import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";

const s3 = new S3Client({
  credentials: {
    accessKeyId: process.env.ACCESS_KEY_ID,
    secretAccessKey: process.env.SECRET_ACCESS_KEY,
  },
  region: process.env.AWS_REGION,
});

export async function getUploadUrl(filename, fileType) {
  const command = new PutObjectCommand({
    Bucket: process.env.S3_BUCKET,
    Key: filename,
    ContentType: fileType,
  });

  return await getSignedUrl(s3, command, { expiresIn: 60 }); // 60s VIP pass
}

Your backend responds with:

{
  "url": "https://your-bucket.s3.amazonaws.com/file.png?...",
  "key": "file.png"
}

Frontend: Upload File

async function uploadFile(file) {
  // 1. Ask backend for presigned URL
  const res = await fetch("/api/upload-url", {
    method: "POST",
    body: JSON.stringify({ filename: file.name, fileType: file.type }),
    headers: { "Content-Type": "application/json" },
  });
j
  const { url } = await res.json();

  // 2. Upload directly to S3
  await fetch(url, {
    method: "PUT",
    headers: { "Content-Type": file.type },
    body: file,
  });

  alert("Upload successful!");
}

It’s like your backend saying: “Here’s your one-time backstage pass, don’t lose it. Now go talk to S3 directly.”

Benefits of Presigned URLs

Why this approach wins:

No long-running backend requests → functions return fast.
Scalable → clients upload big files directly to S3.
Secure → presigned URLs expire quickly and can restrict file type/size.
Flexible → works with private buckets.
Cheaper → backend isn’t wasting execution time watching progress bars.

Basically, presigned URLs let your backend do what it does best: hand out keys, not carry boxes.

Conclusion

We compared three approaches:

Traditional backend upload → works for small files, cries with big ones.
Dedicated upload service → better, but extra work to maintain.
Presigned URLs → simple, secure, scalable, and cost-friendly.

If you’re building on a serverless backend, presigned URLs are the right way to upload files to S3.

Happy coding!

How to Build a Serverless API That Actually Works (with SST, Prisma, TiDB, Bun & AWS Lambda)

Sazzadur Rahman — Tue, 16 Sep 2025 19:01:23 GMT

Welcome, brave developer, to the wild world of modern web development where we combine more technologies than a NASA space mission! Today we’re building a serverless TypeScript application using SST (not the sonic boom), Prisma (not the crystal), TiDB (not a robot), Express.js (not the delivery service), and Bun (not the bread). We’ll deploy this beautiful chaos to AWS Lambda because apparently, we enjoy complicated relationships with cloud providers.

Why This Particular Flavor of Madness?

Let me explain why we’re choosing this specific cocktail of technologies (spoiler: it’s actually pretty awesome):

SST: Because who doesn’t love infrastructure as code that doesn’t make you cry
Prisma: Type-safe database queries that prevent your 3 AM “WHERE DID ALL THE DATA GO?!” moments
TiDB: A database that scales horizontally because vertical scaling is so 2010
Express: The reliable old friend that’s been there since the dinosaur age of Node.js
Bun: The new kid on the block that makes everything ridiculously fast (yes, it’s named after a rabbit)
AWS Lambda: Because paying for servers when they’re not doing anything is like paying rent for a ghost

Prerequisites (AKA “Stuff You Need Before You Can Break Things”)

An AWS Account (and the emotional fortitude to handle the billing alerts)
AWS CLI installed and configured (because apparently we still need command lines in 2025)
Node.js 18+ (anything older and you’re basically using stone tablets)
Basic knowledge of TypeScript (if you’re still writing vanilla JS, we need to have a talk)
A strong cup of coffee ☕

Important: AWS CLI Setup (Or How to Convince AWS You’re Not a Robot)

Before we start building our magnificent creation, you need to authenticate with AWS. Think of it as showing your ID at a very expensive nightclub.

If you haven’t set up AWS CLI yet (and let’s be honest, who has time for documentation?):

Install AWS CLI: Installation Guide
Configure your credentials (AWS wants to know who’s about to rack up the bill):

aws configure

3. Enter your credentials like you’re entering a secret speakeasy

You can verify your setup with this magic incantation:

aws sts get-caller-identity

If it returns your identity without throwing an error, congratulations! AWS acknowledges your existence.

Let’s Get This Party Started

Step 1: Install Bun (The Rabbit That Will Change Your Life)

First, let’s install Bun globally because we’re living dangerously:

npm i -g bun

Yes, we’re using npm to install npm’s potential replacement. The irony is not lost on us.

For more information about why Bun is faster than your ex leaving you, visit bun.sh.

Step 2: Create Your Project (Like Bob Ross Creating Happy Little Servers)

Create a new directory and give it a name that you won’t be embarrassed to show your colleagues:

mkdir my-sst-app
cd my-sst-app

Initialize a new Bun project (watch the magic happen):

bun init

Now let’s clean up the mess and create our proper structure:

rm index.ts # Goodbye, you served us well for about 30 seconds
mkdir src
touch src/app.ts # Our future masterpiece

Step 3: Install Dependencies (AKA Dependency Hell, But Make It Fashion)

Time to install more packages than a teenager’s skincare routine:

bun add express @prisma/client sst @tidbcloud/prisma-adapter @codegenie/serverless-express
bun add -D prisma @types/express @types/aws-lambda tsx

Let’s decode this alphabet soup:

express: The old reliable (like your favorite pair of jeans)
@prisma/client: Your database’s new best friend
sst: Infrastructure as code that doesn’t hate you
@tidbcloud/prisma-adapter: The diplomatic translator between Prisma and TiDB
@codegenie/serverless-express: The magic that makes Express work in Lambda land
Various TypeScript types because we’re not savages

Database Setup (Or: How to Tame the Data Beast)

Step 4: Initialize Prisma (Your New Database Overlord)

Let Prisma set up shop in your project:

bun prisma init

This creates a prisma directory and a .env file. It’s like moving into a new apartment, but for databases.

Step 5: Configure Prisma Schema (The Blueprint of Your Dreams)

Update your prisma/schema.prisma file to work with TiDB:

generator client {
  provider = "prisma-client"
  output = "../src/generated/prisma"
  engineType = "client"
}

datasource db {
  provider = "mysql"
  url = env("DATABASE_URL")
}

model User {
  id Int @id @default(autoincrement())
  email String @unique
  name String?
  age Int?
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

Key points (because I know you skipped the code block):

We’re using provider = “prisma-client” and engineType = “client” to generate the Prisma Client using the TypeScript-based engine. This provides better performance and smaller bundle sizes compared to the traditional binary-based engine, making it ideal for serverless deployments (translation: it’s fast and won’t break your Lambda)
We’re outputting the generated client to src/generated/prisma because organization is key to sanity
Using mysql provider since TiDB speaks MySQL (it’s bilingual!)
Our User model is simpler than your last relationship

Step 6: Set Up TiDB Connection (Database Speed Dating)

Create a TiDB Serverless cluster at tidbcloud.com. Yes, another account to manage. Welcome to modern development!

Update your .env file with your TiDB connection string:

DATABASE_URL=”mysql://username:password@gateway01.region.prod.aws.tidbcloud.com:4000/database?sslaccept=strict”

Pro tip: Don’t commit this to Git unless you want to become famous on r/ProgrammerHumor

Step 7: Run Database Migration (The Moment of Truth)

Generate the Prisma Client and create database tables:

bun prisma migrate dev — name init

This command does more work than a junior developer on their first day:

Creates migration files (like a diary of your database changes)
Applies the migration to your database (fingers crossed!)
Generates the Prisma Client with TypeScript types (because we’re fancy like that)

Application Code (The Fun Part!)

Step 8: Create Prisma Client Singleton (One Client to Rule Them All)

Create src/lib/prisma.ts to set up our database overlord:

import { PrismaTiDBCloud } from "@tidbcloud/prisma-adapter";
import { PrismaClient } from "../generated/prisma/client";

declare global {
  var prisma: undefined | ReturnType<typeof prismaClientSingleton>;
}

const prismaClientSingleton = () => {
  const adapter = new PrismaTiDBCloud({ url: process.env.DATABASE_URL });
  // @ts-ignore: tidb adapter not in prisma types yet
  return new PrismaClient({ adapter });
};

const db = globalThis.prisma ?? prismaClientSingleton();

if (process.env.NODE_ENV !== "production") globalThis.prisma = db;

export default db;

This pattern does several clever things:

Uses the TiDB Cloud adapter (it’s like a universal translator)
Implements singleton pattern to avoid connection drama in serverless land
Reuses connections in development because we’re not made of money

Step 9: Build the Express Application (Your API’s Main Character)

Create your src/app.ts file with all the Express goodness:

import express from "express";
import db from "./lib/prisma";

const app = express();
app.use(express.json());

app.get("/health", (_req, res) => res.json({ ok: true }));

app.get("/users", async (_req, res) => {
  try {
    const users = await db.user.findMany();
    return res.json(users);
  } catch (error) {
    return res.status(500).json({ error: error });
  }
});

app.post("/users", async (req, res) => {
  try {
    const { email, name, age } = req.body;

    const user = await db.user.create({
      data: { email, name, age },
    });
    return res.json(user);
  } catch (error) {
    return res.status(500).json({ error: error });
  }
});

export default app;

Our Express app includes:

A health check endpoint (for those anxious moments)
GET endpoint to fetch all users (because data hoarding is real)
POST endpoint to create new users (population growth!)
Proper error handling (because things go wrong, and that’s okay)
Type safety through Prisma (no more “undefined is not a function” at 3 AM)

Step 10: Create Lambda Handler (The Serverless Magic Portal)

Create src/lambda.ts to handle AWS Lambda integration:

import serverlessExpress from "@codegenie/serverless-express";
import app from "./app";

export const handler = serverlessExpress({ app });

This tiny file is doing more heavy lifting than a gym enthusiast. It wraps our Express app to work with AWS Lambda’s event/callback model.

Infrastructure with SST (Infrastructure as Code, But Fun)

Step 11: Initialize SST (Your Infrastructure Butler)

Set up SST in your project:

bun sst init

This creates sst.config.ts and other SST files. It’s like having a personal assistant for your AWS resources.

Step 12: Configure SST (Teaching AWS How to Behave)

Update your sst.config.ts file to deploy your Express app:

/// 
export default $config({
  app(input) {
    return {
      name: "aws-prisma",
      removal: input?.stage === "production" ? "retain" : "remove",
      protect: ["production"].includes(input?.stage),
      home: "aws",
    };
  },

  async run() {
    const api = new sst.aws.ApiGatewayV2("AwsPrisma");

    api.route("ANY /{proxy+}", {
      handler: "src/lambda.handler",
      runtime: "nodejs20.x",
      memory: "1024 MB",
      timeout: "60 seconds",
      environment: {
        DATABASE_URL: process.env.DATABASE_URL!,
      },
    });

    return { url: api.url };
  },
});

This configuration is like a recipe for AWS:

Creates an API Gateway V2 (faster and cheaper than v1, because we learn from our mistakes)
Routes all requests to our Lambda function (one function to handle them all)
Sets appropriate memory and timeout (because databases take time to think)
Passes environment variables securely (no hardcoded secrets here!)
Uses different settings for production vs development (because YOLO doesn’t work in prod)

Step 13: Update Package.json (The Command Center)

Add useful scripts to your package.json:

{
  "scripts": {
    "dev": "sst dev",
    "build": "sst build",
    "deploy": "sst deploy",
    "prisma:generate": "prisma generate",
    "prisma:migrate": "prisma migrate dev",
    "prisma:studio": "prisma studio"
  }
}

Development and Deployment (The Grand Finale)

Step 14: Local Development (Where Dreams Come True)

Start your development environment:

bun run dev

SST will work harder than a barista during finals week:

Deploy your infrastructure in development mode
Set up live Lambda debugging (because print statements are so passé)
Provide hot reloads for your code changes (instant gratification!)
Give you a real AWS endpoint to test against (no more localhost!)

Step 15: Test Your API (Moment of Truth)

Once deployed, test your endpoints like you’re debugging your relationship:

# Health check (is it alive?)
curl https://your-api-gateway-url.amazonaws.com/health

# Get all users (are there any humans here?)
curl https://your-api-gateway-url.amazonaws.com/users

# Create a user (let's make some friends!)
curl -X POST https://your-api-gateway-url.amazonaws.com/users \
-H "Content-Type: application/json" \
-d '{"email":"test@example.com","name":"John Doe","age":30}'

Step 16: Production Deployment (The Big Leagues)

Deploy to production (aka “the place where things need to actually work”):

bun run deploy - stage production

Best Practices and Pro Tips (Wisdom from the Trenches)

Database Connection Management

Always use connection pooling in production (unless you enjoy 500 errors)
Consider using TiDB’s serverless tier for automatic scaling (it’s like having a database that goes to the gym for you)
Monitor connection usage to optimize performance (knowledge is power!)

Error Handling (Because Murphy’s Law is Real)

app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: "Something went wrong! But don't panic." });
});

Monitoring and Logging (Your Crystal Ball)

Add structured logging for better observability:

import { Logger } from "@aws-lambda-powertools/logger";
const logger = new Logger();

app.get("/users", async (req, res) => {
  logger.info("Fetching users", { userId: req.user?.id });
  // … rest of your code
});

Conclusion (We Made It! 🎉)

Congratulations! You’ve successfully built a serverless API that uses more acronyms than a government document! You now have:

✅ Type-safe database operations (no more “oops, I dropped the table”)

✅ Scalable TiDB database that grows with your success

✅ Fast development experience that doesn’t make you want to switch careers

✅ Cost-effective serverless deployment (your wallet thanks you)

✅ Production-ready code that won’t wake you up at 3 AM

This stack is like assembling the Avengers of web development technologies. Each piece brings its superpower, and together they create something greater than the sum of their parts (and way cooler than your last WordPress site).

Next Steps (Because We’re Never Really Done)

Consider adding these upgrades to your masterpiece:

Authentication (because not everyone should access your data)
Input validation with Zod (trust, but verify)
Rate limiting and caching (because users can be… enthusiastic)
Automated testing with Jest (because manual testing is for masochists)
CI/CD pipelines with GitHub Actions (automate all the things!)
Monitoring with AWS CloudWatch or DataDog (know thy application)

Remember: the best code is the code that works, doesn’t break production, and makes your future self thank your past self instead of cursing your name.

Thanks for reading! 🙌
If you enjoyed this guide:

Leave a ❤️ or comment — it really helps me know what to write next
Follow me here on Hashnode for more
Connect with me on X.

Happy coding, you caffeinated developers! ☕

useForm Like a Pro: Mistakes You Might Be Making (And How to Fix Them)

Sazzadur Rahman — Mon, 31 Mar 2025 03:39:58 GMT

Let’s face it — building forms in React is about as enjoyable as stepping on a LEGO at 3 AM. You start with the best intentions, telling yourself “it’s just a simple form,” and six hours later you’re surrounded by coffee cups, questioning your career choices.

This is your intervention. Put down that seventh cup of coffee and let me introduce you to useForm — the hook that will make you hate forms slightly less than you do now.

The Problem (Or: Why Forms Make Developers Cry)

If you’ve ever built a form in React, you’re probably familiar with code that looks like this monstrosity:

function TraditionalForm() {
  const [name, setName] = useState("");
  const [email, setEmail] = useState("");
  const [nameError, setNameError] = useState("");
  const [emailError, setEmailError] = useState("");
  // …27 more state variables because why not?

  const handleNameChange = e => {
    setName(e.target.value);
    if (e.target.value.trim() === "") {
      setNameError("Name is required");
    } else if (e.target.value.length < 3) {
      setNameError("Name must be at least 3 characters");
    } else {
      setNameError("");
    }
  };

  const handleEmailChange = e => {
    // Copy and paste the function above with minor tweaks
    // Developer skills at work!
  };

  // Several more nearly-identical functions here
  const handleSubmit = e => {
    e.preventDefault();
    // Validate everything again because trust issues
    // Submit if the stars align and Mercury isn't in retrograde
  };

  return (
    
          {/* A UI that took 30% of your development time */}
    
  );
}

This approach has several drawbacks:

State Explosion: More state variables than you have fingers and toes
Copy-Paste Engineering: Spread that validation logic like it’s going out of style
Bug Breeding Ground: “Why isn’t my form validating?” (Narrator: It was.)
TypeScript Nightmares: Type errors that make you question if you really understand programming after all

The Solution: useForm Hook (A.K.A. Form Therapy)

Our custom useForm hook provides a simple API that won’t make you want to become a sheep farmer:

import { useForm } from "./lib/hooks/useForm";
import { required, email } from "./lib/validation";

function SimpleForm() {
 const { values, errors, handleChange, handleSubmit } = useForm({
  initialValues: {
   name: "",
   email: "",
  },
  validationSchema: {
   name: [required()],
   email: [required(), email()],
  },
  onSubmit: values => {
   console.log("Form submitted:", values);
   // Time to celebrate with a victory dance
  },
 });

 return (
  
   
    "name">Name
    "name" name="name" value={values.name} onChange={handleChange} />
    {errors.name && "error">{errors.name}}
   

   
    "email">Email
    "email" name="email" type="email" value={values.email} onChange={handleChange} />
    {errors.email && "error">{errors.email}}
   

   
  
 );
}

Key Features (Or: Why You’ll Delete Your Old Form Code)

The useForm hook provides:

One State to Rule Them All: All form values and errors in one place, like a neat little package that won’t explode in your face
Validation That Actually Makes Sense: Declarative validation rules that don’t make you question your life choices
TypeScript That Helps Instead of Hurts: Full type safety without wanting to throw your computer out the window
Less Code, More Coffee Time: Do more with less so you can actually take that lunch break
Field Tracking: Knows which fields have been touched, unlike your memory after debugging for 5 hours straight

Using the Register API (Because Less Code = More Happiness)

Our hook provides a register function that helps you connect form fields with less code than your average tweet: The register function bundles everything together like a burrito of form functionality — all the good stuff wrapped in a neat package.

import { FormField } from "./components/FormField";
import { useForm } from "./lib/hooks/useForm";
import { required, email, minLength } from "./lib/validation";

function RegisterAPIForm() {
 const { handleSubmit, register } = useForm({
  initialValues: {
   name: "",
   email: "",
   password: "",
  },
  validationSchema: {
   name: [required(), minLength(3)],
   email: [required(), email()],
   password: [required(), minLength(8)], // Because "password" is not secure
  },
  onSubmit: values => {
   console.log("Form submitted:", values);
   // Tell your PM you spent days on this
  },
 });

 return (
  
   "name")} label="Name" />
   "email")} label="Email" type="email" />
   "password")} label="Password" type="password" />

   
  
 );
}

The register function bundles everything together like a burrito of form functionality — all the good stuff wrapped in a neat package.

The FormField component is like the Swiss Army knife of form fields — it handles labels, inputs, and error messages so you don’t have to. For the full code (and to see how the magic happens), check out The FormField Component.

Validation Rules (For All Those Users Who Type “password123”)

Our validation system has more rules than a bureaucratic handbook:

import {
 required,
 email,
 minLength,
 maxLength,
 pattern,
 url,
 numeric,
 alphanumeric,
 range,
 passwordStrength,
 passwordMatch,
 phoneNumber,
 date,
} from "./lib/validation";

// Example usage for those users who think "123" is a strong password:
const validationSchema = {
 username: [
  required("Please provide a username, or we'll just call you 'Mystery Guest'"),
  minLength(3, "Your username needs at least 3 characters—brevity isn't always the soul of wit"),
 ],
 email: [
  required("We need your email, but don't worry, we won't send you cat memes... probably"),
  email("That doesn't look like a valid email—did you forget the '@'?"),
 ],
 password: [
  required("A password is required—security first!"),
  minLength(8, "Make it at least 8 characters—short passwords are so last decade"),
  passwordStrength("Your password needs to be stronger—think 'Fort Knox,' not '1234'"),
 ],
 confirmPassword: [
  required("Please confirm your password—we're not mind readers"),
  passwordMatch("password", "Your passwords don't match—try again, champ"),
 ],
 age: [
  numeric("Enter your age as a number, not 'forever young'"),
  range(18, 99, "You must be between 18 and 99—no exceptions for time travelers"),
 ],
};

Conditional Validation (For When Life Gets Complicated)

Sometimes validation depends on other form values. The when helper lets you add conditions dynamically, making your forms smarter and more adaptable:

import { when, required } from "./lib/validation";

const validationSchema = {
 shippingAddress: [
  when(
   values => values.needsShipping === true,
   required("We need to know where to send your stuff unless you're telepathic")
  ),
 ],
 companyName: [
  when(
   values => values.accountType === "business",
   required("Businesses typically have names, unless you're in the witness protection program")
  ),
 ],
};

Here’s a real-world example of a sign-up form that won’t make you question your career choices:

import { FormField } from "./components/FormField";
import { useForm } from "./lib/hooks/useForm";
import { email, minLength, passwordMatch, passwordStrength, required } from "./lib/validation";

const SignUpForm = () => {
 const { handleSubmit, register } = useForm({
  initialValues: {
   name: "",
   email: "",
   password: "",
   confirmPassword: "",
  },
  validateOnBlur: true,
  validateOnChange: true,
  validationSchema: {
   name: [required(), minLength(3)],
   email: [required(), email()],
   password: [required(), minLength(8), passwordStrength()],
   confirmPassword: [required(), passwordMatch("password")],
  },
  onSubmit: values => {
   console.log("Form submitted with values:", values);
   // In a real app, you would call an API here
   alert("Sign up successful! We now own your data!");
  },
 });

 return (
  "flex flex-col items-center justify-center min-h-screen bg-slate-200">
   "w-full max-w-md p-6 bg-white rounded-lg shadow-md space-y-4">
    "text-2xl font-bold text-center mb-6">Join Our Cult (Er, Platform)

    "name")} label="Name" placeholder="Your name, not your gamer tag" type="text" />

    "email")} label="Email" placeholder="The one you actually check" type="email" />

    "password")} label="Password" placeholder="Not 'password123' please" type="password" />

    "confirmPassword")}
     label="Confirm Password"
     placeholder="Same as above, we're checking"
     type="password"
    />

    
   
  
 );
};

Best Practices (From Developers Who’ve Made All the Mistakes)

Type your form values (unless you enjoy debugging at 2 AM):

interface LoginFormValues {
 email: string;
 password: string;
 rememberMe: boolean; // For those who trust their browser more than their memory
}

const { values } = useForm({
 initialValues: {
  email: "",
  password: "",
  rememberMe: false,
 },
 // ...other stuff that makes forms work
});

Customize validation timing to balance user experience and your sanity:

useForm({
 // ...
 validateOnChange: true, // For the anxious who need immediate feedback
 validateOnBlur: true, // For the reflective who prefer feedback after thinking
});

Use custom error messages that don’t make users feel like they’re being scolded by a robot:

minLength(8, "Think of a password as a toothbrush: longer is better and don't share it with friends");

Separate form logic from UI because mixing concerns is like putting pineapple on pizza — technically possible but fundamentally wrong.

Full Implementation Reference

For those who want to copy-paste their way to productivity (we don’t judge), here are the full implementations of the core components:

The useForm Hook

// lib/hooks/useForm.ts

import { ChangeEvent, FormEvent, useState } from "react";
import { ValidationRule, validateField, validateForm } from "../validation";

export interface UseFormOptionsextends Record> {
 initialValues: T;
 onSubmit: (values: T) => Promise<void> | void;
 validationSchema?: {
  [K in keyof Partial]?: ValidationRule[];
 };
 validateOnChange?: boolean;
 validateOnBlur?: boolean;
}

export function useForm<T extends Record<string, any>>({
 initialValues,
 onSubmit,
 validationSchema = {},
 validateOnChange = false,
 validateOnBlur = false,
}: UseFormOptions) {
 const [values, setValues] = useState(initialValues);
 const [errors, setErrors] = useStatestring>>>({});
 const [touched, setTouched] = useStateboolean>>>({});
 const [isSubmitting, setIsSubmitting] = useState(false);

 const validate = (fieldName?: keyof T) => {
  if (fieldName) {
   // Validate single field
   const fieldRules = validationSchema[fieldName] as ValidationRuletypeof fieldName]>[] | undefined;

   if (fieldRules) {
    const error = validateField(values[fieldName], fieldRules, values);
    setErrors(prev => ({
     ...prev,
     [fieldName]: error,
    }));
    return !error;
   }
   return true;
  } else {
   // Validate all fields
   const newErrors = validateForm(values, validationSchema);
   setErrors(newErrors);
   return Object.keys(newErrors).length === 0;
  }
 };

 const handleChange = (e: ChangeEvent) => {
  const { name, value, type } = e.target as HTMLInputElement;
  const fieldName = name as keyof T;

  // Handle checkbox inputs
  const newValue = type === "checkbox" ? (e.target as HTMLInputElement).checked : value;

  // Update values first
  setValues(prev => ({
   ...prev,
   [fieldName]: newValue,
  }));

  if (validateOnChange || errors[fieldName]) {
   const fieldRules = validationSchema[fieldName] as ValidationRuletypeof fieldName]>[] | undefined;

   if (fieldRules) {
    const updatedValues = { ...values, [fieldName]: newValue };
    const error = validateField(newValue as T[typeof fieldName], fieldRules, updatedValues);

    setErrors(prev => ({
     ...prev,
     [fieldName]: error,
    }));

    if (!touched[fieldName]) {
     setTouched(prev => ({
      ...prev,
      [fieldName]: true,
     }));
    }
   }
  }
 };

 const handleBlur = (e: React.FocusEvent) => {
  const fieldName = e.target.name as keyof T;

  setTouched(prev => ({
   ...prev,
   [fieldName]: true,
  }));

  if (validateOnBlur) {
   validate(fieldName);
  }
 };

 const handleSubmit = async (e: FormEvent) => {
  e.preventDefault();

  // Mark all fields as touched
  const touchedFields = Object.keys(validationSchema).reduce(
   (acc, key) => ({ ...acc, [key]: true }),
   {} as Recordboolean>
  );

  setTouched(touchedFields as Partialboolean>>);

  // Validate all fields
  const isValid = validate();

  if (isValid) {
   setIsSubmitting(true);

   try {
    await onSubmit(values);
   } catch (error) {
    console.error("Form submission error:", error);
   } finally {
    setIsSubmitting(false);
   }
  }
 };

 const setFieldValue = (fieldName: keyof T, value: T[keyof T]) => {
  setValues(prev => ({
   ...prev,
   [fieldName]: value,
  }));

  if (validateOnChange && touched[fieldName]) {
   validate(fieldName);
  }
 };

 const setFieldError = (fieldName: keyof T, error: string) => {
  setErrors(prev => ({
   ...prev,
   [fieldName]: error,
  }));
 };

 const resetForm = () => {
  setValues(initialValues);
  setErrors({});
  setTouched({});
  setIsSubmitting(false);
 };

 const register = (fieldName: keyof T) => {
  return {
   name: fieldName,
   value: values[fieldName],
   onChange: handleChange,
   onBlur: handleBlur,
   error: errors[fieldName],
  };
 };

 return {
  values,
  errors,
  touched,
  isSubmitting,
  handleChange,
  handleBlur,
  handleSubmit,
  setFieldValue,
  setFieldError,
  resetForm,
  validate,
  register,
 };
}

Validation Library

// lib/validation.ts

/**
 * Type-safe validation utilities for form fields
 */

// Generic validation rule type that can handle different value types
export type ValidationRuleextends Record<string, unknown>, V = unknown> = {
 validate: (value: V, formValues?: T) => boolean;
 message: string | ((params: Record<string, unknown>) => string);
 params?: Record<string, unknown>;
};

// Helper to create validation messages with parameters
const createMessage = (
 message: string | ((params: Record<string, unknown>) => string),
 params?: Record<string, unknown>
): string => {
 if (typeof message === "function") {
  return message(params || {});
 }

 if (!params) return message;

 return Object.entries(params).reduce((msg, [key, value]) => msg.replace(new RegExp(`{${key}}`, "g"), String(value)), message);
};

export const required = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => value !== undefined && value !== null && value.trim() !== "",
 message: message || "This field is required",
});

export const email = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return !value || emailRegex.test(value);
 },
 message: message || "Please enter a valid email address",
});

export const minLength = extends Record<string, unknown>>(length: number, message?: string): ValidationRulestring> => ({
 validate: value => !value || value.length >= length,
 message: message || "Must be at least {length} characters long",
 params: { length },
});

export const maxLength = extends Record<string, unknown>>(length: number, message?: string): ValidationRulestring> => ({
 validate: value => !value || value.length <= length,
 message: message || "Cannot exceed {length} characters",
 params: { length },
});

export const pattern = extends Record<string, unknown>>(regex: RegExp, message?: string): ValidationRulestring> => ({
 validate: value => !value || regex.test(value),
 message: message || "Invalid format",
});

export const url = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => {
  if (!value) return true;
  try {
   new URL(value);
   return true;
  } catch {
   return false;
  }
 },
 message: message || "Please enter a valid URL",
});

export const numeric = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => !value || /^[0-9]+$/.test(value),
 message: message || "Must contain only numbers",
});

export const alphanumeric = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => !value || /^[a-zA-Z0-9]+$/.test(value),
 message: message || "Must contain only letters and numbers",
});

export const range = extends Record<string, unknown>>(
 min: number,
 max: number,
 message?: string
): ValidationRulestring | number> => ({
 validate: value => {
  if (value === undefined || value === null || value === "") return true;
  const numValue = typeof value === "string" ? parseFloat(value) : value;
  return !isNaN(numValue as number) && numValue >= min && numValue <= max;
 },
 message: message || "Value must be between {min} and {max}",
 params: { min, max },
});

export const passwordStrength = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => {
  if (!value) return true;
  const hasLetter = /[a-zA-Z]/.test(value);
  const hasNumber = /\d/.test(value);
  const hasSpecialChar = /[!@#$%^&*(),.?":{}|<>]/.test(value);
  return hasLetter && hasNumber && hasSpecialChar;
 },
 message: message || "Password must contain letters, numbers, and special characters",
});

export const passwordMatch = extends Record<string, unknown>>(
 matchField: keyof T,
 message?: string
): ValidationRulestring> => ({
 validate: (value, formValues) => !value || value === (formValues?.[matchField] as string),
 message: message || "Passwords do not match",
});

export const phoneNumber = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => {
  if (!value) return true;
  const phoneRegex = /^\+?[0-9]{10,15}$/;
  return phoneRegex.test(value.replace(/[-()\s]/g, ""));
 },
 message: message || "Please enter a valid phone number",
});

export const date = extends Record<string, unknown>>(message?: string): ValidationRulestring> => ({
 validate: value => {
  if (!value) return true;
  const date = new Date(value);
  return !isNaN(date.getTime());
 },
 message: message || "Please enter a valid date",
});

export const fileType = extends Record<string, unknown>>(
 allowedTypes: string[],
 message?: string
): ValidationRulenull> => ({
 validate: file => {
  if (!file) return true;
  const extension = file.name.split(".").pop()?.toLowerCase() || "";
  return allowedTypes.includes(extension);
 },
 message: message || "File type not allowed. Allowed types: {types}",
 params: { types: allowedTypes.join(", ") },
});

export const fileSize = extends Record<string, unknown>>(
 maxSizeInMB: number,
 message?: string
): ValidationRulenull> => ({
 validate: file => {
  if (!file) return true;
  const sizeInMB = file.size / (1024 * 1024);
  return sizeInMB <= maxSizeInMB;
 },
 message: message || "File size cannot exceed {size}MB",
 params: { size: maxSizeInMB },
});

export const when = extends Record<string, unknown>, V>(
 condition: (formValues?: T) => boolean,
 rule: ValidationRule
): ValidationRule => ({
 validate: (value, formValues) => {
  return !condition(formValues) || rule.validate(value, formValues);
 },
 message: rule.message,
 params: rule.params,
});

/**
 * Validates a field against provided rules
 */
export const validateField = extends Record<string, unknown>, V>(
 value: V,
 rules: ValidationRule[],
 formValues?: T
): string => {
 for (const rule of rules) {
  if (!rule.validate(value, formValues)) {
   return createMessage(rule.message, rule.params);
  }
 }
 return "";
};

/**
 * Validates all fields in a form
 */
export const validateForm = extends Record<string, unknown>>(
 formValues: T,
 validationSchema: { [K in keyof T]?: ValidationRule[] }
): { [K in keyof T]?: string } => {
 const errors: Partialstring>> = {};

 for (const field in validationSchema) {
  if (validationSchema[field]) {
   const error = validateField(
    formValues[field],
    validationSchema[field] as ValidationRuletypeof field]>[],
    formValues
   );
   if (error) {
    errors[field] = error;
   }
  }
 }

 return errors;
};

FormField Component

// components/FormField.tsx

interface FormFieldProps extends React.InputHTMLAttributes {
 label: string;
 error?: string;
}

export const FormField: React.FC = ({ label, error, ...props }) => {
 return (
  `mb-4 ${props.className}`}>
   "block text-sm font-medium text-gray-700 mb-1">
    {label}
   
   `w-full px-3 py-2 border rounded-lg shadow-sm focus:outline-none focus:ring-2 focus:border-transparent ${
     error ? "border-red-500 focus:ring-red-200" : "border-gray-300 focus:ring-blue-200 focus:border-blue-500"
    } ${props.disabled ? "bg-gray-100 text-gray-500" : ""}`}
    {...props}
   />
   {error && "mt-1 text-sm text-red-600">{error}}
  
 );
};

Conclusion

The useForm hook won’t fix all your problems (sorry about that receding hairline), but it will make your form development experience significantly less painful. No more state management nightmares, no more validation logic sprawling across your components like an invasive species.

With our beautifully crafted, lovingly maintained, and slightly over-engineered form solution, you can focus on the important things — like arguing about whether dark mode is superior or if that button should be 2 pixels to the left.

Now go forth and create forms that don’t make users (or developers) want to throw their devices out the window. Your users will thank you, your therapist will see you less often, and your code reviewers might actually smile for once.

This article was written by a developer who has spent way too much time dealing with forms and has the therapy bills to prove it. No forms were harmed in the making of this hook, though several keyboards suffered minor damage from frustrated typing.

How to Create a Custom React Hook for LocalStorage Using React Context

Sazzadur Rahman — Sun, 28 Jul 2024 08:33:40 GMT

Managing local storage in React applications can become cumbersome, especially when you need to synchronize data across multiple components. By creating a custom hook combined with React Context, you can simplify this process and make your code more reusable and maintainable. In this article, I’ll guide you through creating a custom React hook for local storage and demonstrate how to integrate it using React Context.

Setting Up the Project

First, let’s set up a new React project using Vite with TypeScript for better type safety.

Open your terminal and execute the following command to create a new Vite project:

pnpm create vite@latest react-store-hook

During the setup, select react and then typescript to ensure your project uses TypeScript.

Navigate to the project directory and install the dependencies:

cd react-store-hook
pnpm install

Setting Up the React Context

Next, we’ll set up a React Context to provide our custom hook across the application. This way, we can access the local storage state in any component.

First, define the type for the context:

Create a folder types inside the src folder and a file index.d.ts inside the folder.

// src/types/index.d.ts

declare type StoreContextType = {
  [key: string]: unknown;
};

Now create a folder named hooks inside src folder.

Create the context file:

Create a StoreContext.ts file. The StoreContext will provide the global state and a method to update it across your application.

// src/hooks/StoreContext.ts

import { createContext, Dispatch, SetStateAction } from "react";

export const StoreContext = createContext<{
  store: StoreContextType;
  setStore: Dispatch>;
}>({
  store: {},
  setStore: () => {},
});

Next, create the provider component:

Create a StoreProvider.tsx file. The StoreProvider component will wrap your application and provide the StoreContext to its children.

// src/hooks/StoreProvider.tsx

import { useState, ReactNode, FC } from "react";
import { StoreContext } from "./StoreContext";

const StoreProvider: FC<{ children: ReactNode }> = ({ children }) => {
 const [store, setStore] = useState({});

 return {children};
};

export { StoreProvider };

Creating the Custom Hook: useStore

Now let’s create the custom hook useStore. This hook will interact with both the StoreContext and local storage. Create a useStore.ts file.

Add the following code step by step touseStore.ts:

Step 1: Import Necessary Modules

import { useContext, useEffect, useCallback, useState } from "react";
import { StoreContext } from "./StoreContext";

Here, we import React hooks and the StoreContext. We'll use these to manage state and context.

Step 2: Define the Hook Signature

const useStore = (
    key: string,
    initialValue?: T | null,
    storeInLocalStorage: boolean = true
): [T, (value: T) => void, boolean] => {

The useStore hook takes three parameters:

key: The key to store the value under.
initialValue: The initial value to set.
storeInLocalStorage: A flag to determine if the value should be stored in local storage.

It returns a array containing:

The stored value.
A function to update the value.
A loading state.

Step 3: Initialize the State

const { store, setStore } = useContext(StoreContext);

const initializeState = useCallback(() => {
    if (storeInLocalStorage && typeof window !== "undefined") {
        const storedValue = localStorage.getItem(key);
        return storedValue !== null ? JSON.parse(storedValue) : initialValue;
    }
    return initialValue || null;
}, [key, initialValue, storeInLocalStorage]);

const [isLoading, setIsLoading] = useState<boolean>(true);
const [localValue, setLocalValue] = useStateundefined>(initializeState);

We use useContext to get the store and setStore from StoreContext.
initializeState is a function that gets the initial state from local storage if the flag is set and the window object is available. Otherwise, it returns the initial value.
isLoading indicates if the state is being initialized.
localValue holds the current value.

Step 4: Sync State with Local Storage and Context

useEffect(() => {
    setIsLoading(true);

    if (storeInLocalStorage && localValue !== undefined) {
        localStorage.setItem(key, JSON.stringify(localValue));
    }
    setStore(prevStore => ({
        ...prevStore,
        [key]: localValue,
    }));

    setIsLoading(false);
}, [key, localValue, storeInLocalStorage, setStore]);

The useEffect hook syncs the localValue with local storage and the context whenever localValue, key, or storeInLocalStorage changes.
It updates local storage if the flag is set and sets the value in the context.

Step 5: Create the Set Value Function

const setValue = useCallback(
    (value: T) => {
        setLocalValue(value);
        setStore(prevStore => ({
            ...prevStore,
            [key]: value,
        }));

        if (storeInLocalStorage) {
            localStorage.setItem(key, JSON.stringify(value));
        }
    },
    [key, storeInLocalStorage, setStore]
);

The setValue function updates the localValue and the context.
It also updates local storage if the flag is set.

Step 6: Return the Hook Values

    return [store[key] !== undefined ? (store[key] as T) : (localValue as T), setValue, isLoading];
};

export default useStore;

The hook returns the current value, the setValue function, and the loading state.

FulluseStore.tsFile:

// src/hooks/useStore.ts

import { useContext, useEffect, useCallback, useState } from "react";
import { StoreContext } from "./StoreContext";

const useStore = (
 key: string,
 initialValue?: T | null,
 storeInLocalStorage: boolean = true
): [T, (value: T) => void, boolean] => {
 const { store, setStore } = useContext(StoreContext);

 const initializeState = useCallback(() => {
  if (storeInLocalStorage && typeof window !== "undefined") {
   const storedValue = localStorage.getItem(key);
   return storedValue !== null ? JSON.parse(storedValue) : initialValue;
  }

  return initialValue || null;
 }, [key, initialValue, storeInLocalStorage]);

 const [isLoading, setIsLoading] = useState<boolean>(true);
 const [localValue, setLocalValue] = useStateundefined>(initializeState);

 useEffect(() => {
  setIsLoading(true);

  if (storeInLocalStorage && localValue !== undefined) {
   localStorage.setItem(key, JSON.stringify(localValue));
  }
  setStore(prevStore => ({
   ...prevStore,
   [key]: localValue,
  }));

  setIsLoading(false);
 }, [key, localValue, storeInLocalStorage, setStore]);

 const setValue = useCallback(
  (value: T) => {
   setLocalValue(value);
   setStore(prevStore => ({
    ...prevStore,
    [key]: value,
   }));

   if (storeInLocalStorage) {
    localStorage.setItem(key, JSON.stringify(value));
   }
  },
  [key, storeInLocalStorage, setStore]
 );

 return [store[key] !== undefined ? (store[key] as T) : (localValue as T), setValue, isLoading];
};

export default useStore;

Putting It All Together

Finally, let’s see how to use the StoreProvider and useStore hook in your application.

In the `main.tsx` file:

// src/main.tsx

import { StoreProvider } from "./hooks/StoreProvider";
// other imports

ReactDOM.createRoot(document.getElementById("root")!).render(
 
  
   
  
 
);

In the component where you want to use the hook:

// src/MyComponent.tsx

import React from 'react';
import useStore from './hooks/useStore';

const MyComponent: React.FC = () => {
    const [value, setValue, isLoading] = useStore<string>('myKey', 'defaultValue');

    if (isLoading) {
        return Loading...;
    }

    return (
        
            Stored Value: {value}
            
        
    );
};

export default MyComponent;

Conclusion

In this article, we’ve walked through the process of creating a custom React hook for managing local storage, integrating it with React Context to provide a clean and efficient solution for state management across your application. By encapsulating local storage logic within a hook, we can keep our components simpler and more focused on their core responsibilities. Using TypeScript enhances type safety and makes the code more robust.

The useStore hook, combined with StoreContext and StoreProvider, provides a flexible and reusable way to manage local storage, ensuring that data is synchronized across components and reducing the need for repetitive code. This approach not only improves maintainability but also makes your application more scalable and easier to understand.

Implementing custom hooks and contexts in your React applications can significantly improve your development workflow. We encourage you to try integrating these patterns into your projects and experience the benefits of a cleaner, more maintainable codebase.

By following this guide, you’ll have an excellent tool for managing state in your React development toolbox. Feel free to experiment with this to tailor the useStore hook to your specific needs.

Happy coding!

Building a Responsive Layout with Tailwind CSS: Sidebars and Bottom Navigation

Sazzadur Rahman — Tue, 02 Jul 2024 11:46:12 GMT

Introduction

In today’s multi-device world, creating responsive web layouts is essential for delivering a seamless user experience across different screen sizes. A well-designed responsive layout adapts gracefully to various devices, ensuring that content is easily accessible and navigable whether viewed on a desktop, tablet, or smartphone. In this article, we’ll explore how to build a versatile and responsive website layout featuring a left sidebar, a right sidebar for larger screens, and a bottom navigation bar for smaller screens. Using the powerful utility-first CSS framework Tailwind CSS, we’ll simplify the process of crafting a dynamic and adaptive design that enhances usability and aesthetics. Let’s dive in and see how Tailwind CSScan help us achieve a modern, responsive layout effortlessly.

Visual Overview

To help visualize the layout we’ll be building, here are three images showing how it will appear on different screen sizes:

Large Screen Devices

On large screens, the layout includes both the left and right sidebars along with the main content area.

Medium Screen Devices

On medium screens, the layout simplifies to just the left sidebar and the main content area.

Small Screen Devices

On small screens, the layout transforms to have a bottom navigation bar and the main content area.

The main content area for each layout consists of a header, the main content, and a footer, ensuring a consistent structure across all devices.

Setting Up the Project

To get started, let’s create an empty HTML file and configure Tailwind CSS. Follow these steps:

Step 1: Create an HTML File

First, create an empty HTML file named index.html and open it in your preferred code editor. We’ll use the basic HTML boilerplate to set up our file.


"en">
  
    "UTF-8" />
    "viewport" content="width=device-width, initial-scale=1.0" />
    Resposive Layout

Step 2: Configure Tailwind CSS

To configure Tailwind CSS, we’ll use the following steps:

1. Add the Tailwind CSS Script Tag:

Add the following script tag inside the section of your index.html file to include Tailwind CSS from the CDN:

2. Test the Tailwind CSS Configuration:

To ensure that Tailwind CSS is working correctly, add the following HTML tag inside the section:

"text-3xl font-bold underline">Hello world!

Your index.html file should now look like this:


"en">
 
  "UTF-8" />
  "viewport" content="width=device-width, initial-scale=1.0" />
  
  Resposive Layout
 
 
  "text-3xl font-bold underline">Hello world!

3. Check the Result in the Browser:

Open index.html in your web browser. You should see the text “Hello world!” displayed with bold, underlined, and larger font size, confirming that Tailwind CSS is working correctly.

Now that we have our project set up and Tailwind CSS configured, we can start building our responsive layout.

Creating the HTML Structure

For large screen devices, our layout will include a left sidebar, a main content area with a header and footer, and a right sidebar. We’ll divide the page into three sections and place them side by side using display: flex. Here's how we can achieve this:

Step 1: Create the Main Container

We’ll start by creating a main container that takes up the full width of the page and uses Flexbox for layout.

"w-full flex h-svh max-h-svh">

w-full: Ensures the container takes up the full width of the viewport.
flex: Applies Flexbox layout to the container.
h-svh max-h-svh: Ensures the container takes up the full height of the viewport.

Step 2: Add the Left Sidebar

Next, we’ll add a div for the left sidebar inside the main container. This sidebar will take up 30% of the available space.

"w-full flex h-svh max-h-svh">
    "h-full flex-[0.3]">

h-full: Ensures the sidebar takes up the full height of the container.
flex-[0.3]: Allocates 30% of the available width to the sidebar.

Step 3: Add the Main Content Area

We’ll add another div for the main content area, which will take up the remaining space.

"w-full flex h-svh max-h-svh">
    "h-full flex-[0.3]">
        
    

    "h-full flex-1">

flex-1: Allocates the remaining space (70%) to the main content area.

Finally, we’ll add a div for the right sidebar, which will also take up 30% of the available space.

"w-full flex h-svh max-h-svh">
    "h-full flex-[0.3]">
        
    

    "h-full flex-1">
        
    

    "h-full flex-[0.3]">

flex-[0.3]: Allocates 30% of the available width to the right sidebar.

Adding Contents to Visualize

Let’s integrate the demo content into our large screen layout, including the left sidebar, main content area with header, content, and footer, and the right sidebar.

Step 1: Adding Content to Left Sidebar

First, add the demo content inside the left sidebar:

"w-full flex h-svh max-h-svh">
  "h-full flex-[0.3]">
    
    "grid h-full place-content-center bg-green-600">
      "text-xl">Left
      "text-xl">Sidebar
    
  

  "h-full flex-1">
    
  

  "h-full flex-[0.3]">

bg-green-600: Sets the background color of the left sidebar to green.
grid place-content-center: Centers the content vertically and horizontally within the sidebar.

Step 2: Adding Content to Left Sidebar

First, add the demo content inside the left sidebar:

"w-full flex h-svh max-h-svh">
  "h-full flex-[0.3]">
    
    "grid h-full place-content-center bg-green-600">
      "text-xl">Left
      "text-xl">Sidebar
    
  

  "h-full flex-1">
    
  

  "h-full flex-[0.3]">
    
    "grid h-full place-content-center bg-blue-600">
      "text-xl">Right
      "text-xl">Sidebar

bg-blue-600: Sets the background color of the right sidebar to blue.
grid place-content-center: Centers the content vertically and horizontally within the sidebar.

Step 3: Dividing Main Content Area

Next, divide the main content area into sections for header, content, and footer:

"h-full flex-1">
  
  "flex h-full flex-col justify-between overflow-y-scroll">

flex-col: Arranges the content in a column layout.
justify-between: Positions the header and footer at the top and bottom of the main content area, respectively.
overflow-y-scroll: Enables vertical scrolling within the main content area if needed.

Now let’s integrate the sticky header, content, and footer into our layout.

Step 1: Adding Sticky Header

Add the sticky header section at the top of the main content area:

"sticky top-0 w-full">
    
    "bg-orange-500 py-5">
        "text-center text-xl">Header

sticky top-0: Makes the header sticky at the top of the viewport when scrolling.
bg-orange-500: Sets the background color of the header to orange.
py-5: Adds padding vertically to the header for spacing.

Step 2: Content and Footer

Ensure the content and footer sections are appropriately placed within the main content area:


  
  "text-center text-xl">Content


"w-full">
  
  "bg-yellow-600 py-12">
    "text-center text-xl">Footer

Full Main Content Area Code

"h-full flex-1">
  
  "flex h-full flex-col justify-between overflow-y-scroll">
    "sticky top-0 w-full">
      
      "bg-orange-500 py-5">
      "text-center text-xl">Header
    
  

  
    
    "text-center text-xl">Content
  

  "w-full">
    
    "bg-yellow-600 py-12">
      "text-center text-xl">Footer

Current Layout Explanation

Till now, our layout includes a left sidebar, a main content area divided into three sections (header, content, and footer), and a right sidebar. Here’s a visual representation and an explanation of what it looks like:

Image Explanation

1. Left Sidebar:

Appearance: It has a green background with the words “Left” and “Sidebar” centered both vertically and horizontally.

2. Main Content Area:

Header: It has an orange background with the word “Header” centered. It is sticky and remains at the top of the viewport when scrolling.
Content: It has the word “Content” centered within this section.
Footer: It has a yellow background with the word “Footer” centered.

3. Right Sidebar:

Appearance: It has a blue background with the words “Right” and “Sidebar” centered both vertically and horizontally.

Layout Structure

Flexbox Layout: The overall layout uses Flexbox to arrange the left sidebar, main content area, and right sidebar side by side.
Width Distribution:
Left Sidebar: 30% width of the container.
Main Content Area: 40% width of the container.
Right Sidebar: 30% width of the container.
Height Distribution:
The entire layout takes up the full height of the viewport (h-svh and max-h-svh).
The main content area is divided vertically into header, content, and footer sections using Flexbox (flex-col and justify-between).

Full Code for Reference


"en">
 
  "UTF-8" />
  "viewport" content="width=device-width, initial-scale=1.0" />
  
  Resposive Layout
 
 
  "w-full flex h-svh max-h-svh">
   "h-full flex-[0.3]">
    
    "grid h-full place-content-center bg-green-600">
     "text-xl">Left
     "text-xl">Sidebar
    
   

   "h-full flex-1">
    
    "flex h-full flex-col justify-between overflow-y-scroll">
     "sticky top-0 w-full">
      
      "bg-orange-500 py-5">
       "text-center text-xl">Header
      
     

     
      
      "text-center text-xl">Content
     

     "w-full">
      
      "bg-yellow-600 py-12">
       "text-center text-xl">Footer
      
     
    
   

   "h-full flex-[0.3]">
    
    "grid h-full place-content-center bg-blue-600">
     "text-xl">Right
     "text-xl">Sidebar

Making the Layout Responsive

Let’s modify the existing layout to be responsive based on the given requirements:

Left Sidebar: Hidden on small screens and visible on medium screens and above.
Right Sidebar: Hidden on small and medium screens, visible on large screens and above.
Bottom Navigation: Visible on small screens, hidden on medium screens and above.

Here’s the modified code:

Add hidden md:block to the left sidebar to hide it on small screens and show it on medium and above:

"hidden h-full flex-[0.3] md:block">
  
  "grid h-full place-content-center bg-green-600">
    "text-xl">Left
    "text-xl">Sidebar

Add hidden lg:block to the right sidebar to hide it on small and medium screens and show it on large and above:

"hidden h-full flex-[0.3] lg:block">
  
  "grid h-full place-content-center bg-blue-600">
    "text-xl">Right
    "text-xl">Sidebar

Add the bottom navigation inside the main content area, visible on small screens and hidden on medium and above:

"sticky top-0 block bg-pink-500 py-5 md:hidden">
  "text-center text-xl">Bottom Navigation

Step 4: Modifying Main Content Area

Update the main content area to include the bottom navigation:

"flex h-full flex-1 flex-col">
  
  
    
  

  "sticky top-0 block bg-pink-500 py-5 md:hidden">
    "text-center text-xl">Bottom Navigation

Full Responsive Layout Code

Here’s the complete HTML structure for the responsive layout:


"en">
 
  "UTF-8" />
  "viewport" content="width=device-width, initial-scale=1.0" />
  
  Resposive Layout
 
 
  "w-full flex h-svh max-h-svh">
   "hidden h-full flex-[0.3] md:block">
    
    "grid h-full place-content-center bg-green-600">
     "text-xl">Left
     "text-xl">Sidebar
    
   

   "flex h-full flex-1 flex-col">
    
    "flex h-full flex-col justify-between overflow-y-scroll">
     "sticky top-0 w-full">
      
      "bg-orange-500 py-5">
       "text-center text-xl">Header
      
     

     
      
      "text-center text-xl">Content
     

     "w-full">
      
      "bg-yellow-600 py-12">
       "text-center text-xl">Footer
      
     
    

    "sticky top-0 block bg-pink-500 py-5 md:hidden">
     "text-center text-xl">Bottom Navigation
    
   

   "hidden h-full flex-[0.3] lg:block">
    
    "grid h-full place-content-center bg-blue-600">
     "text-xl">Right
     "text-xl">Sidebar

Explanation of Responsive Classes

hidden md:block:
Left Sidebar: Hidden by default (hidden) and displayed as a block (block) on medium screens and above (md).
hidden lg:block:
Right Sidebar: Hidden by default (hidden) and displayed as a block (block) on large screens and above (lg).
block md:hidden:
Bottom Navigation: Displayed as a block (block) by default and hidden (hidden) on medium screens and above (md).

This setup ensures the layout adapts seamlessly to different screen sizes, providing a user-friendly experience across devices.

Visual Representation:

Medium Screen Layout

On medium screens, the layout includes the left sidebar and the main content area, but the right sidebar is hidden.

Explanation:

Left Sidebar: Visible with the same green background as on large screens, taking up 30% of the width.
Main Content Area: Takes up the remaining width (70%) and includes the header, content, and footer sections.
Right Sidebar: Hidden (hidden lg:block).

Small Screen Layout

On small screens, the layout includes only the main content area and a bottom navigation bar, while both sidebars are hidden.

Explanation:

Left Sidebar: Hidden (hidden md:block).
Main Content Area: Takes up the full width and includes the header, content, and footer sections.
Bottom Navigation: Visible at the bottom, with a pink background, displayed using block md:hidden.

Responsive Behavior Summary Table

Here’s a table summarizing the responsive behavior for different screen sizes:

Component	Small Screens (<768px)	Medium Screens (>=768px)	Large Screens (>=1024px)
Left Sidebar	Hidden	Visible	Visible
Main Content	Visible	Visible	Visible
Right Sidebar	Hidden	Hidden	Visible
Bottom Navigation	Visible	Hidden	Hidden

This table provides a clear and concise summary of how each component behaves across different screen sizes, ensuring that the layout adapts effectively to provide an optimal user experience on all devices.

Conclusion

In this guide, we’ve walked through the process of creating a responsive layout for a website using Tailwind CSS. Our goal was to build a layout that adapts to different screen sizes, ensuring a seamless user experience across all devices. Here’s a quick recap of what we’ve accomplished:

1. Initial Setup:

Created an empty HTML file and included the Tailwind CSS script.
Verified the Tailwind CSS setup with a test element.

2. Building the Layout:

Divided the page into three sections: a left sidebar, a main content area (with header, content, and footer), and a right sidebar.
Used Flexbox to arrange these sections side by side.

3. Adding Demo Content:

Populated the left and right sidebars, as well as the main content area, with sample content to visualize the layout.

4. Making the Layout Responsive:

Utilized Tailwind CSS utility classes to hide or show elements based on the screen size:
Left Sidebar: Hidden on small screens, visible on medium and large screens.
Right Sidebar: Hidden on small and medium screens, visible on large screens.
Bottom Navigation: Visible on small screens, hidden on medium and large screens.
Ensured the main content area remained visible on all screen sizes.

5. Responsive Behavior Summary:

Provided a table summarizing the behavior of each component across different screen sizes.

By following these steps, you can create a versatile and user-friendly layout that caters to various devices, from large desktop monitors to small mobile screens. Tailwind CSS simplifies the process, allowing you to focus on designing and building a responsive layout without getting bogged down in complex CSS. This approach not only enhances the visual appeal of your website but also improves accessibility and usability for all users.

Happy Coding!

Building an Infinite Scroll FlatList Component in ReactJS: A Comprehensive Guide

Sazzadur Rahman — Mon, 17 Jun 2024 03:56:15 GMT

Introduction

A FlatList is a performant interface for rendering large lists of data. Commonly used in mobile applications, especially in React Native, Flatlist components help in managing complex lists efficiently. This article will guide you through creating a FlatList-like component in a web application using ReactJS.

Setting Up the Project

First, we’ll create a new React project using Vite and set up Tailwind CSS for styling. Follow these steps:

1. Create React Project:

pnpm create vite@latest react-flatlist

2. Navigate to the project directory and install dependencies:

cd react-flatlist
pnpm install

3. Install Tailwind CSS:

pnpm add -D tailwindcss postcss autoprefixer
pnpm dlx tailwindcss init -p

4. Configure Tailwind CSS:

Update tailwind.config.js:

export default {
  // replace this
  content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx}"],
  // your other configs
  theme: {
    extend: {},
  },
  plugins: [],
}

5. Add Tailwind CSS Directives:

Add these lines to the top of your index.css file:

@tailwind base;
@tailwind components;
@tailwind utilities;

6. Install Axios:

pnpm add axios

7. Run the Project:

pnpm dev

Now, your React project is set up with Tailwind CSS for styling and axios for easy data fetching. You’re ready to start building the Flatlist Component!

Creating the Flatlist Component

1. Import Required Dependencies and Define Props Interface

In src/components/FlatList.tsx, import the necessary modules and define the interface for the props:

import { Fragment, Key, ReactNode, useCallback, useEffect } from "react";

interface ListProps {
 data: T[];
 keyExtractor: (item: T) => Key;
 renderItem: (item: T) => ReactNode;
 ItemSeparatorComponent?: () => ReactNode;
 ListFooterComponent?: () => ReactNode;
 onEndReached?: () => void;
 onEndReachedThreshold?: number;
}

2. Create the FlatList Component

Implement the FlatList component using the provided structure:

const FlatList = ({
 data,
 keyExtractor,
 renderItem,
 ItemSeparatorComponent,
 ListFooterComponent,
 onEndReached,
 onEndReachedThreshold = 0.5,
}: ListProps) => {
 const handleScroll = useCallback(() => {
  const { scrollTop, scrollHeight, clientHeight } = document.documentElement;

  if (scrollTop + clientHeight >= scrollHeight - onEndReachedThreshold) {
   if (onEndReached) onEndReached();
  }
 }, [onEndReached, onEndReachedThreshold]);

 useEffect(() => {
  window.addEventListener("scroll", handleScroll);
  return () => window.removeEventListener("scroll", handleScroll);
 }, [handleScroll]);

 return (
  <>
   {data.map((item, index) => (
    
     {renderItem(item)}
     {ItemSeparatorComponent && index < data.length - 1 && }
    
   ))}
   {ListFooterComponent && }
  
 );
};

export default FlatList;

Using the FlatList Component

1. Basic FlatList Rendering

In your App.tsx, import and use the FlatList component and render demo data:

import FlatList from "./components/FlatList";

type Item = { id: number; title: string };

const data = Array.from({ length: 100 }).map((_, index) => ({ id: index + 1, title: `Item ${index + 1}` }));

const App = () => {
 const renderItem = (item: Item) => {item.title};
 const keyExtractor = (item: { id: number }) => item.id;

 return (
  "space-y-4 max-w-2xl mx-auto w-full">
   "mt-4 text-3xl font-bold text-center">React FlatList

   
  
 );
};

export default App;

2. Check the Browser:

Open your browser and navigate to the local server (usually http://localhost:5173). You should see the heading ‘React FlatList’, followed by 100 list items.

This confirms that your project setup with Tailwind CSS and the FlatList component is rendering the items. Now you’re ready to implement the full features of FlatList component!

Handling Data

1. Fetching Data

Modify the App.tsx to fetch data from an API or use mock data. Let's use the JSONPlaceholder API to get some todos and display them in the list.

First, define the Todo type:

type Todo = { id: number; title: string; completed: boolean; userId: number };

Define a todos state:

const [todos, setTodos] = useState([]);

Write the function to fetch the todos

const fetchData = useCallback(async () => {
 try {
  const { data } = await axios.get("https://jsonplaceholder.typicode.com/todos");

  setTodos(data);
 } catch (error) {
  console.log("error", error);
 }
}, []);

Wrapping the fetch function with useCallback is necessary to ensure it doesn’t recreate the function on every render, which could cause unnecessary re-renders or re-fetches.

Fetch Data on Component Mount

Use useEffect to fetch data when the component mounts.

useEffect(() => {
 fetchData();
}, [fetchData]);

Pass Todos to the FlatList Component

Style the renderItem and ItemSeparatorComponent

const renderItem = (item: Todo) => (
 "bg-slate-900 rounded-lg overflow-hidden flex flex-col justify-between">
  "px-5 py-8 flex items-center gap-4">
   {item.id})
   "text-2xl capitalize">{item.title}
  
  "bg-slate-600 py-2">
   "text-center">{item.completed ? "Completed" : "Not completed"}
  
 
);

const ItemSeparatorComponent = () => "my-1 h-[1px] border-t border-t-zinc-700 border-dashed" />;

2. Whole `App` Component

Here’s the complete code for the App component:

import { useCallback, useEffect, useState } from "react";
import axios from "axios";
import FlatList from "./components/FlatList";

type Todo = { id: number; title: string; completed: boolean; userId: number };
const App = () => {
 const [todos, setTodos] = useState([]);

 const fetchData = useCallback(async () => {
  try {
   const { data } = await axios.get("https://jsonplaceholder.typicode.com/todos");

   setTodos(data);
  } catch (error) {
   console.log("error", error);
  }
 }, []);

 useEffect(() => {
  fetchData();
 }, [fetchData]);

 const renderItem = (item: Todo) => (
  "bg-slate-900 rounded-lg overflow-hidden flex flex-col justify-between">
   "px-5 py-8 flex items-center gap-4">
    {item.id})
    "text-2xl capitalize">{item.title}
   
   "bg-slate-600 py-2">
    "text-center">{item.completed ? "Completed" : "Not completed"}
   
  
 );

 const ItemSeparatorComponent = () => "my-1 h-[1px] border-t border-t-zinc-700 border-dashed" />;

 const keyExtractor = (item: { id: number }) => item.id;

 return (
  "space-y-4 max-w-2xl mx-auto w-full">
   "mt-4 text-3xl font-bold text-center">React FlatList

   
  
 );
};

export default App;

Now, when you run the project and view it in your browser, you should see a list of todos displayed in your browser.

Adding Pagination to the FlatList Component

In this section, we’ll enhance our FlatList component by adding pagination, allowing the list to load more items as you scroll down. We'll use constants to manage the number of items per page, total items, and the threshold for triggering the end-of-list event.

1. Define Constants

First, let’s define some constants for our component:

const ITEM_PER_PAGE = 10;
const TOTAL_ITEMS = 200;
const ON_END_REACHED_THRESHOLD = 0.2;

2. Define States and a Ref

Next, we’ll define the states for managing the current page, the loading state, and a ref to track the initial render:

const [page, setPage] = useState(1);
const [hasMore, setHasMore] = useState(true);
const [isLoading, setIsLoading] = useState(false);

const initialRender = useRef(true); // Ref to track the initial render

3. Modify the fetchData Function

We’ll update the fetchData function to handle pagination. This function will fetch data based on the current page and append it to the existing list:

const fetchData = useCallback(async () => {
  setIsLoading(true);

  try {
    const { data } = await axios.get(`https://jsonplaceholder.typicode.com/todos?_limit=${ITEM_PER_PAGE}&_page=${page}`);

    setTodos(prevData => {
      const todos = [...prevData, ...data];

      if (todos.length >= TOTAL_ITEMS) {
        setHasMore(false);
      }

      return todos;
    });
  } catch (error) {
    console.log("error", error);
  } finally {
    setIsLoading(false);
  }
}, [page]);

4. Modify the useEffect

We’ll modify the useEffect to call fetchData only if there are more items to load:

useEffect(() => {
  if (initialRender.current) {
    initialRender.current = false;
    return;
  }
  if (hasMore) {
    fetchData();
  }
}, [fetchData, hasMore]);

5. Add the ListFooterComponent

We’ll add a ListFooterComponent to display a loading indicator or an end-of-list message:

const ListFooterComponent = () => (
  <>
    {isLoading && "text-center p-5">Loading...}
    {!isLoading && !hasMore && "text-center p-5">End of List}
  
);

6. Add the onEndReached Function

The onEndReached function will increment the page number when the end of the list is reached:

const onEndReached = () => {
  if (!isLoading && hasMore) {
    setPage(prevPage => prevPage + 1);
  }
};

7. Pass Additional Props to FlatList

Finally, we’ll pass ListFooterComponent, onEndReached, and ON_END_REACHED_THRESHOLD to the FlatList component:

8. Complete `App` Component

Here’s the complete App component with all the modifications:

import { useCallback, useEffect, useRef, useState } from "react";
import axios from "axios";
import FlatList from "./components/FlatList";

const ITEM_PER_PAGE = 10;
const TOTAL_ITEMS = 200;
const ON_END_REACHED_THRESHOLD = 0.2;

type Todo = { id: number; title: string; completed: boolean; userId: number };

const App = () => {
 const [todos, setTodos] = useState([]);
 const [page, setPage] = useState(1);
 const [hasMore, setHasMore] = useState(true);
 const [isLoading, setIsLoading] = useState(false);

 const initialRender = useRef(true); // Ref to track the initial render

 const fetchData = useCallback(async () => {
  setIsLoading(true);

  try {
   const { data } = await axios.get(`https://jsonplaceholder.typicode.com/todos?_limit=${ITEM_PER_PAGE}&_page=${page}`);

   setTodos(prevData => {
    const todos = [...prevData, ...data];

    if (todos.length >= TOTAL_ITEMS) {
     setHasMore(false);
    }

    return todos;
   });
  } catch (error) {
   console.log("error", error);
  } finally {
   setIsLoading(false);
  }
 }, [page]);

 useEffect(() => {
  if (initialRender.current) {
   initialRender.current = false;
   return;
  }
  if (hasMore) {
   fetchData();
  }
 }, [fetchData, hasMore]);

 const renderItem = (item: Todo) => (
  "bg-slate-900 rounded-lg overflow-hidden flex flex-col justify-between">
   "px-5 py-8 flex items-center gap-4">
    {item.id})
    "text-2xl capitalize">{item.title}
   
   "bg-slate-600 py-2">
    "text-center">{item.completed ? "Completed" : "Not completed"}
   
  
 );

 const ItemSeparatorComponent = () => "my-1 h-[1px] border-t border-t-zinc-700 border-dashed" />;

 const ListFooterComponent = () => (
   <>
     {isLoading && "text-center p-5">Loading...}
     {!isLoading && !hasMore && "text-center p-5">End of List}
   
 );

 const keyExtractor = (item: { id: number }) => item.id;

 const onEndReached = () => {
  if (!isLoading && hasMore) {
   setPage(prevPage => prevPage + 1);
  }
 };

 return (
  "space-y-4 max-w-2xl mx-auto w-full">
   "mt-4 text-3xl font-bold text-center">React FlatList

   
  
 );
};

export default App;

After implementing these changes, you should be able to see the list of todos in your browser. As you scroll to the bottom, more items will load, and a loading indicator will appear. If there are no more items to load, an “End of List” message will be displayed.

Conclusion

Creating a FlatList-like component for a web application using ReactJS is a powerful way to efficiently manage and display large datasets with infinite scrolling. This tutorial walked through building such a component, emphasizing the importance of handling data fetching, pagination, and maintaining a responsive user experience.

Key steps included:

Setting Up the FlatList Component: We created a reusable FlatList component with essential props such as data, keyExtractor, renderItem, ItemSeparatorComponent, ListFooterComponent, onEndReached, and onEndReachedThreshold.
Handling Data Fetching: By utilizing the useCallback and useEffect hooks, we ensured efficient data fetching and updating the state only when necessary.
Adding Pagination: We implemented a pagination system that loads more items as the user scrolls down, using constants to manage the number of items per page and the total items.
Enhancing User Experience: The ListFooterComponent provided visual feedback to users about the loading state and the end of the list.

By following these steps, you can create a highly customizable and efficient infinite scroll component for any dataset. This approach not only improves the user experience by providing seamless data loading but also enhances performance by loading data incrementally.

Feel free to experiment with different styles and configurations to tailor the FlatList component to your specific needs. Happy coding!

Implementing Google Login in NextJS 14: A Complete Guide with AuthJS 5, MongoDB, and Prisma ORM

Sazzadur Rahman — Thu, 13 Jun 2024 07:30:35 GMT

Introduction

In today’s digital landscape, secure user authentication is crucial for any web application. Google authentication provides a seamless and secure way for users to log in using their Google accounts. This tutorial will guide you through implementing Google authentication in a NextJS 14 application using AuthJS 5, MongoDB, and Prisma ORM.

By the end of this article, you’ll have a robust authentication system that leverages the power of modern web technologies, ensuring both security and ease of use.

Let’s dive in and get started with setting up our NextJS project!

Setting Up the Project

1. Initialize a NextJS Project

First, we’ll create a new NextJS project named nextjs-google-auth by running the following command:

npx create-next-app@latest nextjs-google-auth

Follow the prompts to set up the project according to your preferences.

2. Navigate to the Project Directory

Move into the newly created project directory:

cd nextjs-google-auth

3. Install Necessary Dependencies
Next, install the required packages for authentication and database management:

npm install next-auth@beta @prisma/client @auth/prisma-adapter
npm install prisma --save-dev

Note: We use next-auth@beta because Auth.js version 5 is currently in beta. If you're reading this in the future when Auth.js 5 is fully released, you can install it with npm install next-auth .

4. Set Up Google Auth Credentials
We will need a Google Auth Client ID and Client Secret. To generate these credentials:

Go to the Google Cloud Console
Register a new application and create OAuth 2.0 credentials.
Set the Callback URL to: https:///api/auth/callback/google .

Copy the generated Client ID and Client Secret, and paste them into the .env file in your project directory:

AUTH_GOOGLE_ID="your-google-client-id"
AUTH_GOOGLE_SECRET="your-google-client-secret"

5. Generate an Auth Secret
Run the following command to generate a secret for authentication and add it to the .env file:

npx auth secret

Add the generated secret to your .env file:

AUTH_SECRET="your-auth-secret"

6. Set Up the Database

Go to the MongoDB website and create a new database. Once the database is created, obtain the connection string.

Remember to include your database name in the connection string. Add this connection string to your .env file:

DATABASE_URL="mongodb+srv://:@/?retryWrites=true&w=majority&appName="

This sets up the basic configuration for your project, ensuring you have the necessary environment variables and dependencies to proceed with implementing Google authentication.

Next, we will configure Prisma to work with MongoDB.

Configuring Prisma ORM

1. Initialize Prisma
Run the following command to initialize Prisma with MongoDB as the datasource provider:

npx prisma init --datasource-provider mongodb

This will generate a prisma folder and a schema.prisma file inside it.

2. Configure the Prisma Schema
Replace the contents of the prisma/schema.prisma file with the following:

// prisma/schema.prisma

datasource db {
  provider = "mongodb"
  url      = env("DATABASE_URL")
}

generator client {
  provider = "prisma-client-js"
}

model User {
  id            String    @id @default(auto()) @map("_id") @db.ObjectId
  name          String?
  email         String?   @unique
  emailVerified DateTime?
  image         String?
  accounts      Account[]
}

model Account {
  id                String   @id @default(auto()) @map("_id") @db.ObjectId
  userId            String   @db.ObjectId
  type              String
  provider          String
  providerAccountId String
  refresh_token     String?  @db.String
  access_token      String?  @db.String
  expires_at        Int?
  token_type        String?
  scope             String?
  id_token          String?  @db.String
  session_state     String?
  createdAt         DateTime @default(now())
  updatedAt         DateTime @updatedAt
  user              User     @relation(fields: [userId], references: [id], onDelete: Cascade)

  @@unique([provider, providerAccountId])
}

3. Generate Prisma Client
Run the following command to generate the Prisma client based on the updated schema:

npx prisma generate

This configures Prisma to work with MongoDB and sets up the necessary models for handling user authentication data.

Configuring the Database Connection and Authentication

1. Create alibFolder
Inside the src folder, create a lib folder to store our database and authentication configurations.

2. Createdb.tsin thelibFolder
Create a db.ts file inside the lib folder with the following content:

// @/lib/db.ts

import { PrismaClient } from "@prisma/client";

const prismaClientSingleton = () => {
  return new PrismaClient();
};

declare global {
  var prisma: undefined | ReturnType<typeof prismaClientSingleton>;
}

const db = globalThis.prisma ?? prismaClientSingleton();

export default db;

if (process.env.NODE_ENV !== "production") globalThis.prisma = db;

3. Createauth.config.tsin thelibFolder
Create a auth.config.tsfile inside the lib folder with the following content:

// @/lib/auth.config.ts

import { NextAuthConfig } from "next-auth";
import Google from "next-auth/providers/google";

export const authConfig: NextAuthConfig = {
  providers: [Google],
};

4. Createauth.tsin thesrcFolder
Create a auth.ts file inside the src folder with the following content:

// @/auth.ts

import NextAuth from "next-auth";
import { authConfig } from "@/lib/auth.config";
import { PrismaAdapter } from "@auth/prisma-adapter";
import db from "@/lib/db";

export const { handlers, signIn, signOut, auth } = NextAuth({
 ...authConfig,
 adapter: PrismaAdapter(db),
 session: {
  strategy: "jwt",
 },
 pages: {
  signIn: "/login",
 },
 callbacks: {
  async jwt({ token, user }) {
   if (user) {
    // get user from db with the email
    // if there is no user with the email, create new user
    // else set the user data to token
   }

   return token;
  },

  async session({ session, token }) {
   if (token) {
    // set the token data to session
   }

   return session;
  },

  redirect() {
   return "/login";
  },
 },
});

Setting Up API Routes and Middleware

1. Create API Route for Authentication
Inside the app folder, create an api folder, then an auth folder, and finally a [...nextauth] folder inside it. Create a route.ts file inside the [...nextauth] folder with the following content:

// @/app/api/auth/[…nextauth]/route.ts

import { handlers } from "@/auth";

export const { GET, POST } = handlers;

2. Createroutes.tsin thesrcFolder
Create a routes.ts file inside the src folder with the following content:

// @/routes.ts

export const API_AUTH_PREFIX = "/api/auth";

export const AUTH_ROUTES = ["/login"];

export const PROTECTED_ROUTES = [
  "/",
  // your other protected routes
]

3. Createmiddleware.tsin thesrcFolderCreate a middleware.ts file inside the src folder with the following content:

// @/middleware.ts

import NextAuth from "next-auth";
import { NextResponse } from "next/server";

import { authConfig } from "@/lib/auth.config";
import { API_AUTH_PREFIX, AUTH_ROUTES, PROTECTED_ROUTES } from "@/routes";

export const { auth } = NextAuth(authConfig);

export default auth(req => {
 const pathname = req.nextUrl.pathname;

 // manage route protection
 const isAuth = req.auth;

 const isAccessingApiAuthRoute = pathname.startsWith(API_AUTH_PREFIX);
 const isAccessingAuthRoute = AUTH_ROUTES.some(route => pathname.startsWith(route));
 const isAccessingProtectedRoute = PROTECTED_ROUTES.some(route => pathname.startsWith(route));

 if (isAccessingApiAuthRoute) {
  return NextResponse.next();
 }

 if (isAccessingAuthRoute) {
  if (isAuth) {
   return NextResponse.redirect(new URL("/", req.url));
  }

  return NextResponse.next();
 }

 if (!isAuth && isAccessingProtectedRoute) {
  return NextResponse.redirect(new URL("/login", req.url));
 }
});

export const config = {
 matcher: ["/((?!.+\\.[\\w]+$|_next).*)", "/", "/(api|trpc)(.*)"],
};

This setup configures the database connection, authentication system, API routes, and middleware for your NextJS application.

Implementing Authentication Pages

1. Create the Login Page
Inside the app folder, create a login folder. Inside the login folder, create a page.tsx file with the following content:

// @/app/login/page.tsx

import { signIn } from "@/auth";

const LoginPage = () => {
 return (
   async () => {
       "use server";
       await signIn("google");
     }}
   >
     
   
   );
};

export default LoginPage;

2. Create the Home Page
Inside the app folder, create a page.tsx file with the following content:

// @/app/page.tsx

import { auth, signOut } from "@/auth";
import { notFound } from "next/navigation";

const HomePage = async () => {
 const session = await auth();
 if (!session) return notFound();
 return (
   
     Hello {session.user.name}

     async () => {
         "use server";
         await signOut();
       }}
     >
       
     
   
 );
};
export default HomePage;

3. Run the Development Server
Run the following command in your terminal:

npm run dev

If everything is set up correctly, you will be asked to log in with your Google account. Once logged in, you should be able to see the home page with a greeting and an option to log out.

Conclusion

Implementing Google authentication in a Next.js 14 application using NextAuth.js 5 (beta), Prisma ORM, and MongoDB can be a streamlined and efficient process. By following the steps outlined in this article, you can set up a robust authentication system that leverages Google’s OAuth 2.0 for user authentication, Prisma for database management, and MongoDB as the database.

Here’s a brief recap of what we covered:

Project Setup: Initializing a Next.js project and installing necessary dependencies.
Google Auth Credentials: Configuring Google OAuth 2.0 credentials.
Database Setup: Setting up a MongoDB database and configuring Prisma ORM.
Prisma Configuration: Initializing Prisma and defining schema models for User and Account.
Authentication Configuration: Setting up NextAuth.js configuration with Prisma adapter and custom callbacks.
API Routes and Middleware: Defining API routes for authentication and implementing middleware for route protection.
Authentication Pages: Creating login and home pages with server actions for sign-in and sign-out.

With this setup, you now have a fully functional authentication system integrated into your Next.js application. This foundation can be further extended to include more features such as authorization, role-based access control, and additional OAuth providers.

Feel free to customize and expand upon this setup to fit the specific needs of your application. For a complete reference and code implementation, you can visit the GitHub Repository.

Happy coding!

GitHub Repository

https://github.com/SSazzadur/nextjs-google-auth

Step-by-Step Guide to Building a Rating System in React

Sazzadur Rahman — Wed, 12 Jun 2024 16:42:02 GMT

Introduction

User feedback is essential for improving products and services. A rating system is a simple yet powerful way to gather this feedback. In this article, we’ll walk you through creating a rating system with React. We’ll cover setting up the project, building the rating component, and adding interactivity and styling. By the end, you’ll have a fully functional and customizable rating system ready to enhance your web application. This guide is perfect for developers with basic React knowledge. Let’s dive in!

Setting Up the Project

First, we’ll create a new React project using Vite and set up Tailwind CSS for styling. Follow these steps:

1. Create React Project:

pnpm create vite@latest react-rating-system

2. Navigate to the project directory and install dependencies:

cd react-rating-system
pnpm install

3. Install Tailwind CSS:

pnpm add -D tailwindcss postcss autoprefixer
pnpm dlx tailwindcss init -p

4. Configure Tailwind CSS:

Update tailwind.config.js:

export default {
  // replace this
  content: ["./index.html", "./src/**/*.{js,ts,jsx,tsx}"],

  // your other configs
  theme: {
    extend: {},
  },
  plugins: [],
}

5. Add Tailwind CSS Directives:

Add these lines to the top of your index.css file:

@tailwind base;
@tailwind components;
@tailwind utilities;

6. Install React Icons:

pnpm add react-icons

7. Run the Project:

pnpm dev

Now, your React project is set up with Tailwind CSS for styling and React Icons for easy icon integration. You’re ready to start building the rating system!

Initial Setup and Testing

To ensure everything is set up correctly, we’ll start by adding some initial code to display star icons in your App.tsx file. Follow these steps:

1. Update App.tsx:

Replace the contents of your App.tsx file with the following code:

import { FaRegStar, FaStar } from "react-icons/fa";

import "./App.css";

function App() {
  return (
    -4">
      
      
    
  );
}

export default App;

2. Check the Browser:

Open your browser and navigate to the local server (usually http://localhost:5173). You should see two stars: one filled and one unfilled.

This confirms that your project setup with Tailwind CSS and React Icons is working correctly. Now you’re ready to build out the full rating system!

Adding Rating State and Dynamic Rendering

To implement dynamic rendering based on the selected rating, follow these steps:

1. Define Total Ratings:

Set the total number of stars you want to display:

const TOTAL_RATINGS = 5;

2. Import useState:

Import the useState hook from React:

import React, { useState } from "react";

3. Add Rating State:

Define a state variable to store the current rating:

const [rating, setRating] = useState(0);

4. Replace Icon Rendering:

Update the JSX code to dynamically render filled and unfilled stars based on the rating state:

{Array.from({ length: rating || 0 }, (_, idx) => (
  "h-8 w-auto text-white cursor-pointer" />
))}

{Array.from({ length: TOTAL_RATINGS — (rating || 0) }, (_, idx) => (
  "h-8 w-auto text-white cursor-pointer" />
))}

Now, when you run the project and view it in your browser, you should see TOTAL_RATINGS (in my case 5) unfilled stars.

Adding Rating Functionality

To add functionality to increase and decrease the rating when a star is clicked, follow these steps:

1. Add Handle Rating Function:

Define a function that handles the rating change based on the type of action (increase or decrease) and the index of the star clicked:

function handleRating(type: string, idx: number) {
  let count = 0;

  if (type === "increase") {
    count = rating + idx + 1;
  } else if (type === "decrease") {
    count = idx + 1;
  }

  setRating(count);
 }

2. Update Star Rendering:

Update the JSX code to call the handleRating function when a star is clicked, passing the appropriate type and index:

{Array.from({ length: rating || 0 }, (_, idx) => (
  () => handleRating("decrease", idx)}
    className="h-8 w-auto text-white cursor-pointer"
  />
))}

{Array.from({ length: TOTAL_RATINGS — (rating || 0) }, (_, idx) => (
  () => handleRating("increase", idx)}
    className="h-8 w-auto text-white cursor-pointer"
  />
))}

Now, when you click on a star, the rating should increase or decrease accordingly. This completes the basic functionality of your rating system.

Code

Final App.tsx

Your final App.tsx file should look like this:

import React, { useState } from "react";
import { FaRegStar, FaStar } from "react-icons/fa";
import "./App.css";

const TOTAL_RATINGS = 5;

function App() {
  const [rating, setRating] = useState(0);

function handleRating(type: string, idx: number) {
  let count = 0;

  if (type === "increase") {
    count = rating + idx + 1;
  } else if (type === "decrease") {
    count = idx + 1;
  }

  setRating(count);
}

return (
  "flex items-center gap-x-4">
    {Array.from({ length: rating || 0 }, (_, idx) => (
      () => handleRating("decrease", idx)}
        className="h-8 w-auto text-white cursor-pointer"
      />
    ))}

    {Array.from({ length: TOTAL_RATINGS - (rating || 0) }, (_, idx) => (
      () => handleRating("increase", idx)}
        className="h-8 w-auto text-white cursor-pointer"
      />
    ))}
  
 );
}

export default App;

This code defines a React component App that renders a rating system with filled and unfilled stars. Clicking on a star increases or decreases the rating accordingly.

Conclusion

In this tutorial, we’ve learned how to create a simple yet powerful rating system using React. By utilizing state management with the useState hook, we were able to dynamically render filled and unfilled stars based on the user’s selection.

Through the handleRating function, we implemented the logic to increase or decrease the rating when a star is clicked. This functionality provides a user-friendly way for visitors to rate products, services, or content on your website.

Additionally, by combining Tailwind CSS for styling and React Icons for easily integrating icons, we achieved a visually appealing and functional rating system.

Feel free to further customize this rating system by adding features such as half-star ratings, average rating calculation, or saving ratings to a backend server. The possibilities are endless, and we hope this tutorial serves as a solid foundation for your future projects.

Thank you for following along, and happy coding!

Sazzadur's blog

Soft Delete Is Easy. Data Consistency Is Not.

The Illusion of Safety

Where Things Start to Break

The Dormitory Problem

Why Soft Delete Isn’t the Real Problem

Better Ways to Model This

1. Never Truly Remove Structural Entities

2. Version Your Structure

3. Snapshot What Matters

The Rule I Follow Now

Closing Thoughts

The Right Way to Upload Files to S3 from a Serverless Backend

Introduction

Traditional Approach: Uploading Through Backend

Alternative: External Upload Service

The Right Way: Using Presigned URLs

Backend: Generate Presigned URL

Frontend: Upload File

Benefits of Presigned URLs

Conclusion

How to Build a Serverless API That Actually Works (with SST, Prisma, TiDB, Bun & AWS Lambda)

Why This Particular Flavor of Madness?

Prerequisites (AKA “Stuff You Need Before You Can Break Things”)

Important: AWS CLI Setup (Or How to Convince AWS You’re Not a Robot)

Let’s Get This Party Started

Step 1: Install Bun (The Rabbit That Will Change Your Life)

Step 2: Create Your Project (Like Bob Ross Creating Happy Little Servers)

Step 3: Install Dependencies (AKA Dependency Hell, But Make It Fashion)

Database Setup (Or: How to Tame the Data Beast)

Step 4: Initialize Prisma (Your New Database Overlord)

Step 5: Configure Prisma Schema (The Blueprint of Your Dreams)

Step 6: Set Up TiDB Connection (Database Speed Dating)

Step 7: Run Database Migration (The Moment of Truth)

Application Code (The Fun Part!)

Step 8: Create Prisma Client Singleton (One Client to Rule Them All)

Step 9: Build the Express Application (Your API’s Main Character)

Step 10: Create Lambda Handler (The Serverless Magic Portal)

Infrastructure with SST (Infrastructure as Code, But Fun)

Step 11: Initialize SST (Your Infrastructure Butler)

Step 12: Configure SST (Teaching AWS How to Behave)

Step 13: Update Package.json (The Command Center)

Development and Deployment (The Grand Finale)

Step 14: Local Development (Where Dreams Come True)

Step 15: Test Your API (Moment of Truth)

Step 16: Production Deployment (The Big Leagues)

Best Practices and Pro Tips (Wisdom from the Trenches)

Database Connection Management

Error Handling (Because Murphy’s Law is Real)

Monitoring and Logging (Your Crystal Ball)

Conclusion (We Made It! 🎉)

Next Steps (Because We’re Never Really Done)

useForm Like a Pro: Mistakes You Might Be Making (And How to Fix Them)

The Problem (Or: Why Forms Make Developers Cry)

The Solution: useForm Hook (A.K.A. Form Therapy)

Key Features (Or: Why You’ll Delete Your Old Form Code)

Using the Register API (Because Less Code = More Happiness)

Validation Rules (For All Those Users Who Type “password123”)

Conditional Validation (For When Life Gets Complicated)

Complete Sign-Up Form Example (That Actually Works!)

"text-2xl font-bold text-center mb-6">Join Our Cult (Er, Platform)

Best Practices (From Developers Who’ve Made All the Mistakes)

Full Implementation Reference

The useForm Hook

Validation Library

FormField Component

Conclusion

How to Create a Custom React Hook for LocalStorage Using React Context

Setting Up the Project

Open your terminal and execute the following command to create a new Vite project:

Navigate to the project directory and install the dependencies:

Setting Up the React Context

First, define the type for the context:

Create the context file:

Next, create the provider component:

Creating the Custom Hook: useStore

Putting It All Together

In the main.tsx file:

In the component where you want to use the hook:

Stored Value: {value}

In the `main.tsx` file: