DEV Community: Neel-Vekariya

What Does Express.js Abstract Away?

Neel-Vekariya — Wed, 14 Oct 2026 06:00:12 +0000

In the past, we talked about the general deeper understanding about what Express.js actually is, what problem it tries to solve, and what existed before Express. But another question is: what abstraction does it introduce?

If you've read my previous posts, you know that Express.js provides an abstraction over Node.js's HTTP module. In this post, we'll go deeper and explore what those abstractions actually are.

The most common central abstraction, the low-level processing of an HTTP request into a programmable pipeline of middleware and routes. This is a broad perspective of the Express.js abstraction. But this broad abstraction has many small abstractions. And those abstractions are:

*) Route Matching

Express abstracts manually route matching. It takes responsibility for matching routes for incoming requests. It abstracts that task and gives a simple way to use routes without the complexity of matching routes.

*) Route Parameters:

The next abstraction Express.js provides is parsing request parameters for us, so we don't have to handle them manually. It hides the mechanics of matching and extracting that value. Without it, you might have to manually parse the parameters.

*) Request Processing:

Express abstracts raw HTTP request information into data that is easily accessible to the application. The task of processing raw information of the request is abstracted by Express.

*) Middleware:

Express allows you to represent cross-cutting request processing as reasonable functions. Instead of manually deciding everything inside one HTTP callback, it gives functionality to compose the application out of functions that process the request sequentially.

*) Composition Model:

Express gives you compose behaviour where each piece has a focused responsibility. That’s much more scalable than putting everything into one request.

Express makes application development easier by abstracting some of the complexity, but it does not abstract away everything involved in building an application.

It doesn’t decide:

How my business should work
How I should store users
Which database I should use
How an order should be calculated
How payment should work

What Existed Before Express?

Neel-Vekariya — Sat, 10 Oct 2026 04:04:14 +0000

I already made a post about what Express really is and which problem Express tries to solve. But do you think about what existed before Express? How did developers build servers in the JavaScript ecosystem?

I had this question, and I found out a really interesting thing.

In the JavaScript ecosystem, Node.js was released in 2009, and its standard library already allowed developers to create HTTP servers directly.

Think about the complexity and repetition of code for building servers using the Node.js HTTP module. I saw code for handling different routes, where you handle different types of requests and routes using the if-else block.

Like this:

const server = http.createServer((req, res) => {

  if (req.method === "GET" && req.url === "/") {

    res.writeHead(200, { "Content-Type": "text/plain" });

    res.end("Home page");

  } else if (req.method === "GET" && req.url === "/about") {

    res.writeHead(200, { "Content-Type": "text/plain" });

    res.end("About page");

  } else {

    res.writeHead(404, { "Content-Type": "text/plain" });

    res.end("404 - Page not found");
  }
});

You repetitively write which data type you send and what the actual data (response) will be sent by the server. And this process becomes cumbersome as the application grows.

Developers therefore built higher-level abstractions around Node.js HTTP capabilities, which are frameworks and libraries. Express is one of those abstractions and became particularly influential.

Node.js brought JavaScript to the server, and Express provided a popular web framework abstraction for that environment.

The Engineering Problem Express Tries to Solve

Neel-Vekariya — Wed, 07 Oct 2026 14:36:07 +0000

The Engineering Problem Express Tries to Solve

If you don’t know, we can also build an HTTP application using Node.js low-level HTTP APIs. The application is working properly and able to handle requests and generate responses. So, why do we need to build Express?

The reason behind that is that building an HTTP application using Node.js low-level HTTP APIs becomes repetitive and cumbersome (difficult) as the application grows. The repetition of writing code for request parsing, routing, middleware, and handling the logic becomes more complex.

The Problem Express Solves:

How can we build an HTTP application on top of Node.js without repeatedly implementing the same request parsing, routing, middleware, and response handling logic ourselves?

Express introduces reusable abstractions for those common problems. In application building, the repeated infrastructure, such as routing, middleware composition, request parsing, response handling, and error handling, is directly provided by those reusable abstractions.

If you are confused by reusable abstractions, don’t worry. It simply means a ready-made piece of code or concept that solves a common problem.

This reusable abstraction gives us the ability to write actual business logic instead of writing complex application infrastructure for every project.

This is the actual problem that Express tries to solve. And it exists to provide a higher-level abstraction over Node.js low-level HTTP APIs.

What is Express, really?

Neel-Vekariya — Sun, 04 Oct 2026 06:46:33 +0000

What is Express, really?

In my last blog, I shared some of my personal experience and the thinking that led me from “How?” to “Why?”

So, I’m going to assume you already know the “how” of Express.

Now, let’s start understanding the “why” behind Express.

First, let’s understand what Express really is.

As per the technical definition:

Express.js is a minimal, unopinionated web application framework for Node.js that provides abstractions and APIs for handling HTTP requests, generating HTTP responses, routing, middleware composition, and building web/API applications.

🤦‍♂️🤦‍♂️ Very technical, right?

Don’t worry, I’ll explain it to you.

In simple terms, Express.js is a web application framework that provides the bare minimum (small set of core abstractions) tools to build your applications while giving you maximum freedom in how you structure your application.

It does not force you to follow a specific file structure.

It provides tools for handling requests, responses, routing, and other application tasks instead of making you manually handle those lower-level tasks.

Now you get the idea of what Express is.

But another confusing phrase came up:

“Lower-level application tasks.”

What does that actually mean?

To understand this, you first need to understand what problem Express is solving.

And that is another big topic, which we’ll discuss in the next post.

For now, assume there are some repeated tasks involved in building and setting up HTTP APIs.

Express handles many of these tasks under the hood.

This provides a layer of abstraction over those difficult tasks and gives developers a convenient way to work with:

1. Routing:

Deciding which code should handle a particular URL and HTTP method.

2. Middleware:

Creating a pipeline of functions that process requests and responses.

3. Request Handling:

Handling parameters, headers, and request bodies.

4. Response Handling:

Sending JSON, HTML, status codes, and other data.

5. Error Handling:

Handling errors consistently within the application.

But this brings us to another question:

What problem was Express actually trying to solve?

That’s what we’ll understand in the next blog.

Why I Started Learning Express.js Differently

Neel-Vekariya — Thu, 01 Oct 2026 06:47:11 +0000

Two months ago, if you asked me, “What is Express?”

I would have said, “Express is a framework that handles requests, generates responses, and is used to build servers. That’s it.”

I also learned Express from tutorials and built the projects that the instructor instructed me to build, which you’ve probably done too.

After that, I built my personal project. I had a clear idea of the project, so I built it.

I knew how to use controllers and routers, how to handle errors, requests, and responses, and how to implement middleware because I learned all these things from the tutorials.

But somehow, I felt that something was confusing me.

I didn’t clearly know what was confusing me.

But I found out what was confusing me after a very long time.

And that thing is very interesting:

Why?

What is “why”?

For me, “why” means: “Why do all these things work this way?”

I knew how to build a project using controllers and middleware. I knew how to handle requests and responses.

But the “why” was missing, and I realized this after a very long time.

The “why” is very important when learning the “how.”

I think some realizations are important because they give you the right perspective to see things.

Every time I need to learn a new technology, I run toward “how” and not “why".

The thinking behind “why” is important when understanding how we implement a technology in our projects.

Why gives you an engineering perspective and a clear answer to why we use this technology instead of another technology.

To understand the why give to ability to use this particular technology in particular situation.

That shift helped me understand the engineering thinking behind the technologies I use—not just the APIs, syntax, or common patterns.

So I decided to start sharing this way of thinking here.

I’m starting with Express.js, and I’ll be sharing what I learn along the way.

If you’re also trying to move from “I can use it” to “I understand why it works,” follow along.

If you’re also learning software development, I’d love to hear your thoughts in the comments.

Testing Pyramid

Neel-Vekariya — Tue, 15 Sep 2026 10:30:53 +0000

In recent my posts, I talk about the AAA model of the testing and what is the importance of testing. Now I think this time is perfect for introduce and talk about the testing Pyramid.

The concept of the testing pyramid is introduced by Mike Cohn in 2004. Then in 2009 The formal and polished version of the testing pyramid is introduced in his book “Succeeding with Agile”. They introduce three levels pyramid which is UI tests, Service tests and Unit tests.

The levels of pyramid divides based on their scope, speed, cost and frequency. Different levels have different scope, speed, cost and the running frequency. Based on this parameter, you can easily decide which type of tests to use, where to use them, and how much of each type you need.

Generally, the ratio of this tests levels is 10:20:70. 10 percent of your tests is UI tests, 20 percent tests is service tests and rest of 70 percent tests is unit tests. This ratio is popularized by the google in 2015, in their testing blog “Just Say No to More End-to-End Tests”.

Now let’s understand deeply what are those different levels. Let’s start with unit tests.

Unit Tests

Generally, Unit tests are small and independent block of tests for small feature, small function or small component. This unit tests are isolated then other tests. It tests and checks smallest part of the program.

It run on isolation so that their scope is limited to that function or that component. Unit tests are extremely fast due to mocking of database query, API requests and file I/O. The mocking of those operation makes unit tests faster to execute.

The frequency of the unit tests is very high. After every file change, the unit tests run automatically, testing the relevant cases and providing instant feedback.

Now after every change the test cases automatically checks every component or feature then if any mistake was created it directly indicates failure and the cost of fix this mistake in development phase is very cheap.

So that’s is all about unit tests now let’s understand service tests.

Service Tests

In unit tests we tests individual component, function or feature working individually in isolation or not. But that is not necessary if component works on isolation then it also works when they dependent to each other. In real application most of function is dependent on some component or some dependency in this time unit test is not reliable. So, we done service tests.

In service case we test that the interaction between different parts like function or component is done reliably or not. The goal is to ensure that the complete system behaves correctly when its components are connected.

In service tests, mocking is rarely used. In case where you use external API that is expensive, unreliable or unavailable then the mocking is used in service tests.

In service tests the scope of the tests is from two component to multiple component due to use case of service test. The component is not isolated because they depend on other component so the speed of executing service test is slower than unit test.

The frequency of service tests is lower than unit tests. Because service tests require multiple components or dependencies to work together, they take more time to execute. So we don't need to run every service test after every small file change.

But when we change something that can affect the interaction between components, service tests become very important.

They give us confidence that different parts of our application are working correctly when they are connected with each other.

Now we understand unit tests and service tests. But there is still one level remaining in the Testing Pyramid. That is UI tests.

UI Tests

UI tests are tests where we test the application from the user interface. Instead of directly testing a function or connecting different components, here we test the application from the point where the real user interacts with it.

The test can open the application, find the email input, enter the email, enter the password, click on the login button and check whether the user successfully reaches the dashboard.

So, UI tests test the complete user interaction with the application.

The scope of UI tests is much bigger than unit tests and service tests because it can cover the complete application flow. It can involve UI components, frontend logic, backend services, database and other dependencies.

Because of this large scope, UI tests are much slower than unit tests and service tests. The test needs to start and interact with the application and sometimes it also needs to communicate with the backend and database.

The cost of UI tests is also higher. Writing and maintaining these tests takes more time because even a small change in UI can break the test. For example, if we change the button structure or change some text or element, the UI test may need to be updated.

The frequency of UI tests is also lower. We don't want to run every UI test after every small change because they take more time and resources.

So if we compare all three levels, unit tests have the smallest scope, highest speed, lowest cost and highest frequency.

Service tests have a bigger scope than unit tests, slower speed, higher cost and lower frequency.

UI tests have the biggest scope, lowest speed, highest cost and lowest frequency.

This is the basic idea behind the Testing Pyramid.

There is one more thing that is important to understand.

The terminology around the Testing Pyramid has changed over time.

The original Testing Pyramid described the three levels as Unit Tests, Service Tests and UI Tests.

But as software development practices evolved, different teams and organizations started using different terminology for these levels.

The term UI tests is now often discussed as End-to-End tests, or E2E tests, and service tests discussed as integration tests.

Is Being Good at Coding Enough?

Neel-Vekariya — Sat, 12 Sep 2026 05:26:05 +0000

Over the last six months, I’ve learned a few things that changed the way I think about building a career in software.

When we think about technical careers like software engineering, frontend development, or backend development, we usually believe technical skills are enough to build a successful and stable career.

so we focusing on learning new languages, explore new frameworks, new tools and try to become good in problem solving.

but this is really enough?. I don't saying like this technical skills is not necessary. it is necessary but this are skills alone actually enough.

And this is where social media become interesting.

Today, social media is not just place for entertainment it also become marketplace. where every company today come and they market them and gets visibility and trust. they build their identity as brand use of social media.

do you think how companies build their identity.

lets understand by simple example

How Companies Build Their Identity

lets imagine a company has a good product. does it simply build the product and wait for people to discover it?

usually not.

After building great product company market their product, communicate with community, creates content and tells people about what they stands for. what it does, what it believes in, and what makes its product valuable.

over a time people start recognize the company and associating them with some products which company sells. now company have their identity in the market.

Now Come to Our Main Question

now come to our main question Is it really enough?. now in this case the product is our skills. company may have good product but does it automatically have customers? not

so what does company do?

its markets its product

in a same way we need to market our skills. we need to create our identity, we need to tell people what we does, what is believes in and why we are valuable.

But Think About It Again

Now, let's recall the process of how a company builds its identity.

But think about it again.

Is the company actually trying to build an identity?

Not exactly.

The company is actually building its distribution a way to get its product and services in front of more people.

Let's Understand How Distribution Actually Works

First, let's make one thing clear:

The benefits of content are random and unexpected.

You cannot predict exactly who will see your content, who will connect with it, or what opportunity may come from it.

But through distribution, you increase your chances and expend your surface area of getting opportunities.

The more people who discover your work, your skills, and your thinking, the more chances you have of getting an opportunity.

And over time, this repeated exposure creates recognition and builds your professional identity.

So Is Being Good at Coding Enough?

so now give answer Is Being Good at Coding Enough? no

because "Jo dikhta he vo bikta he"

Why need software testing

Neel-Vekariya — Sun, 06 Sep 2026 07:06:08 +0000

Why need software testing

Two days before, I posted about how my thoughts will change around testing, talked about the AAA model of testing, and how the AAA model is used for testing.

Now the next question came into my mind: if testing is important is ok, but what are the actual and well-defined advantages of testing we have?

I have some thoughts about those advantages, but I can’t describe them in words because I have very unclear thoughts.

Then I decided, let’s make this answer clear. I searched about that and found lots of content created around testing.

The content I found has different-different opinions about testing, but deeply I observed that all the content directly or indirectly indicates the same points, but people have different-different tests and experiences to explain those points.

All the content I found describes the actual thinking on top of product management and software engineering, which is very important to create and maintain the product.

In software engineering, to build the feature or product is not always the task. Software engineering is never about building new ordinary features and products which do not function properly, are not reliable, and do not have enough efficient use cases.

It’s all about achieving maximum functionality, reliability, usability, efficiency, maintainability, and portability of the feature or product.

And the thinking behind testing is to test a feature and product on top of these parameters. And at this point, I have some clear thoughts about testing, so let’s clean those thoughts more.

I described many words like functionality, reliability, usability, efficiency, maintainability, and lastly portability, but what the actual meaning of these words is, let’s clear out more.

Functionality

Functionality :- Functionality means whether all the created or implemented functions do their work correctly or not.

All the functions which are built to achieve some level of expected task, give the correct and well-defined output, and using all the output we achieve the expected task, output is defined by this functionality.

Reliability

Reliability :- Reliability means the downtime and failure rate of the software or service tend to be lower.

The software or service must have maximum uptime and minimum failure time so the software or service does its work reliably.

Usability

Usability :- Usability means designing your software in a way where the features of the software are actually usable and have maximum and easy access to the feature.

This thinking leads to improving the GUI of the product or feature.

Efficiency

Efficiency :- Efficiency means using your resources very wisely.

The resources are very expensive, so design your feature or product in a way where your feature or product consumes a minimum amount of resources and gives the best output using the consumed resources.

Maintainability

Maintainability :- Maintainability means the feature or product is maintainable.

If you design your feature or product in a way where maintaining the feature or product is harder or complex, then this will kill the maintainability of the product.

In software engineering, we try to build a feature or product in a way where the maintainability of the feature or product is very high, so later, if we need to make changes, then we can make changes simply.

Portability

Now last is portability :- Portability is all about running your product on various operating systems.

If your product or feature only runs on your operating system, then the portability of your product or feature is very low.

So this is all the parameters where the quality of the software depends, and to test all the parameters, you need to test these points.

New way to build the software

Neel-Vekariya — Wed, 02 Sep 2026 05:56:48 +0000

If you read my blogs, then you definitely know I learned to build a full-stack application.

But to build an application and to build an application that is efficient, robust, and performs well under any circumstances are different levels of skills and engineering.

In this AI era, everyone generates code using AI and builds applications, but actual software engineering is never about writing code.

The real engineering is to build software that works under any conditions, gives the correct output, and is reliable and well-tested.

This one thought led me to explore things about testing.

Before building my project, I never thought about testing and edge cases.

I built the feature, and if it gave the correct output, then fine, my feature was ready and I moved on to build another feature.

I wrote hundreds of lines of code without any real value because the feature was not reliable, not robust, and did not perform well under critical situations.

Then I found out this is the difference between a senior developer and a junior developer.

I learned to build software, but I didn’t learn to think about edge cases, what if my feature faced a critical situation, and what about robustness.

I missed thinking about edge cases, critical situations, and robustness.

This is the thinking that differentiates a junior developer from a senior developer.

At this stage, I had one doubt, and the doubt was: if testing is important, then I want to learn testing deeply.

If you have the same doubt, then I found the correct answer.

To build reliable, robust software that works in critical situations, you don’t need to learn software testing deeply if your goal is not to become a QA engineer specifically.

Why did I say this? The reason is that you only need to know how to verify your feature in the way you want to perform the task.

During the development period, the cost of finding bugs and vulnerabilities in the feature is very low if the developer finds their bugs in the early development stage.

To overcome the maximum damage of the feature and save your resources, testing becomes very essential in the development phase.

Now I understand the real value of testing, so I need to go deep into testing and need to learn testing.

And I found out that the basic thinking of testing depends on AAA (Arrange, Act, and Assert).

Think like this: these are the main pillars of testing.

In testing, you first arrange your configuration related to the feature, define some inputs and dependencies.

This is called Arrange.

Then the next step is Act.

In Act, you execute the behavior of the feature using the configuration you created in Arrange.

Now the next step is Assert.

Assert means verifying whether the output of the feature matches your expectation or not.

Let’s take one example for that.

I want to test my function greaterOfTwoNumber().

Then my flow of the testing is like that:

// Arrange

// Import the Function for testing.

const a = 2;
const b = 4;

// Act

const result = greaterOfTwoNumber(a, b);

// Assert

expect(result).toBe(4);

This is the most basic example of AAA.

In the first step, we do all the configuration like defining inputs and importing the dependencies and functions or features for the test.

Now in the next step, we do Act.

In Act, we execute the behavior of the function or feature, and in Assert, we check whether the output is as per our need or not.

If the output is not as per our need, then the test fails; if we have the correct output, then the test passes.

This is the basic overview of the testing.

If I am wrong in any section, please drop your thoughts in the comments.

Next step to client-side storage

Neel-Vekariya — Sun, 23 Aug 2026 09:44:40 +0000

Next step to client-side storage

In my past one blog, I wrote about how I improve the performance of the application using the local storage. And the problem local storage solves.

But now I face another problem about the client storage. My project is simply about order management software for the rental clothing industry.

In the rental clothing industry, Showrooms or small shops have a big problem. The problem starts when one order has a single or multiple items that are booked in a particular time range.

Now, a second order wants the same item in between that particular time range. If, by mistake, the second order books that item, then the problem starts.

The item is booked two times in that particular time range. That is called double booking of the item.

This mistake is created by the use of traditional register booking. Now, when I need to store the items data, that is a small amount of data, so I simply use the local storage.

But now I need another and a big storage for storing order details. I build two features: first one is for showing all the orders and second one is for showing the full order.

To implement those features and to maintain the user experience, I decide to store a small amount of data about the order on the client side. First, I decide to store data in local storage.

But to store data in the local storage is not a good option because the local storage is used for storing small details about the application, and storing order details in the local storage compromises the performance of the application.

Now I want a new storage option for storing order details. And again I find out, and that is the IndexedDB.

To integrate IndexedDB in my application, I want to learn about that storage. I search multiple videos about IndexedDB, but no one is teaching me properly.

After finding hundreds of tutorials, I finally found one tutorial that is teaching properly how to integrate IndexedDB in the application. Now I want to share that learning with you.

To integrate IndexedDB, we want to create first one database in IndexedDB. The dbConnect is built for that and used to get the reference of the created database.

To build that function, we want to create first two environment variables: db_name and version. Those two variables describe the name and the version of that database.

If any updation happens in the version variable, then this function will execute and update the database.

const dbConnect = () => {

  const req = indexedDB.open(db_name, version);

  req.onupgradeneeded = () => {

    const db = req.result;

    // Access the reference of the database.

    const payload = {
      keyPath: "id",
      autoIncrement: true
    };

    // The payload is for creating a primary key.

    db.createObjectStore("orders", payload);

    // Create the object that is called store in IndexedDB.
  };

  req.onsuccess = () => {
    console.log("Success", req.result);
  };

  req.onerror = () => {
    console.log("Failed", req.error);
  };
};

Now, in the function, we create first one database and get the reference of that database. The req.onupgradeneeded is an event for updating the database when the version variable is changed, then this event is run and updates the database.

The req variable sends the request to open the database, and after the request is complete, we now have access to the database connection reference. The payload is the rule for how the primary key of that particular store will be generated.

To create a store, first we access the result object, and in the result object, we use the createObjectStore method. onsuccess and onerror are events that indicate the success or failure of the connection.

The function dbConnect is an asynchronous function, so the next step is to convert this asynchronous function to a synchronous function. To create a synchronous function, we simply wrap this function into the promise.

Let's do that.

We do this promise in the req.onsuccess or req.onerror event. If the req is successful, we resolve the promise; otherwise, we reject the promise.

The updated event is:

req.onsuccess = resolve();
req.onerror = reject();

const dbConnect = () => {

  return new Promise((resolve, reject) => {

    const req = indexedDB.open(db_name, version);

    req.onupgradeneeded = () => {

    };

    req.onsuccess = () => resolve(req.result);

    req.onerror = () => reject(req.error);

  });
};

Now our function is converted into the synchronous function. Now, the next step we explore is how to store, update, read and delete the data.

In IndexedDB, all the operations are transactions. Means if any error happens, then all the started operations are undone.

Now the next step is to get knowledge about the permission. When we want to store or delete or update the data, the first step is to define the permission.

readonly, readwrite are the types of permission.

const storeData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readwrite");

    // Define the permission.

    const payload = {
      name: "Neel",
      email: "neel@gmail.com"
    };

    // The data to store.

    transaction.objectStore("orders").add(payload);

    transaction.oncomplete = () => {
      console.log("Data Stored Successfully.");
    };

  } catch (error) {
    console.log(error);
  }
};

This is all about storing the data. Now we learn about reading the data.

For reading the data, we use readonly permission. The getAll() function is used to get all the data, and get() is used to get particular data.

const readData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readonly");

    // Define the permission.

    const request = transaction.objectStore("orders").getAll();

    request.onsuccess = () => {
      console.log("Data Fetched Successfully.", request.result);
    };

  } catch (error) {
    console.log(error);
  }
};

This is all about how to read the data. Now next, we learn how to update the data.

To update the data, we use the readwrite permission.

const updateData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readwrite");

    // Define the permission.

    const store = transaction.objectStore("orders");

    // In this store we do not use any function; either we get the reference.

    const req = store.get(id); // Get old data.

    req.onsuccess = () => {

      const data = req.result;

      if (!data) return;

      const payload = {
        ...data,
        name: "Jay",
        email: "Jay@gmail.com"
      };

      // Only change name and email and other data store as it is.

      store.put(payload);
    };

  } catch (error) {
    console.log(error);
  }
};

This is all about how to update the data. Now next, we learn how to delete the data.

To delete the data, we use the .delete() method.

const deleteData = async () => {

  try {

    const db = await dbConnect();

    const transaction = db.transaction("orders", "readwrite");

    // Define the permission.

    const store = transaction.objectStore("orders");

    // In this store we do not use any function; either we get the reference.

    const req = store.delete(id); // Delete data.

  } catch (error) {
    console.log(error);
  }
};

Now we successfully implemented the IndexedDB in our project.

If I made any mistake, then share my mistake in the comments.

Then My Project Needed This

Neel-Vekariya — Sat, 15 Aug 2026 07:33:22 +0000

Finally, I Integrated the Multiselect Autocomplete Dropdown

In the past few months, I learned a lot of things and also made a project after many retries. The project taught me many important concepts that I didn’t know after learning languages, frameworks, or even in lectures.

These were concepts that I only came across when I wanted to use them in my project or when I faced some issues. The Multiselect Autocomplete Dropdown is one of the concepts that I didn’t learn when I was actually in the learning phase, but I learned it when I was building something on top of my learnings.

In my project, I wanted a feature in the frontend where a user could send me multiple-selected values of one field, and I also wanted that field to be searchable and autocomplete.

Then I noticed that this type of feature is also provided in HTML with the select tag, but there was an exception with this tag, and the exception was that the tag is not searchable and does not support multiple values.

So, I needed a different solution, and I wanted to figure out that solution.

In the age of AI, finding a solution is very easy, but the difficult part was integrating it into my project.

I found the solution with the help of AI, and now the next step is to integrate it into my project.

I think this type of feature is learned only for a purpose. The topic is learned when the functionality is needed.

When the topic is learned only for the purpose of learning, then the topic is not available in the course we want to learn from, documentation, or some video where the topic is not fully explained.

In this case, I faced the same problem.

If you face the same problem, please share your experience in the comments.

Finally I access The Child Element

Neel-Vekariya — Tue, 11 Aug 2026 04:21:58 +0000

Recently, if you read my little weird blogs, you know I learn React.js and build one project. In the project, I made many mistakes like creating a complex component structure. Later I removed all components and made a clear folder structure.

I created cards that did not show data, and I don’t know why. And so on. But one problem came when I used the React-Hook-Forms and my custom input field.

This problem gave me more knowledge as well as an idea about how react-hook-form works. The problem is like this. When I want to access the child component from the parent component to access the data entered by the user.

That gave me undefined instead of the value which was passed by the user. I was not able to find out why that happened. Later I found out that my parent element does not have access to the input field. That is the problem.

Now I don’t know why the parent element does not access the child element. In the parent element, I did not make a mistake in using the child element. Then why did that happen.

Subsequently, I found out that the register which is used for accessing the value from the child element sends one ref to the child element. But I did not define that or use that. Now I found out the method that is used to pass reference to the child component.

React provides a higher order function named forwardRef to solve the problem of passing the reference to the child component. The forwardRef is not needed in a normal input or select field.

The custom component built for reusability blocks the reference. In this situation, we need a service that passes the reference from the parent to the child component.

The service is provided by the higher order function forwardRef. To use forwardRef in the custom component, you need to import it from React. And pass it as a secondary separate parameter ref in the function.

Now pass this parameter as a ref property in the custom input component. And wrap your exported component in forwardRef. Now you have access to the child component in the parent.

And also have the value which is passed in your child component. Now this function solved my problem of passing undefined value.

If I have done something wrong, please let me know in the comments.