DEV Community: Chintan Soni

What Is a Vector Database? A Practical Deep Dive with Milvus

Chintan Soni — Fri, 09 Jan 2026 08:27:17 +0000

Vector databases have become a foundational component of modern AI systems — yet many developers struggle to understand why they exist and how they actually work.

In this video, I explain vector databases from first principles using real-world examples, focusing on clarity over buzzwords.

🔍 What You’ll Learn

Why traditional databases fail at semantic search
What embeddings are and why they are high-dimensional
How vector databases enable similarity search using ANN
How Milvus is architected for scale
Where vector databases fit in RAG and AI agent systems

🎥 Watch the video here:
👉 https://youtu.be/7hSDxxby66M

This video is part of my AI Foundations for Developers series — aimed at helping software engineers build solid mental models before jumping into frameworks.

📌 Coming next:
LangChain + Milvus, real documents, embeddings, hybrid search, and the foundation for AI agents.

If you’re building or planning to build AI-powered systems, this should help clear a lot of confusion.

Dense vs Sparse Vectors in AI — Explained for Developers

Chintan Soni — Tue, 06 Jan 2026 10:27:45 +0000

Dense vs Sparse Vectors in AI — Explained for Developers

When people talk about AI, embeddings, or semantic search, one concept quietly sits underneath almost everything:

Vectors.

And more specifically — dense vectors and sparse vectors.

I recently published Video #2 in my AI Foundations for Developers series, where I break this down with simple mental models and real-world examples, without diving into heavy math or ML theory.

🤔 Why this topic matters

If you’ve worked with:

Search engines
Embeddings
RAG systems
Vector databases
AI agents

…you’re already using dense or sparse vectors — even if you’ve never stopped to think about them.

Understanding the difference helps you answer questions like:

Why keyword search behaves differently from semantic search
Why embeddings are needed at all
Why modern AI systems often combine multiple approaches

📌 What this video covers

In this video, I explain:

What sparse vectors are
- How keyword-based search works
- Why systems like BM25 still matter
What dense vectors (embeddings) are
- How AI captures semantic meaning
- Why similar sentences cluster together
Real-world examples:
- “Find documents containing ERROR”
- vs
- “Find documents related to scaling cloud apps”
Why modern AI systems use both (hybrid search)

This is all explained from a developer’s perspective, focusing on intuition before tools.

▶️ Watch the video

🎥 Dense vs Sparse Vectors in AI | AI Foundations for Developers #2
👉 https://www.youtube.com/watch?v=F84s1pxwWGo

If you’re new to the series, I strongly recommend starting here:

🎥 What Are Vectors in AI? | AI Foundations for Developers #1
👉 https://www.youtube.com/watch?v=nZRiStzyRdo

🧱 About the series

AI Foundations for Developers is a video series where I focus on:

Building strong conceptual foundations
Avoiding hype and buzzwords
Explaining why things exist before showing how to code

Upcoming videos will cover:

Vector Databases (Milvus)
Hybrid Search
LangChain integrations
Hands-on demos

💬 Feedback welcome

I’m building this series in public, and feedback from fellow developers is extremely valuable.

If you watched the video:

What clicked immediately?
What felt confusing?
What should I cover next?

Thanks for reading 🙏

AI Foundations for Developers #1: What Are Vectors?

Chintan Soni — Sat, 03 Jan 2026 18:28:04 +0000

I’ve started a new video series called AI Foundations for Developers.

This series is aimed at software engineers who want to understand
how modern AI systems work from first principles — not just by
using frameworks or copying code.

Most AI content today jumps straight into tools like LangChain,
RAG pipelines, or AI agents. But without understanding the basics,
it’s hard to reason about design choices or debug issues in production.

In the first video of the series, I focus on a very fundamental question:

👉 What exactly is a vector, and why does AI represent information as vectors?

Here’s the video:

Over the next videos, I’ll be covering topics like:

Dense vs sparse vectors
Vector databases
Hybrid search
RAG systems
AI agents, memory, and protocols

If you’re a developer planning to build AI-powered features,
this series is meant to give you clarity and strong foundations.

Node.js Just Got Cooler: Imports and Package JSON Are Here to Save Your Day

Chintan Soni — Sun, 31 Aug 2025 11:20:18 +0000

If you’ve ever worked on a Node.js project, you’ve probably had this experience:

You’re writing an import, your brain says “easy-peasy”, but your editor whispers:

import service from "./../../../path/to/some/service.ts";

Suddenly, you’re not coding anymore. You’re Indiana Jones, lost in a temple of ../ and praying you don’t accidentally end up in the wrong directory.

Well, guess what? Node.js just threw us a lifeline. It’s called Imports via package.json, and it’s here to kick those ../../../ nightmares out of your life.

Before: The Jungle of Relative Paths

Back in the day, importing a file felt like playing “how many dots can you fit in a path?”

import service from "./../../../path/to/some/service.ts";

This is fine when your project is three files and a dream. But once it grows, you’re basically navigating with Google Maps set to “maze mode.”

After: The Alias Glow-Up

Here’s where the magic happens. Open up your package.json, sprinkle in a little configuration, and suddenly your imports are as smooth as butter.

"imports": {
  "#src/*": "./src/*"
}

That’s it. Seriously. Just one tiny block and your codebase is already breathing easier.

Usage: Imports, But Make Them Sexy

Now instead of typing a path that looks like a family tree gone wrong, you just do this:

import service from '#src/path/to/some/app.ts';

Clean. Simple. Understandable.
And if someone asks, “where’s that service coming from?” you don’t have to pull out a whiteboard and draw arrows through directories.

Why This Rocks

No More Dot Gymnastics – Your pinky finger finally gets a break from all those ../ key presses.
Readable Code – Your imports now explain themselves, instead of looking like cryptic treasure maps.
Future-Proof – This is modern Node.js flexing its muscles. You’re not just writing code, you’re writing fancy code.

Bonus: Pair It with Watch Mode

Check out my other piece: Node.js Just Got Cooler: Native TypeScript and Watch Mode Are Here to Party.

Node.js Just Got Cooler: Native TypeScript and Watch Mode Are Here to Party

Chintan Soni — Thu, 24 Apr 2025 18:12:15 +0000

Node.js just rolled up in sunglasses, holding a smoothie, and said, “Guess who supports TypeScript natively now?” That’s right—it’s leveling up in a big way. With built-in TypeScript support and a brand new watch mode, you can finally spend less time wrangling build tools and more time pretending to debug while secretly scrolling memes.

1. Native TypeScript Support: No Compiler? No Problem.
Remember the old days when you had to run tsc just to breathe near a TypeScript file? That’s history. Now, Node.js can run .ts files directly using the --experimental-transform flag. It’s like Node looked at your workflow and said, “You deserve better.”

Here’s the magic spell:

node --experimental-transform-types ./src/index.ts

No compiling. No bundling. No stress. Just type, run, repeat. Sure, it’s still marked as experimental, but so were electric cars—and look at them now.

2. Watch Mode: Because Manually Restarting is So 2022

If you’ve ever fixed a bug and then sighed dramatically while restarting your app… good news: Node.js watch mode has entered the chat. It watches your files and restarts the app automatically when something changes—like an attentive sidekick who actually pulls their weight.

Use it like this:

node --watch ./src/index.ts

Or specify what to watch:

node --watch-path=./src ./src/index.ts

Bonus Tip: Let package.json Do the Heavy Lifting

Add a script to your package.json like this:

"scripts": {
    "dev": "node --experimental-transform-types --watch-path=./src src/index.ts",
 },

Now you can just run:

npm run dev

No more typing out long commands like you’re programming in the Stone Age.

Wrapping Up: Node.js Just Became Your Cool Dev Friend
These new features aren’t just convenient—they’re a vibe. Native TypeScript support means fewer tools to manage. Watch mode means faster feedback loops. And your brain? It means less cluttered by “Did I forget to restart the server?”

So give it a whirl. Build something. Break something. Fix it. Repeat. Just remember to hydrate—and maybe check a meme or two along the way.

Understanding JavaScript's Event Loop: A Simple Cookie-Making Analogy 🍪

Chintan Soni — Fri, 11 Oct 2024 02:28:33 +0000

When learning JavaScript, the event loop is one of those tricky topics that can leave you scratching your head. But don’t worry! We’re going to explain it in a fun and simple way using a real-world example that even a 5-year-old would understand: making cookies! 🎉

Let’s imagine you’re in the kitchen and want to bake a batch of cookies. But here’s the catch—you can only do one thing at a time. This is just like JavaScript: it’s single-threaded, meaning it can only do one task at a time. Now, let’s see how the cookie-making process can help us understand how the event loop works.

The Call Stack = Your To-Do List

In the kitchen, you have a to-do list that tells you exactly what to do next. You follow it step-by-step:

Mix the dough.
Put the cookies in the oven.
Pour some milk.

You can only check off one task at a time. In JavaScript, this list is called the call stack. JavaScript runs code one step at a time, just like how you follow your cookie recipe.

Synchronous Tasks = Simple, Quick Tasks

Some tasks are super simple and take just a moment, like mixing dough or pouring milk. You don’t need to wait for anything, and you can do them immediately. This is like synchronous code in JavaScript—it runs from top to bottom, one step after another, without waiting.

For example:

console.log("Mix dough");
console.log("Pour milk");

This code runs just like mixing dough and pouring milk—you do one, then the next, and move on.

Asynchronous Tasks = Waiting Tasks

But what happens when you put the cookies in the oven? You can't just stand there doing nothing while they bake, right? That would be a waste of time! Instead, you set a timer for 10 minutes and move on to something else, like cleaning up or setting the table.

In JavaScript, this is like using something called setTimeout:

console.log("Put cookies in oven");

setTimeout(() => {
  console.log("Take cookies out of oven");
}, 10000);

console.log("Pour milk");

Here’s what happens:

First, you put the cookies in the oven.
Then, you set a timer (10,000 milliseconds = 10 minutes), but you don’t wait around! Instead, you move on to pouring milk.
When the timer goes off, you come back to take the cookies out of the oven.

This is what we call an asynchronous task in JavaScript—it doesn’t block other things from happening while it waits.

The Event Loop = Your Kitchen Helper

Now, while you’re busy pouring milk or setting the table, you have a kitchen helper (think of the event loop) who checks if your cookies are done. When the timer goes off, your helper reminds you: "Hey! The cookies are ready, time to take them out!"

In JavaScript, the event loop constantly checks if the call stack is clear. If it’s empty and there’s a waiting task (like the cookies being done), it moves that task to the front of the list so it can be completed.

Microtasks = Extra Important Jobs

Sometimes, you have something super important to do, like setting the table. Even if the cookies are almost done, you make sure to set the table first before taking the cookies out.

In JavaScript, these extra important tasks are called microtasks (usually created by things like promises). The event loop makes sure microtasks are done before the regular tasks (like taking the cookies out of the oven).

Here’s an example:

console.log("Mix dough");

setTimeout(() => {
  console.log("Take cookies out of oven");
}, 1000);

Promise.resolve().then(() => {
  console.log("Set table");
});

console.log("Pour milk");

Output:

Mix dough
Pour milk
Set table
Take cookies out of oven

Notice that "Set table" happens before the cookies come out, even though the setTimeout had a shorter delay! That’s because microtasks (like promises) are more urgent than regular tasks.

Wrapping Up

So, let’s bring it all together:

The Call Stack: Your to-do list in the kitchen—one task at a time.
Synchronous Tasks: Quick tasks like mixing dough or pouring milk, done immediately.
Asynchronous Tasks: Tasks that take time, like baking cookies, but you don’t wait—you set a timer and come back later.
The Event Loop: Your kitchen helper, making sure everything happens at the right time.
Microtasks: Super important tasks, like setting the table, that get done before the regular tasks.

By understanding the event loop using a cookie-making analogy, you can now see how JavaScript can do many things without ever getting stuck waiting!

Feel free to share this with anyone just starting out with JavaScript or anyone who loves cookies! 🍪

GitLab CI/CD Pipelines: Best Practices for Monorepos

Chintan Soni — Mon, 01 Jul 2024 02:42:52 +0000

Hello everyone! This article is for those who want to optimize their CI/CD pipelines using best practices in a monorepo setup.

To provide a clear walkthrough, let’s consider the following example:

Project structure:

Initial .gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build-a:
  stage: build
  script:
    - ...

test-a:
  stage: test
  script:
    - ...

deploy-a:
  stage: deploy
  script:
    - ...

build-b:
  stage: build
  script:
    - ...

test-b:
  stage: test
  script:
    - ...

deploy-b:
  stage: deploy
  script:
    - ...

build-c:
  stage: build
  script:
    - ...

test-c:
  stage: test
  script:
    - ...

deploy-c:
  stage: deploy
  script:
    - ...

The above configuration can quickly become unmanageable as the number of projects in the monorepo increases.

Why is this a problem?

Unnecessary Job Triggers: A single commit will trigger all jobs, regardless of the scope of the change. For instance, a commit made for changes in project-a will also trigger jobs for project-b and project-c, which is inefficient..

Reduced Readability: The CI/CD configuration becomes less readable and harder to maintain, especially with environment-specific jobs for dev, QA, UAT, and prod.
Increased Complexity: The setup becomes fragile, making it easy for anyone to inadvertently disrupt the pipeline. It requires more expertise to understand the scope, impact of changes, and dependencies of jobs.

How to solve this?

We will perform a series of steps to optimize the above pipeline. Let’s start.

Parent-Child Pipelines Architecture

With this approach, you will create a child pipeline, meaning a separate CI/CD file, only for that particular project. Move the relevant code into that project’s .gitlab-ci.yml. Below is the example for project-a, and similarly, it can be replicated for project-b and project-c:

project-a/.gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build-a:
  stage: build
  script:
    - ...

test-a:
  stage: test
  script:
    - ...

deploy-a:
  stage: deploy
  script:
    - ...

Then, link the child pipeline to the parent as below:

Root .gitlab-ci.yml:

stages:
  - triggers

trigger-project-a:
  stage: triggers
  trigger:
    include: project-a/.gitlab-ci.yml

trigger-project-b:
  stage: triggers
  trigger:
    include: project-b/.gitlab-ci.yml

trigger-project-c:
  stage: triggers
  trigger:
    include: project-c/.gitlab-ci.yml

With this simple refactor, the pipeline structure becomes more manageable:

Use rules: changes

To scope job execution to project-level changes, we can modify the pipeline to trigger jobs only when changes are made to specific projects.

Root .gitlab-ci.yml:

stages:
  - triggers

trigger-project-a:
  stage: triggers
  trigger:
    include: project-a/.gitlab-ci.yml
  rules:
    - changes:
      - project-a/**/*

trigger-project-b:
  stage: triggers
  trigger:
    include: project-b/.gitlab-ci.yml
  rules:
    - changes:
      - project-b/**/*

trigger-project-c:
  stage: triggers
  trigger:
    include: project-c/.gitlab-ci.yml
  rules:
    - changes:
      - project-c/**/*

If you see duplicate pipelines running (a commit to a branch triggering the pipeline twice), you can add the following rule:

trigger-project-a:
  rules:
    - if '$CI_PIPELINE_SOURCE == "merge_request_event"'
      when: never

Result:

Use YAML Anchors:

YAML anchors allow for the reuse of common configuration blocks, increasing reusability and reducing redundancy, especially when targeting multiple environments like dev, QA, staging, and prod.

project-a/.gitlab-ci.yml:

.base-build:
  stage: build
  image: node:22-alpine
  variables: ...
  before_script:
    - cd project-a

build-a-dev:
  extends: .base-build
  script:
    - export ENV = "dev"
    - // build steps for dev

build-a-qa:
  extends: .base-build
  script:
    - export ENV = "qa"
    - // build steps for qa

build-a-staging:
  extends: .base-build
  script:
    - export ENV = "staging"
    - // build steps for staging

build-a-prod:
  extends: .base-build
  script:
    - export ENV = "prod"
    - // build steps for prod

If you want to reuse only specific blocks of an anchor, you can use !reference as below:

build-a-dev:
  before_script: !reference [.base-build, before_script]
  script:
    - export ENV = "dev"
    - // build steps for dev

Using needs for Proper Job Chaining

We can create dependencies between jobs using needs, ensuring proper execution order.

build-a:
  stage: build
  script:
    - ...

test-a:
  stage: test
  needs: [build-a]
  script:
    - ...

deploy-a:
  stage: deploy
  needs: [test-a]
  script:
    - ...

Result:

Parallel Job Execution

To execute multiple jobs in parallel, for example, if there’s a check stage before the build stage, with a check-a job performing static code analysis, lint checks, etc., you can configure it as below:

stages:
  - check
  - build
  - ...

check-a:
  stage: check
  needs: []
  script:
    - ...

build-a:
  stage: build
  needs: []
  script:
    - ...

test-a:
  stage: build
  needs: [build-a]
  script:
    - ...

deploy-a:
  stage: build
  needs: [test-a]
  script:
    - ...

Result:

Source Code

You can find the source code here: https://gitlab.com/iChintanSoni/learning-ci-cd/

Conclusion

Optimizing CI/CD pipelines in a monorepo setup can significantly enhance the efficiency, readability, and maintainability of your projects. By adopting best practices such as using parent-child pipeline architecture, applying rules: changes, leveraging YAML anchors, and strategically utilizing needs for job chaining, you can create a more robust and scalable pipeline.

These techniques not only help in minimizing unnecessary job executions but also streamline the overall development workflow, making it easier to manage complex projects. By implementing these best practices, you ensure that your CI/CD processes are both efficient and adaptable to the evolving needs of your monorepo.

I hope this guide helps you in refining your GitLab CI/CD pipelines. If you have any questions or additional tips, feel free to share them in the comments below. Happy coding!

Streamlining Database Migrations: From Basic to Ultra Pro Max Approach

Chintan Soni — Fri, 22 Dec 2023 07:11:31 +0000

Introduction

In the ever-evolving landscape of database management, effective migration strategies can significantly impact project timelines and productivity. Having encountered the need for migrating a substantial amount of data from Dynamo DB to RDS PgSQL DB through the AppSync framework, I embarked on a journey to optimize the process. Through trial and error, I discovered methods that not only saved time but also enhanced data integrity.

The Challenge

Tasked with migrating 4.8L records from Dynamo DB to RDS PgSQL DB using AppSync, the initial approach involved fetching records recursively in batches of 1000 and then iterating over the array to insert them into PgSQL one by one. However, this proved to be time-consuming, taking approximately 1.5 hours for 15K records, means around 48 hours in total.

The Evolution

1. Batched Insert Operation
To improve efficiency, I introduced batching with a size of 1000 records. By collecting promises of insert operations into an array and executing them simultaneously using await Promise.all(), the time required was reduced to 36 hours. Though an improvement, the risk of data loss remained low, contingent on any constraint violations.

2. Bulk Insert Statement
The next level involved rewriting the insert statement to support bulk insert. This approach utilized only one database connection to insert all 1000 records at once, cutting the time down to 18 hours. However, the drawback was that if a single record failed insertion, the entire batch was skipped, posing a higher risk of data loss.

3. Ultra Pro Max Approach
Seeking the optimal solution, I implemented a unique strategy. By making calls to AppSync with pagination of 1000, I set up a local PgSQL database environment and synchronized all 4.8L records in just 1.5 hours. Subsequently, I exported the records into a CSV file using PGAdmin (warning: massive file size!) and imported it into the remote PgSQL instance. Surprisingly, the entire process, including data insertion, took less than 2 hours, showcasing the power of import/export features.

Conclusion:

The moral of this migration tale is clear: leveraging the import/export features of databases can drastically reduce migration times and mitigate the risk of data loss. The journey from a basic iterative approach to an Ultra Pro Max strategy highlights the importance of exploring various techniques to find the most efficient solution for your specific migration needs.

Arrow Functions vs. Regular Functions in JavaScript: A Comprehensive Guide

Chintan Soni — Wed, 22 Nov 2023 13:43:01 +0000

In the realm of JavaScript, two primary types of functions reign supreme: arrow functions and regular functions. While both serve the purpose of encapsulating reusable code blocks, they exhibit distinct characteristics that influence their usage and impact on the overall programming flow. Understanding these differences is crucial for JavaScript developers to make informed decisions and craft efficient, maintainable code.

Arrow Function Syntax: A Concise Approach

Arrow functions, also known as lambda expressions, are a concise and expressive way to define functions in JavaScript. Introduced in ES6 (ECMAScript 2015), they offer a shorter and more elegant syntax compared to regular functions.

// Regular function
function square(x) {
  return x * x;
}

// Arrow function
const square = (x) => x * x;

Regular Function Syntax: The Traditional Way

Regular functions, the classic approach to defining functions in JavaScript, have been around since the language's inception. They employ a more explicit syntax, encompassing the function keyword, parameters, and a block of code enclosed in curly braces.

function square(x) {
  return x * x;
}

Key Differences: Unveiling the Distinctions

Beyond their syntactical differences, arrow functions and regular functions diverge in several aspects, each with its own implications for code structure and behavior.

this Binding: Regular functions have their own this binding, which refers to the execution context of the function. This value can change depending on how the function is invoked. Arrow functions, on the other hand, inherit their this binding from the surrounding scope, ensuring consistent behaviour regardless of invocation.
Arguments Object: Regular functions have access to an arguments object, an array-like collection of the function's arguments. Arrow functions do not have this object directly available, but they can still access arguments using the rest parameter syntax (e.g., (...args) => {...}).
Constructor Usage: Regular functions can be used as constructors to create new objects. Arrow functions, however, are not constructors and cannot be invoked with the new keyword. This distinction stems from their different this binding behavior.
Conciseness and Readability: Arrow functions often lead to more concise and readable code, especially for simple functions. Their shorter syntax reduces boilerplate and improves code readability. However, for more complex functions with multiple statements, regular functions may provide better clarity.

Choosing the Right Tool for the Job

The decision between using an arrow function or a regular function depends on the specific context and requirements of the code. Arrow functions are well-suited for short, concise functions, especially within callbacks or nested functions. Regular functions, with their explicit syntax and constructor capabilities, remain valuable for more complex scenarios.

In summary, understanding the differences between arrow functions and regular functions empowers JavaScript developers to make informed choices, enhancing the maintainability and efficiency of their code. By carefully considering the syntax, this binding, arguments access, constructor usage, and conciseness trade-offs, developers can select the most appropriate function type for each task, ensuring clear, well-structured code that aligns with the specific needs of the project.

Creating Custom Hooks in React: Enhancing Component Reusability with Audio Playback

Chintan Soni — Wed, 15 Nov 2023 10:27:01 +0000

React's custom hooks are a powerful tool for encapsulating reusable logic and state management within functional components. They allow developers to extract common patterns into reusable functions, promoting code modularity and enhancing component maintainability. In this article, we'll explore the concept of custom hooks and delve into the creation of an audio hook for playing sounds in React applications.

Demystifying Custom Hooks

Custom hooks are essentially functions that start with the prefix "use" and encapsulate reusable logic for React components. They provide a structured approach to sharing common functionalities across components, enhancing code organization and maintainability.

Creating an Audio Hook for Sound Playback

To illustrate the power of custom hooks, let's create an audio hook for playing sounds in React applications. This hook will handle creating audio elements, managing playback behavior, and providing methods for playing, pausing, and resuming sounds.

import { useEffect, useRef } from "react";

const useAudio = (source: string) => {
  const { current: audio } = useRef(new Audio(source));
  audio.loop = true;

  useEffect(() => {
    return () => {
      audio.pause();
      audio.remove();
    };
  }, []);

  const play = () => {
    audio.play();
  };

  const pause = () => {
    audio.pause();
  };

  const isPlaying = () => {
    return !audio.paused;
  };

  return {
    isPlaying,
    play,
    pause,
  };
};

export default useAudio;

This custom hook takes an audio source URL as a parameter and returns an object containing three methods: play, pause, and resume. These methods can be used to control the playback of the sound.

Utilizing the Audio Hook in Components

To use the audio hook in a component, simply import it and call it with the desired audio source URL. For example:

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

const MyComponent = () => {
  const { play, pause, isPlaying } = useAudio('https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3');

  return (
    <div>
      Is Playing: {isPlaying}
      <button onClick={play}>Play Sound</button>
      <button onClick={pause}>Pause Sound</button>
    </div>
  );
};

export default MyComponent;

This component utilizes the useAudio hook to create an audio element for the specified sound source. It then provides buttons to control the playback using the play, pause, and resume methods provided by the hook.

Advantages of Custom Hooks

Custom hooks offer several advantages for building React applications:

Reusability: Custom hooks encapsulate reusable logic, allowing developers to share common functionalities across components.
Maintainability: By extracting logic into hooks, code becomes more organized and easier to maintain.
Encapsulation: Hooks promote encapsulation, keeping component logic separate and reducing code complexity.
State Management: Custom hooks can manage state efficiently, simplifying stateful logic within functional components.

Conclusion

Custom hooks are a valuable addition to React's arsenal, enabling developers to create reusable and maintainable components. By encapsulating logic into hooks, developers can enhance code organization, improve maintainability, and promote a more structured approach to building React applications.

Using React.memo to optimize your React applications

Chintan Soni — Fri, 10 Nov 2023 10:25:17 +0000

React.memo is a higher-order component (HOC) that can be used to wrap a component and memoize its rendered output. This means that React will only re-render the component if its props change. This can be useful for preventing unnecessary re-renders and improving the performance of your application.

When to use React.memo

React.memo should be used for components that:

Are pure components, meaning that they always return the same output for the same props and state.
Are frequently re-rendered, even when their props haven't changed.
Have expensive rendering logic.

How to use React.memo

To use React.memo, simply wrap your component in the React.memo() HOC. The React.memo() function takes a single argument, which is the component to be memoized. It returns a new memoized component, which can then be rendered in your application.

For example, the following code shows how to use React.memo to memoize a pure component:

import React, { memo } from "react";

const MyMemoizedComponent = memo(() => {
  return <div>Hello, world!</div>;
});

export default MyMemoizedComponent;

Now, whenever the MyMemoizedComponent component is rendered, React will check if the props have changed. If the props haven't changed, React will reuse the memoized output from the previous render. Otherwise, React will re-render the component and generate a new memoized output.

Example usage

The following example shows how to use React.memo to optimize a list of items that is frequently re-rendered:

import React, { useState, memo } from "react";

const MyList = memo(({ items }) => {
  return (
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.name}</li>
      ))}
    </ul>
  );
});

export default function App() {
  const [items, setItems] = useState([
    { id: 1, name: "Item 1" },
    { id: 2, name: "Item 2" },
    { id: 3, name: "Item 3" },
  ]);

  return (
    <div>
      <MyList items={items} />
    </div>
  );
}

In this example, the MyList component is memoized, so it will only re-render if the items prop changes. This can lead to significant performance improvements, especially if the MyList component is rendered frequently.

Tips for using React.memo

Here are a few tips for using React.memo effectively:

Only use React.memo for pure components.
Be careful when memoizing components that use props as callbacks. Make sure that the same callback function instance is provided between renders.
Use profiling to measure the performance gains of memoizing a component.

ReactJS + Docker : Getting started

Chintan Soni — Thu, 02 Nov 2023 11:33:44 +0000

ReactJS is a popular JavaScript library for building user interfaces. Docker is a containerization platform that allows you to package and deploy your applications in a consistent and portable way.

Why use Docker with ReactJS?

There are several benefits to using Docker with ReactJS:

Consistency: Docker ensures that your ReactJS application is run in the same environment on every machine. This can help to reduce errors and make it easier to deploy your application to production.
Portability: Docker images can be run on any platform that has Docker installed. This makes it easy to deploy your ReactJS application to different environments, such as your local machine, a development server, or a production server.
Scalability: Docker makes it easy to scale your ReactJS application by running multiple instances of the application in containers. This can be useful for handling high traffic loads or for running different versions of your application in parallel.

Getting started

First, let's create a React App. To do this, open terminal and hit command:

npx create-react-app my-app --template typescript
cd my-app
code .

This will open your React project in vscode. You can run and check your project using command:

npm run start

Now, create a build of your react project using command:

npm run build

You should see a build folder getting generated in project root directory that we are going to use later.

Next, let's install Docker on your machine. Once you have installed Docker, you can create a Dockerfile for your ReactJS application.

A Dockerfile is a text file that contains instructions for building a Docker image. The Dockerfile for a ReactJS application will typically include the following steps:

From: Specify the base image to use for your image. For a ReactJS application, you will typically use the node base image.
Workdir: Set the working directory for your container.
Copy: Copy the files from your ReactJS application directory into the container.
Run: Run the npm install commands to install the dependencies and build your ReactJS application.
Expose: Expose the port that your ReactJS application is running on.
CMD: Specifies the instruction to be executed when Docker container starts.

Once you have created a Dockerfile for your ReactJS application, you can build a Docker image using the docker build command.

To run the Docker image, you can use the docker run command. The docker run command will start a new container from the Docker image.

Implementation

Let's create a file named Dockerfile (yes, without file extension) and paste the below code in it:

FROM node:20-alpine

WORKDIR /app

COPY build/ .

RUN npm install -g serve

EXPOSE 3000

CMD ["serve", "-s"]

To build a Docker image from this Dockerfile, you can run the following command:

docker build -t my-app .

Note: For the above command to execute properly, make sure Docker Desktop is running, else it would throw an error like:

ERROR: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

To run the Docker image, you can run the following command:

docker run -p 3000:3000 my-app

That's it!!! You should be able to access your react app using http://localhost:3000

Bonus Tips:

For deflating Docker Image size:

Always use alpine as base image (node:20-alpine), as it is very small in size
Always build frontend applications outside of Docker environment and then package the output build folder into Docker instead of copying all the files into Docker and then running npm run install and npm run build.