DEV Community: Rasel Mahmud

A Custom Reusable Delete Confirmation Modal Hook in ReactJS.

Rasel Mahmud — Thu, 09 Oct 2025 07:14:28 +0000

If you've worked with React for a while, you know the common pattern: every time you need a delete confirmation, you reach for a library like react-confirm or sweetalert2. And yes, these tools are stable and do the job.

But here's the catch: they come with extra baggage and limitations.

They add dependencies to your bundle.
They are often less flexible to customize.
They may not fit neatly into your design system.

Been there, done that. I recently wrote a reusable delete confirmation hook (useDeleteConfirmation) that I now use in every project I work on.
It keeps things simple, clean, and fully under your control—without overengineering a simple problem.

It's under 70 lines of code.
Provides a consistent UX across the app.
Works with our UI components out of the box.

This hook allows you to easily request a confirmation before executing irreversible operations.

The Problem With Manual Implementation

Look at how we typically handle delete confirmations manually. We need to track two states (modal open/close and item to delete), which becomes verbose and repetitive across multiple components:

import React, { useState } from 'react';

function UserList() {
  const [isOpenDeleteModal, seOpenDeleteModal] = useState(false);
  const [userToDelete, setUserToDelete] = useState(null);

  function handleDeleteUser(user) {
    setUserToDelete(user);
    seOpenDeleteModal(true);
  }

  function handleConfirm() {
    if (userToDelete) {
      console.log('Deleting user:', userToDelete);
      seOpenDeleteModal(false);
      setUserToDelete(null);
    }
  }

  function handleCancel() {
    seOpenDeleteModal(false);
    setUserToDelete(null);
  }

  return (
    <>
      {isOpenDeleteModal && (
        <div className="modal-overlay">
          <div className="modal">
            <h1>Are you sure?</h1>
            <p>Are you sure you want to delete this user? This action cannot be undone</p>
            <div>
              <button onClick={handleConfirm}>Yes</button>
              <button onClick={handleCancel}>No</button>
            </div>
          </div>
        </div>
      )}

      <div>
        {users.map(user => (
          <div key={user.id}>
            <span>{user.name}</span>
            <button onClick={() => handleDeleteUser(user)}>
              Delete
            </button>
          </div>
        ))}
      </div>
    </>
  );
}

The Problem With Manual Implementation

At first glance, handling delete confirmations manually seems straightforward. But in practice, it introduces several issues:

State Explosion : Every component needs to manage modal visibility and track which item is being deleted.
Code Duplication : Open/close logic and modal markup get repeated across multiple components.
Tight Coupling : Components handle both business logic (e.g., deleting a user) and UI logic (modal state), making them harder to test and maintain.
Scalability Problems : Multiple delete scenarios (users, posts, comments, etc.) lead to repetitive modal logic everywhere.
Inconsistent UX : Manually built modals often vary in wording, styling, or accessibility, breaking design consistency.
Maintenance Overhead : Small changes (button styles, loading states, spacing) must be updated in many places.

The Solution: `useDeleteConfirmation` Hook

Instead of scattering modal state logic across every component, we can centralize everything in a single, reusable hook.
With useDeleteConfirmation, requesting a confirmation becomes as simple as calling one method—no extra state, no repetitive boilerplate.

Here’s the core API in action:

deleteConfirmation.requestConfirmation({
  title: "\"Are you sure?\","
  message: (
    <>This action is permanent and cannot be undone.</>
  ),
  actions: (onConfirm, onCancel) => (
    <>
      <button onClick={onConfirm}>Yes</button>
      <button onClick={onCancel}>No</button>
    </>
  ),
  onConfirm: (close) => {
    // Your delete logic (e.g., API call)
    close(); // Always call close() to dismiss the modal
  },
});

Single Entry Point – You don’t need to manage isOpen or track the item being deleted. Just call requestConfirmation().
Fully Customizable – You decide how the modal looks (buttons, layout, text). The hook only takes care of the lifecycle.
Clean API – All options live inside a single configuration object, so it’s easy to read and extend later.
Built-in Lifecycle Control – The close() callback ensures proper cleanup, even for async operations.

This pattern keeps your components lightweight and focused on business logic, while the hook handles the messy details of modal management.

Here is full example usage:

function UserList() {
  const deleteConfirmation = useDeleteConfirmation();

  function handleDelete(user) {
    deleteConfirmation.requestConfirmation({
      title: "<h1 className=\"font-semibold text-3xl\">Are you sure?</h1>,"
      message: (
        <p className="mt-3">
          Are you sure you want to delete {user.name}?
          This action cannot be undone.
        </p>
      ),
      actions: (onConfirm, onCancel) => (
        <div className="flex items-center gap-x-2 justify-end mt-4">
          <Button theme="primary" onClick={onConfirm}>Yes</Button>
          <Button theme="danger" onClick={onCancel}>No</Button>
        </div>
      ),
      onConfirm: (close) => {
        // Your API call to delete
        console.log('Deleting user:', user);
        close(); // Close the confirmation dialog
      }
    });
  }

  return (
    <div>
      {users.map(user => (
        <div key={user.id}>
          <span>{user.name}</span>
          <Button
            theme="danger"
            onClick={() => handleDelete(user)}
          >
            Delete
          </Button>
        </div>
      ))}
    </div>
  );
}

Design Patterns & Architecture

This hook leverages several key design patterns that provide core React principles for a clean, maintainable solution:

1. Hook Pattern (Custom Hook)

Encapsulates modal logic and state management
Provides a clean, reusable interface
Follows React's compositional patterns

2. Portal Pattern

Uses React Portals to render modals outside the component tree
Prevents CSS inheritance issues and z-index conflicts
Enables proper modal overlay behavior

3. Render Props Pattern

The actions function uses render props to provide maximum flexibility
Allows complete customization of button layout and styling
Maintains separation of concerns between logic and presentation

4. Callback Pattern

Uses callback functions (onConfirm, onCancel) for event handling
Provides controlled cleanup through the close callback
Enables async operations with proper modal lifecycle management

5. Configuration Object Pattern

Single configuration object for all modal options
Makes the API easy to understand and extend
Supports optional parameters with sensible defaults

Implementation

The useDeleteConfirmation hook is intentionally lightweight, yet it follows a few important design principles. Let’s break down how it works step by step:

1. Root Element Management

let deleteConfirmationRoot = document.getElementById('delete-confirmation-root');
if (!deleteConfirmationRoot) {
  deleteConfirmationRoot = document.createElement('div');
  deleteConfirmationRoot.id = 'delete-confirmation-root';
  document.body.appendChild(deleteConfirmationRoot);
}

A dedicated DOM node (#delete-confirmation-root) is created only when the modal is requested.
This keeps the DOM clean and avoids unnecessary hidden modals hanging around.
If the root already exists, it reuses it.

2. Opening and Rendering the Modal

createRoot(deleteConfirmationRoot).render(
  ReactDOM.createPortal(
    <div className="overlay...">
      <div className="modal...">
        ...
      </div>
    </div>,
    deleteConfirmationRoot
  )
);

The hook uses React Portals to render the modal outside of the normal component tree.
This ensures it always appears above everything else and avoids CSS/z-index issues.
The overlay (dark background) and modal are styled with sensible defaults, but you can override them via options.rootClassName and options.modalClassName.

3. Closing the Modal

function handleClose() {
  const root = document.getElementById('delete-confirmation-root');
  if (root) document.body.removeChild(root);
}

When the user confirms or cancels, the modal root is completely removed from the DOM.
This ensures proper cleanup and prevents memory leaks.

4. Confirm and Cancel Handlers

function handleConfirm(onConfirm) {
  onConfirm(handleClose);
}

function handleCancel(onCancel) {
  onCancel?.();
  handleClose();
}

onConfirm gets a close callback injected. This allows async logic (like API calls) before closing.
onCancel is optional, but if provided, it’s called before cleanup.

5. Configuration Object

deleteConfirmation.requestConfirmation({
  title,
  message,
  actions,
  onConfirm,
  onCancel,
});

The hook expects a configuration object that describes what to show and how to behave.
title, message, and actions define the UI.
onConfirm and onCancel define the behavior.
If the config is invalid, the hook throws an error immediately to avoid silent failures.

Why This Design Works

Stateless by design → no extra useState clutter inside your components.
Self-cleaning → creates DOM nodes only when needed, then removes them.
Composable → you fully control how the modal looks and behaves.

In short: this implementation gives you all the power of a modal without the overhead of managing modal state in every component.

Here's the complete implementation of the useDeleteConfirmation hook:

import ReactDOM from 'react-dom';
import { createRoot } from 'react-dom/client';

function useDeleteConfirmation(options = {}) {
  function handleClose() {
    const deleteConfirmationRoot = document.getElementById('delete-confirmation-root');
    if (deleteConfirmationRoot) {
      document.body.removeChild(deleteConfirmationRoot);
    }
  }

  function handleConfirm(onConfirm) {
    onConfirm(handleClose);
  }

  function handleCancel(onCancel) {
    onCancel?.();
    handleClose();
  }

  function requestConfirmation(item) {
    if (!item || typeof item.onConfirm !== 'function' || typeof item.actions !== 'function') {
      throw new Error('Invalid configuration for useDeleteConfirmation hook.');
    }

    let deleteConfirmationRoot = document.getElementById('delete-confirmation-root');
    if (!deleteConfirmationRoot) {
      deleteConfirmationRoot = document.createElement('div');
      deleteConfirmationRoot.id = 'delete-confirmation-root';
      document.body.appendChild(deleteConfirmationRoot);
    }

    createRoot(deleteConfirmationRoot).render(
      ReactDOM.createPortal(
        <div className={`fixed inset-0 bg-black/50 flex items-center justify-center z-50 ${options.rootClassName || ''}`}>
          <div className={`bg-white p-6 rounded-md shadow-md max-w-md w-full ${options.modalClassName || ''}`}>
            <div>{item.title}</div>
            <div className="mt-2">{item.message}</div>
            {item.actions(
              () => handleConfirm(item.onConfirm),
              () => handleCancel(item.onCancel)
            )}
          </div>
        </div>,
        deleteConfirmationRoot
      )
    );
  }

  return { requestConfirmation };
}

export default useDeleteConfirmation;

Best Practices

Always warn the user clearly before destructive actions.
Use destructive button styling (e.g., red for "Delete") to reduce mistakes.
Always call the provided close() callback inside onConfirm to properly clean up the modal.
Keep confirmation text short, clear, and direct.
Consider adding loading states during async operations within onConfirm.
Use consistent styling across your application by leveraging the rootClassName and modalClassName options.

Technical Benefits

Performance

Lazy Loading: Modal DOM elements are only created when needed
Efficient Cleanup: Automatic cleanup prevents memory leaks
Minimal Bundle Size: Under 70 lines with no external dependencies

Maintainability

Single Responsibility: Each function has a clear, focused purpose
Extensible Design: Easy to add new features without breaking existing code
Type Safety: Full TypeScript support with proper type definitions

User Experience

Consistent Behavior: Same interaction patterns across your application
Accessible: Works with keyboard navigation and screen readers
Flexible Styling: Integrates seamlessly with your design system

Next.js (SSR) Usage

This hook directly accesses the browser DOM, so it must only run on the client side in Next.js applications.

How to Use in Next.js

Mark your component as client-only by adding at the very top:

"use client"

Alternative SSR-Safe Pattern

For better SSR compatibility, use this pattern:

import { useEffect, useState } from 'react';

function MyComponent() {
  const [isClient, setIsClient] = useState(false);
  const deleteConfirmation = useDeleteConfirmation();

  useEffect(() => {
    setIsClient(true);
  }, []);

  if (!isClient) return null; // or loading state

  // Rest of your component
}

Conclusion

With useDeleteConfirmation, you get the flexibility of a custom modal without the overhead of an external library. It's a simple, reusable solution that keeps your codebase clean and consistent while providing a better user experience for destructive operations.

The hook is lightweight, customizable, and follows React best practices, making it an ideal solution for projects of any size. Give it a try in your next project and say goodbye to bulky confirmation libraries!

Yarn, Npm থেকে PNPM: আমার ডেভেলপমেন্ট লাইফের গেম চেঞ্জার!

Rasel Mahmud — Wed, 14 May 2025 05:44:16 +0000

🚀 Yarn থেকে PNPM: ডেভেলপমেন্ট লাইফের গেম চেঞ্জার!

হ্যালো ডেভ 👋,

আজ আপনাদের সাথে শেয়ার করতে চাই আমার React Native & Next.js প্রজেক্টে npm থেকে pnpm-এ মাইগ্রেশনের অভিজ্ঞতা। সম্প্রতি প্রজেক্টের node_modules এর সাইজ একটু বেড়ে গিয়ে ছিল - প্রায় ৬ গিগাবাইট!

একটি মিডিয়াম সাইজের অ্যাপের জন্য এত স্পেস?

কোনো একসময় পড়েছিলাম pnpm ক্যাশিং এবং সিমলিংক ব্যবহার করে, কিন্তু পুরোপুরি pnpm-এ মাইগ্রেট করতে সময় হয়ে উঠছিল না। তবে পরে pnpm-এর হার্ড লিংকিং এবং সিমলিংক (Symbolic Link) ব্যবস্থাপনা নিয়ে বিস্তারিত রিসার্চ করলাম। এটি গ্লোবালি প্যাকেজ স্টোর করে এবং প্রজেক্টে সিমলিংকের মাধ্যমে ব্যবহার করে, যা স্পেস এবং ইনস্টলেশনের সময় উভয়ই কমিয়ে আনে।

🔥 মাইগ্রেশন:

প্রথমে সব node_modules ডিলেট (rm -rf node_modules)
PNPM ইনস্টল (npm install -g pnpm)
নতুন করে ডিপেন্ডেন্সি ইনস্টল (pnpm install)

🚀 PNPM এর মূল ধারণা:

গ্লোবাল স্টোর: সমস্ত প্যাকেজের একটি কপি গ্লোবাল স্টোরে থাকে।
হার্ড লিংক: প্রজেক্টে প্যাকেজের আলাদা কপি না করে গ্লোবাল স্টোর থেকে হার্ড লিংক তৈরি করে।
সিমলিংক: node_modules ফোল্ডারে প্যাকেজ রিজলিউশন স্ট্রাকচার তৈরি করে, যা প্রকৃত ফাইলগুলোকে পয়েন্ট করে।

✅ সুবিধা:

দ্রুত ইনস্টলেশন
স্মার্ট ক্যাশিং সিস্টেম
কম স্টোরেজ ব্যবহার
সহজ সংস্করণ নিয়ন্ত্রণ
গ্লোবাল স্টোর: সব প্রজেক্টে একই প্যাকেজের শুধু একটি কপি রাখে
হার্ড লিংক: প্রতিটি প্রজেক্টে আলাদা কপি না করে লিংক তৈরি করে
সিমলিংক: node_modules ফোল্ডারে একটি ভার্চুয়াল স্ট্রাকচার তৈরি করে, প্রতিটি প্যাকেজ .pnpm ফোল্ডারে অবস্থিত হার্ড-লিংকড ফাইলকে পয়েন্ট করে
সিকিউরিটি: ফ্যান্টম ডিপেন্ডেন্সি প্রবলেম ফিক্স করে

👻 ফ্যান্টম ডিপেন্ডেন্সি (Phantom Dependency)

Phantom Dependency মানে এমন একটি প্যাকেজ যা আপনার প্রজেক্টের package.json-এ নেই, কিন্তু অন্য কোনো প্যাকেজের ডিপেন্ডেন্সি হিসেবে node_modules-এ চলে এসেছে।

ফলে আপনি সেটা সরাসরি import বা use করতে পারেন, যদিও আপনি নিজে তা ইনস্টল করেননি।

🧨 সমস্যা কী?

যদি ভবিষ্যতে সেই ডিপেন্ডেন্সি প্যাকেজটি সরিয়ে দেওয়া হয় বা আপডেট করা হয়, যেটা ওই ফ্যান্টম প্যাকেজের ওপর নির্ভর করছিল, তাহলে আপনার অ্যাপ ব্রেক করে যেতে পারে। কারণ আপনি তো সরাসরি ইনস্টল করেননি, কিন্তু কোডে ব্যবহার করেছেন।

✅ pnpm এই প্রবলেম ফিক্স করে — আপনি শুধু যা ইনস্টল করেছেন, সেটাই ব্যবহার করতে পারবেন।

এখানে শুধু ইনস্টল করা প্যাকেজ ই আছে এবং সব গুলো প্যাকেজ সিমলিংক করা আছে .pnpm ডিরেক্টরি তে।

🚀 কিভাবে শুরু করবেন?

npm install -g pnpm
pnpm install

🗂️ Stored Package Directory:

pnpm store path
# Example: /home/rasel/.local/share/pnpm/store/v10

🔧 PNPM কমান্ড সমূহ:

pnpm init                 # নতুন প্রজেক্ট শুরু
pnpm add react            # রিয়্যাক্ট ইনস্টল
pnpm add -D typescript    # টাইপস্ক্রিপ্ট devDependency হিসেবে
pnpm run dev              # স্ক্রিপ্ট চালানো

আরও কমান্ড 👇

pnpm install --frozen-lockfile   # lockfile না বদলে আগের মতোই ইনস্টল করে

pnpm add lodash                  # প্রডাকশন ডিপেন্ডেন্সি হিসেবে lodash যোগ
pnpm add -D eslint               # ডেভেলপমেন্ট ডিপেন্ডেন্সি হিসেবে eslint যোগ

pnpm remove lodash               # lodash রিমুভ করে

pnpm update                      # সব প্যাকেজ আপডেট করে
pnpm update react                # শুধু react আপডেট করে

pnpm list                        # সব ইন্সটলড প্যাকেজ দেখায়
pnpm list -r                     # recursive ভাবে দেখায়

pnpm why <pkg>                   # কোন প্যাকেজ কার মাধ্যমে এসেছে, তা ট্রেস করে

pnpm outdated                    # পুরানো প্যাকেজ লিস্ট করে

pnpm run build                   # build স্ক্রিপ্ট চালায়
pnpm run lint                    # lint স্ক্রিপ্ট চালায়

pnpm exec eslint src/           # সরাসরি eslint চালায়

pnpm env use --global 18        # নির্দিষ্ট Node.js ভার্সন global এ সেট করে

pnpm store prune                # অপ্রয়োজনীয় ক্যাশ ক্লিন করে

pnpm dlx create-next-app        # একবারের জন্য কমান্ড চালিয়ে প্যাকেজ রান করে

কেউ কি PNPM ইউজ করছেন? নাকি এখনও Yarn/npm এ আটকে আছেন?

WebDev #NodeJS #PNPM #NextJS #BanglaDev #ProgrammingTips

RS Authenticator – Your Ultimate 2FA Security Solution!

Rasel Mahmud — Wed, 26 Feb 2025 14:54:20 +0000

🚀 RS Authenticator – Open-Source 2FA Built with Kotlin & Jetpack!

🔐 Looking for a secure, native Android 2FA solution? Introducing RS Authenticator, a lightweight Two-Factor Authentication (2FA) app built with Kotlin & Jetpack for seamless performance and security.

🔹 Your Security, Your Control

🔸 Worried about password leaks? RS Authenticator adds an extra layer of protection to your digital security!

🔸 Compatible with any service, not just our web dashboard—use it with Google, Facebook, GitHub, AWS, and more.

🔸 Generates TOTP (Time-based One-Time Password) codes to safeguard your accounts.

🔹 Works Completely Offline

RS Authenticator does not require an internet connection, ensuring full offline functionality while keeping your data secure.

✅ 100% Data Encryption & Security

✅ Easily set up TOTP using QR code scanning

✅ No internet permissions required

✅ Offline backup feature (Coming Soon!)

✅ No tracking or data sharing – Completely Open Source!

📌 Upcoming Feature: HOTP (HMAC-based One-Time Password) Support

📲 Try it out and contribute to open-source Android security!

📥 Live Demo & Download:

📊 GitHub Repository:

How to Set Up PostgreSQL Logical Replication: Use Cases and Step-by-Step Guide.

Rasel Mahmud — Wed, 18 Dec 2024 17:29:02 +0000

PostgreSQL replication is a powerful mechanism that ensures data consistency and availability across multiple databases. It enables data from one database (the primary) to be synchronized with one or more other databases (the replicas). This process is crucial for applications that require high availability, scalability, or distributed data sharing.

This guide explores the types of PostgreSQL replication, their benefits, and real-world use cases, followed by a step-by-step setup process for logical replication.

What is PostgreSQL Replication?

PostgreSQL replication is a process where data from one database (primary) is copied and kept in sync with one or more other databases (replicas).

There are two main types of replication in PostgreSQL:

Physical Replication: Entire data is replicated at the block level. It’s commonly used for high availability (e.g., streaming replication).
Logical Replication: Replicates changes at the logical level (row-based). It’s more flexible and allows selective replication of data, meaning you can choose specific tables or parts of a database to replicate.

Benefits of Logical Replication

Selective Replication: Replicate only specific tables or rows, improving performance and storage.
Cross-Version Replication: Allows replication between different PostgreSQL versions.
Custom Transformations: Data can be modified during replication, making it customizable.
Replication to Other Systems: Replicate data to other databases or applications, enabling cross-system data sharing.

Real-World Use Case 1: Toll Collection Management Software

Our toll management software, Scott, is used at the Kalna Bridge toll plaza, where we operate 8 lanes. Each lane has its own local database, and every booth operates independently. Toll transaction data from each booth is pushed to the central server in real-time using a message queue system.

Each booth maintains its own records, including:

Users: User management.
Lane Details: Information specific to each lane.
Shift Management: Tracking which operator is assigned to which lane during specific shifts.
Calendar System: Managing operator assignments and schedules.
ETC Mapping: Indicating whether a booth or lane is ETC (Electronic Toll Collection) enabled.

These tables are shared across all lanes, and the admin can update entries from the central server. The challenge arises when some entries are modified, and it’s necessary to keep the data in sync between all 8 booth databases and the central server database.

Why Not Use a Central Database for All Booths?

Each booth needs to operate independently in case the central server goes down or the connection becomes unstable due to natural disasters or other issues. If the central server or connection fails, the booths would become unusable, but the booths must continue to operate to pass vehicles.

What is Logical Replication in This Use Case?

In this context, PostgreSQL logical replication can be used to replicate relevant tables from the central database to each booth’s database. By doing so, updates made in the central database will automatically synchronize to the corresponding tables in all booth databases. This allows the booths to function autonomously while ensuring the data remains consistent across all systems.

Real-World Use Case 2: E-commerce Platforms

Use Case: An e-commerce platform uses logical replication to keep the data in sync between the main database (handling customer transactions) and a separate reporting database (used for analytics). This ensures that the system can generate real-time reports and insights without affecting the performance of the website or app.

Why Use Logical Replication:

Better Performance: Offloading reporting tasks to a replica keeps the primary database fast for customer-facing transactions.
Real-time Insights: Business teams receive up-to-date data for decision-making, such as adjusting inventory or running promotions.
Scalability: Easily add more reporting systems or tools without affecting the main database.
Data Accuracy: Replication ensures that all systems have consistent and accurate data.
High Availability: If the main database goes down, the replica can still provide read-only data, minimizing downtime.
Customizable Data Sync: Replicate only the data that’s needed, making reporting more efficient.

Setting Up PostgreSQL Logical Replication

In this guide, we’ll walk through the steps to set up PostgreSQL logical replication between two servers: a primary (publisher) and a replica (subscriber). This setup allows the replica server to receive real-time data changes from the primary server.

1. Install PostgreSQL

First, install PostgreSQL on both the primary and replica servers. On Ubuntu, you can install it by running the following commands:

sudo apt update
sudo apt install postgresql postgresql-contrib

Repeat this process on both the primary and replica machines.

2. Configure the Primary Database (Publisher)

Edit `postgresql.conf`

On the primary server, you need to enable logical replication. Open the postgresql.conf file and update the following settings:

wal_level = logical
max_replication_slots = 10
max_wal_senders = 10

These settings ensure that PostgreSQL can send changes to the replica server.

Edit `pg_hba.conf`

Next, configure pg_hba.conf to allow the replica server to connect to the primary for replication. Add the following line:

host    replication     postgres     <replica_db_ip>/32        md5

Replace <replica_ip> with the actual IP address of the replica server.

Restart PostgreSQL

After making the changes, restart PostgreSQL on the primary server:

sudo systemctl restart postgresql

3. Configure the Replica Database (Subscriber)

Edit `postgresql.conf`

On the replica server, you need to enable hot standby mode. Open the postgresql.conf file and add:

hot_standby = on

This setting allows the replica server to accept read queries while receiving replication data.

Edit `pg_hba.conf`

In the pg_hba.conf file on the replica, allow the primary server to connect for replication:

host    replication     postgres     <primary_ip>/32       md5

Replace <primary_ip> with the actual IP address of the primary server.

Restart PostgreSQL

After updating the configuration, restart PostgreSQL on the replica:

sudo systemctl restart postgresql

4. Set Up Logical Replication with Docker (Optional)

If you are using Docker, you can configure both the primary and replica databases using docker-compose.

Here's a simple docker-compose.yml configuration:

services:
  central_primary_db:
    image: postgres:16-bullseye
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: 12345
      POSTGRES_DB: primary_db
    ports:
      - "5442:5432"
    volumes:
      - ./central_primary_db_data:/var/lib/postgresql/data
    restart: always
    command: [
      "postgres",
      "-c", "wal_level=logical",
      "-c", "max_replication_slots=10",
      "-c", "max_wal_senders=10"
    ]

  kamalapur_station_db:
    image: postgres:16-bullseye
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: 12345
      POSTGRES_DB: kamalapur_station_db
    ports:
      - "5443:5432"
    volumes:
      - ./kamalapur_station_db_data:/var/lib/postgresql/data
    restart: always

    airport_station_db:
     image: postgres:16-bullseye
     environment:
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: 12345
        POSTGRES_DB: airport_station_db
     ports:
        - "5444:5432"
     volumes:
        - ./airport_station_db_data:/var/lib/postgresql/data
     restart: always

5. Create a Publication on the Primary Database

On the primary database, you need to create a publication to define which tables will be replicated. For example, if you want to replicate the users table, use this SQL command:

-- Connect to the primary database
\c central_primary_db

-- Create a publication for the `users` table or multiple table vai comma sepa.
CREATE PUBLICATION central_railway_system_pub
   FOR TABLE
      users,                      
      train_schedules,            
      tickets,                    
      payments,                   
      seat_reservations           
   WITH (publish = 'insert, update, delete');

6. Create a Subscription on the Replica Database

On the replica database, you need to create a subscription that connects to the primary database and starts receiving changes. Use this SQL command:

-- Connect to the replica database
\c replica_db

-- Create a subscription to the primary database
CREATE SUBSCRIPTION central_railway_system_sub
   CONNECTION 'host=<primary_ip> port=5432 dbname=primary_db user=replicator_user password=<secure_password> sslmode=require'
   PUBLICATION central_railway_system_pub
   WITH (
      copy_data = true,   -- Copy existing data to replica db.
      create_slot = true,  
      enabled = true       
    );

Replace <primary_ip> with the IP address of your primary database.

Once the subscription is created, the replica will start receiving real-time updates from the primary.

Summary

PostgreSQL logical replication is an essential tool for modern data-driven applications, offering flexibility, performance, and high availability. By selectively replicating tables and rows, logical replication addresses unique challenges in use cases like toll booth management and e-commerce analytics. This guide has provided a practical walkthrough for setting up logical replication, ensuring reliable and consistent data synchronization across systems.

Acknowledgment: This content from my personal experience and ai.

Protecting API Requests Using Nonce, Redis, and Time-Based Validation

Rasel Mahmud — Wed, 18 Dec 2024 15:42:01 +0000

The Invisible Threat Lurking in Your API

Imagine you're sending money to a friend via a payment app. You tap "Send," and the payment goes through. But suddenly, a hacker intercepts and resends the same request — without your permission. Your money is sent twice. 😱

This isn’t science fiction. It’s called a replay attack, one of the simplest yet most dangerous threats to modern APIs.
But don’t worry — nonces (numbers used once) are here to save the day! They can help make your APIs bulletproof against these attacks. 🛡️

In this blog, you'll learn how to protect your APIs from replay attacks, man-in-the-middle (MITM) attacks, and request tampering using nonces, Redis, and timestamp validation.

By the end of this post, you'll be able to build a fortress around your API that even the sneakiest hackers can’t break into. 🏰

📘 What is a Nonce?

A nonce (number used once) is a randomly generated unique or encrypted value attached to each request. It acts as a one-time identifier that ensures no two requests are identical, even if their contents are the same.

The key attributes of a nonce are:

Unique: Each request has a distinct identifier.
Time-Limited: Nonces are only valid for a certain time window (e.g., 3 days).
Replay-Protected: Once a nonce is used, it cannot be reused.

By combining the power of nonces with Redis for storage and timestamp validation, we can create a system where each API request is thoroughly validated and immune to replay attacks.

📋 How Does This Protection Work?

The process to protect an API request using nonce can be broken down into the following steps:

Generate Nonce (Client-Side)

The client creates a unique, encrypted token containing the following information:

Unique Identifier (UUID) or only Timestamp
Timestamp (to track when the request was created)
1. Send Nonce in the Request

The client sends the nonce in the request header (e.g., X-Request-Token) when calling the API.

Decrypt Token (Server-Side)

The server decrypts the token and extracts the unique identifier and timestamp.

Timestamp Validation

The server checks if the time difference between the current server time and the client's timestamp is within an acceptable window (e.g., less than 3 days). If the request nonce timestamp is too old, it is rejected.

Replay Protection (Using Redis)

The server queries Redis to check if the unique identifier has been used before.

If the nonce exists in Redis, the request is rejected.
If the nonce does not exist, it is stored in Redis with a time-to-live (TTL) of 3 days.
1. Pass Request to the Next Step

If all checks pass, the request is processed. The nonce is stored in Redis to ensure it cannot be used again.

📦 Key Components of the System

To build a complete nonce-based protection system, you need the following components:

1️⃣ Token Encryption

The nonce (unique identifier + timestamp) is encrypted using AES (Advanced Encryption Standard) or any other secure encryption method. This ensures the token cannot be easily manipulated. Only the server knows how to decrypt the token.

2️⃣ Timestamp Validation

When the server receives the request, it extracts the timestamp and checks how much time has passed. If the timestamp is older than the allowed time window (e.g., 3 days), the request is rejected. This prevents attackers from replaying old requests.

3️⃣ Replay Protection (Redis)

Redis is a fast, in-memory data store that can efficiently track used nonces. Every nonce is stored in Redis with a 3-day TTL (time-to-live). If a request with the same nonce is received, the server immediately rejects it. Redis's TTL feature ensures nonces expire automatically after 3 days.

Diagram

💻 Implementation (Let's build it )

Client-Side: Generating and Sending the Nonce

The client generates a unique nonce, encrypts it, and sends it as a header in the HTTP request. This ensures each request is unique and protects against replay attacks.

Client Code

Explanation of Client Code:

Generate Nonce: Combines the current timestamp with some randomness and encrypts it.
Encryption: Uses AES or a similar method to encrypt the nonce, making it tamper-proof.
Attach to Request: Sends the nonce in the X-Request-Token header, which the server will validate

Server-Side: Validating the Nonce

On the server side, the encrypted nonce is decrypted, the timestamp is validated, and Redis ensures the nonce hasn’t been used before.

Server Code

Explanation of Server Code:

Extract and Decrypt: The server retrieves the nonce from the X-Request-Token header and decrypts it.
Timestamp Validation: Validates that the request timestamp is within the allowed time window (e.g., 3 days).
Replay Protection with Redis: The server checks Redis to ensure the nonce hasn’t been used before. If it has, the request is rejected.
Error Handling: If the nonce is invalid or expired, the request is rejected with an error message.

🔥 Benefits of Nonce-Based Protection

Prevents Replay Attacks: Nonces ensure every request is unique and cannot be reused.
Time-Limited Tokens: The token's expiration (default 3 days) limits its usefulness.
Efficient Storage (Redis): Redis’s in-memory data store ensures fast lookup and storage of nonces.
Tamper-Proof Requests: Encrypted tokens ensure attackers cannot modify the request data.
Stateless Validation: The use of Redis eliminates the need to maintain request state on the server.

🕵️‍♂️ Example Scenario

Imagine you have an online payment API that processes orders. Without nonce protection, an attacker could intercept and replay a "Purchase Order" request. This could cause multiple, unauthorized orders to be placed.

With nonce protection, the steps look like this:

The client creates a token with a ** timestamp **.
The server decrypts the token, validates the timestamp, and checks Redis for the nonce.
If everything is valid, the server processes the order.
The nonce is saved in Redis, so it cannot be used again.

Result: If an attacker tries to replay the purchase request, the server will detect that the nonce has already been used and reject it.

Acknowledgment: This post combines insights from AI and personal experience.

Build Own version of Redux toolkit using Observer design pattern.

Rasel Mahmud — Sat, 06 Apr 2024 13:15:42 +0000

Introduction:

A few months ago, I built my own Redux toolkit. Now, I have completed a basic e-commerce project, and in this project, I used my own Redux toolkit.

This project we will build store, createSlice, createAsyncThunk, useDispatch, useSelectorfrom scratch.

Overview

Key Features

Sync/Async actions handled.
Store state management
Dispatch
RTK Query (coming soon).
createSlice.
createAsyncThunk.
useDispatch.
useSelector Hook implementation

Live link:

https://rsl-redux-shop.netlify.app

Source code:

https://github.com/rasel-mahmud-dev/rsl-redux

Project Structure

We have created a monorepo project using Lerna. It consists of two packages: a redux library and a React e-commerce project.

Project Directory:
- .gitignore
- .idea
- README.md
- app.js
- example/
    |-- .eslintrc.cjs
    |-- .gitignore
    |-- README.md
    |-- dist
    |-- index.html
    |-- node_modules
    |-- package-lock.json
    |-- package.json
    |-- postcss.config.js
    |-- public
    |-- src/
        |-- App.css
        |-- App.jsx
        |-- assets
        |-- axios
        |-- components
        |-- index.css
        |-- layout
        |-- main.jsx
        |-- pages
        |-- routes.jsx
        |-- shared.scss
        |-- store
                        │   ├── actions/
                        │   ├── adminAction.js
                        │   ├── authAction.js
                        │   ├── cartAction.js
                        │   ├── categoryAction.js
                        │   ├── productAction.js
                        │   ├── questionsAction.js
                        │   ├── reviewAction.js
                        │   └── wishlistAction.js
                        │   │
                        ├── slices/
                        │   ├── authSlice.js
                        │   ├── cartSlice.js
                        │   └── productSlice.js
                        ├── store.js
        |-- utils
    |-- tailwind.config.js
    |-- vite.config.js

- lerna.json
- node_modules
- package-lock.json
- package.json
- rsl-redux/
    - dist
    - jest.config.js
    - node_modules
    - package.json
    - readme.md
    - rollup.config.js
    - src/
        |-- configureStore.ts
        |-- createApi.ts
        |-- createAsyncAction.ts
        |-- createSlice.ts
        |-- index.ts
        |-- store.ts
        |-- useDispatch.ts
        |-- useSelector.ts
    - tsconfig.json

Now, let's create our own Redux Toolkit library code.

Let's get started.

First of all, we will create a store which will have state, subscribe, listeners, dispatch, getState, and others.

Create Store.js

import {dispatch} from "./useDispatch"

const store = {
    state: {},
    listens: [],
    asyncActions: {},
    dispatch,
    reducerDispatch: function (reducerName, state) {
        this.state[reducerName] = {
            ...this.state[reducerName],
            ...state
        }
        this.notify()
    },
    subscribe: function (fn) {
        let index = this.listens.findIndex(lis => lis === fn)
        if (index === -1) {
            this.listens.push(fn)
        }
    },
    notify: function () {
        this.listens.forEach(lis => lis(this.state))
    },
    removeListener: function (lis) {
        this.listens = this.listens.filter(list => list !== lis)
    },
    getState(){
        return store.state
    }
}

export default store

Here, the state is an object, which we'll store our Redux state, subscriber, async actions and etc .

listens are an array where we'll store listener callback functions to be notified when an action is dispatched to update the state.

state: This property holds the current state of the redux store. It starts as an empty object {}.
listens: This property is an array that holds callback functions (listeners) to be notified whenever the state is updated.
asyncActions: This property is an object used to store asynchronous actions function. It used to manage asynchronous operations when dispatch some async action.
dispatch: This method is responsible for updating the state of the store. It takes a value parameter, which is typically an object containing the changes to be applied to the state. It merges the new value into the existing state using the spread operator (...) and notifies all subscribed listeners.
reducerDispatch: This method is similar to dispatch, but it's specifically designed for dispatching actions related to reducers. It takes two parameters: reducerName (the name of the reducer) and state (the changes to be applied to that reducer's state). It updates the state for the specified reducer and notifies listeners.
subscribe: This method allows components to subscribe to changes in the store's state. It takes a callback function (fn) as a parameter and adds it to the listens array if it's not already present.
notify: This method is called after state changes are made. It iterates over all subscribed listeners and invokes them, passing the updated state as an argument.
removeListener: This method removes a listener from the listens array. It takes a listener function (lis) as a parameter and filters it out from the array.
getState: This method returns the current state of the store.

Create createSlice.js

Now we will build createSlice:

createSlice is a function that accepts slice name, initial state, an object of reducer functions, extra-reducers and automatically generates action creators and action types that correspond to the reducers and state.

// createSlice.js
import store from "./store"

function createSlice(payload) {
    const {name: reducerName, reducers, extraReducers, initialState} = payload
    reducers["initialState"] = initialState
    let actions = {}

    for (let actionName in reducers) {
        let actionFn = reducers[actionName]

        actions[actionName] = function (arg) {
            return {
                actionFn,
                reducerName,
                payload: arg,
            }
        }
    }

    if (extraReducers) {
        extraReducers({
            addCase: function (actionCreator, reducerAction) {

                if (Object.keys((store["asyncActions"])).includes(actionCreator.type)) {
                    console.warn("Duplicate action type:: " + actionCreator.type)
                }

                if dispatch(!store["asyncActions"]) store["asyncActions"] = {}

                store["asyncActions"][actionCreator.type] = {
                    reducerName: reducerName,
                    reducerActionFn: (updatedState, result) => reducerAction(updatedState, result)
                }
            }
        })
    }

    return {
        name: reducerName,
        reducer: reducers,
        actions
    }
}

export default createSlice

We are already aware of the purpose of the createSlice function. It facilitates the creation of various slices, or we can say reducers, which essentially allows us to segment our redux state into smaller, manageable pieces.

Parameters Deconstruction:

The function accepts a single parameter, payload, which is an object containing essential properties for defining the slice. These properties include:

name: A string representing the name of the slice.
reducers: An object containing synchronous action reducers that update the state.
extraReducers: An optional function for handling asynchronous actions.
initialState: The initial state of the slice.

Reducer Initialization:

The initial state is added to the reducers object under the key "initialState". This ensures easy access to the initial state within the reducers.

Action Creation:

For each reducer defined in the reducers object, the function generates corresponding action creator functions. These functions, when invoked, return an object encapsulating the action function, the reducer name, and the provided payload. Here's an example of how actions are created:

We store all reducer-modifying functions in the actions variable, and later, we dispatch these functions to update the slice state.

const actions = {}
for (let actionName in reducers) {
    let actionFn = reducers[actionName]
    actions[actionName] = function (args) {
        return {
            actionFn,
            reducerName,
            payload: args,
        }
    }
}

When we call setAuth with the dispatch higher-order function:

dispatch(setAuth({…}))

Then, in the reducers, setAuth will be called and , and it will receive the state reference and the action payload that we passed earlier when we modify it.

 reducers: {
      setAuth(state, action) {
          state.auth = {
              ...action.payload
          }
      } 
}

Assigning state.auth to a certain value will update the auth property of the authState. And all subscribers will be notified and got the latest authState updated state.

Which we will be explore later on.

Handling Extra Reducers:

use case:

// authSlice.js
extraReducers: (builder) => {
      builder.addCase(loginAction.fulfilled, (state, action) => {
          state.auth = action.payload.user
          state.authLoaded = true
          localStorage.setItem('token', action.payload.token)
      })

       builder.addCase(loginAction.rejected, (state, action) => {...})
    }

When extra reducers are specified via the extraReducers function, they are processed to handle asynchronous actions or special cases. The function provided to extraReducers likely offers a method, such as addCase, to add new cases for handling actions. If an action type already exists, duplicate action type warnings are issued.

We invoke the extraReducers function, which takes an object as parameters. This object has an addCase method.

The addCase method takes two parameters: actionCreator and reducerAction, which will be passed when calling the addCase method with the dispatch higher-order function.

// dispatch asynchronous action.
dispatch(fetchAllPosts())

Before storing, we check if the action type already exists in the state.asyncActions object. If it does, we don't overwrite it; instead, we throw a warning indicating that the action type should be unique.

In the asyncActions object, we only store two properties: reducerName and reducerActionFn. The reducerActionFn function takes updatedState and result as arguments.

Additionally, the reducerActionFn will call the reducerAction function, which takes the addCase method as an argument.

// createSlice.js
extraReducers({
    addCase: function (actionCreator, reducerAction) {

        if(Object.keys((store["asyncActions"])).includes(actionCreator.type)){
            console.warn("Duplicate action type:: "+ actionCreator.type)
        }

        if(!store["asyncActions"]) store["asyncActions"] = {}

        store["asyncActions"][actionCreator.type] = {
            reducerName: reducerName,
            reducerActionFn: (updatedState, result) => reducerAction(updatedState, result)
        }

    }
})

Return Object:

The function returns an object containing vital information about the slice:

name: The name of the slice.
reducer: The original reducers object.
actions: An object containing the action creator functions generated from the provided reducers.

CreateAsyncThunk

createAsyncThunk is a utility function that used to creating asynchronous action creators. It encapsulates the common asynchronous operation patterns, such as making API requests, and handles the pending, fulfilled, and rejected states of the asynchronous operation automatically.

use case

export const loginAction = createAsyncAction(
    "auth-login",
    async function (payload) {
        try {
            const {data} = await api.post("/auth/login", payload)
            return data
        } catch (e) {
            throw catchErrorMessage(e)
        }

    })

Here we call createAsyncAction function and pass two parameter first one action type that should be unique and second action creator function that return promise of value that received extra-reducers as action.payload or it can return promise of rejection of data.

Now, let's look at our createAsyncThunk. It receives two parameters. The first one is the action type that will be stored in the store when we dispatch some action. It will retrieve the action creator function using the action type that we stored in the store.asyncActions object (in createSlice.js), and we invoke it.

Second one action payloadCreator function-

function createAsyncThunk(typePrefix, payloadCreator) {
    function actionCreator(arg) {
        return (dispatch, getState, extra) => {
            const result = payloadCreator(arg, {dispatch, getState, extra});
            return Object.assign(result, {
                type: typePrefix,
                arg
            })
        };
    }

    return Object.assign(actionCreator, {
        fulfilled: {type: typePrefix + "/fulfilled", payloadCreator},
        rejected: {type: typePrefix + "/rejected", payloadCreator},
        typePrefix,
    });
}

export default createAsyncThunk;

There, we return an object that is a copy of the actionCreator function, which will be called in the dispatch HOC function.

The actionCreator function also takes an argument that will be provided when we call the action with the dispatch higher-order function.

example:

dispatch(loginAction({email: "", password: ""}))

when we call with dispatch it again return a function return (dispatch, getState, extra) => {...}

And

extraReducers: (builder) => {
        builder.addCase(loginAction.fulfilled, (state, action) => {...})
}

Frist when define our slice in extraReducers we define login action fullfiled status, will invoke addCase method (figure 12) and pass actionCreator function that we earlier see on asyncActionThunk.js (figure 13) it return a function and has fulfilled, rejected, type key in its prototype. and as value we had set and object that has type and payloadCreator function that was provided when we create loginAction using createAsyncAction .

we set in store action creator async function as key action type that should be unique (figure 12).

// createSlice.js
extraReducers({
    addCase: function (actionCreator, reducerAction) {

        if(Object.keys((store["asyncActions"])).includes(actionCreator.type)){
            console.warn("Duplicate action type:: "+ actionCreator.type)
        }

        if(!store["asyncActions"]) store["asyncActions"] = {}

        store["asyncActions"][actionCreator.type] = {
            reducerName: reducerName,
            reducerActionFn: (updatedState, result) => reducerAction(updatedState, result)
        }
    }
})

export const loginAction = createAsyncAction(
    "auth-login",
    async function (payload) {
        try {
            const {data} = await api.post("/auth/login", payload)
            return data
        } catch (e) {
            throw catchErrorMessage(e)
        }

    })

Don't worry if it seems confusing at first time! Once you give it a try, you'll quickly grasp it.

Dispatch

Now we will see in dispatch higher order function that dispatch out action and update state.

useDispatch.js

import store from "./store";

function useDispatch() {
  return dispatch;
}

function dispatch(actionObj) {
  let actionCall;
  if (typeof actionObj === "function") {
    // handle asynchronous createAsyncThunk action.
    actionCall = actionObj(dispatch, store.getState, {});
    let action = {};

    // when action creator function return promise
    if (actionCall instanceof Promise) {
      actionCall
        .then((payloadResponse) => {
          action = {
            payload: payloadResponse,
            type: actionCall.type + "/fulfilled",
          };
        })
        .catch((ex) => {
          const type = actionCall.type;
          const lastPartActionType = type.replace(/\/[^/]*$/, "");
          action = {
            payload: ex,
            type: lastPartActionType + "/rejected",
          };
        })
        .finally(() => {
          // retrieve stored async actionCreator function from store via action type
          const reducerActionInfo = store.asyncActions[action.type];

          if (reducerActionInfo) {
            const updatedState = reducerActionInfo.reducerActionFn(
              store.state[reducerActionInfo.reducerName],
              action
            );
            store.reducerDispatch(reducerActionInfo.reducerName, updatedState);
          }
        });
    } else {
      // when action creator function return plain object, arr or other.
      action = {
        payload: actionCall,
        type: actionCall.type + "/fulfilled",
      };
      const reducerActionInfo = store.asyncActions[action.type];
      if (reducerActionInfo) {
        const updatedState = reducerActionInfo.reducerActionFn(
          store.state[reducerActionInfo.reducerName],
          action
        );
        store.reducerDispatch(reducerActionInfo.reducerName, updatedState);
      }
    }
  } else {
    // handle sync action
    const { actionFn, reducerName, payload } = actionObj;
    let sliceState = store["state"][reducerName];
    actionFn(sliceState, { payload });
    store.reducerDispatch(reducerName, sliceState);
    actionCall = payload;
  }

  return {
    unwrap() {
      return actionCall;
    },
  };
}

export default useDispatch;

The useDispatch function follows the React hook pattern, returning a function that acts as our dispatch function.

The dispatch function takes an argument, which can either be a plain object or an asynchronous function.

Here loginAction is an asynchronous action. it make server post request with user email & password and return user login info.

dispatch(loginAction({email, password}))

If you don’t use ReactJS in your project, then you can use the store.dispatch method to dispatch actions.

store.dispatch(loginAction({email, password}))

Here, loginAction represents an asynchronous action. It initiates a server POST request with the user's email and password, aiming to retrieve the user's login information. Upon successful completion, it returns the user login information.

In Figure 15, actionObj becomes a function returned by createAsyncThunk.

// createAsyncThunk.js
return (dispatch, getState, extra) => {
    const result = payloadCreator(arg, {dispatch, getState, extra});
    return Object.assign(result, {
        type: typePrefix,
        arg
    })
};

The actionObj then returns the action result, either a promise or a plain object.

If the promise is fulfilled, we receive the result and create the action object:

 action = {
    payload: ex,
    type: lastPartActionType + "/fulfilled",
  };

Otherwise, if it's rejected:

 action = {
    payload: ex,
    type: lastPartActionType + "/rejected",
  };

This action is then passed to the builder.addCase method as the second parameter.

In the final block, we retrieve the async action handler function using the action type as the key, which we previously stored when calling the createSlice function.

const reducerActionInfo = store.asyncActions[action.type];

We refer to it as reducerActionInfo, an object with two properties: reducerName and reducerActionFn, which are set here:

// createSlice.js
store["asyncActions"][actionCreator.type] = {
    reducerName: reducerName,
    reducerActionFn: (updatedState, result) => reducerAction(updatedState, result)
}

reducerActionFn is a function that takes two arguments: the updated state used to mutate the slice state, and the action object containing the value and type. We mutate the slice state using this value:

const updatedState = reducerActionInfo.reducerActionFn(
      store.state[reducerActionInfo.reducerName],
      action
);
store.reducerDispatch(reducerActionInfo.reducerName, updatedState);

now we call store.reducerDispatch method to emit event to all listener to get updated state value.

store.js

  // store.js
const store = {
        ...
        reducerDispatch: function (reducerName, state) {
            this.state[reducerName] = {
                ...this.state[reducerName],
                ...state
            }
            this.notify()
        },
        subscribe: function (fn) {
            let index = this.listens.findIndex(lis => lis === fn)
            if (index === -1) {
                this.listens.push(fn)
            }
        },
        notify: function () {
            this.listens.forEach(lis => lis(this.state))
        },
        ...
}

The reducerDispatch method takes two arguments: the reducer name and the updated state. We immutably update our state and call the notify method, which sends all listeners the updated state.

We are Done But wait a second;

We are done, but wait a second; we need to access the slice state and also get the updated slice state when some actions are dispatched.

To do this, we create a hook called useSelector, similar to the Redux implementation.

The useSelector hook allows us to access our reducer. It subscribes to our store behind the scenes, so when a dispatch method is called, it will be triggered, and component will be re-render.

Create useSelector

// here full implementation..

// useSelector.js
import { useEffect, useState } from "react";
import store from "./store";
import isArray from "./utils/isArray";
import isObject from "./utils/isObject";

function useSelector(cb) {
    let ini = {};
    const selectedState = cb(store.state);

    if(isArray(selectedState)){
        ini = [...selectedState]
    }else if(isObject(selectedState)) {
        ini = {...selectedState}
    }

    const [state, setState] = useState(ini); // Initialize state with the specific part

    const listener = (gState) => {
        const selectedState = cb(gState);
        setState(selectedState)
    };

    useEffect(() => {
        // Subscribe to the store when the components mounts
        store.subscribe(listener);

        // Clean up the subscription when the components unmounts
        return () => {
            store.removeListener(listener);
        };

    }, [selectedState]); // Only resubscribe if the callback function changes

    // Return the selected state
    return state;
}

export default useSelector;

The useSelector hook function takes an argument to access a specific portion of the state's value. It also subscribes to this state portion. If this portion changes, the component will re-render because it's used in the useState hook.

 useEffect(() => {
    // Subscribe to the store when the components mounts
    store.subscribe(listener);

    // Clean up the subscription when the components unmounts
    return () => {
        store.removeListener(listener);
    };

}, [selectedState]); // Only resubscribe if the callback function changes

Inside useEffect, we establish the subscription to the store

const [state, setState] = useState(ini); // Initialize state with the specific part

const listener = (gState) => {
    const selectedState = cb(gState);
    setState(selectedState)
};

This is our listener function.

When an action is dispatched, the listener function is invoked because we store its reference. In this function, we call the cb callback passed from the component, which returns a portion of our state value.

We then store this returned value using the useState hook, triggering a re-render in our component.

Create configure Store:

// configureStore.js
import store from "./store";

function configureStore({reducer}) {
    for (const reducerKey in reducer) {
        const initialState = reducer[reducerKey]?.["initialState"]
        store.state = {
            ...store.state,
            [reducerKey]: initialState || undefined
        }
    }
    return store
}

export default configureStore

The purpose of the configureStore function in the provided code snippet is to initialize the global state of the Redux-like store with the initial state values provided for each reducer. and also it return our application store object reference.

Finally we are done.

Our redux driver code completed: now we use these to our application.

With Vanila JS Project:

import {createSlice, configureStore} from "rsl-redux"

const blogSlice = createSlice({
    name: "blogState",
    initialState: {
        posts: []
    },
    reducers: {
        setPosts(state, action) {
            state.posts = action.payload
        },
        removePost(state, action) {
            const updatedPosts = [...state.posts]
            state.posts = updatedPosts.filter(post => post.id !== action.payload)
        }
    }
})

const {setPosts, removePost} = blogSlice.actions

const store = configureStore({
    reducer: {
        [blogSlice.name]: blogSlice.reducer
    }
})

// subscription added
store.subscribe((store) => {
    console.log("redux state", store.getState().blogState.posts)
})

const blogs = [
    {
        "id": 2,
        "title": "blog 3",
        "slug": "blog-3"
    },
    {
        "id": 3,
        "title": "blog 4",
        "slug": "blog-4"
    },
    {
        "id": 4,
        "title": "blog 5",
        "slug": "blog-5"
    },
    {
        "id": 5,
        "title": "blog 6",
        "slug": "blog-6"
    },
    {
        "id": 6,
        "title": "blog 7",
        "slug": "blog-7"
    },
    {
        "id": 7,
        "title": "blog 8",
        "slug": "blog-8"
    },
    {
        "id": 8,
        "title": "blog 9",
        "slug": "blog-9"
    },
    {
        "id": 9,
        "title": "blog 10",
        "slug": "blog-10"
    },
    {
        "id": 10,
        "title": "blog 11",
        "slug": "blog-11"
    },
    {
        "id": 11,
        "title": "blog 12",
        "slug": "blog-12"
    }
]

// store all posts in slice.
store.dispatch(setPosts(blogs))

store.dispatch(removePost(1))
store.dispatch(removePost(2))
store.dispatch(removePost(3))
store.dispatch(removePost(4))
store.dispatch(removePost(5))
store.dispatch(removePost(6))
store.dispatch(removePost(7))
store.dispatch(removePost(8))
store.dispatch(removePost(9))
store.dispatch(removePost(10))
store.dispatch(removePost(11))

Output:

[vite] connecting...
client.ts:173 [vite] connected.
main.jsx:42 redux state (10) [{…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}]
main.jsx:42 redux state (10) [{…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}]
main.jsx:42 redux state (9) [{…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}]
main.jsx:42 redux state (8) [{…}, {…}, {…}, {…}, {…}, {…}, {…}, {…}]
main.jsx:42 redux state (7) [{…}, {…}, {…}, {…}, {…}, {…}, {…}]
main.jsx:42 redux state (6) [{…}, {…}, {…}, {…}, {…}, {…}]
main.jsx:42 redux state (5) [{…}, {…}, {…}, {…}, {…}]
main.jsx:42 redux state (4) [{…}, {…}, {…}, {…}]
main.jsx:42 redux state (3) [{…}, {…}, {…}]
main.jsx:42 redux state (2) [{…}, {…}]
main.jsx:42 redux state [{…}]
main.jsx:42 redux state []

Now we use it in our React project.

Our Project `store` root file

import {configureStore} from "rsl-redux";
import authSlice from "./slices/authSlice.js";
import productSlice from "./slices/productSlice.js";
import cartSlice from "./slices/cartSlice.js";

const store = configureStore({
    reducer: {
        [authSlice.name]: authSlice.reducer,
        [productSlice.name]: productSlice.reducer,
        [cartSlice.name]: cartSlice.reducer
    }
})

export default store

Slices

authSlice.js

Auth slice to store auth related all state

import { createSlice } from "rsl-redux";
import { 
    authVerifyAction, 
    createAccountAction, 
    deleteAddress, 
    deleteCustomer, 
    fetchAddresses, 
    fetchAdminCustomersProducts, 
    fetchCategoryWiseOrdersSlatsAction, 
    fetchDashboardSlatsAction, 
    fetchOrdersSlatsAction, 
    fetchOrdersSlatsSummaryAction,
    loginAction 
} from "../actions/authAction.js";

import { 
    deleteReview, 
    fetchCustomerReviews, 
    updateReviewAction
} from "../actions/reviewAction.js"
;
import { 
    deleteQuestionAnswer, 
    fetchCustomerQuestionAnswers, 
    updateQuestionAnswerAction 
} from "../actions/questionsAction.js";

const initialState = {
    auth: null,
    authLoaded: false,
    dashboardSlats: {
        "sales": [],
        "carts": [],
        "users": []
    },
    orderSlats: {},
    orderCategoryWiseSlats: {},
    dashboardSlatsSummary: {
        totalIncome: 0,
        totalSpend: 0,
        totalProducts: 0,
        totalUsers: 0,
        totalCategories: 0,
        totalOrders: 0
    },
    openSidebar: "",
    addresses: [],
    customerReviews: {},
    customerQuestions: {}
}

const authSlice = createSlice({
    name: 'authState',
    initialState,
    reducers: {
        setAuth(state, action) { state.auth = { ...action.payload } },
        logOut(state) { localStorage.removeItem("token"); state.auth = null },
        setSidebar(state, action) { state.openSidebar = action.payload }
    },
    extraReducers: (builder) => {
       builder.addCase(loginAction.fulfilled, (state, action) => {...})
            builder.addCase(loginAction.rejected, (state, action) => {...})
            builder.addCase(fetchAdminCustomersProducts.fulfilled, (state, action) => {...})
            builder.addCase(deleteCustomer.fulfilled, (state, action) => {...})
            builder.addCase(fetchOrdersSlatsAction.fulfilled, (state, action) => {...})
            builder.addCase(fetchDashboardSlatsAction.fulfilled, (state, action) => {...})
            builder.addCase(fetchAddresses.fulfilled, (state, action) => {...})
            builder.addCase(deleteAddress.fulfilled, (state, action) => {...})
            builder.addCase(fetchCategoryWiseOrdersSlatsAction.fulfilled, (state, action) =>{...})
            builder.addCase(fetchOrdersSlatsSummaryAction.fulfilled, (state, action) => {...})
            builder.addCase(createAccountAction.fulfilled, (state, action) => {...})
            builder.addCase(authVerifyAction.fulfilled, (state, action) => {...})
            builder.addCase(authVerifyAction.rejected, (state) => {...})
            builder.addCase(fetchCustomerReviews.fulfilled, (state, action) => {...})
            builder.addCase(updateReviewAction.fulfilled, (state, action) => {...})
            builder.addCase(deleteReview.fulfilled, (state, action) => {...})
            builder.addCase(fetchCustomerQuestionAnswers.fulfilled, (state, action) => {...})
            builder.addCase(updateQuestionAnswerAction.fulfilled, (state, action) => {...})
            builder.addCase(deleteQuestionAnswer.fulfilled, (state, action) => {...})

    }
});

export const { setAuth, logOut, setSidebar } = authSlice.actions;
export default authSlice;

productSlice.js

Store all products related state.

// productSlice.js

const initialState = {
    showCategories: [], // Array<{name: string, slug: string, image: string}>
    homeProducts: {},
    products: [], // Array<Product>
    brands: [], // Array<Brand>
    specsMapping: {},
    categoryBrands: {}, // {[catSlug: string]: Brand[]}
    specs: {},
    wishlist: [],
    orders: {}, // {1: {items: Array<Orders>, count: number} }
    adminProducts: [],
    categories: [],
    filter: {
        search: "",
        categoryIds: [],
        brandIds: [],
        pageNumber: 1,
        attributes: {}
    },
    reviews: {}, // key product id
    questionAnswers: {}, // key product id
}

const productSlice = createSlice({
    name: 'productState',
    initialState: initialState,
    reducers: {

        setFilter(state, action) {
            for (let payloadKey in action.payload) {
                state.filter[payloadKey] = action.payload[payloadKey]
            }
        },

        addToWishlist(state, action) {
            state.wishlist.push(action.payload)
        },

        removeFromWishlist(state, action) {
            state.wishlist = state.wishlist.filter(item => item.productId !== action?.pyload)
        }

    },

    extraReducers: (builder) => {
                builder.addCase(fetchProducts.fulfilled, (state, action) => {...})
                builder.addCase(fetchWishlists.fulfilled, (state, action) => {...})
                builder.addCase(fetchOrdersAction.fulfilled, (state, action) => {...})
                builder.addCase(fetchAdminProducts.fulfilled, (state, action) => {...})
                builder.addCase(fetchAdminDashboardProducts.fulfilled, (state, action) => {...})
                builder.addCase(fetchCategoryBrands.fulfilled, (state, action) => {...})
                builder.addCase(fetchAttributeSpec.fulfilled, (state, action) => {...})
                builder.addCase(fetchAttributeSpecMapping.fulfilled, (state, action) => {...})
                builder.addCase(fetchCategories.fulfilled, (state, action) => {...})
                builder.addCase(deleteAdminProduct.fulfilled, (state, action) => {...})
                builder.addCase(fetchBrands.fulfilled, (state, action) => {...})
                builder.addCase(deleteBrand.fulfilled, (state, action) => {...})
                builder.addCase(deleteCategory.fulfilled, (state, action) => {...})

                // Reviews
                builder.addCase(fetchReviews.fulfilled, (state, action) => {...})
                builder.addCase(addReviewAction.fulfilled, (state, action) => {...})

                // Question and answers
                builder.addCase(fetchQuestionAnswers.fulfilled, (state, action) => {...})
                builder.addCase(addQuestionAnswerAction.fulfilled, (state, action) => {...})
    }
})

export const {removeFromWishlist, addToWishlist, setFilter} = productSlice.actions
export default productSlice

In productSlice.js, we handle the state related to products within our e-commerce application. This slice plays a crucial role in managing product data, including details, categories, brands, reviews, questionAnswers, product attributes and wishlist.

Asynchronous actions, managed through middleware like Redux Thunk or Redux Saga, handle tasks such as fetching product data from an API. You'll find action creators like fetchProducts, fetchBrands, fetchCategories, and fetchReviews, triggering API requests to update the Redux store with the retrieved data.

Actions:

actions/
│   ├── adminAction.js
│   ├── authAction.js
│   ├── cartAction.js
│   ├── categoryAction.js
│   ├── productAction.js
│   ├── questionsAction.js
│   ├── reviewAction.js
│   └── wishlistAction.js

authAction.js

// authAction.js
import {createAsyncAction} from "rsl-redux";
import {api} from "../../axios";
import catchErrorMessage from "../../utils/catchErrorMessage.js";

export const loginAction = createAsyncAction("auth-login", async function (payload) {...})

export const createAccountAction = createAsyncAction("create_account", async function (payload) {...})

export const fetchAddresses = createAsyncAction("fetchAddresses", async function () {...})

export const deleteAddress = createAsyncAction("deleteAddress", async function (id) {...})

export const authVerifyAction = createAsyncAction("verify_auth_account", async function () {...})

export const fetchAdminCustomersProducts = createAsyncAction("fetchAdminCustomersProducts", async function () {...})

export const deleteCustomer = createAsyncAction("deleteCustomer", async function (id) {...})

export const fetchDashboardSlatsAction = createAsyncAction("fetchDashboardSlatsAction", async function ({year, role, taskList = []}) {...})

export const fetchOrdersSlatsAction = createAsyncAction("fetchOrdersSlatsAction", async function ({year, role}) {...})

export const fetchCartsSlatsAction = createAsyncAction("fetchCartsSlatsAction", async function ({year, role, taskList = []}) {...})

export const fetchCategoryWiseOrdersSlatsAction = createAsyncAction("fetchCategoryWiseOrdersSlatsAction", async function ({year, role, type}) {...})

export const fetchOrdersSlatsSummaryAction = createAsyncAction("fetchOrdersSlatsSummaryAction", async function ({role, taskList}) {...})

create our fetch posts and delete post async actions

// productAction.js

import {createAsyncAction} from "rsl-redux";
import {api} from "../../axios/index.js";
import catchErrorMessage from "../../utils/catchErrorMessage.js";

export const fetchProducts = createAsyncAction("fetch-products", async function (pageNumber) {...})

export const fetchOrdersAction = createAsyncAction("fetchOrdersAction", async function (pageNumber) {...})

export const searchProductAction = createAsyncAction("search-products", async function (text) {...})

export const deleteBrand = createAsyncAction("deleteBrand", async function (brandId) {...})

Access Store State

Now we access store state and dispatch some actions.

import React, {useEffect, useRef, useState} from 'react';
import {useParams, useSearchParams} from "react-router-dom";
import {useDispatch, useSelector} from "rsl-redux";
import Product from "../components/Product.jsx";
import {api} from "../axios/index.js";
import Breadcrumb from "../components/Breadcrumb.jsx";
import {FaAngleRight} from "react-icons/fa";
import Loader from "../components/Loader.jsx";
import {HiBars4} from "react-icons/hi2";
import {setSidebar} from "../store/slices/authSlice.js";
import {fetchAttributeSpec, fetchAttributeSpecMapping, fetchCategoryBrands} from "../store/actions/categoryAction.js";
import Popup from "../components/Popup.jsx";
import {setFilter} from "../store/slices/productSlice.js";

const SearchProduct = () => {
    const [getQuery] = useSearchParams()
    const {categoryName} = useParams()

    const filterObj = useRef({
        attributes: {}, brandIds: [],
        categoryIds: []

    })
    const {openSidebar} = useSelector(state => state.authState)

    const {categories, filter,  categoryBrands, specs} = useSelector(state => state.productState)

    const [expandAttributes, setExpandAttributes] = useState(["brand_id"])

    const [pagination] = useState({
        page: 1,
        totalPage: 10
    })

    const dispatch = useDispatch()

    let selectedCategory = categories.find(cat => cat.slug === categoryName)

    const [searchProuduct, setSearchProduct] = useState([])

    const text = getQuery.get("search")
    const [isSearching, setSearching] = useState(false)

    useEffect(() => {
        if (categoryName) {
            dispatch(fetchCategoryBrands(categoryName))
            dispatch(fetchAttributeSpec(categoryName))
            dispatch(fetchAttributeSpecMapping())
        }
    }, [categoryName]);

    useEffect(() => {
        dispatch(setFilter({
            categoryIds: categoryName ? [categoryName] : [],
            search: text,
        }))
    }, [categoryName, text])

    useEffect(() => {
        filterProduct(filter)
    }, [filter.attributes, filter.brandIds, filter.search])

    function filterProduct(filter) {...}


     return (
           <div>...</div>
      )
}

Here use, dispatch some action

dispatch(fetchCategoryBrands(categoryName))
dispatch(fetchAttributeSpec(categoryName))
dispatch(fetchAttributeSpecMapping())

And access state using useSelector hook.

const {categories, filter, categoryBrands, specs} = useSelector(state => state.productState)

NOTE:

Please review any unintentional errors in the writing with forgiveness and a kind perspective. Also, I apologize for my English.

Part 2, I will include RTK Query soon.

A Real Implementation of Server-Sent Events (SSE)

Rasel Mahmud — Fri, 01 Mar 2024 09:41:38 +0000

What are Server-Sent Events (SSE)?

Server-Sent Events (SSE) is a standard mechanism for pushing real-time updates from a server to a web client over a single, long-lived HTTP connection. SSE is often used in scenarios where real-time information needs to be sent from the server to the client without the client needing to continuously poll the server for updates.

Key Features of SSE:

Simple Setup: SSE is easy to implement and only requires standard HTTP connections.
Unidirectional Communication: SSE allows the server to push data to the client without requiring any action from the client.
Text-Based: SSE sends data as plain text, making it easy to understand and implement. we can send any array of object using JSON format.

Introduction:

In this tutorial, we'll explore how to utilize Server-Sent Events (SSE) to enhance the user experience during batch uploads in a web application. We'll address the common challenge of users being left in the dark about the progress of their uploads, leading to frustration and uncertainty. By implementing SSE, we'll enable real-time visualization of backend tasks, providing users with transparency and satisfaction.

Project DEMO:

Repository:

https://github.com/rasel-mahmud-dev/server-sent-event-sse

Recently, I built a project where a large Excel file was uploaded to the backend. The backend handled various tasks, including uploading thousands of areas, departments, designations, creating employee accounts, uploading employee schedules, onboarding driver lists, and assigning cars.

All of these tasks occurred at the same route endpoint.

However, the problem was that clients didn't know what was happening in the backend, and they had to wait for 2 to 5 minutes for the entire process to complete.

After implementing SSE events, clients can now visualize each step of the process in the UI, providing them with more user experience and satisfaction.

Implementation of SSE:

To address this challenge, we'll implement Server-Sent Events (SSE) in our project. SSE allows the server to send real-time updates to the client, enabling users to visualize each step of the backend process directly in the user interface.

Prerequisites:

Basic knowledge of HTML, CSS, JavaScript, and Node.js.
An understanding of Express.js for server-side development.

Step 1: Set Up the Server

First, let's set up the server using Express.js:

const express = require('express');
const { resolve } = require("path");
const app = express();

app.set('view engine', 'ejs');
app.set('views', resolve('views'));
app.use(express.static(resolve("static")));

function sleep(mili = 500) {
    return new Promise((r) => setTimeout(r, mili))
}

// Your SSE logic goes here

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

Step 2: Implement SSE Endpoint (Server side)

Define an SSE endpoint on the server to send progress updates:


app.get('/api/events', async (req, res) => {

    res.setHeader('Content-Type', 'text/event-stream');
    res.setHeader('Cache-Control', 'no-cache');
    res.setHeader('Connection', 'keep-alive');

    const waitForEvent = () => {
        return new Promise(resolve => {
            const checkEvent = () => {
                const eventName = req.app.locals.eventName;
                res.write(`data: ${eventName}\n\n`);
                if (eventName === "COMPLETED") {
                    res.end();
                    resolve();
                } else {
                    setTimeout(checkEvent, 200);
                }
            };

            checkEvent();
        });
    };

    await waitForEvent();

    return res.end();
});

Step 3: Set Up Multi Step Task endpoint

Implement the logic to send SSE updates during the batch upload process:

app.post("/api/upload-batch", async (req, res) => {

    // process time consuming multi step operations

    const locals = req.app.locals

    locals.eventName = "UPLOADING_AREA"

    await sleep()
    locals.eventName = "UPLOADING_DEPARTMENT"

    await sleep()
    locals.eventName = "UPLOADING_DESIGNATION"

    await sleep()
    locals.eventName = "UPLOADING_EMPLOYEE"

    await sleep()
    locals.eventName = "UPLOADING_SCHEDULE"

    await sleep()
    locals.eventName = "UPLOADING_DRIVERS"

    await sleep()
    locals.eventName = "UPLOADING_ASSIGN_CAR"

    await sleep()
    locals.eventName = "COMPLETED"

    res.json({message: "operation done"})
})

Step 4: Create the Frontend UI

Create an HTML file with JavaScript to handle SSE updates:

<div class="control">
        <button onclick="onStartProgress()">Start Upload</button>
        <button onclick="onResetProgress()">Reset</button>
 </div>

  <ol class="stepper">
      <li data-id="UPLOADING_AREA">
          <span>UPLOADING AREA</span>
      </li>
      <li data-id="UPLOADING_DEPARTMENT">
          <span>UPLOADING DEPARTMENT</span>
      </li>
      <li data-id="UPLOADING_DESIGNATION">
          <span>UPLOADING DESIGNATION</span>
      </li>
      <li data-id="UPLOADING_EMPLOYEE">
          <span>UPLOADING EMPLOYEE</span>
      </li>
      <li data-id="UPLOADING_SCHEDULE">
          <span>UPLOADING SCHEDULE</span>
      </li>
      <li data-id="UPLOADING_DRIVERS">
          <span>UPLOADING DRIVERS</span>
      </li>
      <li data-id="UPLOADING_ASSIGN_CAR">
          <span>UPLOADING ASSIGN CAR</span></li>
      <li data-id="COMPLETED">
          <span>COMPLETED</span>
      </li>
  </ol>

Step 5: Implement SSE JavaScript Logic

Add JavaScript code to initiate SSE connection and update UI:


    let eventSource;
    const stepper = document.querySelectorAll(".stepper li")

    async function uploadBatchTask(){
        try{
            const formData = new FormData()
            formData.append("file", 'some_large_xlsx.xlsx')
            const res = await fetch("/api/upload-batch", {
                method: "POST",
                headers: {},
                body: formData
            })
            const data = await res.json()
        } catch (ex){
            // handle error
        }
    }

    function onStartProgress() {
        // reset ui active steps...
        resetUI()
        uploadBatchTask()

        eventSource = new EventSource('/api/events');
        eventSource.onmessage = function (event) {
            const evtData = event.data
            for (let step of stepper) {
                const id = step.dataset.id

                // Update UI step
                if (evtData.startsWith(id)) {
                    step.classList.add("active")
                }

            }

            if (evtData === "COMPLETED") {
                // Terminating SSE communication
                eventSource.close();
            }
        };

        eventSource.onerror = function(error) {
            console.error("EventSource failed:", error);
            eventSource.close();
        };
    }

    function resetUI(){
        for (let step of stepper) {
            step.classList.remove("active")
        }
    }

    function onResetProgress(){
        resetUI()
        eventSource?.close();
    }

Terminating SSE communication

eventSource.close()

WebSocket vs SSE:

WebSocket and SSE serve different purposes and have different characteristics. WebSocket is suitable for applications requiring bidirectional communication and low latency, while SSE is ideal for unidirectional server-to-client communication, such as sending periodic updates or notifications.

Conclusion:

Server-Sent Events (SSE) provide a simple and efficient way to push real-time updates from the server to the client. In your project, SSE is utilized to provide live progress updates during a batch upload process, allowing users to monitor the progress without continuously polling the server. This enhances the user experience by providing real-time feedback and transparency during long-running processes.

ReactJS এ কিভাবে Redux ছাড়াই Redux এর মত করে reducer, dispatch, actions ব্যবহার করা যায়

Rasel Mahmud — Sat, 08 Oct 2022 13:19:19 +0000

আজকে আমরা আলোচনা করব কিভাবে রিয়াক্ট এর Context API, useReducer, Custom Hooks দ্বারা Redux এর মতো state ম্যানেজ করতে পারি।

এগুলো নিয়ে যারা অলরেডি জানেন বা গবেষণা করেছেন তারা এই পোস্টটি এড়িয়ে যেতে পারেন ।

কিভাবে Redux ছাড়াই Redux এর মত করে reducer, dispatch, actions ব্যবহার করতে পারি সেটা দেখব.

আমরা নিশ্চয় জানি রিয়েক্ট এর কোন ডাটা যদি চাইল্ড কম্পোনেন্ট কে পাস করতে চাই তাইলে আমরা ডাইরেক্ট নেস্টেট n তম চাইল কে আমরা সেই ডাটাটা পাঠাতে পারিনা, তার জন্য আমাদের সবগুলো ইন্টারমিডিয়েট চাইল্ডের ভেতর দিয়ে আমাদের সব ডাটা গুলো পাস করতে হয় এবং একসময় Last child component এ ডাটা এক্সেস করতে পারি Props আকারে।

মানে প্রতিটি চিল্ড্রেন কে প্রপস আকারে ডাটা পাঠাতে হবেই ।

প্যারেন্ট থেকে ডাইরেক্ট কোনো চাইল্ড কে কোনো state পাঠাতে পারব না । আর এই প্রবলেম থেকেই গ্লোবাল স্টেট বাবহার শুরু ।

সো. গ্লোবাল স্টেট কি?

গ্লোবাল স্টেট হচ্ছে আমাদের এপ্লিকেশন এর স্টেট যেটা গ্লোবালি অ্যাকেসিবল হয়ে থাকে এবং যেটা
এপ্লিকেশন এর ভিতরে যেকোনো কম্পোনেন্ট এক্সেস করতে পারে । যেমন Redux এর state।

আমরা কনটেক্স এপিআই দ্বারা আমাদের স্টেটকে যে কোন কম্পনেন্টে থেকে এক্সেস করতে পারি।

লেটেস্ট ভার্সন রিয়াক্ট ইউজ রিডিউসার নামে হোক তৈরি করেছে ইউজ রেডিওস ব্যবহার করে আমাদের লোকাল স্টেট কে আরো কমপ্লেক্স ভাবে ইউজ করতে পারি।

রিয়েক্ট ডিসপ্যাচ দ্বারা স্টেট কে পরিবর্তন করতে পারি

আর কন্টাক্সে এপিআই দ্বারা আমাদের অ্যাপ স্টেট কে যেকোন কম্পোনেন্ট বা নেস্টেড চাইল্ড কম্পোনেন্ট থেকেও accees করতে করতে পারি।

আচ্ছা প্রথমে আমরা React.createContext দ্বারা আমরা একটা কনটেক্স তৈরি করবো।

কোড অর্গানাইজেশন করার জন্য আলাদা ফাইল বানাবো।

AppContext.js

ইনিশিয়াল ভ্যালু হিসাবে আমরা নাল প্রোভাইড করি। আপনিই যেকোন ভ্যালু প্রোভাইড করতে পারেন।

// AppContext.js
import {createContext} from "react";

export const AppContext = createContext(null)

এখন আমরা একটা কম্পনেন্ট তৈরি করব AppProvider.jsx

.jsx কেনো ? কারন context provider React component return করে। আর jsx রিটার্ন করে। তবে আপনি create রিয়েক্ট দিয়ে প্রোজেক্ট ইনিশিয়ালাইজ করলে extention js ইউজ করলেই হবে। আমি যেহেতু vite Js use korci তাই jsx ইউজ করছি ।

এর ভিতরে আমাদের এপ্লিকেশনের state রাখবো। যেটা গ্লোবালী Accessible হবে। স্টেট create করার জন্য useState hook ব্যবহার না করে আমরা useReducer hook ইউজ করব। কারন useReducer স্টেট কে আরো অনেক ভাবে মডিফাই করতে পারব লাইক dispatch করতে পারবো যে কোন অ্যাকশন টাইপ দ্বারা।

এই কম্পনেন্ট দ্বারা আমাদের রুট এপ্লিকেশন কে wrap করে দেব ।

কারন আমরা এই কম্পনেন্ট এর ভেতরে আমরা context এর ডাটা Provide করব।

যেভাবে আমরা context প্রোভাইডার দ্বারা আমাদের এপ্লিকেশন রুট কম্পনেন্ট কে wrap করে দেই।

Example code:

// AppProvider.jsx
export let dispatch;

const initialState = {
   auth: null,
   posts: []
}

function AppProvider(props) {
    const [state, dispatch: dis] = useReducer(reducer, initialState)
        dispatch = dis;

    return (
        <AppContext.Provider value={state}>
            {props.children}
        </AppContext.Provider>
    )
}

এখন আমরা reducer তৈরি করব।

যেটা useReducer ফার্স্ট প্যারামেটার আকারে গ্রহণ করে।

reducer হচ্ছে জাস্ট একটা ফাংশন যেটা রিটার্ন করে আমাদের আপডেট state কে।

reducer ফাংশন দুইটা প্যারামিটার গ্রহণ করে প্রথমটা state পরেরটা action অবজেক্ট । এই অবজেক্টটা পাব যখন dispatch মেথড কল করব তখন যে অবজেক্ট পাঠাবো।

অ্যাকশন অবজেক্ট ভিতরে type নামে আর একটা প্রোপার্টি থাকবে যেটার উপর বেস করে আমরা গ্লোবাল state কে পরিবর্তন করবো।

আমরা switch কেস ইউজ করব । আপনি ইচ্ছা করলে if else ব্লক ও ইউজ করতে পারেন।

তবে শর্ত একটাই আপডেটেড state রিটার্ন করতে হবে।

Example code:

// reducer.js
function reducer(state, action) {
    switch (action.type) {
        case "LOGIN":
            return {
                ...state,
                auth: action.payload,
            }

                case "FETCH_POSTS":
            return {
                ...state,
                posts: action.payload,
            }
        default:
            return state
    }
}

AppProvider দ্বারা আমাদের রুট অ্যাপ কে আমরা wrap করে দেবো ।

// index.js
ReactDOM.createRoot(document.getElementById('root')).render(
     <React.StrictMode>
            <AppProvider>
                <App />
            </AppProvider>
    </React.StrictMode>
)

ব্যাস আমাদের কাজ শেষ।

এখন আমরা আমাদের custom hook তৈরি করব l যার সাহায্যে আমরা আমাদের গ্লোবাল কন্টেক্স state কে এক্সেস করতে পারব এবং Dispatch করতে পারব। যেভাবে Redux এর অ্যাকশন create করে।

যখন আমরা আমাদের এই useStore custom hook ফাংশন কল করবো, তখন Array রিটার্ন পাব । যার প্রথম ইনডেক্সে এ থাকবে আমাদের কনটেক্স স্টেট এবং সেকেন্ড ইনডেক্সে এ থাকবে useReducer এর dispatch method.

Example code:

import React, {useContext} from "react";
import AppContext, {dispatch}  from "./AppContext";

function useStore(){
    const state = useContext(AppContext)
    return [state, dispatch]

}
export default useStore

এবার আমরা ইউজ করব আমাদের কাস্টম useStore Hook ।

App.jsx

// App.jsx
function App() {
    // useStore hook
    const [state, dispatch] = useStore()

    function handleLogin() {
        // after successfully api call
        dispatch({
            type: 'LOGIN',
            payload: user,
        })
    }

        console.log(state.auth) // it will update when context state change


    return (
        <div>
            <h1>App Component</h1>
                        <button onClick={handleLogin}>Login</button>
        </div>
    )
}
export default App

এখানে হ্যান্ডেল লগইন যখন ফাংশন কল করলে dispatch method যেটা useStore রিটার্ন করছে এবং Dispatch method কল করার সময় প্যারামিটার হিসেবে action অবজেক্ট পাঠাব। যার একটা প্রোপার্টি type যেটার উপর বেস করে গ্লোবাল state কে পরিবর্তন করবে। এবং payload দিয়ে ডাটা পাশ করব।

পোস্ট পেজ কম্পোনেন্ট

// Posts.jsx
function Posts() {
    // useStore hook
    const [{posts}, dispatch] = useStore()

    useEffect(()=>{
            fetch("/api/posts")
            .then(response=>response.json())    
            .then((data)=>{
                dispatch({
                        type: "FETCH_POSTS",
                        payload: data
                    })
            })  
        }, [])


    return (
        <div>
            <h1>Posts</h1>
                        {posts?.map(post=>(
                            <li>{post.title}</li>                       
                        ))}
        </div>
    )
}
export default Posts

কত সুন্দরভাবে আমরা useReducer ইউজ করতে পারি Context API এর সাথে। কোনো context manually ইম্পোর্ট না করেই।

লিখায় অনিচ্ছাকৃত ভূল ত্রুটি ক্ষমা সুন্দর দৃষ্টিতে দেখবেন। 🙏🏻 🙏🏻 🙏🏻

DEV Community: Rasel Mahmud

A Custom Reusable Delete Confirmation Modal Hook in ReactJS.

The Problem With Manual Implementation

The Problem With Manual Implementation

The Solution: useDeleteConfirmation Hook

Design Patterns & Architecture

1. Hook Pattern (Custom Hook)

2. Portal Pattern

3. Render Props Pattern

4. Callback Pattern

5. Configuration Object Pattern

Implementation

1. Root Element Management

2. Opening and Rendering the Modal

3. Closing the Modal

4. Confirm and Cancel Handlers

5. Configuration Object

Why This Design Works

Best Practices

Technical Benefits

Performance

Maintainability

User Experience

Next.js (SSR) Usage

How to Use in Next.js

Alternative SSR-Safe Pattern

Conclusion

Read more from my site:

Yarn, Npm থেকে PNPM: আমার ডেভেলপমেন্ট লাইফের গেম চেঞ্জার!

🔥 মাইগ্রেশন:

🚀 PNPM এর মূল ধারণা:

✅ সুবিধা:

👻 ফ্যান্টম ডিপেন্ডেন্সি (Phantom Dependency)

🧨 সমস্যা কী?

🚀 কিভাবে শুরু করবেন?

🗂️ Stored Package Directory:

🔧 PNPM কমান্ড সমূহ:

WebDev #NodeJS #PNPM #NextJS #BanglaDev #ProgrammingTips

RS Authenticator – Your Ultimate 2FA Security Solution!

🚀 RS Authenticator – Open-Source 2FA Built with Kotlin & Jetpack!

🔹 Your Security, Your Control

🔹 Works Completely Offline

How to Set Up PostgreSQL Logical Replication: Use Cases and Step-by-Step Guide.

What is PostgreSQL Replication?

Benefits of Logical Replication

Real-World Use Case 1: Toll Collection Management Software

Why Not Use a Central Database for All Booths?

What is Logical Replication in This Use Case?

Real-World Use Case 2: E-commerce Platforms

Setting Up PostgreSQL Logical Replication

1. Install PostgreSQL

2. Configure the Primary Database (Publisher)

Edit postgresql.conf

Edit pg_hba.conf

Restart PostgreSQL

3. Configure the Replica Database (Subscriber)

Edit postgresql.conf

Edit pg_hba.conf

Restart PostgreSQL

4. Set Up Logical Replication with Docker (Optional)

5. Create a Publication on the Primary Database

6. Create a Subscription on the Replica Database

Summary

Protecting API Requests Using Nonce, Redis, and Time-Based Validation

The Invisible Threat Lurking in Your API

📘 What is a Nonce?

📋 How Does This Protection Work?

📦 Key Components of the System

1️⃣ Token Encryption

2️⃣ Timestamp Validation

3️⃣ Replay Protection (Redis)

Diagram

💻 Implementation (Let's build it )

Client-Side: Generating and Sending the Nonce

Server-Side: Validating the Nonce

🔥 Benefits of Nonce-Based Protection

🕵️‍♂️ Example Scenario

Build Own version of Redux toolkit using Observer design pattern.

Introduction:

Overview

The Solution: `useDeleteConfirmation` Hook

Edit `postgresql.conf`

Edit `pg_hba.conf`

Edit `postgresql.conf`

Edit `pg_hba.conf`

Our Project `store` root file