Forem: Debajit Mallick

Build AI-powered React apps using Genkit

Debajit Mallick — Sun, 07 Dec 2025 06:27:16 +0000

Introduction

I've spent the last few months working with various AI frameworks, and Genkit has become my go-to for production applications. It's Google's open-source framework for building AI workflows, and it solves a lot of the headaches I used to deal with when wiring up LLMs to real applications.

In this blog, I will walk you through why I think it's worth your time, and then we'll build something practical together.

The Problem Genkit Solves

If you've tried building AI features into production apps, you've probably run into the same issues I have:

Prompt spaghetti. Your prompts start as simple strings, then grow into multi-line templates with context injection, then suddenly you've got prompts scattered across services with no clear ownership.
Debugging black holes. Something went wrong in your AI pipeline. Was it the prompt? The model? The context you passed in? Good luck figuring it out without proper observability.
The integration mess. You need to call an external API, pass that data to an LLM, maybe do some post-processing, then return a structured response. This gets ugly fast without a clean abstraction.

Genkit addresses these by giving you a flow primitive—think of it as a function that can contain multiple steps (API calls, LLM invocations, transformations) with built-in logging and a dev UI for inspection.

What We're Building

We'll create a city analyser that:

Takes a city name from the frontend
Fetches real weather data from an external API
Passes that to Gemini for analysis
Returns both raw data and AI-generated insights

Nothing revolutionary, but it demonstrates the pattern you'll use for most real-world AI features.

Setting Up the Backend

First, let's get the Genkit server running.

mkdir genkit-backend && cd genkit-backend
npm init -y
npm install @genkit-ai/core @genkit-ai/flow @genkit-ai/google-ai express cors
npm install -D typescript ts-node @types/node @types/express

Here's the flow implementation. I'm using the API Ninjas weather endpoint, but swap in whatever data source makes sense for your use case:

// src/flows/analyzeCity.ts
import { flow } from '@genkit-ai/flow';
import { genkit } from '@genkit-ai/core';
import { googleAI } from '@genkit-ai/google-ai';

const ai = genkit({
  plugins: [googleAI()],
});

interface WeatherData {
  temp: number;
  humidity: number;
  wind_speed: number;
}

async function fetchWeather(city: string): Promise<WeatherData> {
  const response = await fetch(
    `https://api.api-ninjas.com/v1/weather?city=${encodeURIComponent(city)}`,
    {
      headers: { 'X-Api-Key': process.env.WEATHER_API_KEY! },
    }
  );

  if (!response.ok) {
    throw new Error(`Weather API failed: ${response.status}`);
  }

  return response.json();
}

export const analyzeCityFlow = flow(
  'analyzeCityFlow',
  async ({ city }: { city: string }) => {
    // Step 1: Get external data
    const weather = await fetchWeather(city);

    // Step 2: Generate AI analysis
    const result = await ai.generate({
      model: 'google/gemini-pro',
      prompt: `Given the current weather in ${city}:
- Temperature: ${weather.temp}°C
- Humidity: ${weather.humidity}%
- Wind Speed: ${weather.wind_speed} km/h

Write 2-3 sentences describing what it's like there right now and any practical suggestions for someone visiting today.`,
    });

    return {
      city,
      weather,
      analysis: result.text(),
    };
  }
);

And the Express server to expose it:

// src/server.ts
import express from 'express';
import cors from 'cors';
import { analyzeCityFlow } from './flows/analyzeCity';

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

app.post('/api/analyze-city', async (req, res) => {
  try {
    const result = await analyzeCityFlow(req.body);
    res.json(result);
  } catch (error) {
    console.error('Flow failed:', error);
    res.status(500).json({ error: 'Analysis failed' });
  }
});

const PORT = process.env.PORT || 4000;
app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

You can test flows in isolation using npx genkit dev, which spins up a local UI where you can invoke flows with test inputs and inspect each step. This alone has saved me hours of debugging.

The React Frontend

Nothing fancy here—just a Vite + TypeScript setup:

npm create vite@latest genkit-react -- --template react-ts
cd genkit-react
npm install

// src/App.tsx
import { useState } from 'react';

interface AnalysisResult {
  city: string;
  weather: {
    temp: number;
    humidity: number;
    wind_speed: number;
  };
  analysis: string;
}

function App() {
  const [city, setCity] = useState('');
  const [result, setResult] = useState<AnalysisResult | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<string | null>(null);

  const handleAnalyze = async () => {
    if (!city.trim()) return;

    setLoading(true);
    setError(null);

    try {
      const response = await fetch('http://localhost:4000/api/analyze-city', {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ city }),
      });

      if (!response.ok) throw new Error('Request failed');

      setResult(await response.json());
    } catch (err) {
      setError('Failed to analyze city. Check if the backend is running.');
    } finally {
      setLoading(false);
    }
  };

  return (
    <main style={{ maxWidth: 600, margin: '0 auto', padding: 40 }}>
      <h1>City Weather Analyzer</h1>

      <div style={{ display: 'flex', gap: 8, marginBottom: 24 }}>
        <input
          type="text"
          value={city}
          onChange={(e) => setCity(e.target.value)}
          placeholder="Enter a city name"
          onKeyDown={(e) => e.key === 'Enter' && handleAnalyze()}
          style={{ flex: 1, padding: 8 }}
        />
        <button onClick={handleAnalyze} disabled={loading}>
          {loading ? 'Analyzing...' : 'Analyze'}
        </button>
      </div>

      {error && <p style={{ color: 'red' }}>{error}</p>}

      {result && (
        <div>
          <h2>{result.city}</h2>
          <p>{result.analysis}</p>
          <details>
            <summary>Raw weather data</summary>
            <pre>{JSON.stringify(result.weather, null, 2)}</pre>
          </details>
        </div>
      )}
    </main>
  );
}

export default App;

Why This Architecture Works

A few things I like about this setup:

Separation of concerns. The React app doesn't know anything about LLMs or external APIs. It just calls an endpoint and renders the response. If you swap Gemini for GPT-4 or change your data source, the frontend doesn't care.
Testability. Flows are just async functions. You can unit test them, mock the external API calls, and verify the prompt logic independently of the UI.
Observability out of the box. The Genkit dev UI shows you exactly what went into each step and what came out. When something breaks in production, you'll actually be able to figure out why.
Incremental complexity. Start with a single-step flow, then add steps as needed. Need to cache the weather data? Add a step. Need to run the analysis through a moderation filter? Add a step. The architecture scales with your requirements.

Where to Go From Here

This example barely scratches the surface. In production, you'd want to add:

Input validation and rate limiting
Caching for external API calls
Streaming responses for better UX
Authentication
Proper error handling with retries

Genkit also supports retrieval-augmented generation (RAG), evaluations, and deployment to Firebase or Cloud Run. The official docs cover these in detail.

Conclusion

If you're building AI features into production apps and tired of ad-hoc solutions, give Genkit a serious look. The learning curve is minimal if you're already comfortable with TypeScript, and the structure it provides pays dividends as your AI logic grows more complex. If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.

Make & Makefiles: A Modern Developer's Guide to Classic Automation

Debajit Mallick — Wed, 26 Nov 2025 04:53:18 +0000

Introduction

In an era of complex build systems and framework-specific tooling, there's a compelling case for revisiting Make—a build automation tool that has quietly powered software development since 1976. Despite its age, Make remains remarkably relevant for modern development workflows, from React applications to containerized microservices.

This blog helps you to understand why Make deserves a place in your development toolkit and how to leverage it effectively in contemporary projects.

The Challenge of Modern Development Workflows

Every development team faces the same fundamental challenge: managing increasingly complex build and deployment processes. Consider a typical React application workflow:

Installing dependencies across multiple directories
Running development servers with specific configurations
Executing test suites before deployments
Building optimized production bundles
Deploying to various environments

Teams typically address these needs through npm scripts, resulting in package.json files cluttered with intricate command chains:

"scripts": {
  "dev": "NODE_ENV=development webpack-dev-server --config webpack.dev.js",
  "build:prod": "NODE_ENV=production webpack --config webpack.prod.js && cp -r public/* dist/",
  "deploy": "npm run test && npm run build:prod && firebase deploy"
}

While functional, this approach has limitations. Scripts become unwieldy, cross-platform compatibility issues arise, and coordinating tasks across different tools and languages becomes challenging.

What is Make?

Make operates on a simple yet powerful principle: it executes tasks (called targets) based on dependencies and recipes. Unlike language-specific build tools, Make is language-agnostic, making it ideal for projects using different languages and diverse technology stacks.

The Anatomy of a Makefile

A Makefile consists of rules, each containing:

Target: The task name or file to be created
Dependencies: Prerequisites that must be satisfied first
Recipe: Shell commands that execute the task

Here's a basic example:

build: install
    npm run build
    echo "Build completed successfully"

install:
    npm install

When you run make build, Make automatically executes install first (if needed), then proceeds with the build commands.

Key Concepts Every Developer Should Know

Variables for Maintainability

Makefile variables reduce repetition and improve maintainability:

PROJECT_DIR = ./app
BUILD_DIR = $(PROJECT_DIR)/build
NODE_ENV = production

build:
    cd $(PROJECT_DIR) && NODE_ENV=$(NODE_ENV) npm run build

The .PHONY Declaration

One of Make's most important concepts is distinguishing between file targets and task targets. By default, Make assumes targets represent files. If a file with the target's name exists, Make considers it "up to date" and skips execution.

The .PHONY declaration prevents this behavior:

.PHONY: test build deploy

test:
    npm test

build:
    npm run build

Without .PHONY, if a test file or directory exists in your project, make test would fail to run your tests—a common source of confusion for newcomers.

Dependency Management

Make excels at managing task dependencies. Complex workflows become self-documenting:

deploy: lint test build
    firebase deploy

lint:
    eslint src/

test:
    jest --coverage

build:
    webpack --mode production

Running make deploy automatically executes linting, testing, and building in the correct order before deployment.

Practical Implementation: Make in a Modern React Project

Let's examine a production-ready Makefile for a React application with Firebase deployment:

# React + Firebase Project Makefile
# ================================

.PHONY: help install dev build test lint clean deploy check-env

# Configuration
NODE_ENV ?= development
PORT ?= 3000
BUILD_DIR = build
COVERAGE_DIR = coverage

# Default target displays available commands
help:
    @echo "Available targets:"
    @echo "  install    - Install all dependencies"
    @echo "  dev        - Start development server"
    @echo "  build      - Create production build"
    @echo "  test       - Run test suite with coverage"
    @echo "  lint       - Run ESLint checks"
    @echo "  deploy     - Deploy to Firebase (runs tests first)"
    @echo "  clean      - Remove generated files"

# Install dependencies
install:
    @echo "Installing dependencies..."
    npm ci
    @if [ -d "functions" ]; then \
        cd functions && npm ci; \
    fi
    @echo "Dependencies installed successfully"

# Development server
dev: check-env
    NODE_ENV=$(NODE_ENV) PORT=$(PORT) npm start

# Production build
build: clean
    @echo "Creating production build..."
    NODE_ENV=production npm run build
    @echo "Build complete: $(BUILD_DIR)/"

# Run tests with coverage
test:
    @echo "Running test suite..."
    npm test -- --coverage --watchAll=false
    @echo "Tests completed. Coverage report: $(COVERAGE_DIR)/index.html"

# Lint codebase
lint:
    @echo "Running ESLint..."
    npx eslint src/ --ext .js,.jsx,.ts,.tsx
    @echo "Linting complete"

# Clean generated files
clean:
    @echo "Cleaning build artifacts..."
    rm -rf $(BUILD_DIR) $(COVERAGE_DIR)
    @echo "Clean complete"

# Deploy to Firebase
deploy: lint test build
    @echo "Starting deployment..."
    firebase deploy
    @echo "Deployment successful"

# Check environment setup
check-env:
    @which node > /dev/null || (echo "Node.js is required but not installed" && exit 1)
    @which npm > /dev/null || (echo "npm is required but not installed" && exit 1)

This Makefile provides several advantages:

Self-documentation: Running make help displays all available commands
Dependency management: Deployment automatically runs lints and tests
Environment flexibility: Variables can be overridden at runtime
Error handling: The check-env target ensures prerequisites are met
Consistent workflow: Team members use identical commands regardless of their local setup

Best Practices and Recommendations

1. Structure and Organization

Organize your Makefile logically. Group related targets and use comments to explain complex operations:

# ========================================
# Development Tasks
# ========================================

.PHONY: dev dev-backend dev-frontend

dev: dev-backend dev-frontend

dev-backend:
    cd backend && npm run dev

dev-frontend:
    cd frontend && npm start

2. Error Handling

Make your targets robust with proper error checking:

deploy: 
    @if [ -z "$(API_KEY)" ]; then \
        echo "ERROR: API_KEY is not set"; \
        exit 1; \
    fi
    firebase deploy --token $(API_KEY)

3. Cross-Platform Compatibility

While Make is primarily Unix-based, you can write more portable Makefiles:

# Use $(RM) instead of rm for better portability
clean:
    $(RM) -rf build/

4. Progressive Enhancement

Start simple and add complexity as needed. Begin with basic targets for common tasks, then gradually add more sophisticated features like parallel execution or conditional logic.

When to Choose Make

Make is particularly valuable when:

Working across multiple languages: Projects combining JavaScript, Python, Go, or other languages
Managing complex workflows: Multi-step build and deployment processes
Requiring consistency: Ensuring all team members follow identical procedures
Integrating with CI/CD: Make commands translate seamlessly to pipeline steps
Simplifying onboarding: New developers can start with make install && make dev

However, consider alternatives if:

Your project is purely JavaScript-based and npm scripts suffice
You need complex build optimizations specific to a framework
Your team strongly prefers language-specific tooling

Conclusion

Make might be an old tool, but it's still relevant. By providing a language-agnostic, dependency-aware task runner, Make offers a solution to workflow automation that remains remarkably relevant.

For modern developers, Make isn't about replacing webpack, npm, or other contemporary tools. Instead, it's about orchestrating these tools into cohesive, repeatable workflows. If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.

Dynamic Feature Management with Firebase Remote Config in React

Debajit Mallick — Fri, 03 Oct 2025 04:38:12 +0000

Introduction

As Software Engineers, we often face a common challenge: deploying entire applications for minor configuration changes. Whether it's updating banner text, rolling out features to specific user segments, or running A/B experiments, the traditional approach requires a full rebuild and redeployment cycle.

Firebase Remote Config solves this problem by providing cloud-hosted configuration parameters that your application can fetch at runtime. This means you can modify app behaviour instantly without touching your deployment pipeline.

In this blog, we'll learn what Firebase Remote Config is and its use cases in a real-world application.

Firebase Remote Config

Firebase Remote Config is a cloud service that provides key-value pairs to client applications. It acts as a centralised configuration layer between your codebase and runtime behaviour.

Core capabilities:

Feature flags: Toggle features on/off without code changes
Targeted rollouts: Release features to specific user segments
Dynamic content: Update UI elements based on user properties
A/B testing: Run experiments by varying parameters across user groups

Important: Remote Config is designed for application configuration, not sensitive data. Since values are accessible on the client side, never store API keys or secrets here.

Project Setup

1. Initialize a React Project

npm create vite@latest firebase-remote-config-demo -- --template react-ts
cd firebase-remote-config-demo
npm install firebase

2. Configure Firebase SDK

Create src/firebase.ts and add your Firebase project credentials:

import { initializeApp } from "firebase/app";
import { getRemoteConfig } from "firebase/remote-config";

const firebaseConfig = {
  apiKey: "YOUR_API_KEY",
  authDomain: "YOUR_PROJECT.firebaseapp.com",
  projectId: "YOUR_PROJECT_ID",
  appId: "YOUR_APP_ID",
};

export const app = initializeApp(firebaseConfig);
export const remoteConfig = getRemoteConfig(app);

// Configure fetch behaviour
remoteConfig.settings = {
  fetchTimeoutMillis: 5000,
  minimumFetchIntervalMillis: 30_000, // 30s for development
};

// Define fallback values
remoteConfig.defaultConfig = {
  banner_enabled: false,
  banner_text: "Black Friday sale is here!",
  banner_bg: "#111828",
  enable_new_checkout: false,
};

Configuration notes:

fetchTimeoutMillis: Maximum time to wait for fetch completion
minimumFetchIntervalMillis: Controls fetch frequency (set to 3600000ms/1 hour in production to reduce network calls)
defaultConfig: Ensures app functionality even when Remote Config is unavailable

3. Create a Custom Hook

Let's build a reusable hook for accessing Remote Config values. Create src/useRemoteConfig.ts:

import { useEffect, useState } from "react";
import { remoteConfig } from "./firebase";
import { fetchAndActivate, getValue } from "firebase/remote-config";

type RCValues = {
  banner_enabled: boolean;
  banner_text: string;
  banner_bg: string;
  enable_new_checkout: boolean;
};

export function useRemoteConfig() {
  const [values, setValues] = useState<RCValues>({
    banner_enabled: false,
    banner_text: "🎉 Welcome to our shop!",
    banner_bg: "#111827",
    enable_new_checkout: false,
  });
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetchAndActivate(remoteConfig)
      .then(() => {
        setValues({
          banner_enabled: getValue(remoteConfig, "banner_enabled").asBoolean(),
          banner_text: getValue(remoteConfig, "banner_text").asString(),
          banner_bg: getValue(remoteConfig, "banner_bg").asString(),
          enable_new_checkout: getValue(remoteConfig, "enable_new_checkout").asBoolean(),
        });
      })
      .catch((error) => {
        console.error("Remote Config fetch failed:", error);
        // Defaults remain in place on error
      })
      .finally(() => setLoading(false));
  }, []);

  return { values, loading };
}

How it works:

fetchAndActivate: Fetches the latest config and applies it immediately
Type safety ensures correct value types at compile time
Error handling prevents app crashes if Firebase is unreachable
Loading state prevents UI flicker during initial fetch

4. Implement Components

Dynamic Banner Component (src/components/FestivalBanner.tsx):

import React from "react";
import { useRemoteConfig } from "../useRemoteConfig";

export function FestivalBanner() {
  const { values, loading } = useRemoteConfig();

  if (loading || !values.banner_enabled) return null;

  return (
    <div
      style={{
        background: values.banner_bg,
        color: "#fff",
        padding: "12px",
        borderRadius: "8px",
        textAlign: "center",
        marginBottom: "20px",
      }}
    >
      <strong>{values.banner_text}</strong>
    </div>
  );
}

Feature-Flagged Checkout (src/components/CheckoutButton.tsx):

import React from "react";
import { useRemoteConfig } from "../useRemoteConfig";

export function CheckoutButton() {
  const { values } = useRemoteConfig();

  const handleCheckout = () => {
    if (values.enable_new_checkout) {
      alert("🆕 New Checkout Flow Activated!");
      // Route to new checkout implementation
    } else {
      alert("Classic Checkout");
      // Route to legacy checkout
    }
  };

  return (
    <button
      onClick={handleCheckout}
      style={{
        padding: "12px 24px",
        borderRadius: "8px",
        background: values.enable_new_checkout ? "#10b981" : "#3b82f6",
        color: "white",
        border: "none",
        cursor: "pointer",
        fontSize: "16px",
      }}
    >
      {values.enable_new_checkout ? "🚀 Try New Checkout" : "Checkout"}
    </button>
  );
}

5. Integrate in Main App

Update src/App.tsx:

import React from "react";
import { FestivalBanner } from "./components/FestivalBanner";
import { CheckoutButton } from "./components/CheckoutButton";

function App() {
  return (
    <div style={{ 
      maxWidth: "680px", 
      margin: "40px auto", 
      padding: "0 20px",
      fontFamily: "system-ui, sans-serif" 
    }}>
      <h1>T-Mate</h1>
      <FestivalBanner />
      <div style={{ marginTop: "20px" }}>
        <CheckoutButton />
      </div>
    </div>
  );
}

export default App;

Firebase Console Configuration

Setting Up Parameters

Navigate to Firebase Console → Remote Config
Add the following parameters:
- banner_enabled (Boolean) → Default: false
- banner_text (String) → Default: "🎉 Welcome to our shop!"
- banner_bg (String) → Default: "#111827"
- enable_new_checkout (Boolean) → Default: false

Creating Conditions

Geographic targeting:

Condition name: "Users in India"
Rule: country == 'in'
Override: banner_enabled = true, banner_text = "🪔 Diwali Sale is Live!"

Percentage rollout:

Condition name: "10% Beta Users"
Rule: User in random percentile <= 10%
Override: enable_new_checkout = true

Publishing Changes

After configuring parameters and conditions, click "Publish changes." Updates propagate to clients within the configured minimumFetchIntervalMillis window.

Testing the Implementation

npm run dev

Open your browser and test:

The banner appears/disappears based on your location
Refresh multiple times to see the new checkout (10% probability) potentially
Modify values in Firebase Console and observe changes after the fetch interval

Production Best Practices

1. Implement Defensive Defaults

Always provide fallback values in multiple layers:

In remoteConfig.defaultConfig
In your hook's initial state
In component logic where appropriate

This ensures your app remains functional even when Remote Config is unavailable due to network issues or service outages.

2. Optimize Fetch Intervals

Development environment: 30 seconds (fast iteration)
Production environment: 1-2 hours (reduced network overhead)

remoteConfig.settings = {
  fetchTimeoutMillis: 5000,
  minimumFetchIntervalMillis: 
    process.env.NODE_ENV === 'production' ? 3600000 : 30000,
};

3. Never Store Sensitive Data

Remote Config values are accessible through browser DevTools. Use it for:

✅ Feature flags
✅ UI configurations
✅ Content variations
❌ API keys
❌ Authentication tokens
❌ Private credentials

4. Version Your Parameters

Consider including version information in parameter names for complex rollouts:

feature_checkout_v2_enabled: boolean
feature_checkout_v3_enabled: boolean

This allows you to manage multiple versions simultaneously during transitions.

5. Monitor and Measure

Integrate with Firebase Analytics to track the impact of configuration changes:

import { logEvent } from "firebase/analytics";

// Track which checkout version users see
logEvent(analytics, 'checkout_version_shown', {
  version: values.enable_new_checkout ? 'v2' : 'v1'
});

6. Implement Gradual Rollouts

Start with small percentages and gradually increase:

Day 1: 1% of users
Day 3: 5% of users
Day 7: 25% of users
Day 14: 100% of users

Monitor error rates and user metrics at each stage before proceeding.

Advanced Use Cases

User Segmentation

Combine multiple conditions for precise targeting:

Show premium features only to paid subscribers
Display region-specific content based on locale
Enable beta features for users with specific app versions

A/B Testing Integration

Firebase Remote Config integrates seamlessly with Firebase A/B Testing, allowing you to:

Test multiple parameter variations
Measure conversion rates
Automatically roll out winning variants

Dynamic Theming

Store theme configurations remotely:

theme_primary_color: "#3b82f6"
theme_secondary_color: "#10b981"
theme_mode: "light" | "dark"

Conclusion

Firebase Remote Config provides a robust solution for decoupling application configuration from deployment cycles. By implementing feature flags, targeted rollouts, and dynamic content delivery, you gain the flexibility to respond quickly to business requirements without the overhead of continuous redeployment.

Start with simple use cases like dynamic banners and feature toggles, then expand to more sophisticated implementations as your confidence grows. If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.to.

Implement the useStateWithReset custom hook in React

Debajit Mallick — Wed, 27 Aug 2025 06:30:52 +0000

Introduction

In React, useState is a go-to hook for managing component state. But often, especially in forms or interactive UIs, we wish there was a built-in reset function that resets the state back to its original value—just like hitting a "Reset" button.

That’s where a custom hook like useStateWithReset becomes useful.

In this blog, we'll walk through the step-by-step creation of a useStateWithReset hook and see how to use it in a real-world scenario.

Question

Create a custom hook useStateWithReset that:

Takes an initial value (or lazy initializer function) just like useState
Returns the same values as useState, plus a third value: a reset() function
This reset() resets the state back to its original value

useStateWithReset Hook

import { useCallback, useMemo, useState } from 'react';

const useStateWithReset = (initialStateOrInitializer) => {
  const initialState = useMemo(() => {
    if (
      typeof initialStateOrInitializer === 'function' &&
      initialStateOrInitializer.length === 0
    ) {
      return initialStateOrInitializer();
    }
    return initialStateOrInitializer;
  }, []);

  const [value, setValue] = useState(initialState);

  const reset = useCallback(() => {
    setValue(initialState);
  }, [initialState]);

  return [value, setValue, reset];
};

export default useStateWithReset;

Now, let's understand the code step by step:

1. Accepting Initial State or Initializer Function:

const useStateWithReset = (initialStateOrInitializer) => {

Just like useState, this hook supports both:

A primitive or object value: useStateWithReset(0)
A lazy initializer function: useStateWithReset(() => expensiveInit())

2. Memoizing the Initial Value:

const initialState = useMemo(() => {
  if (
    typeof initialStateOrInitializer === 'function' &&
    initialStateOrInitializer.length === 0
  ) {
    return initialStateOrInitializer();
  }
  return initialStateOrInitializer;
}, []);

Why this step?

We want to evaluate initializer function once, not on every re-render.
initialStateOrInitializer.length === 0 checks that the function takes no arguments (like a () => value), mimicking how React handles lazy initial state.
useMemo ensures the initial value is computed once and preserved.

3. Using useState with the Computed Initial State

const [value, setValue] = useState(initialState);

Simple usage of useState, but with the precomputed and memoized initialState.

4. Creating the Reset Function with useCallback:

const reset = useCallback(() => {
  setValue(initialState);
}, [initialState]);

We create a memoized function that resets state to the original value.
useCallback ensures the function reference stays stable unless initialState changes.

5. Returning Value, Setter, and Reset:

return [value, setValue, reset];

This mirrors the API of useState, but with a third item: reset.

Example Usage

import React from 'react';
import useStateWithReset from './useStateWithReset';

const ProfileForm = () => {
  const [name, setName, resetName] = useStateWithReset('John Doe');

  return (
    <div>
      <h2>Edit Profile</h2>
      <input
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
      />
      <button onClick={resetName}>Reset</button>
    </div>
  );
};

export default ProfileForm;

You can update the name by typing. Click “Reset” and it will go back to "John Doe"—just like magic!

When to Use useStateWithReset

Forms that need a clear or reset button
Repeating workflows that need to restore initial state
Complex UI interactions where initial state must be preserved
Interview questions around custom hooks and state abstraction

Conclusion

The useStateWithReset hook is a powerful yet simple abstraction that extends the basic useState with an extra reset() function. If you liked this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.

Implement the useCopy custom hook in React

Debajit Mallick — Thu, 21 Aug 2025 04:51:11 +0000

Introduction

Copying text to the clipboard is a common feature in web apps. If you're letting your users copy coupon codes, share links, or export values with a single click. Instead of writing this logic repeatedly, why not encapsulate it in a clean and reusable custom React hook?

In this blog, we'll build a useCopy hook from scratch, understand each part of the implementation, and see a real-world example to use it in your UI.

What Is the Clipboard API?

Modern browsers offer a Clipboard API under the navigator.clipboard object, which allows us to:

Programmatically read or write text
Interact with the system clipboard securely
Do it asynchronously

But since not all environments support it (especially older browsers or HTTP connections), we should handle fallbacks or at least warn the user.

useCopy Hook

import { useState } from 'react';

const useCopy = () => {
  const [copiedText, setCopiedText] = useState();

  const copy = async (text) => {
    if (!navigator?.clipboard) {
      console.warn('Clipboard not supported');
      return false;
    }

    try {
      await navigator.clipboard.writeText(text);
      setCopiedText(text);
    } catch (error) {
      console.error(`Failed to copy text ${text} `, error);
      setCopiedText(null);
    }
  };

  return { copiedText, copy };
};

export default useCopy;

Now, let's understand the code step by step:

State Management

const [copiedText, setCopiedText] = useState();

We store the latest copied text so the component can display feedback (like a tooltip or success message).

Clipboard API Check

if (!navigator?.clipboard) {
  console.warn('Clipboard not supported');
  return false;
}

navigator is a global browser object that contains info about the browser and OS.
navigator.clipboard is where the Clipboard API lives.
We use optional chaining (?.) to safely check if it exists.

Writing to the Clipboard

await navigator.clipboard.writeText(text);
setCopiedText(text);

This performs the actual copy-to-clipboard action. If it succeeds, we store the text. If it fails, we catch and log the error:

} catch (error) {
  console.error(`Failed to copy text ${text} `, error);
  setCopiedText(null);
}

Example Usage

Here’s how you can use useCopy in a functional React component:

import React from 'react';
import useCopy from './useCopy';

const CopyExample = () => {
  const { copiedText, copy } = useCopy();
  const textToCopy = 'https://dev.to/debajit13/';

  return (
    <div>
      <p>Click below to copy the link:</p>
      <button onClick={() => copy(textToCopy)}>Copy Link</button>
      {copiedText === textToCopy && <span>Text Copied Successfully!</span>}
    </div>
  );
};

export default CopyExample;

When you click the button, the link is copied to your clipboard. A success message is shown once copied.

Bonus: Deep dive into navigator

navigator is part of the Browser Object Model (BOM) in JavaScript. It provides useful properties and methods such as:

navigator.userAgent — info about the browser
navigator.onLine — check if the user is online
navigator.clipboard — read/write access to the system clipboard

Conclusion

The useCopy hook is a small but powerful utility that makes your app feel modern, interactive, and user-friendly. It abstracts away messy clipboard logic and gives you a clean, declarative interface for one of the most common UX features. If you liked this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.

Implement the useDebounce custom hook in React

Debajit Mallick — Sat, 16 Aug 2025 12:41:02 +0000

Introduction

In modern web apps, debouncing is a powerful feature—especially when dealing with frequent user input, such as search bars, form validation, or filtering data.

If you’re preparing for React interviews, one common question you'll face is:

"How do you implement a useDebounce hook in React?"

In this blog, we’ll build a useDebounce custom hook from scratch, explore why it's useful, and show how you can integrate it into real-world projects.

What is Debouncing?

Debouncing ensures that a function is only executed after a certain delay and only if no new event has occurred in the meantime.

It’s especially useful for:

Search input fields
API calls during typing

The useDebounce Hook

Let’s dive right into the code:

import { useEffect, useState } from 'react';

const useDebounce = (value, delay) => {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    let timerId = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(timerId);
    };
  }, [value, delay]);

  return debouncedValue;
};

export default useDebounce;

Now, let's understand the code step by step:

1. Local State

const [debouncedValue, setDebouncedValue] = useState(value);

We store a version of the value that will only be updated after the delay has passed.

2. Effect Hook

useEffect(() => {
  let timerId = setTimeout(() => {
    setDebouncedValue(value);
  }, delay);

  return () => {
    clearTimeout(timerId);
  };
}, [value, delay]);

Every time the value or delay changes, we start a new timer.
If a new change comes in before the delay ends, we clear the previous timer—this is the key to debouncing!
Only after the user stops typing (or stops triggering changes) for the full delay, we update the debouncedValue.

3. Returning the Debounced Output

return debouncedValue;

This allows the component to use the stable, debounced value. It is great for delaying expensive operations like API calls.

Example Usage

Let’s see how we can use this hook in a search input component:

import React, { useState, useEffect } from 'react';
import useDebounce from './useDebounce';

const SearchBox = () => {
  const [query, setQuery] = useState('');
  const debouncedQuery = useDebounce(query, 500);

  useEffect(() => {
    if (debouncedQuery) {
      // Simulate API call
      console.log('Searching for:', debouncedQuery);
    }
  }, [debouncedQuery]);

  return (
    <input
      type="text"
      placeholder="Search users..."
      value={query}
      onChange={(e) => setQuery(e.target.value)}
    />
  );
};

export default SearchBox;

The log message only appears 500ms after the user stops typing.
Prevents unnecessary API calls during rapid keystrokes.

Conclusion

The useDebounce custom hook is an elegant solution to a common problem, and it’s a great way to showcase your React skills in interviews and in production code. Whether you’re optimizing a search bar or building a responsive UI, debouncing will make your app feel smoother and more efficient. If you liked this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.

Implement the useFetch custom hook in React

Debajit Mallick — Fri, 15 Aug 2025 13:22:52 +0000

Introduction

React has revolutionised the way we build web apps with its component-based architecture and declarative style. As your projects grow, it’s important to abstract logic into reusable, composable pieces—and that’s where custom hooks shine.

There are numerous questions about React hooks in interviews. One of the most frequently asked interview questions for React developers is:
“How do you create a custom hook for fetching data?”

In this blog, we’ll dive into building a useFetch hook from scratch and understand its benefits.

What Are Custom Hooks?

Custom hooks in React let you reuse logic across components. They start with use and allow you to encapsulate behaviour using built-in hooks like useState, useEffect, etc.

useFetch Hook

Let’s jump into the implementation:

import { useEffect, useState } from 'react';

const useFetch = (url) => {
  const [data, setData] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    const controller = new AbortController();
    const signal = controller.signal;

    const fetchData = async () => {
      try {
        const response = await fetch(url, { signal });
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const result = await response.json();
        setData(result);
      } catch (error) {
        if (error.name === 'AbortError') {
          console.log('Fetch aborted');
        } else {
          setError(error);
        }
      } finally {
        setLoading(false);
      }
    };

    fetchData();

    return () => {
      controller.abort();
    };
  }, [url]);

  return { loading, data, error };
};

export default useFetch;

Now, let's understand the code step by step:

1. State Management

We declare three pieces of state using useState:

data: The API response data
error: Any error that occurs during the fetch call
loading: A boolean to represent the loading state

2. Effect Hook for Fetching

useEffect is triggered when the url changes. This ensures our hook refetches data when needed.

3. AbortController

This is one of the interesting things. We use AbortController to cancel the fetch request if the component unmounts. When an API call is in progress, if the user unmounts the component, the AbortController will cancel the API call. It helps to avoid memory leaks and unnecessary state updates.

const controller = new AbortController();
const signal = controller.signal;

The signal is passed to the fetch API. In case the component unmounts, the fetch is aborted cleanly:

return () => {
  controller.abort();
};

4. Error Handling

We check if the fetch response is OK; otherwise, we throw an error:

if (!response.ok) {
  throw new Error(`HTTP error! status: ${response.status}`);
}

If the error is due to an abort, we skip setting the state. For other errors, we store them in the error.

5. Return Values

The hook returns { loading, data, error }, making it easy to consume in any component.

Example Usage

Here’s how you can use the useFetch hook in a component:

import React from 'react';
import useFetch from './useFetch';

const UsersList = () => {
  const { loading, data, error } = useFetch('https://jsonplaceholder.typicode.com/users');

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return (
    <ul>
      {data.map((user) => (
        <li key={user.id}>{user.name}</li>
      ))}
    </ul>
  );
};

export default UsersList;

Conclusion

The useFetch hook is a simple yet powerful abstraction that encapsulates async behaviour and makes our components cleaner and more focused. Whether you’re preparing for interviews or building robust frontends, knowing how to craft such hooks is essential. If you liked this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.

From Mobile to Browser: A Guide to React Native for Web

Debajit Mallick — Fri, 04 Jul 2025 15:28:39 +0000

Introduction

React Native has a quote: "write once, run everywhere." But honestly, I always felt like something was missing. Sure, we could target iOS and Android, but what about the web? That's where millions of users spend their time every day. Then I stumbled upon React Native for Web, and let me tell you – it was a game-changer. Suddenly, that same codebase I'd been pouring my heart into for mobile apps could reach web users too. If you already have a react-native app then you can convert your app code easily to web with minimal changes.

What Exactly is React Native for Web?

Think of React Native for Web as your friendly translator. It takes all those React Native components you know and love – View, Text, Image – and magically transforms them into their web equivalents. Your View becomes a div, your Text becomes a span or p element. Specifically, the span element is used for text that is part of a larger text flow (inline), while the p element is used for standalone paragraphs. , and your Image becomes an img tag. It's like having a universal language for UI development.

The best part? If you're already using Expo, web support is baked right in.

Advantages of using React-Native for web:

Look, I've been around the block. I've built separate React apps for web and React Native apps for mobile. I've felt the pain of duplicating logic, styling components twice, and keeping everything in sync. Here's why React Native for Web changed everything for me:

Zero Configuration Stress: Expo handles all the heavy lifting. I can focus on building features instead of fighting build tools.
My Code Gets Reused: Not just the business logic – the entire UI components work across platforms. That custom button I spent hours perfecting? It looks and works the same everywhere.
SEO That Actually Works: With App Router, I get proper URLs and SEO-friendly routing.
Time is Money: Instead of juggling multiple codebases, I can ship features faster as the codebase is shared.

Getting Started

First, let's create our project. To create the project, I am using Expo. Here are the commands to create the basic boilerplate using Expo:

npx create-expo-app my-app
cd my-app

Now, fire up the development server:

npx expo start

Press w in your terminal, and watch your React Native app open in your browser.

Explore App Router

Expo’s App Router is like Next.js for React Native – filesystem-based routing that works out of the box. Just create folders and files, and Expo handles the routes automatically.

In the app/ directory (this already exists in new Expo projects):

app/
├── index.tsx // maps to ‘/’
├── about/
│ ├── index.tsx // maps to ‘/about’
│ └── _layout.tsx // optional shared layout for /about pages

Let’s create our home page:

// app/index.tsx
import { View, Text, Pressable } from 'react-native';
import { Link } from 'expo-router';

export default function Home() {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text style={{ fontSize: 24 }}>Welcome to React Native Web with Expo!</Text>
      <Link href="/about">
        <Pressable>
          <Text style={{ color: 'blue', marginTop: 20 }}>Go to About Page</Text>
        </Pressable>
      </Link>
    </View>
  );
}

About page:

// app/about/index.tsx
import { View, Text, Pressable } from 'react-native';
import { Link } from 'expo-router';

export default function About() {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <Text style={{ fontSize: 24 }}>This is the About Page</Text>
      <Link href="/">
        <Pressable>
          <Text style={{ color: 'blue', marginTop: 20 }}>Back to Home</Text>
        </Pressable>
      </Link>
    </View>
  );
}

✅ (Optional) Add _layout.tsx for nested layouts if you want shared headers, footers, or other UI elements across pages.

✅ Run your project on web:

npx expo start

Press w to open in your browser. Navigate to /about and watch the webapp to render.

Handling Flatlist

FlatList on web can be tricky, but when you get it right, it's amazing:

import React from 'react';
import { FlatList, Text, View } from 'react-native';

const DATA = [
  { id: '1', title: 'First item' },
  { id: '2', title: 'Second item' },
  { id: '3', title: 'Third item' },
];

export default function MyList() {
  const renderItem = ({ item }) => (
    <View style={{ 
      padding: 10, 
      borderBottomWidth: 1, 
      borderColor: '#ccc' 
    }}>
      <Text>{item.title}</Text>
    </View>
  );

  return (
    <FlatList
      data={DATA}
      renderItem={renderItem}
      keyExtractor={item => item.id}
    />
  );
}

Handling API Calls

For any real world webapp we need to handle API calls. To handle API calls in react-native and render elements in UI:

import React, { useEffect, useState } from 'react';
import { View, Text, ActivityIndicator } from 'react-native';

export default function DataFetcher() {
  const [data, setData] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch('https://jsonplaceholder.typicode.com/posts')
      .then(response => response.json())
      .then(json => {
        setData(json);
        setLoading(false);
      })
      .catch(error => {
        console.error('Something went wrong! Error: ', error);
        setLoading(false);
      });
  }, []);

  if (loading) {
    return <ActivityIndicator size="large" color="#0000ff" />;
  }

  return (
    <View>
      {data.slice(0, 5).map(item => (
        <Text key={item.id}>{item.title}</Text>
      ))}
    </View>
  );
}

Handling Responsive Design

Here's how we can handle responsive design for web for different device width:

import { View, Text, useWindowDimensions } from 'react-native';

export default function ResponsiveComponent() {
  const { width } = useWindowDimensions();

  // to check the device screen is desktop or mobile
  const isDesktop = width > 600;

  return (
    <View style={{
      backgroundColor: isDesktop ? 'lightblue' : 'lightgrey',
      padding: 20,
    }}>
      <Text style={{ 
        fontSize: isDesktop ? 24 : 16,
        textAlign: isDesktop ? 'left' : 'center'
      }}>
        This text adapts to your screen size
      </Text>
    </View>
  );
}

Handling code specific for web:

To handle the code specific for web, we can use the Platform API from React Native. From the OS, we can do a check if it's a web browser or not. Here is an example code:

import { Platform, View, Text } from 'react-native';

export default function RenderOnWeb() {
  if (Platform.OS === 'web') {
    return (
      <View style={{ padding: 20, backgroundColor: '#f0f0f0' }}>
        <Text style={{ fontSize: 18 }}>This is rendered only on Web</Text>
      </View>
    );
  }

  // Optionally render something else for mobile
  return (
    <View style={{ padding: 20, backgroundColor: '#e0ffe0' }}>
      <Text style={{ fontSize: 18 }}>This is rendered on Mobile 📱</Text>
    </View>
  );
}

Conclusion

React Native for Web helps us to convert our existing mobile app code to web without creating a new project. It's about building once and deploying everywhere, without sacrificing quality or performance. At the end of the day no library or framework is good or bad. It's all about the use case and tradeoffs. Start with something simple – maybe just a landing page or a basic dashboard, and then move in to some more complex apps. If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.to.

Testing Your React App with Cypress

Debajit Mallick — Tue, 01 Jul 2025 05:56:01 +0000

Introduction

In this blog, I will walk you through setting up a bulletproof testing setup using React + Cypress. We'll cover everything from the basics to testing those tricky async API calls that always seem to break at the worst possible moment.

Getting Started

Firstly, we are going to create a React app using Vite. As CRA is deprecated, Vite is the standard way for creating a React project. Open your terminal and run the following commands:

npm create vite@latest my-react-app -- --template react-ts
cd my-react-app
npm install

To start the project on localhost:

npm run dev

Head over to http://localhost:5173 and you should see your React app.

Cypress Setup

Here's where things get interesting. Cypress isn't just another testing framework—it's like having a tester that clicks through your app exactly like a real user would.

Let's get Cypress installed:

npm install --save-dev cypress

Now run the following command:

npx cypress open

This will create a cypress/ folder and some initial files. Don't worry about all the folders that appear. It's all for the setup.

Cypress Configuration

Time for a little configuration. Create a cypress.config.ts file in your project root:

import { defineConfig } from 'cypress'

export default defineConfig({
  e2e: {
    baseUrl: 'http://localhost:5173',
    supportFile: 'cypress/support/e2e.ts',
    specPattern: 'cypress/e2e/**/*.cy.{js,ts,jsx,tsx}',
  },
})

Here's a pro tip that'll save you some headaches: install start-server-and-test. This command will start your dev server and run tests automatically:

npm install --save-dev start-server-and-test

Update your package.json scripts:

"scripts": {
  "dev": "vite",
  "test:e2e": "start-server-and-test dev http://localhost:5173 'cypress open'"
}

Now you can run npm run test:e2e and everything just works.

First Test

Let's write a test that actually does something. Create cypress/e2e/homepage.cy.ts:

describe('Homepage', () => {
  it('should load the homepage and display welcome text', () => {
    cy.visit('/')
    cy.contains('Vite + React').should('be.visible')
  })
})

Run your tests with:

npm run test:e2e

If you see that test pass, congratulations! You just wrote your first E2E test. It might seem simple, but you've just verified that your app actually loads and displays content.

Testing Real User Behaviour

Static content is nice, but let's test some actual interactions. Remember that counter button in the default Vite template? Let's make sure it actually counts:

describe('Counter', () => {
  it('should increment the count when clicked', () => {
    cy.visit('/')
    cy.get('button').contains('count is').click()
    cy.get('button').should('contain.text', 'count is 1')
  })
})

This test clicks the button and verifies that the count goes up.

Testing Async Code and APIs

Most real-world apps don't just display static content—they fetch data from APIs, and that's where bugs are.

Let's say you have a component that fetches users when it mounts:

// ExampleComponent.tsx
import { useEffect, useState } from 'react'

export function ExampleComponent() {
  const [users, setUsers] = useState<string[]>([])
  const [loading, setLoading] = useState(true)

  useEffect(() => {
    fetch('/api/users')
      .then(res => res.json())
      .then(data => {
        setUsers(data)
        setLoading(false)
      })
      .catch(() => setLoading(false))
  }, [])

  if (loading) return <div>Loading...</div>

  return (
    <ul data-cy="user-list">
      {users.map(user => (
        <li key={user} data-cy="user-item">{user}</li>
      ))}
    </ul>
  )
}

Now here's the interesting part—Cypress can intercept and mock API calls:

describe('User List', () => {
  it('should display users from the API', () => {
    // Mock the API response
    cy.intercept('GET', '/api/users', {
      statusCode: 200,
      body: ['John', 'Jane', 'Robert']
    }).as('getUsers')

    cy.visit('/')

    // Wait for the API call to complete
    cy.wait('@getUsers')

    // Verify the users are displayed
    cy.get('[data-cy="user-list"]').should('be.visible')
    cy.get('[data-cy="user-item"]').should('have.length', 3)
    cy.contains('Alice').should('be.visible')
  })

  it('should handle API failures gracefully', () => {
    cy.intercept('GET', '/api/users', {
      statusCode: 500,
      body: { error: 'Server error' }
    }).as('getUsersError')

    cy.visit('/')
    cy.wait('@getUsersError')

    // Test your error handling
    cy.contains('Something went wrong').should('be.visible')
  })
})

The cy.intercept() method is amazing. You can test both success and failure scenarios without needing a real API.

Best Practices That Actually Matter

Use data-cy attributes religiously.. CSS classes change, text content gets translated, but data-cy="submit-button" stays constant:

// Good
cy.get('[data-cy="submit-button"]').click()

// Fragile
cy.get('.btn-primary').click()
cy.contains('Submit').click()

Reset your state before each test. Use beforeEach() to clear out any leftover state:

beforeEach(() => {
  cy.clearLocalStorage()
  cy.clearCookies()
  // Reset any global state your app might have
})

Think like a user, not a developer. Test the journey, not the implementation. Don't test that a function was called—test that the user sees what they expect.

Mock everything you don't control. Real APIs are slow, unreliable, and might not have the data you need for testing. Mock them for testing.

Conclusion

Testing feels daunting, we all know, but here's the thing: every minute you spend writing tests now saves you hours of debugging later. And with Cypress, those tests actually run in a real browser, so you can trust that they're testing what your users will experience. If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.to.

Exploring Firebase Storage with React

Debajit Mallick — Fri, 23 May 2025 04:59:42 +0000

Introduction

Let's be honest—handling files in web apps can be a pain. Whether it's your users' vacation selfies or important documents, you need somewhere reliable to store them. Firebase Storage has been one of the great solution. In this blog, we will explore Firebase Storage with React. Why you should consider Firebase Storage? Let's understand that:

It's surprisingly easy to set up (even for someone who gets nervous around backend stuff)
The upload progress tracking is a game-changer for user experience
It plays nicely with React and TypeScript

Getting Started

First things first, head over to the Firebase Console. If you haven't already, create a project. Once inside, enable Storage under the Build section—it's just a few clicks.

Next, let's add Firebase to our project:

npm install firebase

Then create a firebase.ts file with your configuration:

import { initializeApp } from "firebase/app";
import { getStorage } from "firebase/storage";

const firebaseConfig = {
  apiKey: "YOUR_API_KEY",
  authDomain: "YOUR_AUTH_DOMAIN",
  projectId: "YOUR_PROJECT_ID",
  storageBucket: "YOUR_STORAGE_BUCKET.appspot.com",
  messagingSenderId: "YOUR_SENDER_ID",
  appId: "YOUR_APP_ID",
};

const app = initializeApp(firebaseConfig);

export const storage = getStorage(app);

Don't worry about memorizing this—you will always copy-paste it from the Firebase console anyway!

Single File Uploads

Let's create a component that lets users upload a single file. We'll also show them a progress bar so they're not left wondering if their file disappeared into the digital void.

Here's a component I built that handles a single file upload:

import React, { useState, ChangeEvent } from 'react';
import { storage } from '../firebase';
import { ref, uploadBytesResumable, getDownloadURL, deleteObject } from 'firebase/storage';

const FileUpload: React.FC = () => {
  const [file, setFile] = useState<File | null>(null);
  const [progress, setProgress] = useState<number>(0);
  const [downloadURL, setDownloadURL] = useState<string>('');

  const handleFileChange = (e: ChangeEvent<HTMLInputElement>) => {
    if (e.target.files && e.target.files[0]) {
      setFile(e.target.files[0]);
    }
  };

  const handleUpload = () => {
    if (!file) return;

    const storageRef = ref(storage, `uploads/${file.name}`);
    const uploadTask = uploadBytesResumable(storageRef, file);

    uploadTask.on(
      'state_changed',
      (snapshot) => {
        const percent = (snapshot.bytesTransferred / snapshot.totalBytes) * 100;
        setProgress(Math.round(percent));
      },
      (error) => console.error('Upload failed', error),
      async () => {
        const url = await getDownloadURL(uploadTask.snapshot.ref);
        setDownloadURL(url);
      }
    );
  };

  const handleDelete = async () => {
    if (!file) return;
    const storageRef = ref(storage, `uploads/${file.name}`);
    try {
      await deleteObject(storageRef);
      setDownloadURL('');
      setProgress(0);
      alert('File deleted successfully!');
    } catch (error) {
      console.error('Delete failed', error);
    }
  };

  return (
    <div>
      <h2>File Upload</h2>
      <input type="file" onChange={handleFileChange} />
      <button onClick={handleUpload}>Upload</button>
      {progress > 0 && <p>Progress: {progress}%</p>}
      {downloadURL && (
        <div>
          <p>File URL: <a href={downloadURL} target="_blank" rel="noreferrer">{downloadURL}</a></p>
          <button onClick={handleDelete}>Delete File</button>
        </div>
      )}
    </div>
  );
};

export default FileUpload;

Multiple File Uploads

In real-world apps, users often need to upload multiple files at once. Maybe it's a bunch of photos from their weekend trip or several documents for an application. Here's how I handled that:

import React, { useState, ChangeEvent } from 'react';
import { storage } from '../firebase';
import { ref, uploadBytesResumable, getDownloadURL } from 'firebase/storage';

interface UploadedFile {
  name: string;
  url: string;
}

const MultiFileUpload: React.FC = () => {
  const [files, setFiles] = useState<File[]>([]);
  const [uploadProgress, setUploadProgress] = useState<Record<string, number>>({});
  const [downloadLinks, setDownloadLinks] = useState<UploadedFile[]>([]);

  const handleFilesChange = (e: ChangeEvent<HTMLInputElement>) => {
    if (e.target.files) {
      setFiles(Array.from(e.target.files));
    }
  };

  const handleUpload = () => {
    files.forEach((file) => {
      const storageRef = ref(storage, `uploads/${file.name}`);
      const uploadTask = uploadBytesResumable(storageRef, file);

      uploadTask.on(
        'state_changed',
        (snapshot) => {
          const percent = (snapshot.bytesTransferred / snapshot.totalBytes) * 100;
          setUploadProgress((prev) => ({ ...prev, [file.name]: Math.round(percent) }));
        },
        (error) => console.error('Upload failed', error),
        async () => {
          const url = await getDownloadURL(uploadTask.snapshot.ref);
          setDownloadLinks((prev) => [...prev, { name: file.name, url }]);
        }
      );
    });
  };

  return (
    <div>
      <h2>File Upload</h2>
      <input type="file" multiple onChange={handleFilesChange} />
      <button onClick={handleUpload}>Upload All</button>

      {files.map((file) => (
        <div key={file.name}>
          <p>{file.name}: {uploadProgress[file.name] || 0}%</p>
        </div>
      ))}

      {downloadLinks.map((file) => (
        <div key={file.name}>
          <p>Uploaded: <a href={file.url} target="_blank" rel="noreferrer">{file.name}</a></p>
        </div>
      ))}
    </div>
  );
};

export default MultiFileUpload;

Putting It All Together

Now let's combine these components in our main App:

import React from 'react';
import FileUpload from './components/FileUpload';
import MultiFileUpload from './components/MultiFileUpload';

const App: React.FC = () => {
  return (
    <div className="App">
      <FileUpload />
      <hr />
      <MultiFileUpload />
    </div>
  );
};

export default App;

Keeping Things Secure: Firebase Rules

Here's something I learned the hard way: Don't forget to set up security rules! Otherwise, anyone could potentially access or modify your files.

Here's a basic rule I use that allows only authenticated users to upload and download files:

service firebase.storage {
  match /b/{bucket}/o {
    match /uploads/{allPaths=**} {
      allow read, write: if request.auth != null;
    }
  }
}

You can configure this in Firebase Console → Storage → Rules.

Conclusion

This blog covers the first step to start your journey with Firebase storage. If you want to go a step ahead, you can implement the following:

Custom file validation for specific project needs
Better integration with Firebase Authentication for user-specific storage
Auto-generating thumbnails for image uploads
Implementing drag-and-drop uploads for a nicer UX If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.to.

Deep Dive into Server-sent Events (SSE)

Debajit Mallick — Mon, 28 Apr 2025 12:21:01 +0000

Introduction

We've all built those apps where fresh data matters—chat applications, notification systems, or those fancy dashboards that marketing loves. While WebSockets often steal the spotlight for real-time features, I've found that when you only need one-way updates (server → client), SSE can be your secret weapon. In this blog, I will discuss all about SSE and when to use it with the implementation details.

What is SSE?

Think of Server-Sent Events as a subscription service where your server pushes updates to browsers over a standard HTTP connection. Unlike WebSockets, which handle two-way communication, SSE is a one-way street—from server to client.

What makes SSE stand out?

It's built right into browsers (no extra libraries needed!)
It's lighter than WebSockets when you just need simple updates
It handles reconnections automatically if the connection drops
Perfect for news feeds, notifications, stock tickers, and similar features

How It Actually Works

The process is beautifully simple:

Your client (browser) opens a special connection to the server using the EventSource API
The server responds with a text/event-stream content type and keeps the connection open
Whenever there's new data, the server sends it along, and the client automatically receives it

It's like having a newspaper delivered to your door whenever there's breaking news—no need to keep checking the newsstand!

Let's Build Something Real

Let's create a simple example where the server sends timestamps to the client every few seconds.

Backend Server (Using Express)

const express = require('express');
const app = express();
const PORT = 8000;

app.get('/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  const sendEvent = () => {
    const data = `data: ${new Date().toLocaleTimeString()}\n\n`;
    res.write(data);
  };

  const intervalId = setInterval(sendEvent, 3000);

  req.on('close', () => {
    clearInterval(intervalId);
    res.end();
  });
});

app.listen(PORT, () => {
  console.log(`Server running at http://localhost:${PORT}`);
});

Frontend Client (Using React)

import { useEffect, useState } from "react";

const App = () => {
  const [messages, setMessages] = useState([]);

  useEffect(() => {
    const eventSource = new EventSource("http://localhost:8000/events");

    eventSource.onmessage = (event) => {
      setMessages(prevMessages => [...prevMessages, event.data]);
    };

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

    return () => {
      eventSource.close();
    };
  }, []);

  return (
    <div>
      <h1>Server-Sent Events Demo</h1>
      <ul>
        {messages.map((msg, index) => (
          <li key={index}>{msg}</li>
        ))}
      </ul>
    </div>
  );
};

export default App;

That's it! No polling, no complex setups—just real-time updates flowing into your React app.

Advantages and Disadvantages of Server Sent Events

Advantages of SSE

It's ridiculously easy to implement
Low overhead with just a plain HTTP connection
Built-in reconnection support
Perfect for those "notification bell" features and data feeds
No need for complex WebSocket servers or libraries

Disadvantages of SSE

It's one-way only (server to client)
Some older browsers might give you headaches (but modern ones work great)
Not ideal when you have many concurrent connections without HTTP/2
Doesn't handle binary data natively (text only)

Custom Event Types

Here's where SSE gets even more interesting. You can define custom event types and handle them separately in your app!

Sending Custom Events from Server

const sendCustomEvent = () => {
  res.write(`event: customEvent\n`);
  res.write(`data: ${JSON.stringify({ message: "This is a custom event!" })}\n\n`);
};

Handling Them in Client Side

useEffect(() => {
  const eventSource = new EventSource("http://localhost:8000/events");

  eventSource.addEventListener("customEvent", (event) => {
    const data = JSON.parse(event.data);
    console.log("Custom event received:", data.message);
  });

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

  return () => {
    eventSource.close();
  };
}, []);

Now you can have distinct event channels, similar to WebSockets but with much less setup!

Securing Your SSE Connection

"But what about security?" I hear you ask. The EventSource API doesn't let you set headers directly (like Authorization headers), but there are workarounds:

Option 1: Query String Tokens

const token = "your_jwt_token_here";
const eventSource = new EventSource(`http://localhost:5000/events?token=${token}`);

Then on your server:

app.get('/events', (req, res) => {
  const token = req.query.token;
  if (!isValidToken(token)) {
    res.status(401).end();
    return;
  }
  // Continue sending events...
});

Just remember to use HTTPS to protect those tokens!

Option 2: Cookie-Based Authentication

If your users are already authenticated via cookies, you're in luck—browsers automatically send cookies with EventSource requests.

When Should You Actually Use SSE?

SSE shines when:

You only need server-to-client updates
You want a simple solution without the WebSocket overhead
You're building notification systems, news feeds, score trackers, or IoT dashboards

But consider alternatives when:

You need two-way communication
Binary data transfer is a must-have

Conclusion

Server-Sent Events might be the unsung hero of real-time web development. They're simpler than WebSockets, built right into browsers, and perfect for many common use cases. Next time you reach for WebSockets just to send updates from your server, pause and ask yourself: "Could SSE handle this with less complexity?" More often than you might think, the answer will be yes! If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.to.

Short Polling vs Long Polling - A Comprehensive Guide for Developers

Debajit Mallick — Sun, 27 Apr 2025 14:08:13 +0000

Introduction

If you're building React applications, you'll eventually face this challenge: keeping your UI fresh with server updates without making your users manually reload the page. That's where polling techniques come in.

In this blog, I'll walk you through short polling and long polling in React—the two most common approaches that can transform your static app into a dynamic, real-time experience. Let's dive in and determine which is right for your next project!

What is Short Polling?

Short polling is like having an impatient child repeatedly asking "Are we there yet?" every few minutes during a road trip. Your app keeps checking with the server at regular intervals: "Got any updates for me? How about now? Now?"

Here's what it looks like in a React code:

import { useEffect, useState } from "react";
import axios from "axios";

const ShortPollingExample = () => {
  const [data, setData] = useState(null);

  useEffect(() => {
    const intervalId = setInterval(() => {
      axios.get("/api/messages")
        .then(response => {
          setData(response.data);
        })
        .catch(error => {
          console.error("Error fetching data:", error);
        });
    }, 5000); // poll every 5 seconds

    return () => clearInterval(intervalId); // cleanup on unmount
  }, []);

  return (
    <div>
      <h1>Messages</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default ShortPollingExample;

Advantages of Short Polling

Super straightforward to implement (just a simple interval!)
Works even with basic server setups that don't support fancy connection handling

Disadvantages of Short Polling

Can be wasteful—imagine checking for updates every 5 seconds when nothing's changed in hours
Your server might start sweating under load when lots of users are constantly pinging it

What is Long Polling?

Long polling is more like leaving your phone number with a store and saying, "Only call me when my order is ready." Instead of repeatedly checking, your app asks the server once, and the server just... waits until it actually has something new to tell you.

Let's see how we'd code this up in React:

import { useEffect, useState } from "react";
import axios from "axios";

const LongPollingExample = () => {
  const [data, setData] = useState(null);

  useEffect(() => {
    let isSubscribed = true;

    const poll = async () => {
      try {
        const response = await axios.get("/api/messages/longpoll", { timeout: 30000 }); // 30s timeout
        if (isSubscribed) {
          setData(response.data);
          poll(); // immediately start next poll
        }
      } catch (error) {
        if (isSubscribed) {
          console.error("Polling error or timeout:", error);
          setTimeout(poll, 5000); // retry after 5 seconds
        }
      }
    };

    poll();

    return () => { isSubscribed = false; };
  }, []);

  return (
    <div>
      <h1>Messages</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default LongPollingExample;

Advantages of Long Polling

Much kinder to your server when updates are infrequent
Feels snappier to users since updates come through almost immediately

Disadvantages of Long Polling

Your server needs to handle holding connections open (not all can do this well)
Requires a bit more care to set up correctly

So Which One Should You Choose?

Here's my practical guide to making the right choice:

If you're dealing with...	Go with...	Because...
Updates that happen every few minutes	Short Polling	Why complicate things when simple works?
A chat app where seconds matter	Long Polling	Your users will appreciate the near-instant updates
A legacy server that chokes on held connections	Short Polling	Work with what you've got!
A production app that needs to scale	Long Polling	Your server will thank you when user counts climb
Limited control over your backend	Short Polling	No special server-side logic needed

Friendly tip: If you're building something that truly needs lightning-fast updates (like a multiplayer game or collaborative editor), you might want to skip polling altogether and look into WebSockets or Server-Sent Events!

Common Mistakes to avoid

Polling too frequently

Be realistic about how "real-time" you actually need to be. Don't set the timeout to 300ms or 500ms if the data doesn't change that much frequently, as that can cause you extra server calls.
Forgetting error handling

Networks fail. Servers time out. Always include proper error handling and retry logic, or your polling will silently stop working when things go wrong.
Creating zombie processes

If you don't clean up your intervals or recursive polling functions when components unmount, they'll keep running in the background, wasting resources and potentially causing weird bugs. Always include cleanup functions in your useEffect!
Overloading servers with long polling

Some servers aren't built to handle hundreds or thousands of open connections. Make sure your infrastructure is up to the task before implementing long polling at scale.
Sticking with polling when better options exist

Sometimes I've gotten so deep into optimizing polling that I missed the forest for the trees. For truly real-time needs, WebSockets often provide a cleaner, more efficient solution.

Conclusion

Both polling techniques have their place in a developer's toolkit:

Short polling is your reliable workhorse for simple apps with infrequent updates
Long polling gives you that near real-time feel without completely reinventing your architecture

The best choice ultimately depends on your specific app needs, your server capabilities, and how much you value that real-time experience for your users. If you like this blog and want to learn more about Frontend Development and Software Engineering, you can follow me on Dev.to.