DEV Community: Azfar Razzaq

Google Lighthouse for Beginners: A Real Portfolio Optimization Case Study

Azfar Razzaq — Wed, 25 Mar 2026 12:43:12 +0000

Okay, so you’ve learned what Google Lighthouse is, how it works, and what the metrics mean. But most tutorials stop there instead of showing you how to actually improve them.
For that purpose, I am structuring this article as a case study in which I am going to optimize the performance of my own portfolio through Google Lighthouse while also highlighting what to focus on, what to ignore, and some useful tips for using Google Lighthouse.

Prerequisite

I wrote this article for junior developers, especially those using Google Lighthouse for the first time and trying to understand how to act on its reports in a practical way.

To follow along, you only need a basic understanding of the main Core Web Vitals and loading metrics: FCP, LCP, INP, and CLS.

Before You Run Lighthouse

Before using Lighthouse, make sure you are testing in the right environment.

If you want to measure the actual performance of your site, run Lighthouse on the live domain where the site is hosted. You can still use it during development or on a local production build to catch issues, but those environments should not be used to judge the site's real performance.
Open the site in an incognito window before running Lighthouse. This helps avoid browser extensions interfering with the test results.

💡Tip
If your website has been live for some time and gets enough traffic, PageSpeed Insights can show you how real users are actually experiencing it through Chrome UX Report (CrUX) data. This makes it useful for spotting real-world performance issues and making decisions based on actual user data.

However, you still need to know how to analyze a Lighthouse report properly. PageSpeed Insights also uses Google Lighthouse, so the lab data, audits, and improvement insights are still presented in a very similar way.

How to Analyze Lighthouse Results

Before getting into the case study itself, here are a few things worth keeping in mind when analyzing Lighthouse results.

Lighthouse scores can vary from one scan to another. Sometimes the difference can even be 20 to 30 points, so do not judge your site based on a single run. Run Lighthouse around 4 to 5 times first to get a more reliable picture. You can also run it again after some time (1-2 hours) for a better overall view.
After fixing an issue, do not just look at the final Performance score. Go back to the Insights tab and check whether that insight is no longer highlighted or whether its severity has gone down. Also check the values shown next to it, such as time saved, file size, or delay, and see if they improved.
Some fixes may not lead to a noticeable jump in the Performance score. That does not necessarily mean the fix was useless. Some improvements are not heavily reflected in the score but they can still boost the site's overall performance.
You do not need to fix every single thing Lighthouse highlights. In some cases, a flagged item may just be part of how your site is built, and changing it may not be worth the effort unless it is causing major issues.
A good place to start is the insights with the highest warning level. The red ones usually deserve attention first because they tend to have the biggest impact. The yellow ones are worth considering too, especially when the fix is small and easy to apply.

How I Optimized My Portfolio

Up to this point, I have covered the setup and the things to keep in mind while reading Lighthouse results. Now it is time for the practical part, where I go through my own portfolio step by step and show what I fixed, what I ignored, and why.

Pre-Optimization Results

Before making any changes, I first ran Lighthouse multiple times to get a more reliable starting point. These were the results of my portfolio before I applied any fixes.

Mobile Version:

Desktop Version:

Moving forward, I will be using the mobile view to analyze performance. This is because Google is mobile-first, and in my case, both mobile and desktop versions load the same assets and only differ in layout, so improving results on mobile would also improve the results on the desktop version.

Initial Mobile Performance Breakdown

My initial mobile Lighthouse score was 55. To understand where that score was coming from, I broke down the metric contributions below:

Metric	Contribution	What it showed
TBT	30 / 30	This was already in good shape.
CLS	25 / 25	Layout shifts were not a problem.
SI	0 / 10	The page was taking too long to visually load.
FCP	0 / 10	The first visible content was appearing too late.
LCP	0 / 25	The main content was loading too late.

This made the main problem clear. The page was stable in terms of layout, but it was slow to show content and slow to load the most important content. That is why my focus in the next steps was on metrics like FCP, LCP, and Speed Index.

Acting on the Lighthouse Insights

As the breakdown shows, LCP carries a lot of weight in the performance score and it is currently at 0. At the same time, FCP is also performing poorly. I am going to focus on FCP first because if the page starts showing content earlier, that will usually help LCP as well.

Filtering down the Lighthouse suggestions for FCP, I got the following insights.

Reducing JavaScript Bundle Size

Normally I would have started with the Insights tab first, but one thing in the diagnostics stood out immediately. Lighthouse showed potential savings of 2445KiB from unused JavaScript. When I checked the built JavaScript bundles, the total size was 2517KB. That is absurd for a page like this, because a reasonable bundle size is usually in the low hundreds of KB, not multiple MB. Most of that size was coming from home.js alone at 2005KB, while index.js was another 472KB.

After seeing that, I inspected the libraries I was importing in my components to find what was causing such a huge bundle size. It turned out that one library was responsible for most of it. I only needed a small part of that library, so I changed the import and used just the subset I actually needed. This brought the build size down by a lot.

This fix caused such a massive improvement because the JavaScript bundles were simply too large before. The browser had to download much more code than necessary, which delayed how quickly the page could start showing content. That was hurting FCP, and because of that, LCP was also affected. Once the bundle size dropped, the JavaScript loaded much faster and the performance score jumped from 55 to 87.

Even though Lighthouse marks Reduce unused JavaScript as unscored, cutting down that much JavaScript still had a direct effect on the page's actual loading performance. You can also see in the diagnostics below that the JavaScript size dropped to a much more reasonable level after the fix:

Self-Hosting Google Fonts

Now I moved back to the Insights tab. The biggest issue there was Render Blocking Requests. It showed that apart from requests to my own server, the page was also making a request to the Google Fonts API. That request alone was costing around 1020ms.

This was happening because I was using Google Fonts through the embed code. That is fine during development, but once your site is finalized and you already know which fonts and font styles you need, it makes more sense to self-host them. Self-hosting the fonts has a few clear advantages:

It removes reliance on a third-party font delivery service.
It removes the extra DNS, TCP, and TLS connection setup needed to fetch fonts from Google.
It is better for privacy and supports GDPR compliance by avoiding transmission of visitor IP addresses and related request data to Google for font delivery. See Google Fonts and GDPR: How to Stay Compliant?.

Using `WOFF2` instead of `TTF`

You can download font files directly from Google Fonts, but they usually come as .ttf files. Those are not ideal for the web because the file sizes are larger than needed. You can convert them to woff2 yourself, or you can use the Google-WebFont-Helper website. It lets you download woff2 versions of Google Fonts directly.

After self-hosting the fonts, the performance score went up to around 95-96. This improvement came from removing that extra external request and reducing the render-blocking delay caused by the font loading.

At this point, the performance score was already above 90, which is generally a good range. But I still decided to go through the remaining insights because some of the fixes were easy to apply and could still improve the website's actual performance, even if the score did not change much.

Prioritizing the LCP Image

The next insight showed that the LCP image was not being fetched with high priority.

This was a simple fix. I only needed to add fetchPriority="high" to the LCP image. Even though this did not noticeably change the performance score by itself, it is still a good practice because the browser can start prioritizing the most important image earlier.

Optimizing Image Sizes

The last major area left to improve was image delivery. Most of the images on my website were in png or jpeg format, so I converted them to webp. webp is generally a better choice for the web because it usually gives you much smaller file sizes.
On top of that, I also compressed the images by lowering their quality to around 75-80%. This reduced their size even further without causing any noticeable drop in quality. I applied this to all images on the website except the LCP image, since that one was already only 30KB and I did not want to reduce its quality at all.

After replacing the images, I was able to reduce their combined size from around 8000KB to 200KB.

Results After Optimization:

To improve the performance of the portfolio, I reduced the JavaScript bundle size, self-hosted the Google Fonts, prioritized the LCP image, and optimized the image sizes. Together, these fixes improved how quickly the page started rendering and how quickly the important content loaded.

As a result, the mobile performance score improved from 55 to 96, while the desktop performance score improved from 68 to 100.

Mobile Scores:

Desktop Scores:

I also acted on some of the Accessibility and SEO insights, which helped improve those scores as well. However, I am not covering them here, so the article stays focused on performance.

What I Did Not Fix

There was one insight called Network Dependency Tree. It showed that during the initial page load, some requests were dependent on earlier requests before they could start. In simple terms, the browser was not able to fetch everything in parallel because parts of the page were waiting on other resources first.

Even though Lighthouse marked this insight with a high severity level, I decided not to act on it. In my case, this behavior was part of how the page was built, and fixing it would have required a lot more time and effort than the other changes.

Another reason I ignored it was that the maximum critical path latency was only around 300ms. That is not nothing, but compared to the other issues I had already fixed, it was not important enough to justify a bigger rewrite.

How to Keep Track of Performance Over Time

Improving performance once is not enough. As you keep adding new features, images, libraries, or third-party scripts, the performance of the site can start dropping again. That is why it is important to keep checking it over time.

A simple habit is to run Lighthouse again after every major update. This can be after adding a new section, a new library, new images, or anything else that changes how the page loads. If you want to take it a step further, you can also integrate Lighthouse into your CI/CD pipeline and set a minimum performance threshold. That way, the build will fail automatically if the score drops below the level you want to maintain.
It also helps to keep a record of your scores and key metrics like FCP, LCP, and CLS. This makes it easier to spot regressions early. Lighthouse allows you to save the reports in multiple formats (HTML, JSON, etc.), which makes it easier to keep track of the scores.
If your site starts getting enough traffic, start checking PageSpeed Insights as well. It can show you how real users are actually experiencing your website through CrUX data. This functionality has also been integrated into Chrome Dev Tools under the Performance tab.
As a more advanced step, you can also use the web-vitals library or analytics-based monitoring to track performance from real users directly. This gives you a better idea of how the site is behaving outside of lab tests.

Conclusion

In the end, the goal is not to chase a perfect score every single time. The real goal is to understand what is slowing your site down. Once you know how to analyze a Lighthouse report properly, it becomes much easier to decide what to fix, what to ignore, and how to keep the site fast over time.

React Router Now Supports Contextual Routing with

Azfar Razzaq — Fri, 20 Mar 2026 15:51:23 +0000

React Router just released v7.13.1. Along with a few bug fixes and improvements, it also introduced an exciting new feature: URL masking through the new <Link unstable_mask={...}> API for Framework and Data Mode. This API now provides a first-class way to handle contextual routing. But what exactly is contextual routing?

Already familiar with contextual routing? Feel free to skip ahead to the API section. If not, let’s quickly break it down first.

Contextual Routing

What Is Contextual Routing?

Contextual Routing means that the same URL might lead to different routes depending on how it was reached.

At first, that might sound like inconsistent behavior, but it really isn't once the context is clear.

For example, imagine you are browsing a product catalog and click on a product. Instead of opening as a separate page, the product details show up in a modal (overlay on top of the catalog). That is great for UX because you can quickly check the product without moving away from the catalog.

Now suppose you want to share that product URL with a friend. Without contextual routing, that same URL could open the catalog page with the modal on top, which is not ideal because your friend only needs the product page, not the catalog in the background.

This is where contextual routing comes in. When you open the product from the catalog, the catalog stays in the background and the details appear in a modal. But when your friend visits the same URL directly, the app renders the full product page instead.

How Contextual Routing Works

Now you know what contextual routing is, but how does it actually work? The neat trick here is that we make the browser mask the real URL and instead display a URL that we want.

So when you click a product and the modal opens, the URL in the address bar is not really the one you were routed to. We mask the original URL with the one for that product’s detail page. This is why, when you share that URL or open it in a new tab, it opens as the full product detail page instead of reopening the product catalog with the modal on top.

Reddit Example

To better understand this concept, let’s see how Reddit uses contextual routing.

In Reddit’s home feed, clicking on an image opens it in a modal while keeping the home feed in the background.

Now, if you copy that URL and open it in a new tab, it opens the detailed view for that post.

Using the URL Masking API in React Router

This part is really easy, and I mean really easy. To enable URL Masking, all you have to do is add the unstable_mask prop to the Link component, and that’s it. Congratulations, you have now enabled contextual routing.

<Link
    to={"actual url string"} 
    unstable_mask={"masked url string"} 
>

Here's an example from the official documentation:

export default function Gallery({ loaderData }: Route.ComponentProps) {
  return (
    <>
      <GalleryGrid>
       {loaderData.images.map((image) => (
         <Link
           key={image.id}
           to={`/gallery?image=${image.id}`}
           unstable_mask={`/images/${image.id}`}
         >
           <img src={image.url} alt={image.alt} />
         </Link>
       ))}
      </GalleryGrid>

      {data.modalImage ? (
        <dialog open>
          <img src={data.modalImage.url} alt={data.modalImage.alt} />
        </dialog>
      ) : null}
    </>
  );
}

View this example in

⚠️ Caution

Keep these points in mind when using the unstable_mask API:

1 - According to the official documentation, this feature is intended only for SPA use, and SSR renders do not preserve the masking.

"This feature relies on history.state and is thus only intended for SPA uses and SSR renders will not respect the masking."

— React Router Documentation

2 - This API is still unstable, so it may go through changes before it is safe to rely on in production.

Hopefully, this article gave you a clear idea of what contextual routing is and how the new URL Masking API makes it easier to implement. If you have any questions, feel free to comment below.

Creating a Multi-Part Form Easily with React-Router (No Third-Party Libraries)

Azfar Razzaq — Tue, 20 May 2025 11:33:44 +0000

Introduction

Ever completed a long form only to hit Submit and get an error that erases everything or blocks submission? We’ve all felt that frustration, and as front-end developers we want to spare our users the same pain. Multi-part (multi-step) forms solve the problem by breaking one large form into smaller, validated stages. A well-designed multi-part form must:

Validate input at each step
Let users move back and forth without losing progress

Most guides lean on extra form libraries, which add bundle size and complexity. Yet React Router v6/v7 already ships the tools we need—loaders, actions, <Outlet>, and outlet context—so we can build a multi-part form with zero third-party dependencies. In this article we’ll do exactly that.

Prerequisites & Tech Stack

This article is structured as a beginner-friendly tutorial you can follow step by step. However, you'll get the most out of it if you're already familiar with:

Basic React (hooks, functional components)
How React Router’s loader and action functions work

Tool	Version	Notes
React	18.x/19.x	Hooks and Suspense support
React Router	v7 (framework mode)	Server loaders/actions
Vite (dev tool)	latest	Fast local builds

(You can reproduce the same project in SPA mode or in React Router v6 with minor tweaks—but they only provide client-side loaders/actions.)

Core React Router APIs we’ll use

<Outlet> – renders the active child route
Outlet context – passes shared state to child routes (similar to React Context)
useSubmit() – imperatively post data to an action

Project Scenario (What We’re Building & Why)

We will create a form to register a sale record for a beauty salon, with just two stages, to keep our examples as minimal as possible. The form is going to be divided into the following two parts:

Part 1: Entering the client's mobile number. This stage allows us to validate whether a client with the provided phone number exists within the database.
Part 2: Entering the rest of the information, such as the service taken, the amount charged, and the employee who provided the service. The reason for dividing this form into two parts is that if a client doesn't exist in the database, the user is notified about that in the first stage, enabling them to register the client first instead of filling all the information in the form only to realize the client isn't registered in the system.

## 1. Project Setup

1.1 Clone the Starter / Finished Repo

Starter code
If you'd like to follow along, you can use the project’s starter repo. All routes, route files, and utility functions are already set up, so you can focus entirely on implementing the multi-part form logic.

Azfar731 / multi_part_form_starter

Creating a Multi-Part Form Easily with React-Router

This is a starter repository that accompanies a tutorial on implementing multi-part forms in React using React Router v7, without relying on any third-party form libraries. This project demonstrates how to create a clean, maintainable, and user-friendly multi-step form implementation using only React Router's built-in features.

Complete Project Repository: Multi-Part-Form

Features

Multi-step form implementation in React Router
Manage form state between different steps
Handle form navigation and validation
Process and submit form data
Includes mock data(for replicating db behaviour)
No third-party form libraries required

Tech Stack

React
React Router
TypeScript
Vite

Project Structure

app/
├── routes/
│   ├── home.tsx                 # Home page
│   ├── record.tsx              # Record view
│   └── create_record/          # Multi-part form implementation
│       ├── form_part1.tsx      # First step of the form
│       ├── form_part2.tsx      # Second step of the form
│       └── route.tsx           # Form route configuration
├── data/                       #

…

View on GitHub

2. Define the Routing Structure

2.1 Route Map Overview

To implement a multi-part form, we must structure the routes with a parent route that shares form state with its child routes, where each child route represents a stage of the form.
The route configuration for the app is defined in the /app/route.ts file. We will create the following routes
- / : root route(containing a single button for us to access form)
- /create_record: parent route containing all form stages as child routes
- index: the index route that gets displayed by default. This will be from part 1
- form_part2: This will contain form part 2
- /record: For displaying a single record of information(optional)

Our route.ts file will look like the following

//route.ts file
import { type RouteConfig, index, route } from "@react-router/dev/routes";

export default [
  index("routes/home.tsx"),
  route("/record", "routes/record.tsx"),
  route("/create_record", "routes/create_record/route.tsx", [
    index("routes/create_record/form_part1.tsx"),
    route("form_part2", "routes/create_record/form_part2.tsx"),
  ]),
] satisfies RouteConfig;

2.2 Create Route Files

Next, we need to create the files that the routes will translate to. A common convention is to place these files in the /app/routes directory.
The routes directory will have the following structure:

Routes
- home.tsx (/)
- record.tsx( /record)
- create_record(Directory)
  - route.tsx(/create-record) => This will be the file within which child routes will be rendered
  - form_part1.tsx(/create-record) => index route, containing form part 1
  - form_part2.tsx(/create-record/form_part2) => contains form part 2

3. Build the Multi-Part Form

Let's start building the main application.

3.1 Creating support files

The steps in this section have already been completed in the starter repo.

Creating root route

This will be a simple file(home.tsx) that only contains a link for us to navigate to our form.

Displaying details of a Service Record:

This route is used to display the properties of a record.

Creating DB

Well, the heading here is a bit misleading, as for the sake of the tutorial, we will not be using an actual DB, but pre-populate some json files instead. These files will store info about clients, services and employees.

Creating Utility functions

I placed the functions for interacting with the json files, inside the app/utils/functions.ts file.

3.2 Parent Route – Outlet & Shared State

3.2.1 Passing Context to Child Routes:

This file will serve as the source of truth for the child routes, meaning that the state that will be used to store the form's data will be declared in this route. The main component that will be utilised in this file is the Outlet. The Outlet component is used to specify where the child routes will render.
The form state will be passed to the child routes using the context parameter in the Outlet component. We will pass an object containing the following:

formData: The current state
setFormData: The function to update the state

import { useState } from "react";
import { Outlet } from "react-router";

export default function CreateSaleRecord() {
  const [formData, setFormData] = useState({
    amount_charged: 0,
    mobile_num: "",
    service: "",
    employee: "",
  });

  return (
    <div className="bg-white text-black flex flex-col items-center justify-center h-screen">
      <Outlet context={{ formData, setFormData }} />
    </div>
  );
}

3.3 Part 1 – Client Lookup Form:

The purpose of this file is the following:

Prompt the user to enter the client's mobile number.
Validate that a client with the provided mobile number exists within the DB.

3.3.1 Form UI

The first thing that we need to do is to access the state and the setter function passed to the child routes. Outlet Context allows us to access the parameters passed through Outlet.


import { useOutletContext } from "react-router";
import type { FormType } from "~/utils/types"; //custom defined type for the formData state variable

export default function Form_Part1() {

  const { formData, setFormData } = useOutletContext<{
    formData: FormType;
    setFormData: React.Dispatch<React.SetStateAction<FormType>>;
  }>();

    return(
        //... form
    )
  }

Now let's define a form with a single input field for a mobile number. We’ll use formData.mobile_num to control this input field.

export default function Form_Part1() {

  const { formData, setFormData } = useOutletContext<{
    formData: FormType;
    setFormData: React.Dispatch<React.SetStateAction<FormType>>;
  }>();

  return (
    <div className="flex justify-center items-center min-h-screen">
      <Form
        method="post"
        className="bg-white p-6 rounded shadow-md w-80"
      >
        <label
          htmlFor="mobile_num"
          className="block text-gray-700 text-sm font-bold mb-2"
        >
          Enter Client Mobile Number
        </label>
        <input
          type="text"
          id="mobile_num"
          name="mobile_num"
          pattern="[0-9]*"
          defaultValue={formData.mobile_num}
          onChange={(e) =>
            setFormData((prev) => ({
              ...prev,
              mobile_num: e.target.value,
            }))
          }
          className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
          required
        />

        <button
          type="submit"
          className="w-full bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded "
        >
          Next
        </button>
      </Form>
    </div>
  );
}

3.3.2 `action` Validation & Redirect

We have defined the form, and the first objective of the file is complete. But what happens when we click Next? For this purpose, we have to define React-Router's server action function, which will help us validate the input.
Here's how the action function will work:

Access submitted form data.
Check whether a client exists against the submitted mobile number
If the client exists, redirect the user to the second part of the form.
If the client doesn't exist, return a message indicating that a client with the provided mobile number doesn't exist in the DB.

import {
  redirect
  type ActionFunctionArgs
} from "react-router";
import { getClientbyMobileNumber } from "~/utils/functions";

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const mobile_num = formData.get("mobile_num")?.toString() || "";
  if (!mobile_num) {
    return { error: "No mobile number received" };
  }

  // Fetch the client
  const client = await getClientbyMobileNumber(mobile_num);
  if (!client) {
    return { error: `No client with mobile number: ${mobile_num} found` };
  }

  const redirectUrl = `form_part2?mobile_num=${encodeURIComponent(mobile_num)}`;
  //redirect user to the second part of the form
  throw redirect(redirectUrl);
}

The complete form_part1.tsx file:

import {
  Form, replace, useActionData,
  useOutletContext,
  type ActionFunctionArgs
} from "react-router";
import type { FormType } from "~/utils/types";
import { getClientbyMobileNumber } from "~/utils/functions";

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const mobile_num = formData.get("mobile_num")?.toString() || "";
  if (!mobile_num) {
    return { msg: "No mobile number received" };
  }

  // Fetch the client
  const client = await getClientbyMobileNumber(mobile_num);
  if (!client) {
    return { error: `No client with mobile number: ${mobile_num} found` };
  }

  const redirectUrl = `form_part2?mobile_num=${encodeURIComponent(mobile_num)}`;
  throw replace(redirectUrl);
}

export default function Form_Part1() {
  const actionData = useActionData<{ error: string }>();
  const { formData, setFormData } = useOutletContext<{
    formData: FormType;
    setFormData: React.Dispatch<React.SetStateAction<FormType>>;
  }>();

  return (
    <div className="flex justify-center items-center min-h-screen">
      <Form
        method="post"
        className="bg-white p-6 rounded shadow-md w-80"
      >
        <label
          htmlFor="mobile_num"
          className="block text-gray-700 text-sm font-bold mb-2"
        >
          Enter Client Mobile Number
        </label>
        <input
          type="text"
          id="mobile_num"
          name="mobile_num"
          pattern="[0-9]*"
          defaultValue={formData.mobile_num}
          onChange={(e) =>
            setFormData((prev) => ({
              ...prev,
              mobile_num: e.target.value,
            }))
          }
          className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
          required
        />
        {actionData ? (
          <div className="text-red-700">{actionData.error}</div>
        ) : undefined}
        <button
          type="submit"
          className="w-full bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
        >
          Next
        </button>
      </Form>
    </div>
  );
}

3.4 Part 2 – Service Details Form

This file serves the following purposes:

Use the loader function to fetch client details based on the mobile number in the search parameters. If the client doesn't exist in the database, redirect to Part 1 of the form. The loader then passes the fetched client object and any additional required data to the component.
Collect user input through a Form.
Submit the complete formData as a JSON object to the action function.

3.4.1 Fetching Data

In the loader function, we will access the search parameter through the request Web API. If the client exists, we proceed to fetch the services and employees from the DB and pass them to the component.

import { replace, type LoaderFunctionArgs } from "react-router"
import {
  createServiceRecord,
  getAllEmployees,
  getClientbyMobileNumber,
  getAllServices,
} from "~/utils/functions";


export async function loader({ request }: LoaderFunctionArgs) {
  const mobile_num = new URL(request.url).searchParams.get("mobile_num");
  if (!mobile_num) {
    throw replace(`/create_record`);
  }
  const client = getClientbyMobileNumber(mobile_num);
  if (!client) {
    throw replace(`/create_record`);
  }
  const services = await getAllServices();
  const employees = await getAllEmployees();
  return { client, services, employees };
}

3.4.2 Form UI

Just like in Form Part 1, we need to access the state and its setter using useOutletContext. This stage of the form includes the following fields:

Service
Employee
Amount Charged

In addition to what we implemented earlier, we’ll introduce one more hook: useNavigate. This hook will be used to navigate back to the previous form when the user clicks the button.

const { client, services, employees } = loaderData;

  const { formData, setFormData } = useOutletContext<{

    formData: FormType;

    setFormData: React.Dispatch<React.SetStateAction<FormType>>;

  }>();

  const actionData = useActionData<{ error?: string }>();
  const navigate = useNavigate();
  
return (
    <Form
      method="post"
      className="bg-white p-6 rounded shadow-md w-80 text-black"
    >
      <div className="block text-gray-700 text-sm font-bold mb-2">
        Client Name:{" "}
        <span className="font-semibold">
          {`${client.first_name} ${client.last_name}`}
        </span>
      </div>
      <div className="block text-gray-700 text-sm font-bold mb-2">
        Mobile Number:{" "}
        <span className="font-semibold">{client.mobile_number}</span>
      </div>

      <label
        htmlFor="service"
        className="block text-gray-700 text-sm font-bold mb-2"
      >
        Select Service
      </label>
      <select
        name="service"
        id="service"
        required
        className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
        value={formData.service}
        onChange={(e) =>
          setFormData((prev) => ({
            ...prev,
            service: e.target.value,
          }))
        }
      >
        <option value="">-- Select a Service --</option>
        {services.map((service) => (
          <option key={service.id} value={service.id}>
            {service.name}
          </option>
        ))}
      </select>

      <label
        htmlFor="amount_charged"
        className="block text-gray-700 text-sm font-bold mb-2"
      >
        Amount Charged
      </label>
      <input
        type="number"
        name="amount_charged"
        id="amount_charged"
        className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
        min={0}
        required
        value={formData.amount_charged}
        onChange={(e) =>
          setFormData((prev) => ({
            ...prev,
            amount_charged: Number(e.target.value),
          }))
        }
      />

      <label
        htmlFor="employee"
        className="block text-gray-700 text-sm font-bold mb-2"
      >
        Select Employee
      </label>
      <select
        name="employee"
        id="employee"
        required
        className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
        value={formData.employee}
        onChange={(e) =>
          setFormData((prev) => ({
            ...prev,
            employee: e.target.value,
          }))
        }
      >
        <option value="">-- Select an Employee --</option>
        {employees.map((employee) => (
          <option key={employee.id} value={employee.id}>
            {employee.first_name} {employee.last_name}
          </option>
        ))}
      </select>
      {actionData?.error && (
        <div className="text-red-700">{actionData.error}</div>
      )}

      <div className="flex justify-between items-center mt-6">
        <button
          type="button"
          onClick={() => navigate(`/create_record`)}
          className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
        >
          Previous
        </button>
        <button
          type="submit"
          className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded disabled:bg-gray-400 disabled:cursor-not-allowed"
        >
          Next
        </button>
      </div>
    </Form>
  );
}

3.4.3 Submit Entire Form with `useSubmit`

We’re almost done, but there’s one last step. Since a multi-part form doesn’t include fields from previous steps, we’ll submit the state variable instead—it holds all the required data.
To accomplish this, we’ll use the useSubmit hook, which enables sending data to the action function in different formats. In our case, we’ll use it to send data as JSON. The steps are as follows:

Declare the useSubmit hook variable.
Define a handleSubmit function for the form.
Inside handleSubmit, use the useSubmit variable to send the data to the action function

Defining the useSubmit hook variable:

import { useSubmit } from "react-router"

export default function Form_Part2({loaderData}: Route.ComponentProps){
const submit = useSubmit()

//...rest of the code
}

Define the handleSubmit function for the form:


const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    submit(formData, { method: "post", encType: "application/json" });
};
return (
    <Form
      method="post"
      onSubmit={handleSubmit}
      className="bg-white p-6 rounded shadow-md w-80 text-black">
    {/*...input fields*/}
    </Form>
)

We set the encType to application/json to submit the data in JSON format.

3.4.3 Accessing Data in `action`

All that is left is to define the action function.

export async function action({ request }: LoaderFunctionArgs) {
  const data = await request.json();
  const { mobile_num, service, amount_charged, employee } = data;

  //perform validation. Usually done through a library like zod or yup

  if (!service || !amount_charged || !employee || !mobile_num) {
    return { error: "All fields are required" };
  }

  //include other validations as needed. important to redo all validations done in previous steps too


  //for the sake of the tutorial, we are just going to pass the data to the `record` URL through search parameters instead of creating a record

  const params = new URLSearchParams({
    mobile_num,
    service,
    amount_charged: amount_charged.toString(),
    employee
  });
  const redirect_url = `/record?${params.toString()}`;
  console.log("redirect_url: ", redirect_url);
  throw replace(redirect_url)
}

So after a record is successfully created, it redirects the user to the /record URL.

Here is the complete form_part2.tsx file

import {
  Form,
  redirect,
  replace,
  useActionData,
  useNavigate,
  useOutletContext,
  useSubmit,
  type LoaderFunctionArgs,
} from "react-router";
import {
  createServiceRecord,
  getAllEmployees,
  getClientbyMobileNumber,
  getAllServices,
} from "~/utils/functions";
import type { Route } from "./+types/form_part2";
import type { FormType } from "~/utils/types";

export async function loader({ request }: LoaderFunctionArgs) {
  const mobile_num = new URL(request.url).searchParams.get("mobile_num");
  if (!mobile_num) {
    throw replace(`/create_record`);
  }
  const client = getClientbyMobileNumber(mobile_num);
  if (!client) {
    throw replace(`/create_record`);
  }
  const services = await getAllServices();
  const employees = await getAllEmployees();
  return { client, services, employees };
}

export async function action({ request }: LoaderFunctionArgs) {
  const data = await request.json();
  const { mobile_num, service, amount_charged, employee } = data;

  //perform validation. Usually done through a libarary like zod or yup

  if (!service || !amount_charged || !employee || !mobile_num) {
    return { error: "All fields are required" };
  }

  //include other validations as needed. important to redo all validations done in previous steps before creating a record in DB

  //create the record

  const params = new URLSearchParams({
    mobile_num,
    service,
    amount_charged: amount_charged.toString(),
    employee
  });
  const redirect_url = `/record?${params.toString()}`;
  console.log("redirect_url: ", redirect_url);
  throw replace(redirect_url)
}

export default function FormPart2({ loaderData }: Route.ComponentProps) {
  const { client, services, employees } = loaderData;
  const { formData, setFormData } = useOutletContext<{
    formData: FormType;
    setFormData: React.Dispatch<React.SetStateAction<FormType>>;
  }>();
  const actionData = useActionData<{ error: string }>();
  const navigate = useNavigate();
  const submit = useSubmit();

  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    submit(formData, { method: "post", encType: "application/json" });
  };

  return (
    <Form
      method="post"
      onSubmit={handleSubmit}
      className="bg-white p-6 rounded shadow-md w-80 text-black"
    >
      <div className="block text-gray-700 text-sm font-bold mb-2">
        Client Name:{" "}
        <span className="font-semibold">
          {`${client.first_name} ${client.last_name}`}
        </span>
      </div>
      <div className="block text-gray-700 text-sm font-bold mb-2">
        Mobile Number:{" "}
        <span className="font-semibold">{client.mobile_number}</span>
      </div>

      <label
        htmlFor="service"
        className="block text-gray-700 text-sm font-bold mb-2"
      >
        Select Service
      </label>
      <select
        name="service"
        id="service"
        required
        className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
        value={formData.service}
        onChange={(e) =>
          setFormData((prev) => ({
            ...prev,
            service: e.target.value,
          }))
        }
      >
        <option value="">-- Select a Service --</option>
        {services.map((service) => (
          <option key={service.id} value={service.id}>
            {service.name}
          </option>
        ))}
      </select>

      <label
        htmlFor="amount_charged"
        className="block text-gray-700 text-sm font-bold mb-2"
      >
        Amount Charged
      </label>
      <input
        type="number"
        name="amount_charged"
        id="amount_charged"
        className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
        min={0}
        required
        value={formData.amount_charged}
        onChange={(e) =>
          setFormData((prev) => ({
            ...prev,
            amount_charged: Number(e.target.value),
          }))
        }
      />

      <label
        htmlFor="employee"
        className="block text-gray-700 text-sm font-bold mb-2"
      >
        Select Employee
      </label>
      <select
        name="employee"
        id="employee"
        required
        className="w-full px-3 py-2 border border-gray-300 rounded-md mb-4"
        value={formData.employee}
        onChange={(e) =>
          setFormData((prev) => ({
            ...prev,
            employee: e.target.value,
          }))
        }
      >
        <option value="">-- Select an Employee --</option>
        {employees.map((employee) => (
          <option key={employee.id} value={employee.id}>
            {employee.first_name} {employee.last_name}
          </option>
        ))}
      </select>
      {actionData?.error && (
        <div className="text-red-700">{actionData.error}</div>
      )}

      <div className="flex justify-between items-center mt-6">
        <button
          type="button"
          onClick={() => navigate(`/create_record`)}
          className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
        >
          Previous
        </button>
        <button
          type="submit"
          className="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded disabled:bg-gray-400 disabled:cursor-not-allowed"
        >
          Next
        </button>
      </div>
    </Form>
  );
}

Conclusion:

In this article, we've successfully demonstrated how React Router v7 provides built-in capabilities to effortlessly create multi-part forms without relying on third-party libraries. By leveraging essential React Router APIs such as loaders, actions, , and outlet context, we've implemented form validation at each stage, seamless navigation between form steps, and efficient state management. This approach not only simplifies your codebase but also enhances performance by reducing dependencies. You can now confidently extend these concepts to build multi-step forms tailored to your application's needs.

Live Sandbox and Github Repository

Access the live StackBlitz demo and full GitHub repository here.

stackblitz.com

Azfar731 / multi_part_form

Creating a Multi-Part Form Easily with React-Router

This repository contains the source code for the tutorial article "Creating a Multi-Part Form Easily with React-Router (No Third-Party Libraries)". It demonstrates how to implement a multi-step form using only React Router's built-in capabilities, without relying on any additional form management libraries.

Features

Multi-step form implementation in React Router
Manage form state between different steps
Handle form navigation and validation
Process and submit form data
Includes mock data(for replicating db behaviour)
No third-party form libraries required

Tech Stack

React
React Router
TypeScript
Vite

Getting Started

Clone the repository:

git clone <your-repo-url>

Install dependencies:

npm install

Run the development server:

npm run dev

Project Structure

app/
├── routes/
│   ├── home.tsx                 # Home page
│   ├── record.tsx              # Record view
│   └── create_record/          # Multi-part form implementation
│       ├── form_part1.tsx      # First step of the form
│       ├── form_part2.tsx      # Second step

…

View on GitHub

Feel free to drop any questions in the comments, and I'd love to hear your thoughts on this approach.

DEV Community: Azfar Razzaq

Google Lighthouse for Beginners: A Real Portfolio Optimization Case Study

Prerequisite

Before You Run Lighthouse

How to Analyze Lighthouse Results

How I Optimized My Portfolio

Pre-Optimization Results

Initial Mobile Performance Breakdown

Acting on the Lighthouse Insights

Reducing JavaScript Bundle Size

Self-Hosting Google Fonts

Using WOFF2 instead of TTF

Prioritizing the LCP Image

Optimizing Image Sizes

Results After Optimization:

What I Did Not Fix

How to Keep Track of Performance Over Time

Conclusion

React Router Now Supports Contextual Routing with

Contextual Routing

What Is Contextual Routing?

How Contextual Routing Works

Reddit Example

Using the URL Masking API in React Router

Further Reading

Creating a Multi-Part Form Easily with React-Router (No Third-Party Libraries)

Introduction

Prerequisites & Tech Stack

Project Scenario (What We’re Building & Why)

## 1. Project Setup

1.1 Clone the Starter / Finished Repo

Azfar731 / multi_part_form_starter

Creating a Multi-Part Form Easily with React-Router

Features

Tech Stack

Project Structure

2. Define the Routing Structure

2.1 Route Map Overview

2.2 Create Route Files

3. Build the Multi-Part Form

3.1 Creating support files

Creating root route

Displaying details of a Service Record:

Creating DB

Creating Utility functions

3.2 Parent Route – Outlet & Shared State

3.2.1 Passing Context to Child Routes:

3.3 Part 1 – Client Lookup Form:

3.3.1 Form UI

3.3.2 action Validation & Redirect

3.4 Part 2 – Service Details Form

3.4.1 Fetching Data

3.4.2 Form UI

3.4.3 Submit Entire Form with useSubmit

3.4.3 Accessing Data in action

Conclusion:

Live Sandbox and Github Repository

Azfar731 / multi_part_form

Creating a Multi-Part Form Easily with React-Router

Features

Tech Stack

Getting Started

Project Structure

Further Reading / Related Documentation

Using `WOFF2` instead of `TTF`

3.3.2 `action` Validation & Redirect

3.4.3 Submit Entire Form with `useSubmit`

3.4.3 Accessing Data in `action`