You scroll a little more, and someone is claiming that a new AI tool released last week has already made entry-level developers obsolete. You go to YouTube, and a thumbnail screams that all technologies are dead, all developer jobs are dead, and at the same time, a solo founder claims that they've built a million-dollar full-stack app in five minutes using AI agents.

At some point, you start feeling overwhelmed. You start to question and doubt the nights you've spent learning something, building something. You wonder whether the effort you're putting into mastering a programming language or framework still makes sense. You start asking yourself an extremely uncomfortable question: "Is my career still safe?"

This concern is valid. Instead of dismissing the concern with a lot of motivational talk or toxic positivity, let's do a reality check. The industry is fundamentally changing. Hiring patterns are shifting. Expectations for both junior and senior developers are rising exponentially. And yes, AI is the main catalyst accelerating all these changes.

But there is a massive misunderstanding around what's going on. The narrative that "AI is replacing developers" lacks a lot of details. It has created unnecessary fear because it fails to specify what's actually happening.

Not many devs are coming up to explain these details because a good portion of us are still observing, and some are steering the fear to their individual benefits.

Well, here's my take: AI isn't replacing all software engineers. It's replacing a specific kind of work. The low-level, average, routine execution work is getting replaced with AI much faster than anyone could imagine. As a result, it's forcing us to think of what it means to be a software engineer in today's market.

This article is about that thought process. It's a deep dive into the changing landscape of software development, the shift from effort-based to impact-based engineering, and a practical, actionable roadmap to enable you to remain relevant in the era of AI-assisted coding.

Table of Contents

1. The End of the Tutorial-Driven Era

2. Let's Decode the "AI is Taking Jobs" Myth

3. Applying a Clean Architecture

4. A Practical, AI-Era Engineering Roadmap

   • Step 1: Strengthen Your Fundamentals

   • Step 2: Build Real (Uncomfortable) Systems

   • Step 3: Master the Art of Debugging

   • Step 4: Use AI as a Tool, Not as a Crutch

   • Step 5: Establishing a Strong Proof of Work

5. The Must-Needed Mindset Shift

6. If You've Read This Far...

The End of the Tutorial-Driven Era

Let's step back for a moment and look at how most of us learned to develop software over the last decade or so.

Between 2010 and 2023, the industry was filled with tutorial-driven developers. We learned to build software by following step-by-step instructions.

Applications like TODO Apps, Weather dashboards, or clones of YouTube or Spotify were in high demand among developers. These projects gave us confidence. They helped us memorise syntax, learn how to use libraries, and figure out how to write a basic frontend and backend.

For a long time, this was enough. The goal was simple: "Can I build this full-stack application that works?"

If you could write code, connect to a few APIs, and build a working interface, companies were willing to hire you. They viewed junior developers as an investment. The expectation was that you should be trainable: you would come in, write standard boilerplate code, and learn the complexities of the system architecture on the job. The industry had the budget and patience for that learning curve.

But while memorizing the syntax and completing Udemy courses, the tooling was quietly evolving. Today, AI has taken that to a different extreme.

A significant portion of what we used to learn manually can now be generated, assisted, and suggested by AI in seconds.

• Need a basic Express server setup with rate limiting and CORS integrated? Can be generated.

• Need a responsive navigation bar written in React? Can be assisted.

• Need a standard SQL query to fetch company data? Can be suggested.

If a machine can do something exponentially faster, cheaper, and reasonably well, that specific task stops being the differentiator in the job market. So, when people say AI is replacing junior developers, what they mean is that AI has automated the execution of these surface-level tasks.

But does it mean developers are no longer needed? No, it means the value of our work has moved up the stack. Building a TODO app, a Weather dashboard, or website clones is no longer a portfolio item. They're just your warm-up exercises.

Let's Decode the "AI is Taking Jobs" Myth

Traditionally, software engineers were given requirements: they wrote code, and they ensured it worked. The value of a software engineer was tied to their work execution. Even in interviews, the emphasis was on effort and memory:

• Can you write a linked list from scratch?

• Can you check if this text is a palindrome?

• Can you find the duplicates in this array of numbers?

If you were a developer who put in long hours analyzing problem statements, manually debugging critical issues, and hand-crafting thousands of lines of source code, you were seen as a dedicated, high-valued employee.

Today, the effort alone is no longer a metric for success.

If you spend hours writing regular expressions or standard authentication flows that an AI agent can scaffold within two minutes, the industry doesn't reward you for your six hours of hard work. The industry asks: "What value did you add beyond what the machine generated?"

This is an uncomfortable truth, but accepting it could be the turning point in your career. Once you accept that AI can write code, your mindset shifts. You start accepting that you no longer have to worry about your execution speed, and you need to focus on System Composition and Abstract Thinking.

If you're a front-end developer today, your job is no longer limited to translating a Figma design into pixel-perfect React components. An AI coding assistant can do 80% of that in a few constructive prompts. Your job role expectations as a front-end developer are now shifted to:

• When that UI connects to the backend, and 10K users log in concurrently, how does the system behave?

• Suppose a customer has an SLA (Service Level Agreement) stating that the dashboard must render with all data in 1.2 seconds on a slow 4G network, in 500 ms on a fast 4G network, and in 12 ms on a 5G network. How do you architect your Next.js application to meet that?

• Are you leveraging server-side rendering, static generation, or edge caching correctly?

• How does the application behave for users depending on screen readers?

Source code is no longer the primary output. It should be the byproduct of your thinking and reasoning. You need to anticipate edge cases, and most importantly, you need to take ownership.

AI can write an API, but AI can't sit in a meeting with a furious client and explain why the production database went down. AI cann't own the consequences of a system failure. That accountability belongs entirely to you.

Applying a Clean Architecture

Suppose you ask an LLM to build a complex application, say, an e-commerce product dashboard with sorting, filtering, and pagination. It will gladly generate the code that you'll be able to run and render on the browser. Bur AI has a very peculiar tendency in that it loves to build monoliths.

The AI will likely output a massive 1000+ line React component. The state management, UI rendering, data fetching, and business logic will be clubbed together in a single file. So it'll technically work in the browser, but it will be a nightmare to test, maintain, and scale.

This is where the human software engineers come in. A modern engineer understands clean code principles and design patterns. Instead of accepting the monolith AI output blindly, the engineer thinks in terms of LEGO-block compositions of React components.

A capable engineer looks into the requirements and thinks, " We shouldn't put everything in a single file. Let's use the Compound Components Pattern here to make the UI flexible. Let's use the Slot Pattern to create holes in our layout so consumers of this component can pass in their own custom elements without breaking the underlying logic."

You apply abstract thinking. You ask architectural questions:

• How are we managing side effects vs. the data fetching?

• Can we swap out the payment provider later with a very small code change?

• What happens if the network drops while the user is filtering?

AI provides us with the bare metal raw materials. We need to provide the engineering discipline on top of it to make it production-ready.

A Practical, AI-Era Engineering Roadmap

Now, it's time to think about how to bridge the gap between a tutorial-driven developer and a modern, impact-driven engineer. Here is a practical stage-by-stage roadmap for you.

Step 1: Strengthen Your Fundamentals

You can't use AI effectively if you don't understand the code it generates. In the past, a surface-level knowledge of a framework would have been enough for you to execute your tasks. You might have gotten away without knowing the "under the hood" aspects of it.

Today, AI abstracts the frameworks. If something breaks underneath, you're multiple layers away from the actual problem. Having a strong fundamental knowledge will help you to battle this situation, and you'll enjoy working with AI even more.

You must go deep into the fundamentals of Computer Science & Web Technologies:

• How does the internet work? Understand Networking basics.

• Don't just learn to write JavaScript promises. Learn about the event loop. Understand the call stack, the microtask queue, and how memory allocation works.

• When a React application has a memory leak, AI will struggle to find it if it spans multiple files. You need to know how to use Chrome DevTools memory profilers.

• Instead of focusing on random algorithmic puzzles, focus on applied abstract thinking. If you're building a real-time collaborative document editor, how do you manage the data structure for concurrent edits? This is how DSA is tested in this era of technical interviews.

Step 2: Build Real (Uncomfortable) Systems

Stop building TODO apps. Stop building basic CRUD applications that only work in an ideal, localhost environment. Learn to build systems to handle failures.

Instead of building a generic e-commerce clone, build an Automated E-book Delivery and Waitlist system. For example,

• The stack: Tanstack Start for the front end, NestJS for the API, Supabase for the database, Razorpay for payment processing, Firebase for social logins, and Resend for email delivery.

• The challenge: Don't be satisfied with just making the happy path work. What happens if the Razorpay webhook fails to reach your server after a user pays? How do you implement a retry mechanism? How do you secure your Supabase database with RLS (Row Level Security) so users can only download the book they paid for? How do you prevent duplicate sign-ups on your waitlist?

When you build systems like this, you naturally run into complex real-world problems. Solving these, you'll build the exact engineering muscles that companies are now desperate to hire.

Step 3: Master the Art of Debugging

When the system breaks in production, panic starts. The developers who can stay calm, isolate assumptions, trace problems, and fix them are invaluable.

AI is great at explaining isolated error messages, but it can't easily debug a distributed system where a frontend state mismatch is caused by a race condition in a backend microservice. That's on you to burn the midnight oil and get it done.

As a software developer at any level:

• Learn how to implement structured logging in your code.

• Learn how to read a stack trace systematically.

• Practice fixing performance bottlenecks without causing regressions in other parts of the application.

• Understand Web Vitals (LCP, CLS, INP, and so on.) and how to profile a slow rendering page.

Step 4: Use AI as a Tool, Not as a Crutch

First of all, stop blind copy-pasting AI responses. Treat AI like an incredibly fast, highly confident, but slightly carefree junior developer.

• Use it for boilerplate: Need an ExpressJS setup? Zustand store set up? Generate it.

• Use it for research: Learning a new thing like Rust, Go, or Cybersecurity? Prompt the AI to generate a 30-day learning roadmap tailored to your existing programming language knowledge.

• Use it for content: Want to write a READ ME file? Want to brainstorm a DRAFT idea? AI can be your companion.

• Use it for scaffolding: Need to write unit tests for a utility function? Let AI scaffold the test suites.

Note, every time you copy code from an LLM without understanding it, you're creating tech debt unknowingly. Your job is to make the AI's response as optimal as possible for production.

If you prompt an AI to write a complex data aggregation logic, and it outputs 72 lines of reducer function, don't just copy-paste it. Read it line-by-line, and ask yourself: Is this optimal? What's the Big O time complexity of this code? Can I make it more readable?

Step 5: Establishing a Strong Proof of Work

A résumé listing your skills or a certificate from a bootcamp aren't very strong proof of work achievements today.

Strong proof of work looks like:

• A GitHub repository featuring a complex real-world application with a beautifully written README explaining the architectural choices.

• Meaningful contributions to the open-source projects where your code had to pass serious reviews from senior maintainers.

• Writing deep tech articles or LinkedIn posts explaining how you solved a difficult rendering bug or why you chose a specific database schema for a project.

• Participating in a hackathon to build something that is either trendy, or has potential to go viral, or can bring revenue, or a combination of all of these.

Don't just code in silos. Build in public. Explain your thought process socially. When you articulate your engineering thoughts and decisions publicly, it separates you from millions of developers who are just relying on the response from ChatGPT or any other AI tools.

The diagram below captures all five steps visually for you to connect them and revisit at any point in time.

You can download this tech frame and many others from here.

The Must-Needed Mindset Shift

"It all begins and ends in your mind. What you give power to, has power over you" - by Leon Brown

If you're currently looking for a job, you need to immediately stop asking people, "Will I get a Job?" It's the wrong question. You can't be sure you'll get a job if you don't have a convincing reason why a company should hire you.

Instead, look at the job descriptions. Look at the companies you admire. Then ask yourself: "Why should they hire me in today's circumstances?"

If you don't have a convincing answer yet, that's perfectly fine! That's your baseline, and you've identified your skill gap. Your mission now is to bridge that gap.

We've entered a phase where the definition of a software engineer is sharper and more demanding than ever before. The bar is higher, but the expectations are clearer. If you refuse to adapt and insist on staying at the level of simple execution, the path forward will likely be incredibly difficult. You'll compete with AI tools that never sleep and developers who are utilizing those tools to do the work of three people.

But if you embrace the shift and move toward abstract thinking, deep fundamentals, system architecture, and true accountability, the opportunities are limitless. You're no longer competing with everyone. Your competition will be with a small set of developers willing to take up the challenge of evolving.

The software engineering of the future (read: "today") is not about typing code syntax into an editor. It's about understanding what to build, why to build it, how it impacts the business, how to design it to last, and how to use AI as a tool to accelerate things exponentially.

If You've Read This Far...

Thank You!

I'm a Full Stack Software Engineer with more than two decades of experience in building products and people. At present, I'm pushing my startup, CreoWis Technologies, and teaching/mentoring developers on my YouTube channel, tapaScript.

I'm thrilled to publish my 50th article on the freeCodeCamp platform, and it makes me exceptionally proud to give back my knowledge to the developer community. If you want to connect with me,

• Follow on LinkedIn and X

• Subscribe to my YouTube Channel

• Catch up with my React Clean Code Rules Book

See you soon with my next article. Until then, please take care of yourself and keep learning.

To make things even worse, how about a CORS error that completely prevented you from showing the page?

It happens, right? Going back to the backend team and getting a quick fix for these issues would be ideal, but may not be realistic in most cases. It depends on the availability of the backend developers, the priority items they're working on, communication protocols between teams, and even interpersonal relationships.

Now, the question is, can you afford to wait? Wait for things to work in your favour within the given deadline so that you can show that demo or deliver the work to your customer? The answer is NO. You may not have that luxury.

Today, in this article, you'll learn a couple of mind-blowing tips and tricks that will save you from these situations. You'll understand how to set up your Chrome browser so that you can continue with your frontend development even when the backend API returns an incorrect response or a CORS error.

This is a step-by-step guide that'll help make you comfortable with all the required configurations and get you set up to use it on your web projects. This guide is also available as a video tutorial as part of the Thinking in Debugging series. You can check it out if you’d like:

Let's get started with the problems and their solutions.

Table of Contents

1. Problem 1: The Backend Response Is Wrong

2. Problem 2: Validating a UI Scenario Without Backend Changes

3. Problem 3: Handling CORS Errors

4. Additional Tips

   • Applying Overrides Globally

   • Disabling or Removing Overrides

5. Learn More From the Thinking in Debugging Mindset

6. Before We End…

Problem 1: The Backend Response Is Wrong

Here is a classic case of a wrong API response, but you still need to continue with your frontend work.

Take a look at the image below. Do you see that something is off? Yeah, on the first card, the spelling of Banana seems to be misspelled as Banananana. This user interface is constructed using the data we have received as an API response.

We can go to the backend team and request that they fix it as soon as possible. But it may not happen until the next sprint starts, which might be 15 days from now.

So, what can we do to continue with our work and all the validations on the frontend side? We can use the Content Overriding feature of the Chrome browser to mitigate this situation.

How to Use Content Overriding

First, open up the DevTools of your Chrome browser by pressing the F12 (on Mac, Cmd+F12) key. Then move to the network tab and inspect the API request that returns the incorrect response.

Next, right-click on the API request and select the Override content option from the context menu.

You may wonder what content means here, and what I am overriding? You're overriding the API response so that it can reflect on the UI locally.

This will bring up a UI at the top where you can select a folder to store override files. It's important to understand that all the content overrides are locally stored on your machine's hard disk. This means you can use these persisted overrides again and again until someone fixes the issue permanently at the backend.

Now click on the Select folder button.

This will open up the folder explorer for you. Create a new folder and select it, or select an existing folder where you want to save the overrides. In my case, I've named the folder as debug_devtools.

Now, Chrome DevTools will ask for confirmation that you're allowing DevTools to edit files on your local system. Just click on the Allow button.

That's all for the setup. Now, you'll find the same response in the editable mode under the Sources tab of DevTools. Let's take a deeper look at the image below:

1. The Local overrides are listed under the Sources > Oveerides tab of the DevTools.

2. On the left side, the Enable Local Overrides checkbox is selected, and the overrides are listed below. You can find the same folder you created before, and under that, you'll see another folder called localhost:3001 and a file called edibles under it. The localhost:3001 folder name is related to the API endpoint namespace we're connecting to. The edibles file name under it goes with the request name.

3. On the right side, you can see the content (that is, the response to the edibles request) in editable mode.

You can even cross-check now by traversing to the file system's debug_devtools folder. You should find the same folders and files as you saw in the DevTools.

You can open up the edibles file. The file content should match exactly the response you saw before.

Now, it's time to override. Coming to the Sources tab's editable response panel, you can fix the spelling. Save your changes using Ctrl + S (or Cmd + S).

Now, hard refresh your browser. You should be able to see your change reflected on the UI.

Awesome!! You can now share this overridden response (the edibles file) with other developers to point to from their Chrome DevTools to get the same local fix until the backend fixes it.

Problem 2: Validating a UI Scenario Without Backend Changes

Imagine you need to validate that certain items are low in stock on an item listing page. If the stock quantity of an item hits 50 or below, you want to show a Low Stock label for that item.

Now, what if the API response doesn't return a quantity of 50 or below? Content overriding can come to the rescue once again!

You can edit the response to set the quantity value to 50 or below and follow the same process as before to reflect the change on the UI. Look at the image below:

1. We have edited the quantity on the right-side panel.

2. Once saved and refreshed, we not only see the updated count on the UI, but it also runs the underlying JavaScript logic to show the Low Stock label automatically. This is a superpower.

Problem 3: Handling CORS Errors

Cross-Origin Resource Sharing (CORS) is a browser security feature that allows a web server to explicitly grant requests coming from a domain other than its own. By default, browsers don't allow these cross-origin requests and follow a strict rule called Same Origin Resource Sharing.

In many cases, your API server and the web server could be hosted on different domains. In those cases, when the web application attempts to access an API, it faces the CORS error.

On the server side, you need to have explicit configurations to allow cross-origin requests. For example, you need to add the following response headers:

Access-Control-Allow-Origin: http://localhost:5174
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: *

So, again, it may not be guaranteed that your CORS error will be resolved at the server side as soon as you want. But you cann't afford to get blocked due to it. So, what's the way around? Yes! The overriding, but this time, overriding the response header.

Go to the network tab of the Chrome DevTools and right-click on the request that has the CORS error. Now, select the Override headers option from the context menu.

By the way, have you noticed that the Override content option is disabled here? This is because we don't have any response as content from this request, as it got an error.

Clicking on the Overriding headers will take you to the Headers tab where you can find the option to add additional headers to the response headers. Click on the + Add header button to add the CORS-related headers.

Add all three headers with their respective values one by one:

Access-Control-Allow-Origin: http://localhost:5174 
Access-Control-Allow-Methods: GET 
Access-Control-Allow-Headers: *

Each of these headers has its own important use:

1. With the Access-Control-Allow-Origin header, you can specify the origin domains that are allowed to have a cross-origin request to the server. In this case, the value is http://localhost:5174 where we're running a Vite-based ReactJS app.

2. The header Access-Control-Allow-Methods specifies what kind of HTTP methods are allowed from the originating domain. In this case, we're allowing only the GET method.

3. The Access-Control-Allow-Headers HTTP response headers specify which HTTP headers can be safely used during a cross-origin request.

Alright, let's add them all and save.

Like overriding content, overriding the header will also create a folder with the context of the server domain, and under that, a file called .headers. As the file name starts with a dot(.), it may be treated as a hidden file by most operating systems. So make sure you go through the OS settings to view the hidden files to view this file.

Once you view and open the file, you'll see the headers you have added with overriding.

Now, hard refresh your browser, and try to perform the same operation that was giving you the CORS error before. Wow, the error has gone now! You should be able to see the request success and the response coming back from the server.

Just imagine, not a single line of server-side code changes, and you're unblocked so you can move forward with your client-side UI work. Fantastic, isn't it?

Additional Tips

Before we end, let's learn about a couple more handy tips.

Applying Overrides Globally

We applied the CORS error-related header overriding only on the /user API endpoint. What if you need to apply the same overriding for other endpoints, too? You can do it easily by following these simple steps:

1. Navigate to the Sources tab.

2. Select the Overrides sub-tab.

3. Click on the .headers override.

4. On the right-side panel, change the value of the Apply to to *.

That's it. Now, the same response headers will be applied as overrides for all the endpoints.

Disabling or Removing Overrides

Sometimes, you might want to disable or remove overrides. To disable overrides without removing them, just uncheck the Enable Local Overrides checkbox. To remove all the overrides permanently, click on the stop icon at the top-right corner. Also, to selectively remove an override, right-click on it and delete.

Learn More From the Thinking in Debugging Mindset

If you've liked this practical, example-driven guide, you'll enjoy my other debugging-related content from the Thinking in Debugging series. Please check it out.

Before We End…

That’s all! I hope you found this insightful.

Let’s connect:

• Subscribe to my YouTube Channel.

• Check out my courses, 40 Days of JavaScript and 15 Days of React Design Patterns

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Join my Discord Server, and let’s learn together.

• Follow my work on GitHub.

See you soon with my next article. Until then, please take care of yourself and keep learning.

Traditionally, you may have used a useEffect here, a loading flag there, and an error state along with it to tackle data fetching. Moving forward, another fetch depended on the first one, then a second useEffect, and another loading and error state.

This likely continued until you started feeling like you were writing code that you yourself could’t even maintain in the future.

Requests that should run in parallel started running sequentially. Components re-rendered unnecessarily just to satisfy another data fetch request-response. Loading spinners appeared when nothing meaningfully changed. Error states got scattered inside the component.

Well, none of these things are React’s problem. These are core design problems you should be aware of while coding your React Apps.

In this handbook, we’ll walk through one React Pattern that fixes data fetching at the architecture level without ignoring real data dependencies, and without introducing any new magic. If data fetching in React has ever felt harder than it should be, this pattern will make even more sense to you.

You’ll learn how to use React’s Suspense with the recently introduced use() API to handle data fetching smoothly. In case of errors, you’ll learn how an Error Boundary can help handle them gracefully.

Give this one a read, and code along to get a better grip on this pattern’s mental model.

This handbook is also available as a video tutorial as part of the 15 Days of React Design Patterns initiative. You can check it out if you’d like:

We’ll use a lot of source code to demonstrate the problems with the traditional data-fetching approach and how the Suspense Pattern can improve things. I would suggest that you try the code as you read. But if you want to take a look at the source code ahead of time, you can find it on the tapaScript GitHub.

Table of Contents

1. The Traditional Way of Data Fetching in React

   • The Problem with the Traditional Way

2. Let’s Build a Dashboard with the Traditional Data Fetching Approach

3. What is Suspense?

4. What is the use() API in React?

5. How to Use Suspense and the use() API for Data Fetching

6. Let’s Build the Dashboard with Suspense and the use() API

   • Project Setup

   • API Services

   • Create a Centralised User Resource

   • Create Individual Components

   • Create the Fallback UI

   • Create the Dashboard Component with Suspense

   • Run the Dashboard App

7. How to Handle Error Scenarios with Error Boundaries?

   • Error Boundary

   • Suspense and Error Boundary

8. Learn from the 15 Days of React Design Patterns

9. Before We End…

The Traditional Way of Data Fetching in React

To understand why data fetching can become painful in React, we first need to understand how React works under the hood.

React works in phases. It doesn’t do everything at once. At a high level, every update in React goes through three distinct phases:

• Render phase – React figures out what the UI should look like

• Commit phase – React applies those changes to the DOM

• Effect phase – React synchronises with the outside world

This separation is intentional. It’s what allows React to be predictable, interruptible, and efficient.

Now, let’s see where data fetching with useEffect fits into this picture:

Where does useEffect actually run? It doesn’t run during rendering. It runs after React has already committed the UI to the DOM.

That means the flow looks like this:

1. React renders the component (without data)

2. React commits the UI

3. useEffect runs

4. Data fetching starts

5. State updates when the data arrives

6. React renders again

useEffect(() => {
  fetchData().then(setData);
}, []);

Hence, the fetch only starts after the UI has already rendered.

The Problem with the Traditional Way

Consider a very common scenario: you fetch a user, and then fetch related data using the user ID.

The traditional React data fetching solution would look like this:

useEffect(() => {
  fetchUser().then(setUser);
}, []);

useEffect(() => {
  if (!user) return;
  fetchOrders(user.id).then(setOrders);
}, [user]);

What actually happens is:

• The component renders

• React commits the UI

• The first effect runs and fetches the user

• React re-renders

• The second effect runs and fetches orders

Even if the network is fast, the requests are forced to start one after another, because each fetch is triggered by a render that only happens after the previous fetch completes.

This paradigm of data fetching is called Fetch-On-Render. The fetching logic is no longer controlled by data dependencies – it’s controlled by render timing. But that’s not all. There are other problems with this approach: you create and maintain unnecessary states.

Now, let’s see both these problems in action by building something practical.

Let’s Build a Dashboard with the Traditional Data Fetching Approach

Let’s build a simple dashboard with the traditional data fetching approach using the useEffect hook at the center. The dashboard will have four primary sections:

• A Static heading.

• A Profile section welcoming the user with their name.

• An Order section listing the items ordered by the user.

• An Analytics section showing a few metrics for the same user.

You can visualise it like this:

The profile, order, and analytics sections should show the dynamic data of a user and their order and analytics. Hence, we’ll simulate three API calls to get the user details, order details, and the analytics data.

// API to fetch User
export function fetchUser() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ id: 1, name: "Tapas" });
    }, 1500);
  });
}

// API to fetch the Orders of a User
export function fetchOrders(userId) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve([
          `Order A for user ${userId}`,
          `Order B for user ${userId}`
      ]);
    }, 1500);
  });
}

// API to fetch the Analytics of a User
export function fetchAnalytics(userId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({
        revenue: "$12,000",
        growth: "18%",
        userId
      });
    }, 1500);
  });
}

As you can see in this code:

• Each of the API functions returns a promise.

• There is an intentional delay of 1.5 seconds using setTimeout to simulate the feel of a network call. The promise resolves after the delay passes.

• Once the promise gets resolved, we get the data.

Now, let’s create the Dashboard component:

import { useEffect, useState } from "react";
import { fetchAnalytics, fetchOrders, fetchUser } from "../api";

export default function Dashboard() {
    const [user, setUser] = useState(null);
    const [orders, setOrders] = useState(null);
    const [analytics, setAnalytics] = useState(null);

    // Step 1: Fetch user
    useEffect(() => {
        fetchUser().then(setUser);
    }, []);

    // Step 2: Fetch orders (depends on user)
    useEffect(() => {
        if (!user) return;
        fetchOrders(user.id).then(setOrders);
    }, [user]);

    // Step 3: Fetch analytics (depends on user)
    useEffect(() => {
        if (!user) return;
        fetchAnalytics(user.id).then(setAnalytics);
    }, [user]);

    // Logic to ensure that user, orders, and analytics data 
    // loaded before we render them on JSX
    if (!user || !orders || !analytics) {
        return <p className="text-xl m-3">Loading dashboard...</p>;
    }

    return (
        <div className="m-2">
            <header>
                <h1 className="text-5xl mb-12">📊 Dashboard</h1>
            </header>

            <h2 className="text-3xl">Welcome, {user.name}</h2>

            <h2 className="text-3xl mt-3">Orders</h2>
            <ul>
                {orders.map((o) => (
                    <li className="text-xl" key={o}>
                        {o}
                    </li>
                ))}
            </ul>

            <h2 className="text-3xl mt-3">Analytics</h2>
            <p className="text-xl">Revenue: {analytics.revenue}</p>
            <p className="text-xl">Growth: {analytics.growth}</p>
        </div>
    );
}

Let’s break it down:

• The first thing you’ll notice is that we have three states for holding the data of users, orders, and analytics.

• Then we have three useEffects to manage the fetching of data and updating the states.

• Then we show the data values in the JSX.

• We’re using a Fetch-On-Render methodology.

However, in between, there’s an explicit logic to check if the user data, order data, or analytics data has been loaded. If the data are not loaded, then we don’t even process the JSX – rather, we show a loading message.

// Logic to ensure that user, orders, and analytics data 
// loaded before we render them on JSX
if (!user || !orders || !analytics) {
  return <p className="text-xl m-3">Loading dashboard...</p>;
}

This is good as a measure so that the UI doesn’t crash at runtime. But this is not a declarative approach. Since React is declarative, it would make more sense if we could handle this scenario in a declarative way as well.

In Declarative programming, you as a programmer don’t specify how to to solve certain problems. You declare what you want to achieve, and the programming language/framework takes care of the “how” part for you. When you specify the “how” part, it becomes imperative, not declarative.

React is declarative because you don’t specify how to update the browser DOM to render the UI changes. You declare them using JSX, and React takes care of it under the hood.

As an alternative to the explicit imperative logic like the above, you could also handle it using loading states. You could have loading states for profile, orders, and analytics. The loading states could decide when to show the data conditionally. But this approach needs additional state management and conditional rendering of JSX.

Along with these issues, think of handling errors! Again, you would need states for error handling and the conditional logic to show and hide the error messages. That’s too much to manage.

So, with the useEffect strategy, data fetching in React is not that effective. We need a better pattern to handle data along with loading states and errors.

But before we move on, I want to clarify that useEffect isn’t bad. It has a purpose, but sometimes we don’t use it as intended. If you’re someone who wants to learn the effective usages of this hook and how to debug it properly, you can check out this session.

What is Suspense?

At its core, React Suspense is not a loading feature. It’s a rendering coordination mechanism. Suspense allows a component to tell React, “I’m not ready to be rendered, yet”. When that happens, React pauses rendering for that part of the tree and shows a fallback UI until the required data becomes available.

This is fundamentally different from how data fetching works with useEffect.

With the traditional Fetch-On-Render approach, React must first render a component before it’s allowed to start fetching data. Effects run after the commit phase, which means data fetching is always a reaction to rendering, never a prerequisite for it. As applications grow, this creates render-fetch-re-render loops, hidden waterfalls, and loading logic spread across components.

Suspense flips that model.

Instead of rendering first and fetching later, Suspense enables Render-as-you-Fetch. Data fetching can begin before React attempts to commit the UI, and rendering simply waits until the data is ready. The UI doesn’t guess when to show loading states. React coordinates it declaratively through Suspense boundaries.

With Suspense, you need to wrap the component that handles the asynchronous call.

Suspense can pause the rendering while the wrapped component is dealing with the promise. Suspense can show a fallback UI (it could be a loader, UI skeleton, and so on) until the promise is resolved (or rejected). Once the promise is resolved, Suspense replaces the fallback UI with the actual wrapped component baked with the data. No hard-coded logic, no extra state management is needed.

What is the use() API in React?

use() is an API introduced in React 19 that accepts a promise and returns its resolved value. If the promise hasn’t resolved yet, React doesn’t continue rendering. It suspends. If the promise fails, React throws an error. Both cases are handled declaratively by Suspense and Error Boundaries.

import { use } from "react";

function fetchUser() {
  return fetch("/api/user").then(res => res.json());
}

const userPromise = fetchUser();

export default function Profile() {
  const user = use(userPromise);
  return <h2>Welcome, {user.name}</h2>;
}

What’s important here:

• use() is called during render

• If the promise is unresolved, rendering pauses

• No useEffect, no loading state

use() is very powerful. It can read promises that depend on other promises.

const userPromise = fetch("/api/user").then(r => r.json());

const ordersPromise = userPromise.then(user =>
  fetch(`/api/orders?userId=${user.id}`).then(r => r.json())
);

function Orders() {
  const orders = use(ordersPromise);
  return (
    <ul>
      {orders.map(o => <li key={o.id}>{o.title}</li>)}
    </ul>
  );
}

Here:

• Dependencies are expressed in data, not effects

• Rendering is coordinated automatically (declaratively)

The primary mental model is: this render is not allowed to complete without this data. It suspends.

const data = use(promise);

We need to use Suspense to handle this gap (when the promise hasn’t resolved yet) using a fallback UI, and then to continue rendering once the promise is resolved.

How to Use Suspense and the use() API for Data Fetching

The use() API is what finally makes Suspense practical for data fetching. Before use(), Suspense could pause rendering, but React didn’t have a clean way to consume asynchronous data during render without hacks. Most examples relied on custom abstractions or libraries to bridge that gap. use() changed that by allowing React components to read async values directly during rendering.

When a component reads data using use(promise), React treats that promise as a render dependency. If the promise hasn’t resolved yet, React pauses rendering at the nearest Suspense boundary. When it resolves, React retries rendering automatically, without manual state updates, effects, or conditional logic.

import { Suspense, use } from "react";

const userPromise = fetch("/api/user").then(res => res.json());

function Profile() {
  const user = use(userPromise);
  return <h2>Welcome, {user.name}</h2>;
}

export default function App() {
  return (
    <Suspense fallback={<p>Loading profile...</p>}>
      <Profile />
    </Suspense>
  );
}

What happens here:

• Profile tries to read userPromise

• If the promise is unresolved, React pauses rendering

• React renders the nearest Suspense fallback

• When the promise resolves, React retries rendering automatically

Here, there are no effects, no loading flags, and no manual re-rendering.

Now, let’s see all these in action together by rebuilding the same Dashboard app.

Let’s Build the Dashboard with Suspense and the use() API

Now that we have a better understanding of Suspense and use(), let’s rewrite the same Dashboard application with it.

Project Setup

First, you’ll need to create a React project scaffolding using Vite. You can use the following command to create a Vite-based React project with modern toolings:

npx degit atapas/code-in-react-19#main suspense-patterns

This will create a React 19 project with TailwindCSS configured.

Now use the npm install command to install the dependencies. This will create the node_modules folder for you. At this point, the directory structure should look like this:

API Services

Now under src/, create a new folder called api/. Then create an index.js file under src/app/ with the following code snippet:

export function fetchUser() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({ id: 1, name: "Tapas" });
    }, 1500);
  });
}

export function fetchOrders(userId) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      resolve([
          `Order A for user ${userId}`,
          `Order B for user ${userId}`
      ]);
    }, 1500);
  });
}

export function fetchAnalytics(userId) {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve({
        revenue: "$12,000",
        growth: "18%",
        userId
      });
    }, 1500);
  });
}

These are the same APIs we used before when constructing the dashboard with useEffect.

• fetchUser: For fetching the user’s profile

• fetchOrders: For fetching the orders made by a user

• fetchAnalytics: For fetching the analytics data of a user

Create a Centralised User Resource

Now, let’s create a centralised JavaScript utility file where we can create each of the promises by calling their respective fetch methods. It’s a good practice to handle all the fetch APIs and their promises from a single place, rather than keeping them scattered. The same utility can export the promises so that we can consume them in the components.

Create a resources/ folder under src/. Create a file userResource.js file under src/resources/ with the following code:

import { fetchAnalytics, fetchOrders, fetchUser } from "../api";

let userPromise;
let ordersPromise;
let analyticsPromise;

export function createUserResources() {
  userPromise = fetchUser();

  ordersPromise = userPromise.then(user =>
    fetchOrders(user.id)
  );

  analyticsPromise = userPromise.then(user =>
    fetchAnalytics(user.id)
  );
}

export function getUserResources() {
  return {
    userPromise,
    ordersPromise,
    analyticsPromise
  };
}

Here, we export two functions:

1. The createUserResources() creates all the promises and keeps them ready.

2. The getUserResources() returns all the promises we can consume later.

Now, the question is, when will we create these promises? That is, where we will call the createUserResources() function? We should create these promises when the application starts up, and the main.jsx file would be the perfect place for that.

Open the main.jsx file, import {createUserResources}, and invoke it immediately.

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App.jsx";
import "./index.css";

import { createUserResources } from "./resources/userResource.js";

createUserResources();

ReactDOM.createRoot(document.getElementById("root")).render(
    <React.StrictMode>
        <App />
    </React.StrictMode>,
);

Great! Our data fetching APIs and the promises are ready. Let’s create the components where we’ll be using these promises.

Create Individual Components

We’ll create three components to compose the dashboard: Profile, Orders, and Analytics.

Let’s start with the Profile component. Create a folder components/ under the src/. Now, create a Profile.jsx with the following code:

import { use } from "react";
import { getUserResources } from "../resources/userResource";

export default function Profile() {
    const { userPromise } = getUserResources();
    const user = use(userPromise);
    return <h2 className="text-3xl">Welcome, {user.name}</h2>;
}

Let’s break it down:

• We imported the use() from React, as we’ll be dealing with the use promise here to handle it and get the user name to render.

• Next, we need the user promise. We have the getUserResources() function to get that, so we imported it.

• Then, inside the Profile component, we destructured userPromise from the getUserResources() function.

• After that, we passed the promise to the use(). We have learned that the use() API accepts a promise and returns the result when it is resolved. Until then, the passed-in promise itself will be returned.

• Finally, we used the resolved user to extract the name property and render it.

Simple, right? Let’s quickly create the Orders and Analytics components.

The Orders component:

import { use } from "react";
import { getUserResources } from "../resources/userResource";

export default function Orders() {
   const { ordersPromise } = getUserResources();
  const orders = use(ordersPromise);

  return (
    <>
      <h2 className="text-3xl mt-2">Orders</h2>
      <ul>
        {orders.map((o) => (
          <li className="text-xl" key={o}>{o}</li>
        ))}
      </ul>
    </>
  );
}

It has the same flow as the Profile component.

Now, let’s do the Analytics component:

import { use } from "react";
import { getUserResources } from "../resources/userResource";

export default function Analytics() {
    const { analyticsPromise } = getUserResources();
    const analytics = use(analyticsPromise);

    return (
        <>
            <h2 className="text-3xl mt-2">Analytics</h2>
            <p className="text-xl">Revenue: {analytics.revenue}</p>
            <p className="text-xl">Growth: {analytics.growth}</p>
        </>
    );
}

All three components are ready. Before we move further, let’s reflect once more on what we learned about Suspense.

Suspense wraps a component that deals with promises (async operations). Until the promise gets resolved, the Suspense holds the rendering and can show a fallback UI in the meantime. Once the promise gets resolved and we have the value, the fallback UI gets swapped with the actual component Suspense wrapped.

So, we have the ideal case now: wrapping the <Profile />, <Orders/>, and <Analytics/> with the <Suspense>…</Suspense> boundary to handle the promises and resolved data for each of the components.

Let’s do that, but aren’t we missing something? Yeah we are: the fallback UI. Let’s create it.

Create the Fallback UI

Now we’ll create three different fallback UI components. Create a file Skeletons.jsx under the src/components/ with the following code:

export const ProfileSkeleton = () => <p className="text-3xl m-2">Loading user...</p>;
export const OrdersSkeleton = () => <p className="text-3xl m-2">Loading orders...</p>;
export const AnalyticsSkeleton = () => <p className="text-3xl m-2">Loading analytics...</p>;

We now have a fallback skeleton UI for each of our components. These are very simple components that just render loading messages.

Create the Dashboard Component with Suspense

Now we have everything to make our Dashboard work. Create a suspense/ folder under src/. Then create a Dashboard.jsx file under src/suspense/ with the following code:

import { Suspense } from "react";

import Analytics from "../components/Analytics";
import Orders from "../components/Orders";
import Profile from "../components/Profile";

import {
    AnalyticsSkeleton,
    OrdersSkeleton,
    ProfileSkeleton,
} from "../components/Skeletons";

export default function Dashboard() {
    return (
        <div className="m-2">
            <header>
                <h1 className="text-5xl mb-12">📊 Dashboard</h1>
            </header>

            <Suspense fallback={<ProfileSkeleton />}>
               <Profile />
            </Suspense>
            <Suspense fallback={<OrdersSkeleton />}>
               <Orders />
            </Suspense>
            <Suspense fallback={<AnalyticsSkeleton />}>
               <Analytics />
            </Suspense>
        </div>
    );
}

First, let me explain the code:

• We imported Suspense from React, all the components, and all the fallback UI components.

• Then we rendered a static header and three suspense boundaries for each of the components. We wrapped Profile, Orders, and Analytics with Suspense, respectively. To handle the pending promise state, we have passed the individual skeleton component as the fallback to the suspense.

How clean is this? If you scroll up and recheck our old implementation of the dashboard using useEffect and compare it with the one we created with suspense, the positive differences are clear.

• It’s declarative.

• There’s less code, with the chance of fewer bugs

• There’s no effect management and synchronisations

• There’s no conditional JSX

It’s a huge win 🏆.

Run the Dashboard App

To run the dashboard app, import the dashboard component in the App.jsx file and use it like this:

import Dashboard from "./suspense/Dashboard";
function App() {
    return (
        <div className="flex items-center justify-center gap-12">
            <Dashboard />
        </div>
    );
}

export default App;

Next, open the terminal. Run the app using the npm run dev command. You get the same dashboard back, but it’s much improved:

• It loads the data of each of the sections independently.

• Each of the sections shows the data loading indicator when the promise is pending.

• It doesn’t block the entire UI.

Suspense and use() together are very powerful. Now you have learned that powerful pattern end-to-end.

How to Handle Error Scenarios with Error Boundaries

This data fetching handbook wouldn’t be complete without talking about error scenarios and how to handle them. So far, we’ve spoken about only the happy path. But what if any of the promises are rejected? How do we handle that?

To understand this in depth, let’s reject one of the promises – say the Order promise. Open the index.js file under the src/api/ folder and replace the fetchOrder() function with this updated code:

export function fetchOrders(userId) {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      // Simulate failure
      if (Math.random() < 0.5) {
        reject(new Error("Failed to fetch orders"));
      } else {
        resolve([
          `Order A for user ${userId}`,
          `Order B for user ${userId}`
        ]);
      }
    }, 1500);
  });
}

Here, the changes are:

• We have simulated a failure by rejecting a promise.

• The promise gets rejected randomly and throws an error with an error message.

At this point, if you refresh the UI a few times, you’ll randomly get a blank broken UI with the error message logged into the browser console. This isn’t ideal. It kills the UX of the app.

A better way of handling would be to show the error message on the UI and provide a way to retry and check if the user can recover from the error.

This is where Error Boundary comes in.

Error Boundary

Error Boundaries in React exist for a simple reason: Errors are inevitable, and we must handle them gracefully. There could be:

• Network requests fail

• Data is malformed

• The assumptions break

Without boundaries, a single tiny rendering error can crash the entire React tree. Error Boundaries provide React with a structured way to handle failures.

Technically, an Error Boundary is a component that catches errors thrown during rendering. When an error occurs, React stops rendering the subtree and renders a fallback UI instead.

Let’s now create an Error Boundary. Create a file called ErrorBoundary.jsx under src/components with the following code:

import { Component } from "react";
import { createUserResources } from "../resources/userResource";

export default class ErrorBoundary extends Component {
  state = { error: null };

  static getDerivedStateFromError(error) {
    return { error };
  }

  handleRetry = () => {
    this.setState({ error: null });
    createUserResources();
  };

  render() {
    if (this.state.error) {
      return (
        <div className="border border-red-700 rounded p-1">
          <p className="text-xl">{this.state.error.message}</p>
          <button 
                className="bg-orange-400 rounded-xl p-1 text-black cursor-pointer" 
                onClick={this.handleRetry}>
            Retry
          </button>
        </div>
      );
    }

    return this.props.children;
  }
}

Now, let’s understand what’s going on in the code above:

• This is a class component that inherits from React.Component. That’s because Error Boundaries must use class lifecycle methods, which are not available in function components.

• The component keeps track of whether an error has occurred. state = { error: null } means everything is rendering normally. When an error happens, this state will store the error object.

• The static getDerivedStateFromError() is a special lifecycle method. React automatically calls it when a child component throws an error during render.

• The handleRetry() method resets the error state back to null. It calls the createUserResources() to reinitialise the async resources.

• In the render() method, if an error exists, render a fallback UI, show the error message, and provide an ability to retry the error using a retry button. If no error exists, render the children normally. The Error Boundary becomes invisible when everything works without an error. The fallback UI also can be an external component that we can pass as a prop to the Error Boundary.

If you’re interested in diving deep into the Error Boundary pattern and want to learn various use cases of it, here is a dedicated video you can check out.

Suspense and Error Boundary

Next, we’ll now use the Error Boundary to wrap each of the Suspense boundaries so that if an error originated from any of those, it can be managed. Open the Dashboard.jsx file and wrap each of the Suspense boundaries with the ErrorBoundary component as shown below:

import { Suspense } from "react";
import Analytics from "../components/Analytics";
import ErrorBoundary from "../components/ErrorBoundary";
import Orders from "../components/Orders";
import Profile from "../components/Profile";
import {
    AnalyticsSkeleton,
    OrdersSkeleton,
    ProfileSkeleton,
} from "../components/Skeletons";

export default function Dashboard() {
    return (
        <div className="m-2">
            <header>
                <h1 className="text-5xl mb-12">📊 Dashboard</h1>
            </header>

            <ErrorBoundary>
                <Suspense fallback={<ProfileSkeleton />}>
                    <Profile />
                </Suspense>
            </ErrorBoundary>

            <ErrorBoundary>
                <Suspense fallback={<OrdersSkeleton />}>
                    <Orders />
                </Suspense>
            </ErrorBoundary>

            <ErrorBoundary>
                <Suspense fallback={<AnalyticsSkeleton />}>
                    <Analytics />
                </Suspense>
            </ErrorBoundary>
        </div>
    );
}

That’s it. Now, access the dashboard on the browser. Whenever the order promise rejects, we’ll get the fallback error UI from the error boundary. Note, the remaining UI isn’t broken and rendered successfully. The partial failure of the UI is also recoverable, as we have provided a retry button to attempt to revive that portion. It provides a great UX.

This is how the Suspense boundary, the use() API, and the Error Boundary work together to help you write scalable React code that can be maintained very easily in the future. I hope you found it helpful. All the source code used in this handbook is in the tapaScript GitHub Repository.

Learn from the 15 Days of React Design Patterns

I have some great news for you: after my 40 days of JavaScript initiative, I have now completed a brand new initiative called 15 Days of React Design Patterns (with Bonus Episodes).

If you enjoyed learning from this handbook, I’m sure you’ll love this series, featuring the 15+ most important React design patterns. Check it out, subscribe, and get it for free:

Before We End…

That’s all! I hope you found this insightful.

Let’s connect:

• Subscribe to my YouTube Channel.

• Check out my courses, 40 Days of JavaScript, 15 Days of React Design Patterns, and Thinking in Debugging.

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Join my Discord Server, and let’s learn together.

• Follow my work on GitHub.

See you soon with my next article. Until then, please take care of yourself and keep learning.

But in the actual world of Software Engineering, especially in product-focused companies and customer-facing systems, coding is only half the work. The other half is just as important, and it’s the process called Debugging.

Table of Contents

1. What is Debugging?

2. Why this Guide?

3. Why is Debugging Hard?

4. What is a Mental Model?

5. The Debugging Mental Model Framework

   • Step 1: Bug Found

   • Step 2: Define the Facts

   • Step 3: Identify Your Assumptions

   • Step 4: Form a Hypothesis

   • Step 5: Verify the Hypothesis

   • Putting Everything Together

6. How to Apply the Debugging Mindset Framework to Code

7. The Debugging Mindset Framework is Tool Agnostic

8. What’s Next?

9. Before We End...

What is Debugging?

Debugging is the practice and methodology developers use to identify issues or problems within a system. Usually, an issue or an unexpected behaviour/problem is known as a bug. The process of debugging, then, is to identify the bug – followed by an attempt to eliminate it or fix it.

Debugging becomes necessary when assumptions break, customers report issues, products behave unexpectedly, or metrics go red. It’s the practice that keeps a software product reliable, teams calm, and users trusting what you build.

Yet, strangely, debugging rarely gets the same respect and attention as coding. It’s often treated as a necessary evil, something that you “figure out along the way” rather than a skill to be learned deliberately.

Why this Guide?

The general neglect of basic debugging skills is catching up with us.

Today, with AI tools, generating code is easier than it has ever been. You can create boilerplate, scaffold components, write functions, establish relations, and even build entire applications in minutes.

But when things go wrong (as they always do), AI doesn’t sit with your product logs, customer complaints, partial failures, and confusing edge cases. Debugging still falls to the human to tackle, and that’s where many devs struggle.

Over the last two decades, I’ve build many products and worked with many developers across experience levels. I’ve noticed a consistent pattern: most debugging failures are not tool failures. They are thinking failures. People jump to fixes too quickly. They start guessing. They panic. They change code without understanding why it broke in the first place.

That’s why I am writing this debugging mindset tutorial. This guide will NOT:

• Teach you tools

• Share tricks

But it will enable you to think things through when things break.

Alongside this article, I’m also creating a free YouTube course called “Thinking in Debugging”. It’s a practical series on how professional developers approach debugging in JavaScript, React, CSS, and real-world frontend systems. Here is the first session from the course:

In modern software development, writing code gets you started. But debugging is what makes you reliable. Reliability is the most important trait both an engineer and a product must have.

Why is Debugging Hard?

Here’s how most developers debug code:

• Something is broken

• Let me change the line

• Let’s refresh (wishing the error would go away)

• Hmm… still broken!

• Now, let me add a console.log()

• Let me refresh again (Ah, this time it may…)

• Ok, looks like this time it worked!

This is reaction-based debugging. It’s like throwing a stone in the dark or finding a needle in a haystack. It feels busy, it sounds productive, but it’s mostly guessing. And guessing doesn’t scale in programming.

This approach and the guessing mindset make debugging hard for developers. The lack of a methodology and solid approach makes many devs feel helpless and frustrated, which makes the process feel much more difficult than coding.

This is why we need a different mental model, a defined skillset to master the art of debugging. Let’s understand what a mental model is and what the debugger’s mindset should be.

What is a Mental Model?

A mental model drives us to think and make decisions. Our brain is at the centre of it. It collects information, processes it, and helps us make those decisions.

When we encounter an issue in programming and we need to find the root cause to fix it, we need to rely on various information and inputs to make logical decisions. We need to create a mental model.

Good debuggers don’t fight bugs. They investigate them. They don’t start with the mindset of “How do I fix this?”. They start with, “Why must this bug exist?” This one question changes everything.

When you ask about the existence of a bug, you go back to the history to collect information about the code, its changes, and its flow. Then, you feed this information through a “mental model” to make decisions that lead you to the fix.

Now, let’s learn about this debugging mental model. This isn’t merely a tool – this is a way of thinking.

The Debugging Mental Model Framework

Before we take a deep dive into the debugging mental model, the key idea is that you never touch the fix until the hypothesis survives reality.

So in this context, what does hypothesis mean?

A Hypothesis is an idea that is suggested as the possible explanation for something but has not yet been found to be true or correct.

With this, let’s get started understanding the debugging mental model framework. It consists of multiple steps or phases that you must go through to find the root cause of a bug and fix it. Once you understand the framework, we’ll apply it to an actual bug in some JavaScript code to make our learning practical.

Let’s Go.

Step 1: Bug Found

The first step is identifying the bug. You or someone else (QA, Customer, and so on) has found that something is wrong. It could be a UI glitch, the wrong output, slow performance, or anything else that is not working as promised and expected.

At this stage, the unexpected behaviour should be documented with enough proof, like logs, screenshots, and steps, for anyone else to reproduce the bug easily. As a developer, don’t panic that something isn’t working as expected. Also, don’t code yet.

Step 2: Define the Facts

Once the bug is found and reported, the next stage is defining or establishing the facts. Facts are things that you can prove, not guesses. For example:

• This component renders twice.

• This API returns correct data.

• This function receives a string, not a number.

Here are a few examples of guesses, but not facts:

• React is acting weird.

• The API must be slow.

• This worked yesterday.

• It works on my machine 😁.

Defining facts means writing down only what you can prove. What actually happened? What did the user see? What error was thrown? What data was received? Facts are observable, repeatable, and not an outcome of your emotions.

Defining the facts also empowers you to be aware of the code flow and business cases. So this phase is your opportunity to carefully review the code, requirements, and learn about it, irrespective of who wrote it. Once you know the facts, note them down.

Step 3: Identify Your Assumptions

Every bug is based on a broken assumption. Assumptions often feel harmless because they usually work, until they don’t. Examples:

• I assumed this was a number.

• I assumed useEffect would run only once.

• I assumed the state updates immediately.

• I assumed the API always returns data.

Here, the goal is to surface those hidden beliefs. Ask yourself, what must be the actual reason for this code to work as expected? The moment your answer is an assumption, you’re off track. You then recollect, think carefully, stop blaming the system, and start questioning the mental model.

Most bugs are not caused by bad code, but by unverified assumptions.

Step 4: Form a Hypothesis

This is where the actual debugging of the code begins. Once the facts are clear and assumptions are visible, the debugging makes its way forward.

Now you’ll need to form a hypothesis. A hypothesis is a simple cause-and-effect statement: If this assumption is wrong, then the behaviour makes sense. If not, provide a fix.

You may have logs from customers and the best debugging tools from management. But without a good hypothesis, logs become noise and tools become unnecessary. With a good hypothesis, debugging stops being reactive and becomes investigative.

Step 5: Verify the Hypothesis

A hypothesis has no value without meeting reality. You’ll need to verify if your hypothesis is realistic. How do you do that? This is where you use the tools with a purpose. A console.log() statement, a breakpoint, and a network inspection are some of the actions you can perform to answer the question: Is my hypothesis true or false?

If the hypothesis fails, you discard it and move to the next. That’s progress, not failure. On the other hand, if the hypothesis holds, the fix should become clear. You’re no longer making code changes to make the bug disappear suddenly – rather, you’re correcting the root cause.

Putting Everything Together

As we now understand each of the phases, let’s visualise them together and see the bigger picture. I would encourage you to take a pause here and look carefully at each of the boxes below. Now, try processing your understanding from whatever you learned so far about them. Promise yourself that you will apply these to your day-to-day development journey.

Sounds good? Theoretically, it does. But you may have doubts about how all these strategies can work practically. Now, we will apply these to a problem statement and see the practicality of it.

How to Apply the Debugging Mindset Framework to Code

Let’s take an example of a bug that has confused millions of developers across the globe 😀.

Here’s the code:

function fetchUser() {
  let user;

  setTimeout(() => {
    user = { name: "Alex" };
  }, 1000);

  return user;
}

console.log(fetchUser());

The Output: It logs undefined to the browser’s log.

The Bug: I Set the User… Why is it undefined?

Now, let’s apply the debugging mental model framework.

Step 1: Bug Found

Here, the observation is that the function returns undefined. There are no errors in the console. The code looks correct. The scariest bugs are the ones that don’t throw errors.

Step 2: Define the Facts

So, what are the provable facts you see here?

• fetchUser() runs.

• setTimeout is scheduled.

• return user runs.

• The user is undefined at return time.

Remember that facts are the things you can prove, not what you believe.

Step 3: Identify Your Assumptions

Now, ask yourself, “What am I assuming here?”. Here are a few common beginner assumptions for this case:

• JavaScript runs line-by-line synchronously.

• The setTimeout blocks execution.

• Code waits for 1 second.

• The user variable is assigned before the return from the function.

Most async bugs come from the assumptions about execution time.

Step 4: Form a Hypothesis

Next, we need to form a hypothesis to introduce structured thinking. The function returns undefined. If our assumptions were right, the user variable should have the assigned value. It seems that there’s something wrong with the assumptions.

• Does the setTimeout really block execution?

• Does the code really wait for 1 second?

• If JavaScript doesn’t wait for setTimeout, then return user will execute before the assignment. This is how the user variable could be undefined. It seems like we’re dealing with the Async operation here. This is the aha moment – that’s our hypothesis.

We aren’t fixing anything yet. We’re predicting behaviour.

Step 5: Verify or Kill the Hypothesis

Now, we need to verify our hypothesis. Let’s use console.log() for that. We’ll add two logs, one inside the setTimeout before assigning the user variable value, and the other just before returning the user from the function.

function fetchUser() {
  let user;

  setTimeout(() => {
    console.log("Inside timeout");
    user = { name: "Alex" };
  }, 1000);

  console.log("Before return:", user);
  return user;
}

console.log(fetchUser());

Execute the code, and here are the observations:

• “Before return:” logs first.

• “Inside timeout” logs later.

This means that our hypothesis survives the reality. We proved that debugging is not guessing – it’s about ordering the execution time correctly in our heads.

Step 6: Fix With the Proof

Now our fix becomes obvious, not a guess or magic. If we want the user’s value to be logged instead of undefined, we can fix it in multiple ways, like using a callback function or a promise object.

• With a callback: Define a callback function that gets called after the time expires. The callback function takes the value as a parameter and assign to the user before logging it to the console.

function fetchUser(callback) {
  setTimeout(() => {
    callback({ name: "Alex" });
  }, 1000);
}

fetchUser(user => console.log(user));

• With Promise Object: Alternatively, we can use the Promise object. The promise resolves after 1 second, and we log the user details with the help of the .then() handler method.

function fetchUser() {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve({ name: "Alex" });
    }, 1000);
  });
}

fetchUser().then(user => console.log(user));

Let’s now visualise all the stages together with respect to the problem we discussed:

The Debugging Mindset Framework is Tool Agnostic

Note that the debugging mental model teaches you how to observe, think through, and justify your beliefs to find the root cause of the issue. Once confirmed, you need to use your programming language knowledge and coding skills to implement the fix. The debugging mindset or mental model framework itself is technology and tool agnostic.

It doesn’t belong to JavaScript, React, Python, or any specific tool. The need for facts, assumptions, hypotheses, and verification exists in every technology stack. Today, you might be debugging a React component. Tomorrow it could be CSS layout, backend logic, or a memory leak. The same thinking applies. This is why experienced developers adapt more quickly to new programming languages, frameworks, or tools. They carry this mindset with them.

What’s Next?

Technologies evolve, frameworks come and go, but the debugging mental model framework remains constant. So focus on that. Have a mindset to own up to the issues you’ve found in a software product. No development is bug-free. You create bugs sometimes, so you should just proudly own them. And now, you should have the mindset to confidently fix them.

I would like to invite you to join my free course Thinking in Debugging. In it, we won’t only set up this mental model, but also realise it by debugging JavaScript, React, and CSS with DevTools, Debugger, and Profiler.

Before We End...

That’s all! I hope you found this article insightful.

Let’s connect:

• Subscribe to my YouTube Channel.

• Check out my courses, 40 Days of JavaScript and 15 Days of React Design Patterns.

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Join my Discord Server, and let’s learn together.

• Follow my work on GitHub.

See you soon with my next article. Until then, please take care of yourself and keep learning.

Now imagine you hit the same Like button, but it takes its sweet time in making the server call, performing the DB updates, and getting you the response back to update the state of the Like button.

Which experience would you like the most? You are most likely to select the first scenario. We all love “instant feedback”. The magic of instant feedback is powered by a pattern called the Optimistic UI Pattern.

In this article, we will uncover:

• What does Optimistic UI really mean?

• Why does it massively improve the user experience?

• How does React 19’s new useOptimistic() hook make it easier than ever?

• How to implement a real-world scenario using the Optimistic Pattern

• A bunch of use cases where you will be able to use this pattern.

By the end, you will be proactively thinking of using this design pattern to improve the UX of your project.

This article is also available as a video tutorial as part of the 15 Days of React Design Patterns initiative. Please check it out.

Table of Contents

1. What is Optimistic UI?

2. How Does it Work Under the Hood?

3. How to Build an Optimistic Like Button

4. The Pitfalls and Anti-Patterns

5. 15 Days of React Design Patterns

6. Before We End...

What is Optimistic UI?

Optimistic UI (also known as optimistic updates) is a pattern that helps you update the UI immediately, assuming the server operation will succeed, and if it later fails, you roll back the UI to the correct state.

Instead of waiting for the round-trip of the client request, database write, server response, and then the UI render, the UI just updates instantly. This dramatically increases what’s called the perceived speed. The user of the application perceives the UI update as instant – but the actual operation may take place in the background.

Without an Optimistic Update:

If you’re not using the optimistic pattern, it’s just a traditional client-server mechanism, where:

• At the client side, a user interacts with a UI element.

• An async call (request) is made to the server.

• The server processes the request and may make DB updates.

• On a successful case, the server sends back the response to the client.

• The client updates the relevant UI.

• In an error case, the server sends back the error response to the client.

• The client informs the user about the error.

In this case, the user has to wait for the success/failure of the request to perceive any change after their interaction. This wait is neither uniform nor optimal. It may vary based on the network speed, network latency, and deployment strategies of the application.

With an Optimistic Update:

When you’re using an optimistic update, here’s how things go:

• At the client side, a user interacts with a UI element.

• The UI gets updated instantly, and the user perceives the feedback immediately.

• In parallel, in the background, the client initiates the server call.

• The server processes the request and may make DB updates.

• On a successful case, the server doesn’t do anything else, as the UI has been updated already, assuming this call will succeed.

• In an error case, the server sends back the error response to the client.

• The client rolls back the eager, optimistic UI update it made.

In this case, the user doesn’t wait for the server round-trip to complete before the UI is updated. It’s much faster, assuming that, in most cases, the parallel server call will succeed.

With this comparison, we can now understand why Optimistic Updates matter in modern UI.

• It improves perceived speed

• It keeps users engaged

• It eliminates the awkward feelings like “Did my click work?”

And so on. Optimistic updates are critical for real-time feeling features like chat messages, likes, comments, cart updates, poll votes, collaborative editing, and more. Even AI-driven apps that take time to respond benefit from optimistic placeholders like “Thinking…”, “Sending…” and so on.

How Does it Work Under the Hood?

Under the hood, there are actually two states:

1. The Actual State: This is the actual source of truth. This data should be in sync with the server.

2. The Optimistic State: This is temporary and instantly shown to the user.

When the server request succeeds, do nothing. Your optimistic state is now correct. If the server request fails, perform a rollback, and return UI the actual state.

React 19 introduced a built-in hook to help with this pattern called useOptimistic() . In the next section, we will take a deep dive into it with code and working internals.

The useOptimistic() Hook in React 19

useOptimistic() is a React hook introduced in React 19 to help with optimistic updates. The syntax and usage of the hook go like this:

const [optimisticState, addOptimistic] = useOptimistic(state, updateFn);

When an async action is underway, the useOptimistic() hook allows you to show different states.

It accepts:

1. currentState: your real source of truth (useState, Redux, server state, and so on)

2. updateFn: a pure function that says how to compute the optimistic value

It returns:

1. optimisticState: the temporary UI state

2. addOptimisticUpdate(input): function you call to apply immediate updates

Take a look at the picture below. It shows the relationship between the current state and the optimistic state clearly:

Here’s what’s going on there:

1. We pass the current state and an updater function to the useOptimistic hook.

2. The updater function takes the current state and a user input to compute and return the next optimistic state.

3. The input to the updater function is supplied using the addOptimistic(input) function.

4. Finally, the optimistic state value is used in the component.

Let’s now build something exciting using this hook to understand its internals better.

How to Build an Optimistic Like Button

We will be building the Like button functionality optimistically. The flow will be like this:

• The user clicks on the Like button.

• We update the Like button’s state immediately and optimistically.

• In parallel, we send the server call to persist the value into the DB (we will simulate it)

• Then we handle any error scenarios.

First, let’s simulate a network call to the server using JavaScript’s Promise object and the setTimeout() web API:

// simulate a network call to the Server
async function sendLikeToServer(postId) {
    await new Promise((r) => setTimeout(r, 700));

    if (Math.random() < 0.2) throw new Error("Network failed");
    console.log(`Sent a like for the post id ${postId}`);
    return { success: true };
}

The sendLikeToServer function takes a post ID as a parameter and simulates a fake network call using a Promise and a delay of 700 ms. It pretends to submit a request to the server to persist a post’s likes value.

To make it a bit more realistic, we have created a random error. The function will throw an error randomly so that we can understand the rollback scenario as well.

Next, we will create the real source of truth, the actual state for the Like count:

const [likes, setLikes] = useState(initialLikes);

Then, create the optimistic state value with the useOptimistic() hook:

 const [optimisticLikes, addOptimisticLike] = useOptimistic(
        likes, (currentLikes, delta) => currentLikes + delta);

Let’s understand this declaration well:

• We have passed the actual state value (likes) and the updater function to the useOptimistic() hook.

• Take a look at the updater function, (currentLikes, delta) => currentLikes + delta. It’s an arrow function that gets the current like value and a delta. It returns the sum of the current like value and the delta. The return value logic is your own business logic. For incrementing the like count, it makes sense to increase the current like value by a delta value (of 1).

• Now, the question is, how do we get this delta value? Who passes it? That’s where the return values of useOptimistic() come in handy. The addOptimisticLike is a function through which we can pass that delta value. How? Let’s take a look.

When someone clicks on the Like button, we need to handle the click event and increase the like count value. So here is a handleLike() function which does that:

const handleLike = async () => {
        addOptimisticLike(1);
        try {
            await sendLikeToServer(postId);
            setLikes((prev) => prev + 1);
        } catch (err) {
            console.error("Like failed:", err);
            setLikes((s) => s); 
        }
};

A lot is happening here:

• We call the addOptimisticLike() function with a delta value of 1. This call will ensure that the updater function (currentLikes, delta) => currentLikes + delta of the useOptimistic() will be called. The return value will be set to the optimistic state, that is, optimisticLikes.

• This optimistic state value we use in the JSX. So we can see the increased like count immediately.

• Then we make the fake server call, and also update the actual state, provided the server call was successful.

• In case of an error, the control goes into the catch-block, where we roll back the likes value to the previous one. This will also sync the optimistic state’s value with a rollback.

Here is the complete code of the LikeButton component:

import { startTransition, useOptimistic, useState } from "react";

// simulate a network call to the Server
async function sendLikeToServer(postId) {
    await new Promise((r) => setTimeout(r, 700));

    if (Math.random() < 0.2) throw new Error("Network failed");
    console.log(`Sent a like for the post id ${postId}`);
    return { success: true };
}

// The Like Button Component
export default function LikeButton({ postId, initialLikes = 0 }) {
    // the "real" source of truth for likes (committed)
    const [likes, setLikes] = useState(initialLikes);
    // optimistic state and updater function
    const [optimisticLikes, addOptimisticLike] = useOptimistic(
        likes,
        (currentLikes, delta) => currentLikes + delta
    );

    const handleLike = async () => {
        // 1) Apply optimistic change *immediately*
        addOptimisticLike(1);

        // 2) Start server call in low priority to avoid blocking UI

        try {
            await sendLikeToServer(postId);
            // On success, commit the real state update:
            // IMPORTANT: update the real state so optimistic snapshot eventually matches
            setLikes((prev) => prev + 1);
        } catch (err) {
            // On error, rollback the real state (or trigger a refetch)
            // Because we never incremented likes (real), just leave likes unchanged
            // But we should show an error to user:
            console.error("Like failed:", err);
            // Optionally: show toast or set an error state
            // And — to force the optimistic view to refresh and reflect real state,
            // call setLikes to current value
            setLikes((s) => s); // no-op but will cause optimistic to reflect the
                                // committed value Or you can trigger a re-fetch of the 
                                // post state
        }
    };

    return (
        <div className="flex">
            <button onClick={handleLike}>❤️ {optimisticLikes}</button>
            <button onClick={() => startTransition(async () => handleLike())}>
                ❤️ {optimisticLikes}
            </button>
        </div>
    );
}

Have you noticed that we have wrapped the handleLike() call with the startTransition?

Without this, React gives us a warning:

“An optimistic state update occurred outside a transition or action.”

This is because optimistic updates are low-priority visual updates, not critical ones.

Using startTransition() ensures that:

• React doesn’t block rendering

• We do not get the warning

• We get a smooth, optimistic experience

The transitions are part of React’s concurrency model that helps us improve the performance of React applications. If you are interested in learning various performance optimisation techniques, here is a two-part guide for you.

The Pitfalls and Anti-Patterns

With any design pattern, we need to be aware of possible pitfalls, misuses, and anti-patterns. Here are a few things you should be aware of:

• Don’t assume that the server call will be successful. Network failure will happen, and you need to have a way to roll back. Rollback is the heart of optimistic UI. Omitting the rollback logic will cause adverse consequences.

• Don’t try hiding the bad UX behind optimistic updates. The Optimistic UI is not a fix or replacement for poor designs.

• Don’t perform any expensive work in optimistic updates. Keep the optimistic updater function lean, pure, and fast.

15 Days of React Design Patterns

I have some great news for you: after my 40 days of the JavaScript initiative, I have now started a brand new initiative called 15 Days of React Design Patterns.

If you enjoyed learning from this article, I am sure you will love this series, featuring the 15+ most important React design patterns. Check it out and join for FREE:

Before We End...

That’s all! I hope you found this article insightful. You can find all the source code used in this tutorial on the tapaScript GitHub.

Let’s connect:

• Subscribe to my YouTube Channel.

• Grab the React Hooks Cheatsheet.

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Join my Discord Server, and let’s learn together.

• Subscribe to my fortnightly newsletter, The Commit Log.

See you soon with my next article. Until then, please take care of yourself and keep learning.

JSON was built for humans. It’s readable, accessible, and universal for APIs to consume data or return responses. But in the modern era of AI, a downside of JSON has really come to light: it’s quite verbose.

Every brace, every quote, and every repeated key consumes tokens. If you spend time building apps that talk to large language models (LLMs), you’ll likely know that tokens are the currency of LLM interactions. The more tokens, the more costly your AI solution is going to be.

Now, there is a new kid in town called TOON (Token-Oriented Object Notation). It promises to enable LLMs to talk to structured data more efficiently, intelligently, and cost-effectively.

This article is the result of my curiosity in exploring TOON. I wanted to learn why it’s trending, how it works, and how you can use it today in your JavaScript/TypeScript and Python projects. I hope you find this equally exciting as I do.

You can find all the source code used in this article in this GitHub Repository.

Table of Contents

1. What is Toon?

2. Why is TOON Important Now?

3. JSON vs TOON - Learn With Examples

4. How to Use TOON With JavaScript / TypeScript

5. How to Use Toon With Python?

6. Hold On, JSON Might Still Be Better(In Many Cases)

7. The Future of TOON

8. Before We End…

What is Toon?

TOON is a new data serialization format designed with a code objective:

Reduce the number of tokens when exchanging structured data with language models.

While JSON uses verbose syntax with braces, quotes, and commas, TOON relies on a token-efficient tabular style, which is much closer to how LLMs naturally understand structured data.

Let’s make a quick comparison between JSON and TOON:

Here is some JSON with a users array that contains information about two users (two objects):

{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin" },
    { "id": 2, "name": "Bob", "role": "user" }
  ]
}

If you wanted to represent the same data in TOON, it would look like this:

users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user

Did you notice the differences?

• No quotes, braces, or colons in TOON.

• The users[2]{id,name,role}: declares an array of two objects with the fields id, name, and role.

• The lines below are simply the data rows.

You can see that TOON visibly reduced the token usage by 30-50%, depending on the data shape.

Why is TOON Important Now?

LLMs like GPT, Gemini, and Claude are token-based systems. Each word, symbol, or chunk costs tokens for input and output. So, if you’re preparing an LLM with structured data input/output like this:

{ "products": [ ... 300, "items" ... ] }

You might waste thousands of tokens in quotes, braces, colons, and repeated keys. TOON solves that by focusing on a compact yet structured representation.

Some of the key benefits of TOON are:

• 30-50% fewer tokens for uniform data sets.

• It has less syntactic clutter, which makes it easier for LLMs to reason about.

• It can be nested as we do with JSON.

• Works well with languages like Python, Go, Rust, and JavaScript.

TOON is a great augmentation to JSON, especially for AI projects, LLMs, and data-heavy prompts. It may not replace JSON entirely, but it’s suitable for use cases where JSON is considered heavyweight for data exchange.

JSON vs TOON – Learn With Examples

Now that you have a basic idea of what TOON does and why it’s helpful, let’s look at some of the most used JSON structures and their equivalent representation in TOON.

1. A Simple Object

Here’s how you’d represent an object with JSON:

{ "name": "Alice", "age": 30, "city": "Bengaluru" }

And here’s how it works with TOON:

name: Alice
age: 30
city: Bengaluru

2. Array of Values

With JSON:

{ "colors": ["red", "green", "blue"] }

With TOON:

colors[3]: red,green,blue

3. Array of Objects

With JSON:

{
  "users": [
    { "id": 1, "name": "Alice" },
    { "id": 2, "name": "Bob" }
  ]
}

With TOON:

users[2]{id,name}:
  1,Alice
  2,Bob

Here, users[2]{id,name} represents the schema, and the lines following it contain the actual data rows.

4. Nested Objects

With JSON:

{
  "user": {
    "id": 1,
    "name": "Alice",
    "profile": { "age": 30, "city": "Bengaluru" }
  }
}

With TOON:

user:
  id: 1
  name: Alice
  profile:
    age: 30
    city: Bengaluru

Indentation represents nesting. It’s almost YAML-like, but it’s still structured.

5. Array of Objects With Nested Fields

With JSON:

{
  "teams": [
    {
      "name": "Team Alpha",
      "members": [
        { "id": 1, "name": "Alice" },
        { "id": 2, "name": "Bob" }
      ]
    }
  ]
}

With TOON:

teams[1]:
  - name: Team Alpha
    members[2]{id,name}:
      1,Alice
      2,Bob

This is still perfectly understandable, and much smaller than the JSON format.

Now that you know a bit about TOON syntax, let’s see how to use it with different programming languages.

How to Use TOON With JavaScript / TypeScript

In most cases, TOON is not meant to be handwritten. Most TOON data will be generated automatically by software, or you’ll need to encode existing data (say, JSON data) into the TOON format.

And there’s good news – TOON already has an official NPM package that you can use in your JavaScript/TypeScript project to convert your JSON data to TOON and vice versa.

Install it using the following command:

npm install @toon-format/toon # Or yarn add, pnpm install, etc

The easiest way to create TOON code is by converting JSON to TOON. You can use the encode() method from the above-mentioned NPM package:

import { encode } from "@toon-format/toon";

const data = {
  users: [
    { id: 1, name: "Alice", role: "admin" },
    { id: 2, name: "Bob", role: "user" },
  ],
};

const toonString = encode(data);
console.log(toonString);

Output:

users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user

To do the reverse (TOON => JSON), you need to use the decode() method:

import { decode } from "@toon-format/toon";

const toonString = `
users[2]{id,name,role}:
  1,Alice,admin
  2,Bob,user
`;

const jsonObject = decode(toonString);
console.log(jsonObject);

Output:

{
  "users": [
    { "id": 1, "name": "Alice", "role": "admin" },
    { "id": 2, "name": "Bob", "role": "user" }
  ]
}

You can check out this sandbox and try out a few encoding and decoding examples.

How to Use Toon With Python

Using TOON in Python projects is as straightforward as it was with JavaScript/TypeScript. There are Python packages that can encode JSON data to TOON and decode it back to JSON. The python-toon package is the most famous one in recent days.

First, open your terminal and install the python-toon package:

pip install python-toon

Note that if you’re in a virtual environment, you’ll need to activate it first:

python -m venv venv
source venv/bin/activate
pip install python-toon

That’s it! Now you’re all set to use the methods to encode and decode your data to and from TOON. First, let’s encode JSON data to TOON using Python:

from toon import encode

# A channel object
channel = {"name": "tapaScript", "age": 2, "type": "education"}
toon_output = encode(channel)
print(toon_output)

Output:

name: tapaScript
age: 2
type: education

Similarly, we can decode TOON back to JSON:

from toon import decode

toon_string = """
name: tapaScript
age: 2
type: education
"""

python_struct = decode(toon_string)
print(python_struct)

Output:

{"name": "tapaScript", "age": 2, "type": "education"}

Hold On, JSON Might Still Be Better (In Many Cases)

Let’s make it clear that TOON is NOT a universal replacement for JSON. In fact, you should still prefer JSON in many cases, such as when:

• Your data is deeply nested.

• Your data is irregular (for example, varying object shapes).

• Your application needs strict schema validations or type enforcement.

• NON-AI use cases where JSON still stands out and does its job perfectly.

A hybrid approach may even work better. Keep JSON for your application’s data exchange format with APIs, but convert to TOON when it comes to sending data to LLMs.

The Future of TOON

TOON, though in its infancy, is still getting a lot of attention from the developer community. Its early traction is making it unavoidable to talk about.

TOON has already been explored for:

• Less token overhead for structured training data to fine-tune LLMs.

• Compact data exchange in Agent frameworks.

• Faster data serialization and deserialization between the MCP and AI workflow engines.

• With Serverless AI APIs, where cost and speed matter a lot.

Just as JSON has been a standard for the Web’s data exchange, TOON may soon be standardized for AI data interchange. So next time you craft a prompt or pass structured data to an AI model, try it in the TOON format. You may notice the model gets faster and cheaper.

Before We End…

That’s all! I hope you found this article insightful.

Let’s connect:

• Subscribe to my YouTube Channel.

• Check out my FREE courses, 40 Days of JavaScript and 15 Days of React Design Patterns.

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Join my Discord Server, and let’s learn together.

See you soon with my next article. Until then, please take care of yourself and keep learning.

If you happen to shout out “Yes!” to the above, you’re not alone. It’s a common feeling among many React developers across the globe. But React itself is not responsible for any of these issues. These situations arise because of code smells like:

• Props drilled six levels down.

• A single bloated component doing everything.

• Logic that’s duplicated across different components.

• Careless rendering (and re-rendering) causing performance issues.

A Code Smell doesn’t mean broken code. Rather, it’s an indication that the code may work now, but is difficult to maintain, reuse, scale, and much harder to debug.

And that’s exactly where we need to use Design Patterns. They’re well-tested solutions to the various code smell problems that developers have been encountering for decades. When you know how to use them well, you achieve a clean, maintainable codebase that is easy to enhance, debug, and scale.

Today, we will take a deep dive into one of the most prominent design patterns in React called the Compound Components Pattern. This pattern saves React developers from passing a long list of props and helps build composable user interface components.

This is going to be a complete hands-on tutorial. So get your favourite code editor ready, and let’s get started. This article is also available as a video tutorial as part of the 15 Days of React Design Patterns initiative. Please check it out.

Table of Contents

1. React 19 Code Set Up

2. A Messy Modal Component

3. The Problems with this messy Modal Component

4. The Compound Components Pattern

5. How to Build a Modal Component using the Compound Components Pattern

   • Why Didn’t We Create Separate Files for the SubComponents?

   • How to Use the Modal Component

   • How to build an Accordion Component using the Compound Components Pattern

   • Add the Accordion to the Modal

6. The Use Cases

7. The Pitfalls and Anti-Patterns

8. 15 Days of React Design Patterns

9. Before We End...

React 19 Code Set Up

The best way to understand how to apply a design pattern is by refactoring messy code with code smells to improve it to cleaner code. So let’s set up a coding ground so that we can start putting in our messy code first, and then go about applying the design pattern to it.

Note: you can find all the source code used in this tutorial on the tapaScript GitHub. Feel free to follow along with it side by side.

Also, make sure you have Node.js installed (preferably v18+). You can check it out by typing this command on your terminal/command prompt:

node -v

If you get an output with the installed Node.js version, you are all set. Otherwise, just download and install Node.js from here.

Now, run this command in your terminal to create a React 19 project scaffolding:

npx degit atapas/code-in-react-19#main compound-components-pattern

It will create a folder called compound-components-pattern with the Vite-based React project files under it. Now, change the directory using this command:

cd compound-components-pattern

Then install the dependencies using this command:

npm install ## Or, yarn install, or pnpm install, etc,

Now, you can import the project folder into your favourite code editor (I use VS Code).

Finally, to start the project locally, use the following command:

npm run dev ## Or, yarn dev, or pnpm dev

Now the project should be running locally and should be accessible on the default URL, http://localhost:5173. You can access the URL in your browser. Now we’re all set to start coding.

A Messy Modal Component

Let’s get started by creating a Modal component. Start by creating a directory called messy under the src/ directory. Now, create a file called Modal.jsx under src/messy/ with the following code snippet:

function Modal({ title, body, primaryAction, secondaryAction }) {
    return (
        <div className="modal-backdrop">
            <div className="modal-container">
                <h2 className="modal-header">{title}</h2>
                <p className="modal-body">{body}</p>
                <div className="modal-footer">
                    {secondaryAction}
                    {primaryAction}
                </div>
            </div>
        </div>
    );
}

export default Modal;

This is a simple React implementation of a modal component that accepts a title, body, and a couple of actions as props to render them as a modal.

• The title: The header title of the modal.

• The body: The modal content.

• The primaryAction: An action button like delete, create, save, and so on to place in the footer section of the modal.

• The secondaryAction: An action button like cancel, close, and so on to place in the footer section of the modal.

Next, open the App.jsx file and replace the existing code with the following code snippet:

import Modal from "./messy/Modal";

import "./App.css";

function App() {
    return (
        <div className="flex flex-col items-center">
            <Modal
                title="Delete Account"
                body="Are you sure you want to delete your account?"
                primaryAction={<button>Delete</button>}
                secondaryAction={<button>Cancel</button>} />
        </div>
    );
}

export default App;

Here, we have imported the Modal component and used it by passing its props values. Go to the browser tab and access the app’s URL. You should see the modal appearing like this:

Well, as it doesn’t look like a traditional modal with a backdrop and all, so let’s fix that using CSS. Open the App.css and paste the following CSS styles into it and save it:

.modal-backdrop {
    position: fixed;
    inset: 0;
    background: rgba(0, 0, 0, 0.5);
    display: flex;
    justify-content: center;
    align-items: center;
}
.modal-container {
    background: white;
    border-radius: 8px;
    padding: 1rem;
    width: 400px;
    position: relative;
}
.modal-header {
    font-weight: bold;
    margin-bottom: 1rem;
}
.modal-footer {
    display: flex;
    justify-content: flex-end;
    gap: 0.5rem;
    margin-top: 1rem;
}
.modal-close {
    position: absolute;
    top: 8px;
    right: 8px;
    background: none;
    border: none;
    font-size: 1.2rem;
}

Great! Now you have a cool-looking modal dialog asking for your confirmation to delete your account.

The Problems with This Messy Modal Component

Question for you: What problems do you think this modal implementation might have?

Let’s find the answers:

1. Lack of Flexibility: The modal has a rigid structure that dictates exactly what it renders. What if you want a modal without a title? Or a modal with a custom layout? Or more than two action buttons? You need to write additional logic and pass additional props every time you think of enhancing the modal for another use case. These changes in the component will bring maintainability issues and increase code smell.

2. Mixed Responsibilities: The modal tries to do multiple things. It handles both layout and content. This violates the separation of concerns principle that we learn from other design patterns, such as the Container-Presenter Pattern.

3. Hard Reusability: The modal lacks reusability due to its rigidness. Right now, if you want a modal with this:

    <h2>Something Wrong!</h2>
    <img src="warning.png" />
    <p>Something went wrong. please see the logs for more details.</p>
   

   You can not reuse this component, and you will end up creating a new one.

4. Poor Scalability: The modal component is not scalable. Think, for example, if you’re creating a component library and you end up creating multiple modal instances like ConfirmationModal, InfoModal, FormModal, ImageModal, and so on. It would be a huge ding on the scalability of that component library to create and maintain every new version of the modal.

5. Hard to Test: This modal implementation is hard to test due to its tight coupling with props.

With these issues in mind, let’s welcome the compound components pattern and see how it can help us solve them.

The Compound Components Pattern

Compound Components Pattern in React is a design pattern where a parent component works together with its child components to share an implicit state and behaviour. Instead of passing a long list of props, the parent manages the state and exposes flexible child components (<Modal.Header>, <Modal.Body>, <Modal.Footer>, and so on) so that consumers can compose the UI naturally, just like using native HTML elements.

Think of Compound Composition Pattern like LEGO blocks.

• The parent component is like the LEGO base plate.

• The child components are the LEGO blocks (door, window, roof, and so on).

• You don’t pass any props to the base plate, saying, “add a door here, add a window there.” Instead, you simply place the pieces where you want them.

• The base plate (parent) still provides the rules and structure (studs, alignment, stability), but you get the flexibility to assemble your model however you like.

Got it? That’s the power of compound components. It’s a flexible composition with a shared state/behaviour underneath.

Let’s now refactor our messy (and smelly) modal component by applying the compound components pattern.

How to Build a Modal Component Using the Compound Components Pattern

Create a folder called with-pattern under the src/ folder. We will arrange and maintain the modal component, and in the future, an accordion component under this new folder.

Next, create a folder called modal under the src/with-pattern. Finally, create a file called Modal.jsx with the following code snippet:

// File Location: src/with-pattern/modal/Modal.jsx

const Modal = ({ children, isOpen, onClose }) => {
    if(!isOpen) return null;
    return (
        <div className="modal-backdrop">
            <div className="modal-container">
                {children}
                <button className="modal-close" onClick={onClose}>
                    ✖
                </button>
            </div>

        </div>
    );
};

function ModalHeader({ children }) {
    return <div className="modal-header">{children}</div>;
}

function ModalBody({ children }) {
    return <div className="modal-body">{children}</div>;
}

function ModalFooter({ children }) {
    return <div className="modal-footer">{children}</div>;
}

Modal.Header = ModalHeader;
Modal.Body = ModalBody;
Modal.Footer = ModalFooter;

export default Modal;

Let me break it down for you:

• First, focus on the Modal component above. It doesn’t take title, body, and so on as props anymore. Rather, it accepts children, a special prop in React to pass any HTML elements, a group of HTMLs, JSX, or even a React component. It brings flexibility that we are no longer fixed to any particular structure to pass to the Modal component.

• The JSX of the Modal component just renders the children prop as is, giving the entire power to the consumer of the Modal component to pass any structure it’s willing to. The Modal component uses the backdrop and container style to dictate the basic look and feel of a modal.

• The Modal’s JSX also has a button to close the modal by clicking on an x. To open and close the modal, we have passed two additional props, isOpen and onClose. You can imagine isOpen is a state value that the consumer of this modal uses to open the modal, and the onClose is a function that sets the value of the isOpen to false to close the modal.

• Then, we have defined three more components, ModalHeader, ModalBody, and ModalFooter which are equally flexible to accept any legit HTML structure or React component through the children prop. Now you can pass anything to render to the modal header. The same goes for the body and footer as well.

• Next, we add the header, body, and footer as the subcomponents to the Modal component.

    Modal.Header = ModalHeader;
    Modal.Body = ModalBody;
    Modal.Footer = ModalFooter;
  

• Finally, we exported the Modal component.

Why Didn’t We Create Separate Files for the SubComponents?

This question is quite natural. In general, we follow the standard practice of one component in one source file(.jsx/.tsx). Here, we seem to be breaking that rule…so are we? Actually not.

The golden rules are:

• The subcomponents (ModalHeader, ModalBody, and ModalFooter) are only meaningful in the context of Modal. They don’t have (or need) any existence beyond the modal.

• They are small helper components that you don’t expect to reuse anywhere else.

• Keeping them together is good for discoverability and is safe from potential misuse that we’ll discuss in the pitfalls section later.

How to Use the Modal Component

So we’re sorted. Let’s now learn how to use this Modal component and see how it can bring flexibility, reusability, scalability, and testability.

Open the App.jsx file and replace the content of it with the following code snippet:

import { useState } from "react";
// import Modal from "./messy/Modal";
import Modal from "./with-pattern/modal/Modal";

import "./App.css";

function App() {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div className="flex flex-col items-center">

      <button onClick={() => setIsOpen(true)}>Open Modal</button>

      <Modal isOpen={isOpen} onClose={() => setIsOpen(false)}>

        <Modal.Header>
          <h2>Welcome!</h2>
        </Modal.Header>

        <Modal.Body>
          <p>
              This is a modal built with the Compound Component
              pattern.
          </p>
        </Modal.Body>

        <Modal.Footer>
          <button>Help!</button>
          <button onClick={() => setIsOpen(false)}>Close</button>
          <button onClick={() => alert("Action Performed!")}>Do Action</button>
        </Modal.Footer>

      </Modal>

    </div>
  );
}

export default App;

Check out how we have passed a bunch of JSX inside <Modal>…</Modal> as the children. It’s so powerful. We’re passing the subcomponents header, body, and footer in the sequence we want them to appear in the modal.

Next, if we look into the <ModalHeader>, <ModalBody>, or <ModalFooter> components, we can again pass anything as children to them. For example, the <ModalFooter /> can now take three buttons (in fact, anything else) based on the needs.

We can compose the components like Lego blocks to build the kind of Modal that we wish to. You don't need to have different components to represent different kinds of modals now. This single component can cater to all your modal needs without introducing any props soup drama.

We have a button to open the modal, and the App.jsx component manages a state called isOpen to tackle the opening and closing of the modal.

You should be able to see these changes now in the browser. Click on the open modal button.

The modal dialog opens up with all the content we have passed to it.

It’s a big leap towards achieving clean code to use the compound components design pattern. Now that you’re familiar with the basics, let’s quickly do another classic implementation of this pattern by building an Accordion component.

How to Build an Accordion Component Using the Compound Components Pattern

An accordion component is an array of Accordion Items. It’s a combination of a header and body that shows and hides the content when users click on the header.

Create a folder called accordion under src/with-pattern folder. Now, create a file called Accordion.jsx inside the src/with-pattern/accordion with the following code snippet:

import { useState } from "react";

function Accordion({ children }) {
  return <div className="accordion">{children}</div>;
}

function AccordionItem({ title, children }) {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div className="accordion-item">
      <button className="accordion-title" onClick={() => setIsOpen(!isOpen)}>
        {title}
      </button>
      {isOpen && <div className="accordion-content">{children}</div>}
    </div>
  );
}

// Attach subcomponents
Accordion.Item = AccordionItem;

export default Accordion;

Here,

• We have followed the same pattern as we did for the modal previously. We have an Accordion component that takes a special prop called children, enabling the Accordion to accept any HTML/JSX/React component and render it.

• Then we defined the AccordionItem. It takes two props: the title to create the header, and the special prop called children to form the accordion content flexibly.

• The header is formed using the button that is driven by a state called isOpen to show/hide the content area.

• The content area of an AccordionItem could be anything: a paragraph, a table, an image, or even a JSX combining them.

• Finally, we have added the AccordionItem as the subcomponent to the Accordion component.

To make the accordion look better, let’s add a few styles. Open the App.css file and add these styles at the end of the file:

.accordion-item {
    margin-bottom: 0.5rem;
    border: 1px solid #ddd;
    border-radius: 4px;
}
.accordion-title {
    width: 100%;
    text-align: left;
    padding: 0.5rem;
    font-weight: bold;
    cursor: pointer;
    background: #f9f9f9;
    border: none;
}
.accordion-content {
    padding: 0.5rem;
    background: #fff;
}

Great, let’s now use the Accordion component. Create a new file called AccordionDemo.jsx under the folder src/with-pattern/accordion with the following code snippet:

import Accordion from "./Accordion";

export default function AccordionDemo() {
  return (
    <Accordion>
      <Accordion.Item title="What is Compound Component Pattern?">
        It’s a React pattern that allows parent and child components to work
        together seamlessly while giving developers flexible composition.
      </Accordion.Item>

      <Accordion.Item title="Why use it?">
        It makes UI libraries like modals, tabs, accordions, menus, etc. easier
        to build and use.
      </Accordion.Item>

      <Accordion.Item title="Pitfalls?">
        Overusing it can lead to deeply nested structures or make things harder
        to debug if not documented well.
      </Accordion.Item>
    </Accordion>
  );
}

Check out how the Accordion component can accept a bunch of AccordionItem components. You can also create an array of AccordionItem components and pass them dynamically to the Accordion component.

Each of the AccordionItem components accepts the title prop value, and we passed the text as the children. If needed, you can pass any other valid JSX as a child. That’s amazing!

Add the Accordion to the Modal

Now, let’s take the usage of this pattern to the next level. How about using the AccordionDemo inside the Modal component? Can we do it without changing the Modal component?

Oh yes! Remember, the Modal component accepts any JSX as children, and so does the ModalBody component. So we can just import the AccordionDemo component into the App.jsx file and use it inside the <Modal.Body>…</Modal.Body> as shown below, right?

import { useState } from "react";
// import Modal from "./messy/Modal";
import Modal from "./with-pattern/modal/Modal";

import AccordionDemo from "./with-pattern/accordion/AccordionDemo";

import "./App.css";

function App() {
  const [isOpen, setIsOpen] = useState(false);

  return (
    <div className="flex flex-col items-center">

      <button onClick={() => setIsOpen(true)}>Open Modal</button>

      <Modal isOpen={isOpen} onClose={() => setIsOpen(false)}>

        <Modal.Header>
          <h2>Welcome!</h2>
        </Modal.Header>

        <Modal.Body>
          <p>
              This is a modal built with the Compound Component
              pattern.
          </p>
          <AccordionDemo />
        </Modal.Body>

        <Modal.Footer>
          <button>Help!</button>
          <button onClick={() => setIsOpen(false)}>Close</button>
          <button onClick={() => alert("Action Performed!")}>Do Action</button>
        </Modal.Footer>
      </Modal>

    </div>
  );
}

export default App;

Now, if you run the app with these code changes, you should see the accordion appearing inside the modal. You will also be able to show/hide the accordion content and open/close the modal. This means their individual states are intact as expected.

The Use Cases

So far, we have seen a couple of important usages of the Compound Components pattern with modal and accordion. Similarly, you can use this pattern to build reusable components like:

• Tables (Table.Head, Table.Body, Table.Row).

• Any component where layout and nesting matter.

Also, if you’re ever writing your own component library or design system, this pattern is a must. If you need some inspiration, look at ShadCN, Material UI, or Radix UI. They all do this.

The Pitfalls and Anti-Patterns

As you know, with great power comes great responsibility. And with patterns comes the pitfalls and anti-patterns you’ll need to be aware of. When you’re using the compound components pattern, just make sure that you:

• Don’t attach subcomponents randomly. They should belong to the parent semantically.

• Avoid re-exporting subcomponents separately. It will be a disaster if someone uses the ModalFooter without a Modal. What if the ModalFooter changes tomorrow in the context of the Modal, and the other consumers are not in need/aware of that change?

• Don’t attempt to make everything in the compound components pattern. The rule of thumb is, only use it when the children's structure matters, and you want to keep it flexible.

15 Days of React Design Patterns

I have some great news for you! After the 40 days of the JavaScript initiative, I have now started a brand new initiative called 15 Days of React Design Patterns.

If you enjoyed learning from this article, I am sure you will love this series, featuring the 15 most important React design patterns. Check it out and join.

Before We End...

That’s all! I hope you found this article insightful.

Let’s connect:

• Subscribe to my YouTube Channel.

• Subscribe to my fortnightly newsletter, The Commit Log.

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Join my Discord Server, and let’s learn together.

See you soon with my next article. Until then, please take care of yourself and keep learning.

JavaScript has been a popular programming language for over three decades. We build web, mobile, PWA, and server-side applications using JavaScript and various popular JavaScript-based libraries (like ReactJS) and frameworks (like Next.js, Remix, and so on).

Being a loosely typed language, JavaScript imposes the challenge of handling type safety correctly. TypeScript is useful for managing types, but we still need to handle runtime errors efficiently in our code.

Errors like TypeError, RangeError, ReferenceError are probably pretty familiar to you if you’ve been building with JavaScript for a while. All these errors may cause invalid data, bad page transitions, unwanted results, or even the entire application to crash – none of which will make end users happy!

In this handbook, you’ll learn everything you need to know about error handling in JavaScript. We will start with an understanding of errors, their types, and occurrences. Then you’ll learn how to deal with these errors so that they don’t cause a bad user experience. At the end, you’ll also learn to build your own custom error types and clean-up methodologies to handle your code flow better for optimizations and performance.

I hope you enjoy reading along and practising the tasks I have provided at the end of the article.

This handbook is also available as a video session as part of the 40 Days of JavaScript initiative. Please check it out.

Table of Contents

1. Errors in JavaScript

2. Handling Errors With the try and catch

   • The try Block

   • The catch Block

3. Error Handling: Real-World Use Cases

   • Handling Division by Zero

   • Handling JSON

4. Anatomy of the Error Object

   • What is the Error Object?

5. Throwing Errors and Re-throwing Errors

   • Rethrowing

6. The finally with try-catch

   • Caution with finally

7. Custom Errors

   • A Real-World Use Case of Custom Errors

8. Task Assignments for You

   • Find the Output

   • Payment Process Validation

9. 40 Days of JavaScript Challenge Initiative

10. Before We End...

Errors in JavaScript

Errors and exceptions are the events that disrupt program execution. JavaScript parses and executes code line by line. The source code gets evaluated with the grammar of the programming language to ensure it is valid and executable. If there is a mismatch, JavaScript encounters a parsing error. You’ll need to make sure you follow the right syntax and grammar of the language to stay away from parsing errors.

Take a look at the code snippet below. Here, we have made the mistake of not closing the parentheses for the console.log.

console.log("hi"

This will lead to a Syntax Error like this:

Other types of errors can happen due to wrong data input, trying to read a value or property that doesn’t exist, or acting on inaccurate data. Let’s see some examples:

console.log(x); // Uncaught ReferenceError: x is not defined

let obj = null;
console.log(obj.name); // Uncaught TypeError: Cannot read properties of null

let arr = new Array(-1) // Uncaught RangeError: Invalid array length

decodeURIComponent("%"); // Uncaught URIError: URI malformed

eval("var x = ;"); // Uncaught EvalError

Here is the list of possible runtime errors you may encounter, along with their descriptions:

• ReferenceError – Occurs when trying to access a variable that is not defined.

• TypeError – Occurs when an operation is performed on a value of the wrong type.

• RangeError – Occurs when a value is outside the allowable range.

• SyntaxError – Occurs when there is a mistake in the syntax of the JavaScript code.

• URIError – Occurs when an incorrect URI function is used in encoding and decoding URIs.

• EvalError – Occurs when there is an issue with the eval() function.

• InternalError – Occurs when the JavaScript engine runs into an internal limit (stack overflow).

• AggregateError – Introduced in ES2021, used for handling multiple errors at once.

• Custom Errors – These are user-defined errors, and we will learn how to create and use them soon.

Have you noticed that all the code examples we used above result in a message explaining what the error is about? If you look at those messages closely, you will find a word called Uncaught. It means the error occurred, but it was not caught and managed. That’s exactly what we will now go for – so you know how to handle these errors.

Handling Errors With the try and catch

JavaScript applications can break for various reasons, like invalid syntax, invalid data, missing API responses, user mistakes, and so on. Most of these reasons may lead to an application crash, and your users will see a blank white page.

Rather than letting the application crash, you can gracefully handle these situations using try…catch.

try {
    // logic or code
} catch (err) {
    // handle error
}

The try Block

The try block contains the code – the business logic – which might throw an error. Developers always want their code to be error-free. But at the same time, you should be aware that the code might throw an error for several possible reasons, like:

• Parsing JSON

• Running API logic

• Accessing nested object properties

• DOM manipulations

• … and many more

When the code inside the try block throws an error, the code execution of the remaining code in the try block will be suspended, and the control moves to the nearest catch block. If no error occurs, the catch block is skipped completely.

try {
  // Code that might throw an error
} catch (error) {
  // Handle the error here
}

The catch Block

The catch block runs only if an error was thrown in the try block. It receives the Error object as a parameter to give us more information about the error. In the example shown below, we are using something called abc without declaring it. JavaScript will throw an error like this:

try {
    console.log("execution starts here");
    abc;
    console.log("execution ends here");
} catch (err) {
    console.error("An Error has occured", err);
}

JavaScript executes code line by line. The execution sequence of the above code will be:

• First, the string "execution starts here" will be logged to the console.

• Then the control will move to the next line and find the abc there. What is it? JavaScript doesn’t find any definition of it anywhere. It’s time to raise the alarm and throw an error. The control doesn’t move to the next line (the next console log), but rather moves to the catch block.

• In the catch block, we handle the error by logging it to the console. We could do many other things like show a toast message, send the user an email, or switch off a toaster (why not if your customer needs it).

Without try...catch, the error would crash the app.

Error Handling: Real-World Use Cases

Let’s now see some of the real-world use cases of error handling with try…catch.

Handling Division by Zero

Here is a function that divides a number by another number. So, we have parameters passed to the function for both numbers. We want to make sure that the division never encounters an error for dividing a number by zero (0).

As a proactive measure, we have written a condition that if the divisor is zero, we will throw an error saying that division by zero is not allowed. In every other case, we will proceed with the division operation. In case of an error, the catch block will handle the error and do what’s needed (in this case, logging the error to the console).

function divideNumbers(a, b) {
    try {
        if (b === 0) {
            const err = new Error("Division by zero is not allowed.");
            throw err;
        }
        const result = a/b;
        console.log(`The result is ${result}`);
    } catch(error) {
        console.error("Got a Math Error:", error.message)
    }
}

Now, if we invoke the function with the following arguments, we will get a result of 5, and the second argument is a non-zero value.

divideNumbers(15, 3); // The result is 5

But if we pass the 0 value for the second argument, the program will throw an error, and it will be logged into the console.

divideNumbers(15, 0);

Output:

Handling JSON

Often, you will get JSON as a response to an API call. You need to parse this JSON in your JavaScript code to extract the values. What if the API sends you some malformed JSON by mistake? You can’t afford to let your user interface crash because of this. You need to handle it gracefully – and here comes the try…catch block again to the rescue:

function parseJSONSafely(str) {
  try {
    return JSON.parse(str);
  } catch (err) {
    console.error("Invalid JSON:", err.message);
    return null;
  }
}

const userData = parseJSONSafely('{"name": "tapaScript"}'); // Parsed
const badData = parseJSONSafely('name: tapaScript');         // Handled gracefully

Without try...catch, the second call will crash the app.

Anatomy of the Error Object

Getting errors in programming can be a scary feeling. But Errors in JavaScript aren’t just some scary, annoying messages – they are structured objects that carry a lot of helpful information about what went wrong, where, and why.

As developers, we need to understand the anatomy of the Error object to help us better with faster debugging and smarter recovery in production-level application issues.

Let’s deep dive into the Error object, its properties, and how to use it effectively with examples.

What is the Error Object?

The JavaScript engine throws an Error object when something goes wrong during runtime. This object contains helpful information like:

• An error message: This is a human-readable error message.

• The error type: TypeError, ReferenceError, SyntaxError, and so on that we discussed above.

• The stack trace: This helps you navigate to the root of the error. It is a string containing the stack trace at the point the error was thrown.

Let’s take a look at the code snippet below. The JavaScript engine will throw an error in this code, as the variable y is not defined. The error object contains the error name (type), message, and the stack trace information.

function doSomething() {
  const x = y + 1; // y is not defined
}
try {
  doSomething();
} catch (err) {
  console.log(err.name);    // ReferenceError
  console.log(err.message); // y is not defined
  console.log(err.stack); // ReferenceError: y is not defined
                          // at doSomething (<anonymous>:2:13)
                          // at <anonymous>:5:3
}

Tip: If you need any specific properties from the error object, you can use destructuring to do that. Here is an example where we are only interested in the error name and message, not the stack.

try {
  JSON.parse("{ invalid json }");
} catch ({name, message}) {
  console.log("Name:", name);       // Name: SyntaxError
  console.log("Message:", message); // Message: Expected property name or '}' in JSON at position 2 (line 1 column 3)
}

Throwing Errors and Re-throwing Errors

JavaScript provides a throw statement to trigger an error manually. It is very helpful when you want to handle an invalid condition in your code (remember the divide by zero problem?).

To throw an error, you need to create an instance of the Error object with details and then throw it.

throw new Error("Something is bad!");

When the code execution encounters a throw statement,

• It stops the execution of the current code block immediately.

• The control moves to the nearest catch block (if any).

• If the catch block is not found, the error will not be caught. The error gets bubbled up, and may end up crashing the program. You can learn more in-depth about events and event bubbling from here.

Rethrowing

At times, catching the error itself in the catch block is not enough. Sometimes, you may not know how to handle the error completely, and you might want to do additional things, like:

• Adding more context to the error.

• Logging the error into a file-based logger.

• Passing the error to someone more specialized to handle it.

This is where rethrow comes in. With rethrowing, you catch an error, do something else with it, and then throw it again.

function processData() {
  try {
    parseUserData();
  } catch (err) {
    console.error("Error in processData:", err.message);
    throw err; // Rethrow so the outer function can handle it too
  }
}

function main() {
  try {
    processData();
  } catch (err) {
    handleErrorBetter(err);
  }
}

In the code above, the processData() function catches an error, logs it, and then throws it again. The outer main() function can now catch it and do something more to handle it better.

In the real-world application development, you would want to separate the concerns for errors, like:

• API Layer – In this layer, you can detect HTTP failures

    async function fetchUser(id) {
      const res = await fetch(`/users/${id}`);
      if (!res.ok) throw new Error("User not found"); // throw it here
      return res.json();
    }
  

• Service Layer – In this layer, you handle business logic. So the error will be handled for invalid conditions.

    async function getUser(id) {
      try {
        const user = await fetchUser(id);
        return user;
      } catch (err) {
        console.error("Fetching user failed:", err.message);
        throw new Error("Unable to load user profile"); // rethrowing 
      }
    }
  

• UI Layer – Show a user-friendly error message.

    async function showUserProfile() {
      try {
        const user = await getUser(123);
        renderUser(user);
      } catch (err) {
        displayError(err.message); // A proper message show to the user
      }
    }
  

The finally with try-catch

The try…catch block gives us a way to handle errors gracefully. But you may always want to execute some code irrespective of whether an error occurred or not. For example, closing the database connection, stopping a loader, resetting some states, and so on. That’s where finally comes in.

try {
  // Code might throw an error
} catch (error) {
  // Handle the error
} finally {
  // Always runs, whether an error occured or not
}

Let’s take an example:

function performTask() {
  try {
    console.log("Doing something cool...");
    throw new Error("Oops!");
  } catch (err) {
    console.error("Caught error:", err.message);
  } finally {
    console.log("Cleanup: Task finished (success or fail).");
  }
}

performTask();

In the performTask() function, the error is thrown after the first console log. So, the control will move to the catch block and log the error. After that, the finally block will execute its console log.

Output:

Doing something cool...
Caught error: Oops!
Cleanup: Task finished (success or fail).

Let’s take a more real-world use case of making an API call and handling the loading spinner:

async function loadUserData() {
  showSpinner(); // Show the spinner here

  try {
    const res = await fetch('/api/user');
    const data = await res.json();
    displayUser(data);
  } catch (err) {
    showError("Failed to load user.");
  } finally {
    hideSpinner(); // Hide spinner for both success and fail cases.
  }
}

Usually, we show a loading spinner while making an API (asynchronous) call from the browser. Irrespective of the successful response or an error from the API call, we must stop showing the loading spinner. Instead of executing the code logic twice to stop the spinner (once inside the try block and then again inside the catch block), you can do it inside the finally block.

Caution with finally

The finally block can override return values or a thrown error. This behaviour may be confusing and can lead to bugs as well.

function test() {
  try {
    return 'from try';
  } finally {
    return 'from finally';
  }
}

console.log(test());

What do you think the above code returns?

It will return 'from finally'. The return 'from try' is completely ignored. The return from finally overrides it silently.

Let’s see one more example of the same problem:

function willThrow() {
  try {
    throw new Error("Original Error");
  } finally {
    throw new Error("Overriding Error"); // The original error is lost
  }
}

try {
  willThrow();
} catch (err) {
  console.log(err.message); // "Overriding Error"
}

Here, the original error ("Original Error”) is swallowed. The finally block overrides the actual root cause.

When using finally:

• Avoid returns and throws from finally as much as possible.

• Avoid performing logic in the finally block that may impact the actual outcome. The try block is the best place for that.

• Any critical decision-making must be avoided inside the finally block

• Use finally for cleanup activities, such as closing files, connections, and stopping loading spinners, etc.

• Ensure the finally block contains side-effect-free code.

Custom Errors

Using the generic Error and its existing types, like ReferenceError, SyntaxError, and so on, can be a bit vague in complex applications. JavaScript lets you create custom errors that are more related to your business use cases. The custom errors can provide:

• Additional contextual information about the error.

• Clarity about the error

• More readable logs

• The ability to handle multiple error cases conditionally.

A custom error in JavaScript is a user-defined error type that extends the built-in Error class. The custom error should be an ES6 Class that extends JavaScript’s Error class. We can use the super() in the constructor function to inherit the message property of the Error class. You can optionally assign a name and clean the stack trace for the custom error.

class MyCustomError extends Error {
  constructor(message) {
    super(message);         // Inherit message property
    this.name = this.constructor.name; // Optional but recommended
    Error.captureStackTrace(this, this.constructor); // Clean stack trace
  }
}

Let’s now see a real-world use case for a custom error.

A Real-World Use Case of Custom Errors

Using a form on a web page is an extremely common use case. A form may contain one or more input fields. It is recommended to validate the user inputs before we process the form data for any server actions.

Let’s create a custom validation error we can leverage for validating multiple form input data, like the user’s email, age, phone number, and more.

First, we’ll create a class called ValidationError that extends the Error class. The constructor function sets up the ValidationError class with an error message. We can also instantiate additional properties, like name, field, and so on.

class ValidationError extends Error {
  constructor(field, message) {
    super(`${field}: ${message}`);
    this.name = "ValidationError";
    this.field = field;
  }
}

Now, let's see how to use ValidationError. We can validate a user model to check its properties and throw a ValidationError whenever the expectations mismatch.

function validateUser(user) {
  if (!user.email.includes("@")) {
    throw new ValidationError("email", "Invalid email format");
  }
  if (!user.age || user.age < 18) {
    throw new ValidationError("age", "User must be 18+");
  }
}

In the code snippet above,

• We throw an invalid email format validation error if the user’s email doesn’t include the @ symbol.

• We throw another validation error if the age information of the user is missing or is below 18.

A custom error gives us the power to create domain/usage-specific error types to keep the code more manageable and less error-prone.

Task Assignments for You

If you have read the handbook this far, I hope you now have a solid understanding of JavaScript Error Handling. Let’s try out some assignments based on what we have learned so far. It’s going to be fun.

Find the Output

What will be the output of the following code snippet and why?

try {
    let r = p + 50;
    console.log(r);
} catch (error) {
    console.log("An error occurred:", error.name);
}

Options are:

• ReferenceError

• SyntaxError

• TypeError

• No error, it prints 10

Payment Process Validation

Write a function processPayment(amount) that verifies if the amount is positive and does not exceed the balance. If any condition fails, throw appropriate errors.

Hint: You can think of creating a Custom Error here.

40 Days of JavaScript Challenge Initiative

There are 101 ways of learning something. But nothing can beat structured and progressive learning methodologies. After spending more than two decades in Software Engineering, I’ve been able to gather the best of JavaScript together to create the 40 Days of JavaScript challenge initiative.

Check it out if you want to learn JavaScript with fundamental concepts, projects, and assignments for free (forever). Focusing on the fundamentals of JavaScript will prepare you well for a future in web development.

Before We End...

That’s all! I hope you found this article insightful.

Let’s connect:

• Subscribe to my YouTube Channel.

• Follow on LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Check out and follow my open-source work on GitHub.

See you soon with my next article. Until then, please take care of yourself and keep learning.

Many of the libraries and frameworks you likely use to build modern web applications are based on JavaScript, like React.js, Next.js, Angular, Solid.js, Vue.js, and Node.js to name a few.

While these libraries and frameworks provide a lot of helpful abstractions on low-level programming, as an application developer you still have to have a solid grasp of JavaScript fundamentals to be able to use them effectively.

A very basic programming concept is Control Flow and decision-making. And it’s not related to JavaScript alone – you’ll encounter it in most of the programming languages you work with.

In this article, you’ll learn about two primary techniques for managing control flow in JavaScript: using if-else and switch-case. Many of you may be aware of their constructs and usages. But the focus of this article is to draw a comparison between the two, so that by the end of it you’ll know which one to choose for each use case.

This article is also available as a video tutorial as part of the 40 Days of JavaScript initiative. Please check it out.

Table of Contents

• What is Control Flow in JavaScript?

• How to Handle Control Flow With the if-else Block

• How to Handle Control Flow With the switch Statement

• The Comparison: if-else vs switch-case

• Before We End...

What is Control Flow in JavaScript?

In JavaScript, your code runs line-by-line starting from the first line up to the last line of the JavaScript file. This order of code execution by the JavaScript interpreter is called control flow.

At times, your program may require changes in the flow of execution depending on one or more conditions. These conditions will determine whether a set of statements in the JavaScript file should be executed or not.

Let’s look at this example of a JavaScript file (some.js) shown below:

The file has 12 lines of code. Once this file is loaded into the JavaScript environment, the interpreter will start the execution from line number 1 and will proceed line by line. At line number 4, the interpreter will encounter a control statement which will allow the interpreter to either execute or skip line number 5. In our case, it is skipping the execution of line number 5.

So, the control goes to line 6, executes every line, and proceeds to line 9. Then, it encounters another control statement to skip line 10, start execution from line 11, and finish at the last line, line 12.

There are two major control statements in JavaScript that you must be aware of:

• if and if-else

• switch-case

First, let’s discuss them with examples to understand how they impact the control flow of code execution.

How to Handle Control Flow With the if-else Block

The if keyword and the combination of the if-else keywords help us create control statements in the code execution flow. With if, a block of code will be executed only when a test condition is passed. A passed condition returns a true, and a failed condition returns a false.

Let’s take an example: If you catch the bus, you will get home on time. Now, if you had to write this scenario programmatically, you’d create a condition for cacthingBus. Then, you’d pass the condition to the if using a pair of parenthesis. The code block associated with the if gets executed if the condition results in true.

let catchingBus = true;

// Some code here...

if (catchingBus) {
    console.log("I will get home on time");
} 

// Some other code here...

In the code snippet above, the result of the condition catchingBus is true. So the code execution flow will enter the if-block and execute the console log, I will get home on time. If you change the value of the condition to false, the if-block will be skipped. In such cases, you may want to handle an alternate use case – so you bring an else block along with the if.

In the code snippet below, we have both if and else. In this case, the condition results in false. So, the else block will be executed and I will be late to get home will be logged into the console.

let catchingBus = false;

if (catchingBus) {
    console.log("I will get home on time");
} else {
    console.log("I will be late to get home");
}

You may have more than a pair of if-else for handling complex problems. Let’s take an example of a grading system. If your score is 90 or above, you get a grade A, for 80 or above, a Grade B, for 70 or above, and a Grade C, or else you fail.

Let’s write the program for it with the help of the if-else. As we have multiple conditions to handle, we will need multiple if-blocks and associated else-blocks.

let score = 76;

if (score >= 90) {
    console.log("Grade A");
} else if (score >= 80) {
    console.log("Grade B");
} else if (score >= 70) {
    console.log("Grade C");
} else {
    console.log("Fail");
}

Combining multiple if-else statements is a great way to handle checking for multiple conditions and take action based on a condition that passes or fails.

How to Handle Control Flow with the switch-case Statement

While if-else is great when we’re checking multiple possible conditions, you can use switch-case to handle multiple conditions based on a single value.

switch(value) {
    case "case 1": // do something
    case "case 2": // do something
    case "case 3": // do something
    case "case 4": // do something
    default: // do something
}

Unlike if-block, the switch-block accepts a value and then checks for a matching case for that value. When a case is matched, JavaScript will execute the code block for the case. Using a break statement will exit from the switch block. When none of the cases match, the default will be executed.

In the code snippet below, we are checking for a match based on a position value. So, the position value is passed to the switch statement. Now, if the position value is 1, the first case will be matched because it matches for the value 1. Likewise, it will be the same for the positions 2, 3, or 4. If we pass a position value that is not 1,2, 3, or 4, the default block will be executed.

let position = 10;

switch (position) {
    case 1:
        console.log("Print 1");
        break;
    case 2:
        console.log("Print 2");
        break;
    case 3:
        console.log("Print 3");
        break;
    case 4:
        console.log("Print 4");
        break;

    default:
        console.log("Nothing is matched");
}

The Comparison: if-else vs switch-case

Now, it’s time to compare each of these approaches. Apart from their syntactical differences, there are a few key differences and considerations you need to keep in mind before opting for one instead of the other:

• Use if-else when you have to handle complex logical conditions. But if you need to check for a fixed value like numbers, strings, and so on, and then match it to a specific case value, go for switch-case.

• When there are many if-else blocks, the readability of the code starts going downhill. It’s much easier to read case labels for switch-case.

• If there are too many if-else blocks, the performance may be slower than the switch-case block. In many JavaScript engines, switch statements are optimized. They use a jump table for the JavaScript engine to directly jump into the correct case than evaluate each condition sequentially.

Let’s understand with an example. Check out the following code snippet written using the if-else blocks:

let value = 3;

if (value === 1) {
    console.log("One");
} else if (value === 2) {
    console.log("Two");
} else if (value === 3) {
    console.log("Three");
} else {
    console.log("Not found");
}

In this case,

• All the if-else statements will be executed sequentially. The JavaScript engine will check for each condition one by one until a match is found.

• If the matching condition is towards the bottom, then all the conditions above it must be checked. So the if-else can be slower when we have a worst-case scenario for the match. In the above example, if the match is for the value 3, the JavaScript interpreter finishes checking for values 1 and 2, before checking the value 3.

Now, the same result with the switch case:

let value = 3;

switch (value) {
    case 1:
        console.log("One");
        break;
    case 2:
        console.log("Two");
        break;
    case 3:
        console.log("Three");
        break;
    default:
        console.log("Not found");
}

Here,

• The JavaScript engine may have the jumping table created.

• The engine directly jumps into case 3, skipping all other unnecessary checks, so it’ll be faster. But keep in mind that this difference in performance is negligible for a small number of conditions.

I hope these points help you to choose between the if-else and switch statements more easily.

Before We End...

That’s all. I hope you found this article insightful. Focusing on the fundamentals of JavaScript will prepare you well for a future in web development. Check out my 40 Days of JavaScript initiative if you want to learn JavaScript with fundamental concepts, projects, and assignments for free (forever).

Let’s Connect:

• Subscribe to my YouTube Channel.

• Follow on X (Twitter) or LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Check out and follow my Open Source work on GitHub.

• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and keep learning.

In this case, there is no database to store the information. Rather, you just have a free Discord text channel that keeps the data as a sequence of messages in chat. And an admin/moderator/user with the required access rights can read through these messages and take the appropriate action.

In case you are new to Discord, it’s a great platform for chatting, playing video games, having calls, and even running a virtual team for your startup. It’s free, and you can download it from here.

Alright, coming back to the topic, I had a requirement like this to implement using Discord’s webhook and Next.js. I learned a lot from the activity. So I wrote this step-by-step tutorial about that process.

The primary objective here is to understand:

• What is a Webhook and what are the use cases?

• How to Integrate a webhook with a web application framework like Next.js

• How to build a user interface with the latest APIs and components from Next.js

I hope you’ll like it. If you want to learn from a video, the article is also available as a video tutorial:

Table of Contents

1. What is a Webhook?

2. How to Configure a Webhook on Discord

3. How to Create a Next.js Project

4. How to Set Environment Variables

5. How to Integrate the Webhook with the Next.js Form Component

   • Create the Form

   • Create the Server Action

6. How to Update the App Page

7. Let’s Test it Out

8. How to Improve the Message feedback using React 19’s useActionState Hook

   • Set up a toaster

   • Enhance the Form with the useActionState Hook

   • How to Update the Server Action to Return Results

9. Let’s Test it One More Time

10. Source Code and Resources

What is a Webhook?

Assume we have an email service that connects to a third-party email sender to send emails to users. Traditionally, there will be an API gateway to talk to the email service from the client devices. When the request is received, the email service will contact the email-sending provider.

While the email-sending provider processes the emails, the email service needs to know their status. One generic way to handle this is for the email service to poll for the status at a short frequency and update the client as and when the status changes. But this method has many drawbacks, such as resource mis-utilization, unnecessary connections, and poor performance.

On the contrary, how about the email service registers a callback URL that the email sender can call with relevant information when the email-sending action has been completed? This way, there is no unnecessary polling. Rather, the email sender can proactively inform the email service of a success or a failure after attempting to send the email. Then, the email service can respond to the clients regarding their status accordingly.

This registered callback is called a Webhook. Webhooks are widely used today in various industries like payments and checkout, system health monitoring, and third-party app integrations.

How to Configure a Webhook on Discord

You should now have an idea of how webhooks work, so let’s configure one with Discord.

Create or select a text channel on your Discord server. Click on the Edit Channel button.

Then, from the left-side navigation menu, select the Integration option. You should see the Webhooks option listed there.

Click on the Webhooks option and then click on the New Webhook button.

Give your webhook a name, and you can optionally upload a photo. This can be helpful when you have multiple webhooks and you want to quickly identify them by their photo and name.

Now, click on the Copy Webhook URL button to copy the webhook URL. Keep it safe somewhere, as we will be using it shortly in our application.

That’s it. Now let’s create a Next.js 15 application so we can integrate the webhook with it.

How to Create a Next.js Project

Open the terminal and use the following command to create a Next.js application:

npx create-next-app@latest

You’ll have to provide a few inputs for the initial project to create it. I will be using JavaScript (as opposed to TypeScript), Tailwind CSS, App Router, and Turbopack for this project. So I’ve opted for those choices by providing Yes as the response.

With that, you’ve created a Next.js project you can use for the rest of the tutorial.

How to Set Environment Variables

Create a .env file at the root of your project. We will now create an environment variable secret with the webhook URL you had copied before. Create an entry in the .env file like this:

DISCORD_WEBHOOK_URL=<YOUR_DISCORD_WEBHOOK_URL>

Make sure you replace the <YOUR_DISCORD_WEBHOOK_URL> with your actual webhook URL in the .env file. Remember, you must not commit and push this file to your version control. So, make sure that the .env file has been added to the .gitignore file of the project.

How to Integrate the Webhook with the Next.js Form component

Now, we will create the user interface to capture inputs from the user and send those to the Discord text channel using the webhook.

Let’s create a simple message form using the <Form /> component from Next.js. The <Form/> component is an extension of HTML’s native form with more flexibilities and features introduced by the release of Next.js 15. I would suggest that you go over this project-based video tutorial if you are interested in learning more about this new addition to Next.js.

Our strategy here is very straightforward:

• We will create a form and add an action to it using the form’s action prop.

• We will then create a Server Action using the webhook URL to communicate with Discord.

• The action will be invoked when the user fills up the form and submits it. Thus the webhook communication will be done.

Let’s write the code for these functionalities now.

Create the Form

Create a folder called _components under the app/ directory. Now, create a file message-form.jsx under the app/_components/ folder with the following code:

import Form from "next/form";
import { sendDiscordMessage } from "../actions";

const MessageForm = () => {
  return (
    <Form className="flex flex-col items-center" action={sendDiscordMessage}>
      <input
        type="text"
        placeholder="Your name"
        name="username"
        className="border p-1 rounded w-[300px] my-2"
        required
      />

      <input
        type="email"
        placeholder="Your e-mail"
        name="email"
        className="border p-1 rounded w-[300px] my-2"
        required
      />

      <input
        type="text"
        placeholder="Your Image Url"
        name="dp"
        className="border p-1 rounded w-[300px] my-2"
      />

      <select
        name="type"
        className="p-1 rounded border my-2 w-[300px]"
        required
      >
        <option value="">Message Type</option>
        <option value="thanks">Say, Thanks!</option>
        <option value="qa">QA</option>
        <option value="general">General</option>
      </select>

      <textarea
        placeholder="What do you want to say?"
        name="message"
        className="border p-1 rounded w-[300px] my-2"
        required
      />

      <button
        type="submit"
        className="bg-blue-500 w-[70px] text-white rounded-md"
      >
        Send
      </button>
    </Form>
  );
};

export default MessageForm;

Here, we have created a basic form with five fields for users to enter their name, email, profile image URL, message type (general, thanks, qa), and the message. There is a send button as well to submit the form.

We have used the Form component from the next/form package. The Form component allows us to execute a function on the server (server action) with the help of its action attribute. As you can see in the code above, we have imported a server action sendDiscordMessage and used that as the value for the action attribute of the form.

 <Form className="flex flex-col items-center" action={sendDiscordMessage}>

Now, let’s create the server action so that we can submit the form with it.

Create the Server Action

We’ll use a server action to send messages to Discord using webhooks. Create a folder called actions under the app/ directory. It’s a convention to keep all the actions colocated under the actions/ directory. Now, create a file called index.js under the app/actions/ directory with the following code:

"use server";

export const sendDiscordMessage = async (formData) => {
  try {
    const rawFormEntries = Object.fromEntries(formData);

    console.log(rawFormEntries);

    await fetch(process.env.DISCORD_WEBHOOK_URL, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        username: rawFormEntries?.username,
        avatar_url: rawFormEntries?.dp || "https://i.imgur.com/mDKlggm.png",
        content: rawFormEntries?.message,
        embeds: [
          {
            fields: [
              {
                name: "Email",
                value: rawFormEntries?.email,
                inline: true,
              },
              {
                name: "Message Type",
                value: rawFormEntries?.type,
                inline: true,
              },
            ],
          },
        ],
      }),
    })
  } catch (err) {
    console.log(err.message);
  }
};

Let’s understand what’s going on in the above code:

• In Next.js (or with React 19), a server function (aka server action) needs a special directive called ”use server” at the top of the file. So we have declared that.

• A server action is an async function that gets the formData as a parameter. The formData will contain the values of all the form fields submitted by the user. We can use the Object.formEntries() API to get a key-value pair from the formData. Check this out to learn the best way to handle formData in JavaScript.

• Next, we used the Discord webhook URL to make a POST call with the required payload to create the message.

• Let’s understand the payload format well. We need to follow a specific payload structure for the discord webhook to create the message. It follows a schema to have the following:

  • username: the name of the message sender. It appears at the top of the message. We’re reading the name field from the submitted data and populating the username field.

  • avatar_url: the profile photo of the message sender. We have a dp field in the form to capture the profile photo URL. We’re using that, and in case the user does not provide it, we’re using a default image as the profile photo.

  • content: The content field is the actual message content. We are reading the value of the message field and populating the value.

  • embeds: In the Discord message, you can use embeds. These embeds could be text messages, images, or videos. We will utilize the embeds to show the email and message type information. The embeds is an array of fields. In each of the fields, we have passed the email and message type values as the inline values. Inline values will appear in line, side by side.

How to Update the App Page

Finally, let’s update the application’s page with our form component so that everything gets stitched together. Open the page.js file under the app/ directory and paste in the following code:

import MessageForm from "./_components/message-form";

export default function Home() {
    return (
        <div className="flex flex-col justify-center items-center">
          <h1 className="text-3xl my-3">Send a message to tapaScript</h1>
          <MessageForm />
        </div>
      ) 
}

Here we have integrated the form with the app page so that we can access it on the browser.

Let’s Test it Out

Now you can run the app with the command yarn dev from your terminal. The app will be available on localhost:3000 by default. Open a browser tab and hit the URL http://localhost:3000. You should see a form like the one below. Fill it out with values and hit the Send button.

Go to the text channel of your Discord server and check for a message that should appear there momentarily. Check that the fields of the message match the input values you provided in the form.

TADA! We have done it. But hold on – we can make it even better. Did you notice that we aren’t showing any kind of feedback saying the “Message has been sent successfully”, or “There are issues in sending the message”? We’re not taking care of providing the result of the server action to the form component. Let’s fix that.

How to Improve the Message Feedback using React 19’s useActionState Hook

React 19 introduced a hook called useActionState that helps you update the state based on the result of a server action. Let’s use this hook to enhance the message form and the server action so that when the action gets executed successfully (or fails), we can notify the form component to change its state and show the success/error messages accordingly.

Set up a toaster

We will use a toast message to show the success/error messages. Let’s use the toast library called sonner. First, install it with this command:

yarn add sonner

Now, we have to add the Toaster from sonner to our app. The best place to add it is at the root level Layout of the application. Open the layout.js file and import the Toaster:

import { Toaster } from 'sonner';

Then, use the Toaster in the JSX of the layout:

 <html lang="en">
      <body
        className={`${geistSans.variable} ${geistMono.variable} antialiased`}
      >
        {children}
        <Toaster richColors />
      </body>
 </html>

That’s it. The toaster set-up is done. Now we will be able to use it in our components to show the toast messages.

Enhance the Form with the useActionState Hook

First, import the useActionState and useEffect hooks into the message-form.jsx file. Also, import the toast from sonner. As we will be using the hooks now, we have to make the message-form component a client component. So, add the ”use client” directive at the top of the file.

"use client";

import Form from "next/form";
import { useActionState } from "react";
import { sendDiscordMessage } from "../actions";
import { useEffect } from "react"
import { toast } from "sonner";

Next, use the useActionState hook to get the formState updated from the server action result. An isPending state tells us if the form submission has been completed. The useActionState returns a new formAction from the existing server action instance.

The syntax goes like this:

const [formState, formAction, isPending] = useActionState(sendDiscordMessage,null);

Now, we need to use this formAction as the value of the action attribute of the <Form /> component:

<Form className="flex flex-col items-center" action={formAction}>

Next, use the useEffect hook to track the formState changes and show the toast message accordingly. The shape of the formState can be customized based on our needs. We will see shortly how the server action can return this state value.

  useEffect (() => {
    if (formState?.success) {
      toast.success(formState?.message);
    } else if (formState?.success === false) {
      toast.error(formState?.message);
    }
  },[formState?.success])

The last thing here is to improve the UX of the form using the isPending state we got from the useActionState hook. The value of the isPending state will be true if the form is still in transition and being submitted. It will be changed to false when the form is submitted. So we can use the state value to customize the submit button text.

<button
  type="submit"
  className="bg-blue-500 w-[70px] text-white rounded-md">
    {isPending ? "Sending..." : "Send"}
</button>

Those are all the changes we need to make in the form component. Here’s the complete code of the modified form component for you to check out and use:

"use client";

import Form from "next/form";
import { useActionState } from "react";
import { sendDiscordMessage } from "../actions";
import { useEffect } from "react"
import { toast } from "sonner";

const MessageForm = () => {
  const [formState, formAction, isPending] = useActionState(
    sendDiscordMessage,
    null
  );

  useEffect (() => {
    if (formState?.success) {
      toast.success(formState?.message);
    } else if (formState?.success === false) {
      toast.error(formState?.message);
    }
  },[formState?.success])



  return (
    <Form className="flex flex-col items-center" action={formAction}>
      <input
        type="text"
        placeholder="Your name"
        name="username"
        className="border p-1 rounded w-[300px] my-2"
        required
      />

      <input
        type="email"
        placeholder="Your e-mail"
        name="email"
        className="border p-1 rounded w-[300px] my-2"
        required
      />

      <input
        type="text"
        placeholder="Your Image Url"
        name="dp"
        className="border p-1 rounded w-[300px] my-2"
      />

      <select
        name="type"
        className="p-1 rounded border my-2 w-[300px]"
        required
      >
        <option value="">Message Type</option>
        <option value="thanks">Say, Thanks!</option>
        <option value="qa">QA</option>
        <option value="general">General</option>
      </select>

      <textarea
        placeholder="What do you want to say?"
        name="message"
        className="border p-1 rounded w-[300px] my-2"
        required
      />

      <button
        type="submit"
        className="bg-blue-500 w-[70px] text-white rounded-md"
      >
        {isPending ? "Sending..." : "Send"}
      </button>
    </Form>
  );
};

export default MessageForm;

How to Update the Server Action to Return Results

The changes in the server action should be as follows:

1. When you use the useActionState hook, pass a returned formAction to the form. We have seen this before. It helps in multiple ways, and one of them is getting the previous state value of the formState inside the server action. You must be mindful to pass it as the first argument to the server function, and then the formData.

2. We can now return the result of the server action so that the formState gets updated with the result. We will create a result structure with a boolean success field indicating if it is a success or error scenario and a message field with the actual message.

Here’s the changed code with the above two updates:

"use server";

export const sendDiscordMessage = async (prevState, formData) => {
  try {
    const rawFormEntries = Object.fromEntries(formData);

    console.log(rawFormEntries);

    await fetch(process.env.DISCORD_WEBHOOK_URL, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify({
        username: rawFormEntries?.username,
        avatar_url: rawFormEntries?.dp || "https://i.imgur.com/mDKlggm.png",
        content: rawFormEntries?.message,
        embeds: [
          {
            fields: [
              {
                name: "Email",
                value: rawFormEntries?.email,
                inline: true,
              },
              {
                name: "Message Type",
                value: rawFormEntries?.type,
                inline: true,
              },
            ],
          },
        ],
      }),
    });

    return {
      success: true,
      message: `Your message has been sent successfully.`,
    };
  } catch (err) {
    console.log(err.message);
    return {
      success: false,
      message: `Problem is sending message ${err.message}`,
    };
  }
};

As you must have noticed, the returned result is the formState we have used inside the form component to show the toast messages.

Let’s Test it One More Time

Let’s test things out with all the changes.

1. First, fill out the form with the details. Now we’re using a profile picture URL rather than keeping it empty. Click on the Send button.

2. You should see the that button text gets changed to Sending… while the form is being submitted.

3. After the submission, you should get the success message in the toast. Also, the form state should be restored to its original state.

4. On the Discord text channel, you should see the message posted successfully.

That’s amazing! We have now made the app much better with the message and error handling.

Source Code and Resources

All the source code used in this article is in the GitHub repository. You can take a look, follow the README to set it up, and run it locally.

• The next-js-discord GitHub repository

Here are the resources I mentioned in the article that you may find helpful:

• Next.js 15 Form Component - All That You Need To Know

• Next.js Server Actions || Learn Patterns & Project Building

• MASTER React 19 useActionState Hook with Project & Usecases

• The useActionState official doc

Also, you can connect with me by:

• Subscribing to my YouTube Channel. If you are willing to learn React and its ecosystem, like Next.js, with both fundamental concepts and projects, I have great news for you: you can check out this playlist on my YouTube channel with 30+ video tutorials and 20+ hours of engaging content so far, for free. I hope you like them as well.

• Following me on X (Twitter) or LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Checking out and following my Open Source work on GitHub.

• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and keep learning.

Next.js provides us with Server Actions which are asynchronous functions that execute on the server. We can use server actions for data mutations on the server, but server actions can be invoked from both server and client components.

Server actions are a great way to handle form submissions by executing the action when the form data gets submitted. In this article, we will look into a practical use case of handling additional arguments in Next.js server actions.

If you are interested in learning Next.js Server Actions with design patterns and project building, I have created a crash course for you that you can find here.

Also, this article is also available as a video tutorial here:

Table of Contents

1. Why Would You Need to Pass Additional Arguments?

2. A Form with a Server Action

3. How to Pass Additional Arguments

4. What About the Hidden Fields?

5. Resources

Why Would You Need to Pass Additional Arguments?

When we execute a server action on a form submission, the server action gets the form data automatically. For example, take a look at the form below:

<form className="p-4 flex" action={updateUser}>
  <Input className="w-1/2 mx-2" type="text" name="name" />
  <Button type="submit">Update User Name</Button>
</form>

Here, we are executing a server action called updateUser when the form gets submitted. The updateUser function will receive the submitted form data as an argument which can be used to extract the form field values.

As you see in the code snippet below, the updateUser function gets a formData as an argument, and we can extract the value of the name field from it.

"use server"

export async function updateUser(formData) {
  const name = formData.get('name');
  console.log(name);
}

While this pattern covers most of the basic use cases, you may need to pass additional arguments programmatically to the server actions. These arguments are not part of the form or form data or user input data. They may be programmatically passed values to your server action.

To understand this, check the server action code snippet below. It’s the same server action we have seen before, but we have passed an additional userId argument along with the regular formData argument.

"use server"

export async function updateUser(userId, formData) {
  const name = formData.get('name');
  console.log(userId);
  console.log(name);
}

The userId value is something internal to the application – and you wouldn’t ask a user to submit the value as part of the form submission. Rather, you may need to pass it programmatically to your server action to perform further computations.

Right, that’s the use case we’re talking about. As we understand why we need it, let’s understand how to achieve it. But first, let’s create a form and a working server action for it.

A Form With a Server Action

Create a directory called actions under the app directory of your Next.js application. Now create a user.js file under the actions folder with the following code:

"use server"

export async function updateUser(formData) {
  const name = formData.get('name');
  console.log(name);

  // Do anything with the name, save in DB, create invoice, whatever!
}

This is how you create a server function in Next.js. It must have a ”use server” directive at the top of the file to tell Next.js that this is a special file with one or more asynchronous functions to execute on the server.

Then we have the server action (the async function) updateUser with formData as the argument. Inside the function definition, we extract out the name value and print it on the console.

Let’s now attach this server action to a form. To do that, create a folder called components under the project root folder. Create a file called user-form.jsx with the following code:

import { Input } from "./ui/input"
import { Button } from "./ui/button"

import { updateUser } from "@/app/actions/user"

const UserForm = () => {
  return(
    <form className="p-4 flex" action={updateUser}>
      <Input className="w-1/2 mx-2" type="text" name="name" />
      <Button type="submit">Update User Name</Button>
    </form>
  )
}

export default UserForm;

This is a simple React component with a form. The form has one input text field called name and a submit button to submit the form. The form has an action attribute with the server action updateUser as the value. Now, when the form gets submitted with a name value, the server action will get it as part of the form data as we discussed above.

Let’s test it out. To do that, we’ll create a Next.js route and page where we can use the UserForm component. Create a folder called extra-args under the app directory. Now, create a file called page.js under the app/extra-args directory with the following code:

import UserForm from "@/components/user-form";

const ExtraArgsDemo = () => {
  return (
    <UserForm />
  )
}

export default ExtraArgsDemo;

This is a simple React component where we have imported the UserForm component and used it in the JSX. Now run the local server and access this route localhost:3000/extra-args. You should see the form with a text field and a button.

Type some text inside the text field and click on the button.

Now, you will be able to see that the typed text has been printed on the server console. Why on the server console? Why not on the browser console? This is because server actions execute on the server, not on the client side browser.

So, with this we have now established a data flow like this:

Page => Form => Server Action

The page has a form. The form execute a server action on submission. The server action prints a form data on the server console.

Let’s now enhance these pieces to pass additional arguments to the server action.

How to Pass Additional Arguments

Let’s pass a prop to the UserForm component from the page. We’ll pass a userId with a value to pretend that we are passing this userId programmatically to our form and to the server action from there.

import UserForm from "@/components/user-form";

const ExtraArgsDemo = () => {
  return (
    <UserForm userId={"1234"} />
  )
}

export default ExtraArgsDemo;

In the UserForm component, we accept the userId prop. Now, we have to do something special to pass this userId to the updateUser server action.

JavaScript has a magical method called bind() that helps us create a Partially Applied Function. With this partially applied function, you can create a function from another function’s preset arguments.

In our case, the updateUser function already has an argument called formData. Now we can pass userId as the additional argument using the bind() method to create a new function.

const updatedUserWithId = updateUser.bind(null, userId);

The first argument of the bind() method is the context you are binding the function to. The context handles the association of the function with the this keyword value. In our case, we can keep it null as we are not changing it. After that, we passed the new argument userId. It’s good to know that the bind() method works on both server and client components.

Here is the modified UserForm component (user-form.jsx file). Note that the form action value is now modified to the new function updatedUserWithId.

import { Input } from "./ui/input"
import { Button } from "./ui/button"

import { updateUser } from "@/app/actions/user"

const UserForm = ({userId}) => {
  const updatedUserWithId = updateUser.bind(null, userId);

  return(
    <form className="p-4 flex" action={updatedUserWithId}>
      <Input className="w-1/2 mx-2" type="text" name="name" />
      <Button type="submit">Update User Name</Button>
    </form>
  )
}

export default UserForm;

Now, the server action will receive the userId value as an argument. Let’s print that to the console as well.

"use server"

export async function updateUser(userId, formData) {
  const name = formData.get('name');
  console.log(userId);
  console.log(name);

  // Do anything with the user id and name, save in DB, 
  // create invoice, whatever!
}

Now if you submit the form with a name value:

You’ll see that both userId and the name values are logged into the server console. Great! We have logged one value from the form data, and the other one was passed internally to the server action.

So, we learned how to pass the extra arguments to the server action along with the form data.

What About the Hidden Fields?

HTML supports a hidden type form field to pass client data to the server without accepting the input from the users. So this means that we could have used the hidden field to pass the userId value like this:

So why did we do all that with the bind() method? Well, because of security concerns. When you pass data using hidden fields, the value will be part of the rendered HTML, and it will not be encoded as well. So it’s better to handle it programmatically.

Resources

That's all for now. Did you enjoy reading this article and have you learned something new? If so, I would love to know if the content was helpful. Let me share a few additional resources you may need:

• All the Source Code used in this article is on my GitHub.

• Here’s the Server Action Crash Course with Patterns and Project.

• Here’s the Server Action Official Documentation if you want to read more.

• And you can read more about the bind() method here.

Additionally, you can connect with me by:

• Subscribing to my YouTube Channel. If you are willing to learn React and its ecosystem, like Next.js, with both fundamental concepts and projects, I have great news for you: you can check out this playlist on my YouTube channel with 25+ video tutorials and 15+ hours of engaging content so far, for free. I hope you like them as well.

• Following me on X (Twitter) or LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Checking out and follow my Open Source work on GitHub.

• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and keep learning.

React is a user interface library that has been doing its job quite well for over a decade. The component architecture, uni-directional data flow, and declarative nature stand out in helping devs building production-ready, scalable software applications.

Over the releases (even up until the latest stable release of v18.x), React has provided various techniques and methodologies to improve application performance.

For example, the entire memoization paradigm has been supported using the React.memo() higher-order component, or with hooks like useMemo() and useCallback().

In programming, memoization is an optimization technique that makes your programs execute faster by caching the result of expensive computations.

Although React's memoization techniques are great for applying optimizations, as Uncle Ben (remember, Spiderman's uncle?) once said, "With great power comes great responsibility". So we as developers need to be a little more responsible in applying them. Optimization is great, but over-optimization can be a killer for the application's performance.

With React 19, the developer community has received a list of enhancements and features to boast about:

• An experimental open-source compiler. We will be focusing primarily on it in this article.

• React Server Components.

• Server Actions.

• Easier and more organic way of handling the document metadata.

• Enhanced hooks and APIs.

• ref can be passed as props.

• Improvements in asset loading for styles, images, and fonts.

• A much smoother integration with Web Components.

If these are exciting to you, I recommend watching this video that explains how each feature will impact you as a React developer. I hope you like it 😊.

The introduction of a compiler with React 19 is set to be a game-changer. From now on, we can let the compiler handle the optimization headache rather than keeping it on us.

Does this mean we do not have to use memo, useMemo(), useCallback, and so on anymore? No – we mostly don't. The compiler can take care of these things automatically if you understand and follow the Rules of React for components and hooks.

How will it do this? Well, we'll get to it. But before that, let's understand what a compiler is and whether it's justified to call this new optimizer for React code the React Compiler.

If you like to learn from video tutorials as well, this article is also available as a video tutorial here:

Table of Contents

1. What is a Compiler, traditionally?

2. React Compiler Architecture

3. React Compiler in action

4. Understanding the problem: Without the React Compiler

5. Fixing the problem: Without the React Compiler

6. Fixing the problem: Using the React Compiler

7. Optimized React App with React Compiler

8. React Compiler in React DevTools

9. Diving deep - How does the React Compiler work?

10. How do you opt in and out of the React compiler?

11. Can we use the React Compiler with React 18.x?

12. Repositories to look into

13. What's Next?

What is a Compiler, Traditionally?

Simply put, a compiler is a software program/tool that translates high-level programming language code (source code) into machine code. There are several steps to follow to compile source code and generate machine code:

• The lexical analyzer tokenizes the source code and generates tokens.

• The Syntax Analyzer creates an abstract syntax tree (AST) to structure the source code tokens logically.

• The Semantic Analyzer validates the semantic (or syntactic) correctness of the code.

• After all three types of analysis by the respective analyzers, some intermediate code gets generated. It is also known as the IR code.

• Then optimization is performed on the IR code.

• Finally, the machine code is generated by the compiler from the optimized IR code.

Now that you understand the basics of how a compiler works, let's learn about the React Compiler and understand how it works.

React Compiler Architecture

React compiler is a build-time tool that you need to configure with your React 19 project explicitly using the configuration options provided by the React tools ecosystem.

For example, if you are using Vite to create your React application, the compiler configuration will take place in the vite.config.js file.

React compiler has three primary components:

1. Babel Plugin: helps transform the code during the compilation process.

2. ESLint Plugin: helps catch and report any violations of the Rules of React.

3. Compiler Core: the core compiler logic that performs the code analysis and optimizations. Both Babel and ESLint plugins use the core compiler logic.

The compilation flow goes like this:

• The Babel Plugin identifies which functions (components or hooks) to compile. We will see some configurations later to learn how to opt in and out of the compilation process. The plugin calls the core compiler logic for each of the functions and finally creates the Abstract Syntax Tree.

• Then the compiler core converts the Babel AST into IR code, analyzes it, and runs various validations to ensure none of the rules are broken.

• Next, it tries to reduce the amount of code to be optimized by performing various passes to eliminate dead code. The code gets further optimized using memoization.

• Finally, in the code generation stage, the transformed AST is converted back to the optimized JavaScript code.

React Compiler in Action

Now that you know how React Compiler works, let's now dive into configuring it with a React 19 project so you can start learning about the various optimizations.

Understanding the problem: Without the React Compiler

Let's create a simple product page with React. The product page shows a heading with the number of products on the page, a list of products, and the featured products.

The component hierarchy and the data passing between the components look like this:

As you can see in the image above,

• The ProductPage component has three child components, Heading, ProductList, and FeaturedProducts.

• The ProductPage component receives two props, products and the heading.

• The ProductPage component computes the total number of products and passes the value along with the heading text value to the Heading component.

• The ProductPage component passes down the products prop to the ProductList child component.

• Similarly, it computes the featured products and passes the featuredProducts prop to the FeaturedProducts child component.

Here is how the source code of the ProductPage component may look:

import React from 'react'

import Heading from './Heading';
import FeaturedProducts from './FeaturedProducts';
import ProductList from './ProductList';

const ProductPage = ({products, heading}) => {
  const featuredProducts = products.filter(product => product.featured);
  const totalProducts = products.length;

  return (
    <div className="m-2">
      <Heading
        heading={heading}
        totalProducts={totalProducts} />

      <ProductList
        products={products} />

      <FeaturedProducts
        featuredProducts={featuredProducts} />  

    </div>
  )
}

export default ProductPage

Also, assume we use the ProductPage component in the App.js file like this:

import ProductPage from "./components/compiler/ProductPage";

function App() {

  // A list of food products    
  const foodProducts = [
    {
      "id": "001",
      "name": "Hamburger",
      "image": "🍔",
      "featured": true
    },
    {
      "id": "002",
      "name": "French Fries",
      "image": "🍟",
      "featured": false
    },
    {
      "id": "003",
      "name": "Taco",
      "image": "🌮",
      "featured": false
    },
    {
      "id": "004",
      "name": "Hot Dog",
      "image": "🌭",
      "featured": true
    }
  ];

  return (
      <ProductPage 
            products={foodProducts} 
            heading="The Food Product" />
  );
}

export default App;

That's all good – so where is the problem? The problem is that React proactively re-renders the child component when the parent component re-renders. An unnecessary rendering requires optimizations. Let's understand the problem fully first.

We'll add the current timestamp in each of the child components. Now the rendered user interface will look like this:

The big number you see beside the headings is the timestamp (using the simple Date.now() function from the JavaScript Date API) we have added to the component code. Now what happens if we change the value of the heading prop of the ProductPage component?

Before:

<ProductPage 
   products={foodProducts} 
   heading="The Food Product" />

And after (notice that we have made it plural for products by adding an s at the end of the heading value):

<ProductPage 
   products={foodProducts} 
   heading="The Food Products" />

Now you will notice an immediate change in the user interface. All three timestamps got updated. This is because all three components were re-rendered when the parent component was re-rendered due to the props change.

If you notice, the heading prop was passed only to the Heading component, and even then the other two child components re-rendered. This is where we need the optimizations.

Fixing the Problem: Without the React Compiler

As discussed before, React provides us with various hooks and APIs for memoization. We can use React.memo() or useMemo() to safeguard the components that are re-rendering unnecessarily.

For example, we can use React.memo() to memoize the ProductList component to ensure that unless the products prop is changed, the ProductList component will not be re-rendered.

We can use the useMemo() hook to memoize the computation for the featured products. Both implementations are indicated in the image below.

But again, recollecting the wise words of great Uncle Ben, over the last few years we have started over-using these optimization techniques. These over-optimizations can negatively impact the performance of your applications. So, the availability of the compiler is a boon for React developers as it lets them delegate many such optimizations to the compiler.

Let's now fix the problem using the React compiler.

Fixing the problem: Using the React Compiler

Again, React compiler is an opt-in build-time tool. It doesn't come bundled with React 19 RC. You need to install the required dependencies and configure the compiler with your React 19 project.

Before configuring the compiler, you can check if your codebase is compatible by executing this command on your project directory:

npx react-compiler-healthcheck@experimental

It will check and report:

• How many components can be optimized by the compiler

• If the Rules of React are followed.

• If there are any incompatible libraries.

If you find that things are compatible, it's time to install the ESLint plugin powered by the React compiler. This plugin will help you catch any violation of the rules of React in your code. Violating code will be skipped by the React compiler and no optimizations will be performed on it.

npm install eslint-plugin-react-compiler@experimental

Then open the ESLint configuration file (for example, .eslintrc.cjs for Vite) and add these configurations:

module.exports = {
  plugins: [
    'eslint-plugin-react-compiler',
  ],
  rules: {
    'react-compiler/react-compiler': "error",
  },
}

Next, you'll use the Babel plugin for the React compiler to enable the compiler for your entire project. If you're starting a new project with React 19, I recommend that you enable the React compiler for the entire project. Let's install the Babel plugin for the React compiler:

npm install babel-plugin-react-compiler@experimental

Once installed, you need to complete the configuration by adding the options in the Babel config file. As we're using Vite, open the vite.config.js file and replace the content with the following code snippet:

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

const ReactCompilerConfig = {/* ... */ };

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react({
    babel: {
      plugins: [
        [
          "babel-plugin-react-compiler",
           ReactCompilerConfig
          ]
        ],
    },
  })],
})

Here, you've added the babel-plugin-react-compiler to the configuration. The ReactCompilerConfig is required to provide any advanced configuration like if you want to provide any custom runtime module or any other configurations. In this case, it's an empty object without any advanced configurations.

That's it. You are done configuring the React compiler with your code base to utilize its power. From now on, the React compiler will look into every component and hook in your project to try and apply optimizations to it.

If you want to configure the React compiler with Next.js, Remix, Webpack, and so on, you can follow this guide.

Optimized React App with React Compiler

Now you should have an optimized React app with the inclusion of the React compiler. So, let's run the same tests you did before. Again, change the value of the heading prop of the ProductPage component.

This time, you will not see the child components re-rendering. So the timestamp will not be updated either. But you will see the portion of the component where the data changed, as it will reflect the changes alone. Also, you won't have to use memo, useMemo(), or useCallback() in your code anymore.

You can see it working visually from here.

React Compiler in React DevTools

React DevTools version 5.0+ has built-in support for the React compiler. You will see a badge with the text Memo ✨ beside the components optimized by the React compiler. This is fantastic!

Diving Deep – How Does the React Compiler Work?

Now that you've seen how the React compiler works on React 19 code, let's deep dive into understanding what's happening in the background. We will use the React Compiler Playground to explore the translated code and the optimization steps.

We'll use the Heading component as an example. Copy and paste the following code inside the leftmost section of the playground:

const Heading = ({ heading, totalProducts }) => {
  return (
    <nav>
      <h1 className="text-2xl">
          {heading}({totalProducts}) - {Date.now()}
      </h1>
    </nav>
  )
}

You will see that some JavaScript code is generated immediately inside the _JS tab of the playground. The React compiler generates this JavaScript code as part of the compilation process. Let's go over it step-by-step:

function anonymous_0(t0) {
  const $ = _c(4);
  const { heading, totalProducts } = t0;
  let t1;
  if ($[0] === Symbol.for("react.memo_cache_sentinel")) {
    t1 = Date.now();
    $[0] = t1;
  } else {
    t1 = $[0];
  }
  let t2;
  if ($[1] !== heading || $[2] !== totalProducts) {
    t2 = (
      <nav>
        <h1 className="text-2xl">
          {heading}({totalProducts}) - {t1}
        </h1>
      </nav>
    );
    $[1] = heading;
    $[2] = totalProducts;
    $[3] = t2;
  } else {
    t2 = $[3];
  }
  return t2;
}

The compiler uses a hook called _c() to create an array of items to cache. In the code above, an array of four elements has been created to cache four items.

const $ = _c(4);

But, what are the things to cache?

• The component takes two props, heading and totalProducts. The compiler needs to cache them. So, it needs two elements in the array of cacheable items.

• The Date.now() part in the header should be cached.

• The JSX itself should be cached. There is no point in computing JSX unless either of the above changes.

So there are a total of four items to cache.

The compiler creates memoization blocks using the if-block. The final return value from the compiler is the JSX which depends on three dependencies:

• The Date.now() value.

• Two props, a heading and totalProducts

The output JSX needs re-computation when any of the above changes. This means that the compiler needs to create two memoization blocks for each of the above.

The first memoization block looks like this:

if ($[0] === Symbol.for("react.memo_cache_sentinel")) {
    t1 = Date.now();
    $[0] = t1;
} else {
    t1 = $[0];
}

The if-block stores the value of the Date.now() into the first index of the cacheable array. It re-uses the same every time unless it is changed.

Similarly, in the second memoization block:

if ($[1] !== heading || $[2] !== totalProducts) {
    t2 = (
      <nav>
        <h1 className="text-2xl">
          {heading}({totalProducts}) - {t1}
        </h1>
      </nav>
    );
    $[1] = heading;
    $[2] = totalProducts;
    $[3] = t2;
  } else {
    t2 = $[3];
  }

Here, the check is for the value changes for either heading or totalProducts props. If either of these changes, the JSX needs to be recomputed. All the values are then stored in the cacheable array. If there are no changes in the value, the previously computed JSX is returned from the cache.

You can now paste any other component source code into the left side and look into the generated JavaScript code to help you understand what's going on as we did above. This will help you to get a better grip on how the compiler performs the memoization techniques in the compilation process.

How Do You Opt in and Out of the React Compiler?

Once you've configured the React compiler the way we have done with our Vite project here, it's enabled for all the compilers and hooks of the project.

But in some cases, you may want to selectively opt-in for the React compiler. In that case, you can run the compiler in “opt-in” mode using the compilationMode: "annotation" option.

// Specify the option in the ReactCompilerConfig
const ReactCompilerConfig = {
  compilationMode: "annotation",
};

Then annotate the components and hooks you want to opt-in for compilation with the "use memo" directive.

// src/ProductPage.jsx
export default function ProductPage() {
  "use memo";
  // ...
}

Note that there is a "use no memo" directive as well. There might be some rare cases where your component may not be working as expected after compilation, and you want to opt out of the compilation temporarily until the issue is identified and fixed. In that case, you can use this directive:

function AComponent() {
  "use no memo";
  // ...
}

Can We Use the React Compiler with React 18.x?

It is recommended to use the React compiler with React 19 as there are required compatibilities. If you can't upgrade your application to React 19, you'll need to have a custom implementation of the cache function. You can go over this thread describing the workaround.

Repositories to Look Into

• All the source code used in this article is in this repository.

• If you want to start coding with React 19 and its features, here is a template repository configured with React 19 RC, Vite, and TailwindCSS. You may want to try it out.

What's Next?

To learn further,

• Check out the official documentation of React Compiler from here.

• Check out the discussions in the Working Group.

Up next, if you are willing to learn React and its ecosystem-like Next.js with both fundamental concepts and projects, I have great news for you: you can check out this playlist on my YouTube channel with 22+ video tutorials and 12+ hours of engaging content so far, for free. I hope you like them as well.

That's all for now. Did you enjoy reading this article and have you learned something new? If so, I would love to know if the content was helpful.

• Subscribe to my YouTube Channel.

• Follow me on X (Twitter) or LinkedIn if you don't want to miss the daily dose of up-skilling tips.

• Check out and follow my Open Source work on GitHub.

• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and keep learning.

An application that takes more than 3 seconds to load is considered slow and may cause users to leave the application or website.

Next.js is a React-based framework you can use to build scalable, performant, and faster web applications and websites. With the inclusion of React Server Components in the Next.js app router release, developers have a new mental model for "thinking in a server components" way. It solves the problem with SEO, helps create zero bundle size React components, and the end result is faster loading of UI components.

But your application may not be always about the server components. You may need to use client components as well. Also, you may want to load them either as part of the application's initial load or on demand (say at the click of a button).

Loading a client component on the browser includes downloading the component code into the browser, downloading all the libraries and other components you had imported into that client component, and a few additional things that React takes care of for you to make sure your components are working.

Based on the user's internet connection and other network factors, the entire loading of the client component may take a while, which may keep your users from using the application more quickly.

This is where Lazy Loading techniques can come in handy. They can help save you from a monolithic loading of your client components on the browser.

In this article, we will discuss a couple of lazy loading techniques in Next.js for client component loading optimization. We will also talk about a few edge cases you should know to handle.

If you like to learn from video content as well, this article is also available as a video tutorial here: 🙂

Before we get started, a couple of things for you:

• We will write a bunch of code to build an app to demonstrate the lazy loading techniques. You can find all the source code from this GitHub repository: https://github.com/tapascript/nextjs-lazy-load. But I strongly suggest that you write the code yourself as we proceed and use the repository only as a reference.
• You can also access the app deployed publicly on Netlify here.

Let's start 🚀. Oh yes, if you are Tom & Jerry cartoon lover, you are going to enjoy this even more!

Table of Contents

• What is Lazy Loading?
• Lazy Loading Techniques in Next.js
• Lazy Loading with dynamic import and next/dynamic
• Lazy Loading with React.lazy() and Suspense
• How to Lazy Load the Named Exported Components
• Lazy Loading Your Server Components
• Should We Lazy Load All Client Components in Next.js?
• What's Next?

What is Lazy Loading?

In modern day web application development, we don't code all the logic in one JavaScript/TypeScript file, or all the styles into one mammoth CSS file. Rather, we split them at the source code level and create logical modules, business logic, presentational components, and style related files. This helps us organize our code better.

Then we use something called a bundler which kicks in at the build phase of the application development process. It creates bundles for our scripts and styles. Some of the famous bundlers are Webpack, Rollup, and Parcel, among others.

Bundler creating bundles from the source code

Now, as we have the bundles, if we try to load them on the browser all together, we will encounter some slowness. This is because the complete bundle needs to be loaded into the browser for the user interface to be functional.

Loading a huge bundle results in a poor loading experience

So, instead of waiting for the huge bundle to get loaded into the browser, modern web development libraries and tooling systems allow us to load the bundle in chunks.

We may want to load some of the chunks immediately, as users may need them sooner as the application loads. At the same time, we may want to wait to load certain parts of a web page until they're needed.

Breaking into chunks and loading what is needed

This mechanism of waiting to load part of the pages or application, and loading them only when they are absolutely necessary, is called Lazy Loading. The concept of lazy loading is not React or Next.js-specific. It is a performance optimization technique that you can implement with various libraries and frameworks.

Lazy Loading Techniques in Next.js

Lazy loading techniques in Next.js is used to reduce the amount of JavaScript needed by a route. This helps the initial load performance of the application be faster. We can defer the load of the client components and imported libraries until they are needed.

There are two ways we can implement lazy loading techniques in Next.js:

• Using dynamic imports with the help of the next/dynamic package.
• Using a combination of React.lazy() and Suspense.

Let's understand each of these techniques with code examples.

Lazy Loading With dynamic import and next/dynamic

next/dynamic is a combination of React.lazy() and Suspense from ReactJS. Using a dynamic import with the next/dynamic package is a preferred approach to achieve lazy loading in Next.js.

To demonstrate it, let's first create a Next.js app using the following command:

npx create-next-app@latest

You can start the app locally using the following command:

## Using npm
npm run dev

## Using yarn
yarn dev

## Or use pnpm, bun, whatever you wish!

Now create a folder called components under the app/ directory. We will create all our components under the component folder. Now, create a folder called tom under the app/components/. Finally, create a React component called tom.jsx under the app/components/tom/ directory with the following code:

// tom.jsx

const LazyTom = () => {
  return (
    <div className="flex flex-col">
      <h1 className="text-3xl my-2">The Lazy Tom</h1>
      <p className="text-xl my-1">
        Tom, named &quot;Jasper&quot; in his debut appearance, is a gray and white
        domestic shorthair cat 🐈. &quot;Tom&quot; is a generic name for a male cat. He is
        usually but not always, portrayed as living a comfortable, or even
        pampered life. Tom is no match for Jerry&apos;s wits.
      </p>
      <p className="text-xl my-1">
        Although cats typically chase mice to eat them, it is quite rare for Tom
        to actually try to eat Jerry. He tries to hurt or compete with him just
        to taunt Jerry, even as revenge, or to obtain a reward from a human,
        including his owner(s)/master(s), for catching Jerry, or for generally
        doing his job well as a house cat. By the final &quot;fade-out&quot; of each
        cartoon, Jerry usually gets the best of Tom.
      </p>
    </div>
  );
};

export default LazyTom;

To explain the above code:

• We have created a ReactJS component called LazyTom.
• It is a simple presentational component which has a heading and a couple of paragraphs talking about the cat, Tom, from the famous Tom & Jerry cartoon.
• At the end, we have default exported the component to import it elsewhere.

Now, create another file called tom-story.jsx under the app/components/tom/ directory with the following code:

// tom-story.jsx

"use client";

import { useState } from "react";
import dynamic from "next/dynamic";

const LazyTom = dynamic(() => import("./tom"), {
    loading: () => <h1>Loading Tom&apos;s Story...</h1>,
});

function TomStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1">Demonstrating <strong>dynamic</strong></h2>
            <button
                className="bg-blue-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🐈 Tom&apos;s Story
            </button>

            {shown && <LazyTom />}
        </div>
    );
}

export default TomStory;

The main magic of lazy loading with dynamic is happening in the above code:

• We have created a client component called TomStory using the "use client" directive.
• First, we have imported the useState hook for managing a toggle state, and the dynamic function from the next/dynamic for the lazy loading of the component we created before.
• The dynamic function takes a function as an argument that returns the imported component. You can also configure a custom loading message by providing an optional configuration object as argument to the dynamic function.
• The dynamic() function returns the lazily loaded component instance – that is, LazyTom (could be any name). But this component is not loaded yet.
• In the JSX, we have a toggle button that shows and hides the LazyTom component. Note that the component will be lazy loaded into the user browser at the first instance of a button click. After that, if you hide and show it again, the LazyTom component will not be reloaded until we hard refresh the browser or clear the browser cache.
• Finally, we have default exported the TomStory component.

Now we need to test it out. To do that, open the page.js file in the app/ directory and replace the content with the following code:

import TomStory from "./components/tom/tom-story";

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
    </div>
  );
}

This is a simple ReactJS component that imports the TomStory component and uses it in its JSX. Now open your browser window. Open the browser's DevTools and open the Network tab. Make sure that the All filter is selected.

Now access the app on your browser using http://localhost:3000. You should see the button to load Tom's story. Also a bunch of resources will be listed on the Network tab. These are resources required in the initial load of the application and have been downloaded on your browser.

The LazyTom component from the tom.jsx has not been downloaded yet. This is because we haven't yet clicked on the Load Tom's Story button.

The button to lazy load Tom's story

Now, click on the button. You should see a loading message for a moment and then the component will be loaded with Tom's story. You can now see the tom.jsx component listed in the Network tab and also the component rendered on the page with the Tom's story.

Now Tom's story is lazily loaded

Now that you have experienced how the dynamic function from next/dynamic helps us load a component lazily, let's get started with the other technique using React.lazy() and Suspense.

Lazy Loading with React.lazy() and Suspense

To demonstrate this technique, let's start with Jerry's story, my favourite character from the Tom & Jerry cartoon.

First, we'll create a folder called jerry under the app/components/ directory. Now, create a file called jerry.jsx under the app/components/jerry/ with the following code:

// jerry.jsx

const LazyJerry = () => {
  return (
    <div className="flex flex-col justify-center">
      <h1 className="text-3xl my-2">The Lazy Jerry</h1>
      <p className="text-xl my-1">
        Jerry 🐀, whose name is not explicitly mentioned in his debut appearance,
        is a small, brown house mouse who always lives in close proximity to
        Tom. Despite being very energetic, determined and much larger, Tom is no
        match for Jerry&apos;s wits. Jerry possesses surprising strength for his
        size, approximately the equivalent of Tom&apos;s, lifting items such as
        anvils with relative ease and withstanding considerable impacts.
      </p>
      <p className="text-xl my-1">
        Although cats typically chase mice to eat them, it is quite rare for Tom
        to actually try to eat Jerry. He tries to hurt or compete with him just
        to taunt Jerry, even as revenge, or to obtain a reward from a human,
        including his owner(s)/master(s), for catching Jerry, or for generally
        doing his job well as a house cat. By the final &quot;fade-out&quot; of each
        cartoon, Jerry usually gets the best of Tom.
      </p>
    </div>
  );
};

export default LazyJerry;

The content of jerry.jsx is structurally similar to tom.jsx. Here we have posted Jerry's story, instead of Tom's, and default exported the component.

Like the last time, let's create a jerry-story.jsx file to showcase the lazy loading of Jerry's story. Create the file under the app/components/jerry/ directory with the following code:

// jerry-story.jsx

"use client";

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

const LazyJerry = React.lazy(() => import('./jerry'));

function JerryStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1"> Demonstrating <strong>React.lazy()</strong></h2>
            <button
                className="bg-pink-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🐀 Jerry&apos;s Story
            </button>

            {shown && <Suspense fallback={<h1>Loading Jerry&apos;s Story</h1>}>
                <LazyJerry />
            </Suspense>}
        </div>
    );
}

export default JerryStory;

Here also we have a client component, and we will be using the lazy() method and Suspense from React, so we have imported them. Like the dynamic() function in the last technique, the lazy() function also takes a function as an argument that retrurns the lazily imported component. We have also provided the relative path to the component that we are trying to load.

Note that with dynamic() we had an opportunity to customize the loading message as part of the function itself. With lazy(), we will be doing that as part of the Suspense fallback.

Suspense uses a fallback when you wait for the data to load. If you would like to understand the Suspense and Error Boundary from ReactJS in-depth, you can check out this video tutorial.

Here, as our LazyJerry component is loading lazily, we have provided a fallback to show a loading message until the component code is download into the browser successfully and rendered.

{shown && 
    <Suspense fallback={<h1>Loading Jerry&apos;s Story</h1>}>
                <LazyJerry />
    </Suspense>
}

Also, as you can see, we are loading the component on the first button click. Here also, the component will not be reloaded every time we click on the button unless we refresh the browser or clear the browser cache.

Let's now test it by importing it into the page.js file and adding the component in its JSX.

// page.js

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story"; 

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
    </div>
  );
}

Now, you'll see another component appear on the user interface with a button to load Jerry's story. At this stage, you will not see the jerry.jsx component loaded into the browser.

The button to lazy load Jerry's story

Now, click on the button. You will see that the component is loaded, and you can see it on the Network tab list. You should be able to read Jerry's story rendered as part of the lazily loaded component.

Jerry's story is lazily loaded

How to Lazy Load the Named Exported Components

So far, with both the techniques we have imported a component that was exported with the default export and then lazy loaded it. In JavaScript (and so in React), you can export and import modules in two different ways:

• With the default keyword. In this case, the exported module can be imported with any name. You would use this if you wanted to export only one functionality from a module.
• Without the default keyword, this is called a named export. In this case, you have to maintain the same module name for the export and import. You also need to enclose the module name in the curly brackets ({...}) while importing. You would use this if you wanted to export multiple functionalities from a module.

If you want to get into JavaScript modules and how they work in greater detail, I would suggest going through this crash course published on freeCodeCamp's YouTube channel.

To demonstrate the lazy loading of a named export component, let's create another simple presentational React component. This time we will use the angry but cute dog named Spike from the Tom & Jerry cartoon.

Create a folder called spike under the app/components/ directory. Now, create a file called spike.jsx under the app/components/spike/ directory with the following code:

// spike.jsx

export const LazySpike = () => {
  return (
    <div className="flex flex-col">
      <h1 className="text-3xl my-2">The Lazy Spike</h1>
      <p className="text-xl my-1">
        In his attempts to catch Jerry, Tom often has to deal with Spike 🦮, known
        as &quot;Killer&quot; and &quot;Butch&quot; in some shorts, an angry, vicious but easily
        duped bulldog who tries to attack Tom for bothering him or his son Tyke
        while trying to get Jerry. Originally, Spike was unnamed and mute, aside
        from howls and biting noises as well as attacking indiscriminately, not
        caring whether it was Tom or Jerry though usually attacking Tom.
      </p>
      <p className="text-xl my-1">
      In
        later cartoons, Spike spoke often, using a voice and expressions,
        performed by Billy Bletcher and later Daws Butler, modeled after
        comedian Jimmy Durante. Spike&apos;s coat has altered throughout the years
        between gray and creamy tan. The addition of Spike&apos;s son Tyke in the
        late 1940s led to both a slight softening of Spike&apos;s character and a
        short-lived spin-off theatrical series called Spike and Tyke.
      </p>
    </div>
  );
};

Again, this component is structurally exactly same as the tom.jsx and jerry.jsx components we have seen before, but with two major differences:

1. Here, we have exported the component without the default keyword, hence it is a named export.
2. We are talking about the dog, Spike.

Now, we need to handle the lazy loading of a named exported component and it's going to be a bit different from the default exported component.

Create a file called spike-story.jsx under the app/components/spike/ directory with the following code:

// spike-story.jsx

"use client";

import { useState } from "react";
import dynamic from "next/dynamic";

const LazySpike = dynamic(() => import("./spike").then((mod) => mod.LazySpike), {
    loading: () => <h1>Loading Spike&apos;s Story...</h1>,
});

function SpikeStory() {
    const [shown, setShown] = useState(false);

    return (
        <div className="flex flex-col m-8 w-[300px]">
            <h2 className="text-xl my-1">Demonstrating <strong>Named Export</strong></h2>
            <button
                className="bg-slate-600 text-white rounded p-1"
                onClick={() => setShown(!shown)}
            >
                Load 🦮 Spike&apos;s Story
            </button>

            {shown && <LazySpike />}
        </div>
    );
}

export default SpikeStory;

Like tom-story, we are using the dynamic import with the next/dynamic. But let's zoom into the following block from the above code:

const LazySpike = dynamic(() => import("./spike").then((mod) => mod.LazySpike), {
    loading: () => <h1>Loading Spike&apos;s Story...</h1>,
});

The changes you will notice here are that we are resolving the promise explicitly from the import("./spike") function using the the .then() handler function. We get the module first, and then pick the exported component by its actual name – that is LazySpike in this case. The rest of the things remain the same as before as in the tom-story.

Now to test it out, again import the component into the page.js file, and use it in the JSX like the last two times.

// page.js

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story";
import SpikeStory from "./components/spike/spike-story"; 

export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
      <SpikeStory />
    </div>
  );
}

There you go – you should see the new component rendered on the browser with a button to load Spike's story from the spike.jsx file which is not loaded yet.

The button to lazy load Spike's story

Clicking on the button will load the file into the browser and render the component to show you Spike's story.

Spike's story is lazily loaded

Below you can see all three components demonstrating three different techniques and uses cases side-by-side. You can test them together. The image below is showcasing lazy loading of two components in parallel where another component was already lazily loaded.

Lazily loading multiple components in parallel

Here is another case where all three components were lazy loaded, on demand with the respective button clicks.

All the stories lazy loaded

Lazy Loading Your Server Components

We spoke about the lazy loading techniques of client components. Can we use the same on server components as well? Well, you can but you don't have to, as server components are already code split and the loading aspect is already been taken care of by Next.js. You are not going to get any kind of error if you are trying to do so, but it would be unnecessary.

In case, you are dynamically importing a server component that has one or more client components as children, those client components will be lazy loaded. But there won't be any impact on the (parent) server component itself.

Here is an example of a server component that has two client components as children:

// server-comp.jsx

import ComponentA from "./a-client-comp";
import ComponentB from "./b-client-comp";

import React from 'react'

const AServerComp = () => {
  return (
    <div className="flex flex-col m-8 w-[300px]">
      <ComponentA />
      <ComponentB />
    </div>
  )
}

export default AServerComp

Now, we are dynamically importing the server component into the page.js file and using it in its JSX. The child client components of the dynamically imported server component will be lazy loaded, but not the server component itself.

// page.js

import dynamic from "next/dynamic";

import TomStory from "./components/tom/tom-story";
import JerryStory from "./components/jerry/jerry-story";
import SpikeStory from "./components/spike/spike-story";

const AServerComp = dynamic(() => import('./components/server-comps/server-comp'), {
  loading: () => <h1>Loading Through Server Component...</h1>,
})


export default function Home() {
  return (
    <div className="flex flex-wrap justify-center ">
      <TomStory />
      <JerryStory />
      <SpikeStory />

      <AServerComp />
    </div>
  );
}

Should We Lazy Load All Client Components in Next.js?

I had this question when I first started learning about lazy loading. Now that I have gained more experience with this technique, here is my perspective:

You don't have to lazy load all client components. Optimzation is great, but over optimization can have adverse effects. You need to identify where these optimizations are required.

• Do you have client components that are really bulky?
• Are you unnecessarily putting so many things into one component that you should break it down and refactor?
• Do you import heavy libraries into your client components?
• Have you opted for tree-shaking?
• Can you mark bulky client components per route and is it fine not to load some or all of them at the initial load of the page for that route?

As you see, these are a bunch of meaningful questions to ask before you step into optimizing things. Once you have answers, and decide you need lazy loading, then you can implement the techniques you learned from this article.

What's Next?

That's all for now. Did you enjoy reading this article and have you learned something new? If so, I would love to know if the content was helpful. I have my social handles provided below.

Up next, if you are willing to learn Next.js and its ecosystem like Next-Auth(V5) with both fundamental concepts and projects, I have a great news for you: you can check out this playlist on my YouTube channel with 20+ video tutorials and 11+ hours of engaging content so far, for free. I hope you like them as well.

Let's connect.

• Subscribe to my YouTube Channel.
• Follow me on X (Twitter) or LinkedIn if you don't want to miss the daily dose of up-skilling tips.
• Check out and follow my Open Source work on GitHub.
• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and keep learning.

I come from a Java background where writing code demands that you be type-aware. This means that if you are declaring a string, you would have to write its type as String explicitly, like this:

// Declaring a String in Java

String greeting = "Is TypeScript Worth Learning?"

After developing software products with Java for 8 long years, when I shifted to JavaScript, the developer inside me was thrilled – so much so that it felt like, "Oh man! I finally got a fresh breath of air”.

I didn't have to worry about types and declaring them beforehand. I seemed to be writing less code, and the world was suddenly a paradise of freedom for me to build, test, and ship.

Another enjoyable 4 years passed with JavaScript and I grew up to become a senior developer. Then I got my formal introduction to TypeScript.

So here is my opportunity to tell you what I think, and whether TypeScript is worth learning. I am going to share the experience I've earned over the years. If you agree/disagree/want to know more, my socials are mentioned at the bottom of this article. I would love to connect and discuss. Keep reading.

If you would also like to check out the video version of this article, here it is: 😊

Table of Contents

• What is TypeScript?
• Getting Started with TypeScript – The Challenges
• Learning More About TypeScript – The Benefits
• Baby Steps to Start Coding in TypeScript
• So What's The Verdict: Is TypeScript Worth It or Not?
• Before We End...

What is TypeScript?

TypeScript is JavaScript at its core with additional syntax for types. Traditionally, JavaScript is a loosely typed language. Its flexibility in allowing developers to use (or misuse) random type assignments may lead to unwanted bugs in their applications.

That's where TypeScript comes in handy as a strongly typed programming language. It helps safe-guard devs from breaking applications at runtime by helping with type checks at code compilation time. You can learn more about TypeScript and its Type Safety from the official TypeScript site.

TypeScript helps JavaScript developers catch errors early in their code editor. The experience of being aware of the possible errors as you code can help you and your team trust the final output the code will produce.

If you know JavaScript, you do not have to learn any additional programming fundamentals to code in TypeScript. You just need to be aware of its type system and related syntax to apply them on your JavaScript code.

Personally, TypeScript has changed the way I used to code and ship my products. But it was not a cake walk to get into the mindset of using TypeScript by sacrificing all the flexibility you get with JavaScript. I had my own challenges and ways to overcome them.

This article is for every developer who comes across those challenges when they start coding in TypeScript. And it's meant to help you with the mindset you'll need to appreciate TypeScript's strictness, and how to identify biased (and false) information related to TypeScript to make the right choice for your projects.

Remember, TypeScript is not for everyone or every occasion. But it'll be easier for you to make the choice if you are aware of its qualities, where it fits in, and where it doesn't. I hope you this article helps you start understanding TypeScript's benefits and limitations, and that you enjoy the process of selecting or rejecting TypeScript for your upcoming projects.

Getting Started with TypeScript – The Challenges

To be honest, starting with TypeScript was a shock for me, and it proved to be a bit of a nightmare. This was primarily because of the following challenges:

Project Setup and Tools Needed

It was not as simple as opening up the browser DevTool's Console tab, and starting to write code to see the output. This works great with JavaScript, and I – like many other beginners – had started gaining confidence coding in JavaScript by writing the code in the browser directly.

Writing JavaScript in the browser DevTool's console tab

With TypeScript, though, the browser doesn't understand its syntax. And you might be left wondering...what's next?

You can't run the TypeScript program the same way - you'll get an error

You may start realizing that you need additional tools and build systems to print a “Hello World” on the console.

The TypeScript Compiler

So, is there a compiler, too? Also, are you saying that the TypeScript Compiler (tsc) compiles the TypeScript code to create equivalent JavaScript code which we will run eventually? That’s weird. Then why not code in JavaScript directly? This thought baffles many developers starting with TypeScript.

The “One and Only” tsconfig.json File

TypeScript projects need explicit configurations to work in an environment that you define. You provide the configurations using the tsconfig.json file. It allows you to configure the output file path, type strictness, how to handle TypeScript related-features like any, and how you want TypeScript to treat null, undefined, and so on.

The good news is, it works great once you've configure things correctly. But the bad news is, as a newbie, you may be clueless about an error like the one you see below in the tsconfig.json file, even when you haven't touched the file at all.

The curious case of the tsconfig file.

The Sense of Slowing You Down

As a beginner to TypeScript (especially when you have already spent a good amount of time working with JavaScript), you may feel like you're being slowed down. The feeling comes from the need to always be defining your types.

That's when you start thinking:

• I'm writing extra code.
• Extra code means extra hours of work.
• That's extra brain power and maintenance.
• Am I overcomplicating some of the simple patterns of JavaScript?

After a few days...

Learning More About TypeScript – The Benefits

If you haven't given up yet, and you're still in exploration mode, your perspective of TypeScript may start changing. Here are some of the benefits of coding in TypeScript:

Type Safety

TypeScript is a superset of JavaScript. It has everything that JavaScript has, plus it ensures Type Safety.

TypeScript as a superset of JavaScript

Type safety is a mechanism to ensure you are using the right types of values in your code. It helps safeguard your applications from breaking something at runtime (in production when your users are using the application). TypeScript also ensures type safety at compile time, much before you push any code changes to other developers or to your users.

Here is an example of some type-safe code in TypeScript. The function sumOfTwo accepts two parameters of number type and returns a value that is also of number type.

function sumOfTwo(a: number, b: number): number {
    return a + b;
}

If the caller of the function doesn't adhere to the types defined, the code will not compile and produces compilation errors.

console.log(sumOfTwo(1,2)); // 3
console.log(sumOfTwo(1,-1)); // 0

console.log(sumOfTwo("tapas", 1)); // TypeError

This behaviour of TypeScript safe-guards your code so it doesn't fail in production from any type-related errors.

Easier Learning Curve

Type Safety is fine. How about the learning curve? If you know JavaScript already, your learning curve for TypeScript will be smaller.

If you do not know JavaScript, you can consider starting with TypeScript straightway, as learning JavaScript is equally challenging.

The Tooling Problem

Fortunately, there are ways to handle the initial tooling and build system problem we discussed before. Developers around the world have been using TypeScript for a while now and there are existing resources to get the help you need and set everything up.

If you have prior knowledge of Node and the JavaScript ecosystem, it may take half a day to set things up. If you do not have either Node or JavaScript or both, it may take a couple days max.

I have been through a similar phase, and now I have my own environment to use for all my TypeScript projects. You can check it out on my GitHub and feel free to start using it. If you want to create something similar and customize it to create your own, this guide will help you with that.

Also, the best part is, all this setup is a one-time job. You do it once, and you can replicate or reuse it for all your future projects.

You will also understand the power of VS Code IntelliSense while coding in TypeScript. It prompts you with code completion to make your coding experience even better.

How about the tsconfig thingy?

Undoubtedly, you'll need some time to learn about the configuration properties in the tsconfig.json file and what they do. But the positive thing is you do not need to know them all.

When you are getting started, just make sure you know what is minimally needed for your project and learn about those things. Rest assured that you can learn other things as and when you need them.

Baby Steps to Start Coding in TypeScript

After the initial struggle with tooling, building, and configuration, you may be itching to write your first line of TypeScript code (assuming you haven't started blaming TypeScript for your lack of productivity yet!).

Let's look at some scenario-based comparisons between the flexible world of JavaScript and the strict world of TypeScript.

JavaScript vs TypeScript Examples

A simple sum of two numbers in JavaScript would look like this:

function sumOfTwo(a, b) {
  return a + b;
}

console.log(sumOfTwo(1,2)); // 3
console.log(sumOfTwo(1,-1)); // 0

But doing the same thing with TypeScript would require an extra bit of code to tell the TypeScript compiler about the type of the parameters and the return type:

function sumOfTwo(a: number, b: number): number {
  return a + b;
}

console.log(sumOfTwo(1,2)); // 3
console.log(sumOfTwo(1,-1)); // 0

Hmm! That seems to be more work than necessary. But it's really more helpful than you can imagine. It guards your code against considering unacceptable inputs instead of what the more "flexible" JavaScript would allow:

function sumOfTwo(a, b) {
  return a + b;
}

console.log(sumOfTwo(1, true)); // The output is 2
console.log(sumOfTwo(1, [])); // Believe or not, it will result 1

Trying out the above code in TypeScript wouuld result in compilation errors. If you are running the TypeScript compiler in watch mode (with the command tsc -w), you can catch these errors while writing the code itself!

function sumOfTwo(a: number, b: number): number {
  return a + b;
}

console.log(sumOfTwo(1, true)); // Error
console.log(sumOfTwo(1, [])); // Error

That's not all. Let’s take another example. Consider an employee array with the details of a few employees in your JavaScript code:

// Employee Object

const employees = [
    {
        id: '01',
        name: 'Alex',
        age: 23,
        married: false
    },
    {
        id: '02',
        name: 'Bob',
        age: 3,
        married: false
    },
    {
        id: '03',
        name: 'Clara',
        age: 28,
        married: true
    }
];

Now, let's say you want to filter out the married employees.

// Filter the married employees

employees.filter(emp => emp.married) // Clara

It works great! But imagine if some of the employee data is incorrect somewhere. What if you are getting the employee object as an API response where the married property value of the employee Bob is set to 3 by mistake!

const employees = [
    {
        id: '01',
        name: 'Alex',
        age: 23,
        married: false
    },
    {
        id: '02',
        name: 'Bob',
        age: 3,
        married: 3
    },
    {
        id: '03',
        name: 'Clara',
        age: 28,
        married: true
    }
];

Now, your same logic of filtering the married employees would result in saying both Bob and Clara are the married employees – but Bob may not be married at all.

// Filter the married employees

employees.filter(emp => emp.married) // Bob and Clara

Hold on! You can still safe-guard the above situation with some lines of extra logic in your JavaScript code. How about you check the type of the value of each employee's married property in the array and throw an error if it's not a boolean?

employees.filter((employee) => {
  if (typeof employee.married  === 'boolean') {
      return employee.married && employee;
  } else {
      throw new Error("The employee.married type is not of boolean type.")
  }
});

This fixes the problem. But hang on, isn’t that:

• Extra lines of code you have written to safe guard your code from failing?
• Extra hours of work?
• Extra brain power and maintenance? What if similar value mistakes happen in other properties of the employee object? Would you keep adding conditions in the filter callback?
• Overcomplicating some of the simple patterns of JavaScript?

A better and safer situation is to use TypeScript and type safe each of the properties of the employee object either by defining a type or using interfaces.

type Employee = {
    id: string,
    name: string,
    age: number,
    married: boolean
}

So What's The Verdict: Is TypeScript Worth It or Not?

If you are coming to this section following the previous sections of this article, then the following points will make sense to you:

• You may not like TypeScript just by looking into it, what it promises, and the code written with it. You need to spend some time with TypeScript by writing code, and building projects with it.
• The complexity of tooling, builds, and configurations shouldn't stand in your way. There are many resources to help you figure these things out. As we discussed before, these are solved problems, and you don't need to reinvent the wheel.
• For JavaScript developers, it can hard to accept TypeScript without a deeper understanding of JavaScript itself. But the more you learn about it, the more I think you'll see that TypeScript indeed has an edge that'll help safeguard you and your team from type issues.

Now the question is – is it worth it?

Absolutely yes! Especially so if:

• Your project is beyond a simple app like a TODO app.
• You want to catch type errors and mistakes at compile time while writing your code instead of in production.
• The project is being developed by a team of JavaScript developers.
• You want to debug your code efficiently.
• You are looking for a common data contract interface between client and server for data exchange.
• Last but not least, if you don't want to miss out on the job opportunities that come with knowing TypeScript. If you know JavaScript basics, getting started with TypeScript will not be hard if you get proper guidance.

Before We End...

I want to end this article with a quote:

“Learning is an experience. Everything else is just information.” – Albert Einstein.

So it's up to you to decide if something is worth learning.

It should depend on why, rather than what, you want to learn. You will have limitations with how many things you can learn in your lifetime…so learn wisely.

This is also why I started my TypeScript playlist practically to make sure you don't come in with certain assumptions. I want you to learn TypeScript first so you can be a confident decision-maker when technology choices come.

Here is the link to my TypeScript playlist if you want to check it out. The playlist will break down each of the configurations, concepts, and project building in a beginner-friendly way to help you learn TypeScript rapidly.

That's all for now. I hope you found this article informative and insightful. I am an educator on my YouTube channel, tapaScript. Please SUBSCRIBE to the channel if you want to learn JavaScript, TypeScript, ReactJS, Next.js, Node.js, Git, and all about Web Development in a fundamental way.

Let's connect.

• Follow me on X (Twitter) or LinkedIn if you don't want to miss the daily dose of Career Tips.
• Find all my public speaking talks here.
• Check out and follow my Open Source work on GitHub.
• I regularly publish meaningful posts on my GreenRoots Blog, you may find them helpful, too.

See you soon with my next article. Until then, please take care of yourself, and stay happy.

If you are a React developer, you likely appreciate its component-based architecture, uni-directional data binding, huge community support, and the React team's passion for bringing features in front of developers.

If you are just getting started with React or a beginner at it, that's great – there's a complete React.js roadmap published here on the freeCodeCamp you can check out. And I think you'll find the library a lot easier to learn if you have a solid grip on basic JavaScript foundations.

Irrespective of where you stand with React, the real fun is in building things with it, don't you agree? So I thought of building a simple inventory list to explain a few powerful concepts like complex state management with useReducer.

And while we're doing that, we'll also create a mock API server using JSON Server, we'll use axios to call the API, and finally we'll use the useReducer hook to manage state.

Sounds interesting? Let's do it. If you would also like to check out the video version of this project, here it is: 😊

Table of Contents

• Project Setup with React and TailwindCSS
• How to Setup a Server with JSON Server
• How to Set Up and Use Axios
• How to Use the useReducer Hook from React
• How to Create Actions
• How to Create an Inventory Reducer
• How to Build the Inventory List Component
• How to Use Axios to Fetch Data and Dispatch it to the Reducer
• Let's Complete the JSX Part
• How to Use the Inventory List in the App Component
• Wrapping Up

Project Setup with React and TailwindCSS

Before we do anything else, let's get the project set up. Also, you can follow along with the source code as you read through.

To build this app, we will use React with Vite and TailwindCSS. You can set up these tools by following a few steps from the Vite and TailwindCSS documentation.

But, why not use something that provides everything built together? This will save you time for future React projects as you can use the same infrastructure to create a React projects every time.

Head over to this repository and click on the Use this template button as indicated in the image below. It will help you create a brand new repository out of a template repository with Vite, React, and TailwindCSS configured.

Create a React Project Repository with TailwindCSS and Vite from an Existing Template

Now provide a suitable name to your repository (let's call it inventory-list in this article) along with a description. You may chose to keep the repository private if you wish to, otherwise go ahead and create the repository by clicking on the button at the bottom.

Provide the Details of the New Repository

That's it. You have a repository with all the basic ingredients to get started. Now, go to the command prompt/terminal and clone the newly created repository:

git clone <YOUR NEWLY CREATED REPOSITORY URL>

Change directories to the project directory and install the project dependencies using the following commands:

## Change to the project directory
cd inventory-list

## Install dependencies

## Using NPM
npm install

## Using Yarn
yarn install

## Using PNPM
pnpm install

After the dependencies are installed successfully, execute the following command to run the project on a local server:

## Run the project locally

## Using NPM
npm run dev

## Using Yarn
yarn dev

## Using PNPM
pnpm dev

Now the project should be running locally and should be accessible on the default URL, http://localhost:5173. You can access the URL on yor browser and import the project source code into your favourite code editor (I use VS Code). We are all set to start the coding.

How to Setup a Server with JSON Server

JSON Server is the go-to option when you want to work with fake/mock APIs to serve data of your choice. It is easy to set up and customize to your use case.

Let's set up the JSON Server for our project. The first thing is to install it.

Open a terminal at the root of the project folder and type the following command to install JSON Server:

## Using NPM
npm install json-server

## Using Yarn
yarn add json-server

## Using PNPM
pnpm install json-server

JSON Server uses JSON files as the data sources to perform HTTP operations like GET/POST/PUT/PATCH/DELETE. Create a server/database directory under the src/ directory. Now create a file called data.json under the src/server/database/ with the following content:

{
  "edibles": [
    {
      "id": 1,
      "picture": "🍌",
      "name": "Banana",
      "price": 32,
      "quantity": 200,
      "type": "fruits"
    },
    {
      "id": 2,
      "picture": "🍓",
      "name": "Strawberry",
      "price": 52,
      "quantity": 100,
      "type": "fruits"
    },
    {
      "id": 3,
      "picture": "🍗",
      "name": "Checken",
      "price": 110,
      "quantity": 190,
      "type": "foods",
      "sub-type": "Non-Veg"
    },
    {
      "id": 4,
      "picture": "🥬",
      "name": "Lettuce",
      "price": 12,
      "quantity": 50,
      "type": "Vegetables"
    },
    {
      "id": 5,
      "picture": "🍅",
      "name": "Tomato",
      "price": 31,
      "quantity": 157,
      "type": "Vegetables"
    },
    {
      "id": 6,
      "picture": "🥩",
      "name": "Mutton",
      "price": 325,
      "quantity": 90,
      "type": "Non-Veg"
    },
    {
      "id": 7,
      "picture": "🥕",
      "name": "Carrot",
      "price": 42,
      "quantity": 190,
      "type": "Vegetables"
    }
  ]
}

The data.json file contains an array of edible items. Each of the items in the array has properties like picture, name, price, quantity, and type to show in the inventory list.

The last thing left is to add a script into the package.json file so that we can start the JSON Server easily every time. Open the package.json file and add this line inside the scripts object like this:

"start-server": "json-server --watch ./src/server/database/data.json"

Next, go to the terminal and use the following command to start the JSON Server to serve the API:

## Using NPM
npm run start-server

## Using Yarn
yarn start-server

## Using PNPM
pnpm run start-server

You should see a message like this in your terminal:

The Output

It indicates that the JSON Server is running locally on localhost:3000 and there is an API endpoint called edibles serves the data. Now you can access the URL http://localhost:3000/edibles from your browser to see the data (fetched by a GET method call):

The API Output

Great! Now we have the /edibles API endpoint ready to consume into the React component.

How to Set Up and Use Axios

Axios is an HTTP client that helps us make promise-based asynchronous calls from the browser and Node.js environment. It has a number of useful features that make it one of the most used libraries for asynchronous request-response.

Note that we could have used the fetch Web API from JavaScript instead of Axios in this project. The only reason for using Axios here is to introduce it progressively. In the future articles, you'll learn its usages in handling JWT tokens from a React application. Stay tuned!

Open the terminal at the root of the project folder and use the following command to install Axios:

## Using NPM
npm install axios

## Using Yarn
yarn add axios

## Using PNPM
pnpm install axios

That's it. We will use Axios in a bit after laying out the basic components needed for the inventory list.

How to Use the useReducer Hook from React

React is a user interface library that supports component-based architecture at the core. A component is a single entity that's supposed to perform one task well. Multiple components come together to compose the final user interface.

Often, a component will have its own private data. We call these the states of a component. The value of a state drives the behaviour and appearance of a component. When state changes, the component re-renders to keep itself up-to-date with the latest state value.

The traditional way of handling state in React is with the useState hook. It works great as long as your state changes are trivial. As the state change logic becomes more complex and if you need to manage multiple scenarios around it, useState may make things clumsy. This is where you should think about using the useReducer hook.

useReducer is a standard hook from the React library. It accepts two primary parameters:

• initState: the initial state value
• reducer: a JavaScript function that holds the state change logic based on an action (or trigger).

The hook returns the following:

• A state: the current state value.
• A dispatch function: a function that tells the respective reducer what to do next, and what data to act on.

The image below explains each of the entities of the useReducer hook. If you want to learn about this hook in a greater depth, feel free to check this out.

The Anatomy of the useReducer Hook

How to Create Actions

The reducer function is the heart of the useReducer hook. It performs all the necessary logic to keep your application state updated and valid.

But how would the reducer function be aware of its task? Who would tell the reducer function what to do and what kind of data to work on? Here comes actions, an object that contains all the details for the reducer.

We define actions with types that indicate the stages a state change will occur in the reducer function. The same action object may also carry the application data(at times we call it payload) to pass to the reducer function when a component performs a dispatch.

We will now get started by creating some actions. We will define the types here. As our reducer needs to manage the inventory state on a data fetch, data fetch success, and data fetch error, we'll be defining actions for each of those.

Create a directory called actions/ under the src/ directory. Now create a file called index.js under the src/actions/ directory with the following content:

const FETCH_ACTIONS = {
  PROGRESS: 'progress',
  SUCCESS: 'success',
  ERROR: 'error',
}

export { FETCH_ACTIONS };

We have defined three actions, PROGRESS, SUCCESS, and ERROR. Next, let's create the reducer.

How to Create an Inventory Reducer

We need a reducer where we will keep all the state change logic. The same reducer will be passed to the useReducer hook later to get the current state value and dispatch the function to the component.

Create a directory called reducers/ under the src/. Now, create a file called inventoryReducers.js under the src/reducers/ directory.

Our reducer will need the actions because it has to work on state changes based on the actions. So, let's import the actions into the inventoryReducers.js file:

import { FETCH_ACTIONS } from "../actions"

You can define an initial state in the reducer file. The useReducer hook needs a reducer and an initial state to give us the current state value, remember? Let's define an initial state.

We need to show a list of inventory items after getting a successful API response. While we are fetching the list of items by making an API call, we need to manage a loading data state.

In case there is any problem in fetching data, we need to report the error using the error state. So we can create an initial state with all these values as object properties.

Now, create an initialState variable with the following state object value assigned to it:

const initialState = {
  items: [],
  loading: false,
  error: null,
}

Next, let's create the reducer function. Create a function called inventoryReducer with the following code snippet:

const inventoryReducer = (state, action) => {

  switch (action.type) {
    case FETCH_ACTIONS.PROGRESS: {
      return {
        ...state,
        loading: true,
      }
    }

    case FETCH_ACTIONS.SUCCESS: {
      return {
        ...state,
        loading: false,
        items: action.data,
      }
    }

    case FETCH_ACTIONS.ERROR: {
      return {
        ...state,
        loading: false,
        error: action.error,
      }
    }

    default: {
      return state;
    }      
  }

}

Let's understand the above code snippet. The inventoryReducer function takes two arguments, state and action. The reducer function works on the state based on the action type. For example,

• When it is a PROGRESS action, we want the loading value to be true.
• For a SUCCESS action, we want to populate the items with the data received from the API response along with making the loading value as false.
• For an ERROR action, we'll provide a value to the error property of the state.

In any of the cases above, we do not mutate the state directly. Rather, we create a clone (a new reference of it using the ... operator) of the state and then update its properties accordingly. Finally, we return the updated state for each of the actions. If the passed actions do not match any of the given types, we return back the state as it is.

Last, export the inventoryReducer function and the initialState object:

export {inventoryReducer, initialState};

Here is the complete code from the inventoryReducers.js file:

import { FETCH_ACTIONS } from "../actions"

const initialState = {
  items: [],
  loading: false,
  error: null,
}

const inventoryReducer = (state, action) => {

  switch (action.type) {
    case FETCH_ACTIONS.PROGRESS: {
      return {
        ...state,
        loading: true,
      }
    }

    case FETCH_ACTIONS.SUCCESS: {
      return {
        ...state,
        loading: false,
        items: action.data,
      }
    }

    case FETCH_ACTIONS.ERROR: {
      return {
        ...state,
        loading: false,
        error: action.error,
      }
    }

    default: {
      return state;
    } 
  }

}

export {inventoryReducer, initialState};

How to Build the Inventory List Component

We will now create the inventory list component where we will use the reducer we created above.

Create a directory called components/ under the src/ directory. Now, create a file called InventoryList.jsx under the stc/components/ directory.

First import the required things like:

• The useReducer hook where we will use the inventory reducer.
• The useEffect hook to handle the async call with Axios.
• The inventory reducer and the initial state we created a few minutes back.
• The actions, as we need them to dispatch.
• The axios for making async calls.

import { useReducer, useEffect } from "react";

import { inventoryReducer, initialState } from "../reducers/inventoryReducer";

import { FETCH_ACTIONS } from "../actions";

import axios from "axios";

Now, create a function to define the component:

const InventoryList = () => {

  const [state, dispatch] = useReducer(inventoryReducer, initialState);

  const { items, loading, error} = state;

  return(
    <div className="flex flex-col m-8 w-2/5">

    </div>
  );
};

Here,

• We have used the useReducer hook. We passed the inventoryReducer and the initialState to it as arguments to get the current state value and the dispatch function.
• As we know the state object has the items, loading, and error as properties, we destructure them into our component. We will use them shortly.
• The component returns an empty div that we will change as we proceed.

Finally export the component as a default export like this:

export default InventoryList;

How to Use Axios to Fetch Data and Dispatch it to the Reducer

It's data fetching time! Data fetching by making an asynchronous call is a side effect you need to handle in your component. Copy and paste the useEffect code block inside the InventoryList function.

// -- The code above as it is

const InventoryList = () => {

  // --- The code above as it is


  useEffect(() => {
    dispatch({type: FETCH_ACTIONS.PROGRESS});

    const getItems = async () => {
      try{
        let response = await axios.get("http://localhost:3000/edibles");
        if (response.status === 200) {
          dispatch({type: FETCH_ACTIONS.SUCCESS, data: response.data});
        }
      } catch(err){
        console.error(err);
        dispatch({type: FETCH_ACTIONS.ERROR, error: err.message})
      }
    }

    getItems();

  }, []);

  // --- The JSX return statement below as it is

Let's understand the code flow:

• At the start of the useEffect callback, we dispatched a PROGRESS action. It invokes the reducer function with progress action type to turn the loading property value to true. We can use the loading property value in the JSX later to show a loading indicator.
• Then we use Axios to make an asynchronous call using the API URL. On receiving the response, we check if it's a success, and in that case we dispatch a SUCCESS action along with the items data(remember, payload?) from response. This time the dispatcher will invoke the reducer with the success action to change the items and loading properties accordingly.
• If there is an error, we dispatch an error action with the error message to update the state with the error information in the reducer.

Each time we dispatch an action and update the state, we also get back the latest state value into our component. It's time to use the state value in the JSX to render the inventory item list.

Let's Complete the JSX Part

The JSX part is fairly simple:

// -- The code above as it is

const InventoryList = () => {

  // -- The code above as it is

  return (
    <div className="flex flex-col m-8 w-2/5">
      {
        loading ? (
          <p>Loading...</p>
        ) : error ? (
          <p>{error}</p>
        ) : (
          <ul className="flex flex-col">
            <h2 className="text-3xl my-4">Item List</h2>
            {
              items.map((item) => (
                <li
                  className="flex flex-col p-2 my-2 bg-gray-200 border rounded-md" 
                  key={item.id}>
                  <p className='my-2 text-xl'>
                    <strong>{item.name}</strong> {' '} {item.picture} of type <strong>{item.type}</strong>
                    {' '} costs <strong>{item.price}</strong> INR/KG.
                  </p>
                  <p className='mb-2 text-lg'>
                    Available in Stock: <strong>{item.quantity}</strong>
                  </p>

                </li>
              ))
            }

          </ul>
        )
      }

    </div>
  )
}

export default InventoryList;