DEV Community: ajay-8192

`useTransition` for Smoother API Calls in React

ajay-8192 — Wed, 02 Jul 2025 10:35:35 +0000

Mini-Post: `useTransition` for Smoother API Calls in React

React 18 introduced a powerful new hook called useTransition. Its primary purpose is to differentiate between urgent updates (like typing in an input) and non-urgent updates (like fetching data or rendering a large list). This can significantly improve the perceived responsiveness of your application.

What is `useTransition`?

useTransition provides a way to mark certain state updates as "transitions." During a transition, React will keep the old UI visible and interactive while it prepares the new UI in the background. Once the new UI is ready, it will seamlessly swap it in. This avoids jarring loading states or blocking the main thread for less critical operations.

How to use it for API Calls

API calls are a perfect candidate for useTransition because they often involve a delay, and you wouldn't want to block the user interface while waiting for data.

Here's a common pattern:

import React, { useState, useTransition } from 'react';

function ProductList() {
  const [products, setProducts] = useState([]);
  const [isLoading, setIsLoading] = useState(false);
  const [isPending, startTransition] = useTransition();

  const fetchProducts = async () => {
    setIsLoading(true); // Indicate the start of data fetching
    startTransition(async () => {
      // Mark this update as a transition
      const response = await fetch('/api/products');
      const data = await response.json();
      setProducts(data);
      setIsLoading(false); // Data fetching is complete
    });
  };

  return (
    <div>
      <button onClick={fetchProducts} disabled={isLoading}>
        {isLoading ? 'Loading...' : 'Fetch Products'}
      </button>

      {isPending && <p>Preparing new product list...</p>} {/* Optional pending indicator */}

      <ul>
        {products.map(product => (
          <li key={product.id}>{product.name}</li>
        ))}
      </ul>
    </div>
  );
}

export default ProductList;

Explanation:

const [isPending, startTransition] = useTransition();:

  * `isPending`: A boolean that tells you if a transition is currently in progress. You can use this to show a lightweight, non-blocking indicator (e.g., a "Preparing..." message) instead of a full spinner that blocks the UI.
  * `startTransition`: A function that you wrap your non-urgent state updates in.

startTransition(async () => { ... });:

  * Inside this callback, you perform your API call and update the state (setProducts). React knows that these updates are part of a transition.


While the API call is in progress and setProducts is preparing the new UI, the isPending flag will be true, allowing you to show a subtle indicator. The old products list will remain visible and interactive until the new data is ready.

Benefits:

Improved User Experience: The UI remains responsive and interactive even during data fetching, preventing frustrating freezes.
Smoother Transitions: Users perceive a smoother flow as new data is seamlessly integrated without abrupt loading screens.
Clearer Intent: It explicitly tells React which updates are critical and which can be deferred.

By leveraging useTransition, you can create a much more fluid and user-friendly experience when dealing with data fetching and other potentially slow operations in your React applications.

Go Concurrency

ajay-8192 — Wed, 02 Jul 2025 10:31:26 +0000

Go Concurrency Explained in Detail

Go has a built-in feature to handle concurrency, which allows it to run multiple functions simultaneously and efficiently. Concurrency isn't parallelism. Parallelism refers to the simultaneous execution of multiple tasks, whereas concurrency refers to the ability to deal with multiple tasks at once. Go Concurrency is a common topic of discussion. Let's look at the mechanisms that support Go Concurrency.

Goroutines

Goroutines are functions or methods that run concurrently with other functions or methods. Goroutines are lightweight threads managed by the Go runtime. They're similar to threads, but they're much cheaper to create and manage. You can create thousands of goroutines without significant overhead.

To create a goroutine, simply add the go keyword before the function call:

package main

import (
    "fmt"
    "time"
)

func hello() {
    fmt.Println("Hello from goroutine!")
}

func main() {
    go hello() // This will run hello() as a goroutine
    fmt.Println("Hello from main function!")
    time.Sleep(1 * time.Second) // Wait for the goroutine to finish
}

In this example, hello() will run concurrently with the main() function. The time.Sleep() is added to give the goroutine enough time to execute before the main function exits. Without time.Sleep(), the main function might exit before the hello() goroutine has a chance to print its message.

Channels

Channels are the conduits through which goroutines communicate. They allow goroutines to send and receive values of a specified type. Channels are a fundamental part of Go's concurrency model, enabling safe and synchronized communication between concurrent processes.

Declaring and Initializing Channels

You can declare a channel using the chan keyword, followed by the type of data it will carry:

var myChannel chan int // Declares a channel that will carry integers

To initialize a channel, you use the make function:

myChannel := make(chan int) // Initializes an unbuffered channel

Sending and Receiving Values

You send values into a channel using the <- operator:

myChannel <- 10 // Sends the integer 10 into myChannel

You receive values from a channel using the same <- operator, but this time it's on the left side of the assignment:

value := <-myChannel // Receives a value from myChannel and assigns it to 'value'

Here's an example demonstrating channel communication:

package main

import (
    "fmt"
)

func sendData(ch chan string) {
    ch <- "Go Concurrency is awesome!"
}

func main() {
    myChannel := make(chan string) // Create a channel of type string
    go sendData(myChannel)         // Start a goroutine to send data
    message := <-myChannel         // Receive data from the channel
    fmt.Println(message)
}

In this example, sendData sends a string to myChannel, and the main function receives that string and prints it.

Buffered Channels

Channels can be buffered, meaning they have a capacity to hold a certain number of values before blocking. When a channel is unbuffered (capacity 0), sending to it will block until another goroutine receives from it, and receiving from it will block until another goroutine sends to it.

You can create a buffered channel by providing a capacity to the make function:

bufferedChannel := make(chan int, 3) // Creates a buffered channel with a capacity of 3

Here's an example of a buffered channel:

package main

import (
    "fmt"
)

func main() {
    ch := make(chan int, 2) // Buffered channel with capacity 2

    ch <- 1
    ch <- 2
    // ch <- 3 // This would block because the buffer is full

    fmt.Println(<-ch)
    fmt.Println(<-ch)
}

Select Statement

The select statement is used to wait on multiple channel operations. It allows a goroutine to block until one of multiple send/receive operations is ready. It's similar to a switch statement but specifically for channels.

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    go func() {
        time.Sleep(1 * time.Second)
        ch1 <- "message from channel 1"
    }()

    go func() {
        time.Sleep(500 * time.Millisecond)
        ch2 <- "message from channel 2"
    }()

    for i := 0; i < 2; i++ { // We expect two messages
        select {
        case msg1 := <-ch1:
            fmt.Println(msg1)
        case msg2 := <-ch2:
            fmt.Println(msg2)
        }
    }
}

In this example, select will wait for either ch1 or ch2 to send a message. Whichever message arrives first will be printed.

Mutexes (Mutual Exclusion)

While channels are the preferred way to communicate and synchronize in Go, there are situations where you might need to protect shared resources from concurrent access. This is where sync.Mutex comes in. A mutex ensures that only one goroutine can access a critical section of code at a time, preventing race conditions.

package main

import (
    "fmt"
    "sync"
    "time"
)

var (
    counter int
    mutex   sync.Mutex
)

func increment() {
    mutex.Lock()   // Acquire the lock
    counter++
    mutex.Unlock() // Release the lock
}

func main() {
    var wg sync.WaitGroup

    for i := 0; i < 1000; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            increment()
        }()
    }

    wg.Wait() // Wait for all goroutines to finish
    fmt.Println("Final counter:", counter)
}

In this example, mutex.Lock() ensures that only one goroutine can increment counter at a time, preventing a race condition where the final counter value might be incorrect without the mutex. sync.WaitGroup is used to wait for all goroutines to complete before printing the final counter.

Conclusion

Go's concurrency model, built around goroutines and channels, provides powerful and elegant ways to write concurrent programs. By understanding these core concepts, you can build highly performant and scalable applications in Go. While mutexes are available for shared memory access, the Go idiom often favors communication through channels to achieve concurrency safely and efficiently. Embrace goroutines and channels, and you'll unlock the true potential of Go for concurrent programming!

SOLID in Software Development - 5

ajay-8192 — Wed, 15 Nov 2023 14:00:17 +0000

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle (DIP) states that "High-level modules should not depend on low-level modules; both should depend on abstractions." In other words, we should depend on high-level abstractions (interfaces, abstract classes) rather than on low-level concretions (concrete classes, implementations). This makes our code more flexible and easier to test.

Here is an example of how the DIP can be violated:

public class EmailService {
    private SendEmailUseCase sendEmailUseCase;

    public EmailService(SendEmailUseCase sendEmailUseCase) {
        this.sendEmailUseCase = sendEmailUseCase;
    }

    public void sendEmail(String to, String subject, String body) {
        sendEmailUseCase.sendEmail(to, subject, body);
    }
}

public class SendEmailUseCase {
    private SMTPClient smtpClient;

    public SendEmailUseCase(SMTPClient smtpClient) {
        this.smtpClient = smtpClient;
    }

    public void sendEmail(String to, String subject, String body) {
        smtpClient.connect();
        smtpClient.send(to, subject, body);
        smtpClient.disconnect();
    }
}

The EmailService class depends on the SendEmailUseCase class, which in turn depends on the SMTPClient class. This violates the DIP because the EmailService class depends on a low-level concretion (SMTPClient). This makes the EmailService classless flexible and more difficult to test.

A better way to design this code would be to use an interface to abstract the SMTPClient class:

public interface SMPTClient {
    void connect();
    void send(String to, String subject, String body);
    void disconnect();
}

public class EmailService {
    private SMPTClient smtpClient;

    public EmailService(SMPTClient smtpClient) {
        this.smtpClient = smtpClient;
    }

    public void sendEmail(String to, String subject, String body) {
        smtpClient.connect();
        smtpClient.send(to, subject, body);
        smtpClient.disconnect();
    }
}

public class MockSMPTClient implements SMPTClient {
    @Override
    public void connect() {
        // Implement mock connection logic
    }

    @Override
    public void send(String to, String subject, String body) {
        // Implement mock send logic
    }

    @Override
    public void disconnect() {
        // Implement mock disconnect logic
    }
}

public class SendEmailUseCase {
    private SMPTClient smtpClient;

    public SendEmailUseCase(SMPTClient smtpClient) {
        this.smtpClient = smtpClient;
    }

    public void sendEmail(String to, String subject, String body) {
        smtpClient.connect();
        smtpClient.send(to, subject, body);
        smtpClient.disconnect();
    }
}

This code follows the DIP because the EmailService class depends on an interface (SMPTClient) rather than on a low-level concretion (SMTPClient). This makes the EmailService class more flexible and easier to test.

**** 💻ALL THE BEST💻 ****

SOLID in Software Development - 4

ajay-8192 — Wed, 15 Nov 2023 13:51:05 +0000

Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) is one of the five SOLID principles of object-oriented programming (OOP). It states that "Many client-specific interfaces are better than one general-purpose interface." In other words, we should avoid creating large, monolithic interfaces that expose a lot of functionality that not all clients need. Instead, we should create smaller, more specific interfaces that only expose the functionality that a particular client needs.

here is an example of how the Interface Segregation Principle (ISP) can be violated:

public interface Shape {
    void draw();
    void resize();
    void rotate();
    void translate();
}

public

class

Circle

implements

Shape

{
    private

double radius;

    public

Circle(double radius)

{
        this.radius = radius;
    }

    @Override


public

void draw() {
        // Draw a circle
    }

    @Override
    public void resize() {
        // Resize the circle
    }

    @Override
    public void rotate() {
        // Rotate the circle
    }

    @Override
    public void translate() {
        // Translate the circle
    }
}

public

class

Triangle

implements

Shape

{
    private

double sideA;
    private

double sideB;
    private

double sideC;

    public

Triangle(double sideA, double sideB, double sideC)

{
        this.sideA = sideA;
        this.sideB = sideB;
        this.sideC = sideC;
    }

    @Override


public

void draw() {
        // Draw a triangle
    }

    @Override
    public void resize() {
        // Resize the triangle
    }

    @Override
    public void rotate() {
        // Rotate the triangle
    }

    @Override
    public void translate() {
        // Translate the triangle
    }
}

The Shape interface defines five methods: draw, resize, rotate, translate, and getArea. However, not all shapes support all of these methods. For example, a circle does not support the getArea method, and a triangle does not support the rotate method. This violates the ISP because it forces all shapes to implement methods that they do not support.

A better way to design this code would be to create separate interfaces for each type of shape:

public interface Drawable {
    void draw();
}

public interface Resizable {
    void resize();
}

public interface Rotatable {
    void rotate();
}

public interface Translatable {
    void translate();
}

public interface Shape extends Drawable, Resizable, Translatable {
    double

getArea();
}

public

class

Circle

implements

Shape

{
    private

double radius;

    public

Circle(double radius)

{
        this.radius = radius;
    }

    @Override
    public void draw() {
        // Draw a circle
    }

    @Override
    public void resize() {
        // Resize the circle
    }

    @Override
    public void translate() {
        // Translate the circle
    }

    @Override
    public double getArea() {
        return Math.PI * radius * radius;
    }
}

public

class

Triangle

implements

Shape

{
    private

double sideA;
    private

double sideB;
    private

double sideC;

    public

Triangle(double sideA, double sideB, double sideC)

{
        this.sideA = sideA;
        this.sideB = sideB;
        this.sideC = sideC;
    }

    @Override


public

void draw() {
        // Draw a triangle
    }

    @Override
    public void resize() {
        // Resize the triangle
    }

    @Override
    public void translate() {
        // Translate the triangle
    }

    @Override
    public double getArea() {
        // Calculate the area of the triangle
    }
}

This code follows the ISP because the Shape interface only defines methods that are common to all shapes, and the Drawable, Resizable, Rotatable, and Translatable interfaces define methods that are specific to certain types of shapes. This allows us to only implement the methods that are relevant to a particular shape, and it makes our code more modular and easier to maintain.

***** More to Part 5 ***** **** 💻ALL THE BEST💻 ****

SOLID in Software Development - 3

ajay-8192 — Wed, 15 Nov 2023 13:40:53 +0000

Liskov Substitution Principle (LSP)

The Liskov Substitution Principle (LSP) states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application. This means that subclasses should be able to fulfill the same contract as their superclass without introducing any unexpected behavior.

Here is an example of how the LSP can be violated:

public class Rectangle {
    private double length;
    private double width;

    public Rectangle(double length, double width) {
        this.length = length;
        this.width = width;
    }

    public double getArea() {
        return length * width;
    }
}

public class Square extends Rectangle {
    public Square(double side) {
        super(side, side);
    }

    @Override
    public double getArea() {
        return side * side * side; // This violates the LSP because it changes the behaviour of the `getArea` method
    }
}

The Square class is a subclass of the Rectangle class. However, the getArea method of the Square class violates the LSP because it changes the behaviour of the getArea method of the Rectangle class. This means that if we substitute an object of the Square class for an object of the Rectangle class, then the program may break.

A better way to design this code would be to have the Square class return the correct area:

public class Rectangle {
    private double length;
    private double width;

    public Rectangle(double length, double width) {
        this.length = length;
        this.width = width;
    }

    public double getArea() {
        return length * width;
    }
}

public class Square extends Rectangle {
    public Square(double side) {
        super(side, side);
    }

    @Override
    public double getArea() {
        return side * side;
    }
}

This code follows the LSP because the getArea method of the Square class does not change the behaviour of the getArea method of the Rectangle class.

***** More to Part 4 ***** **** 💻ALL THE BEST💻 ****

SOLID in Software Development - 2

ajay-8192 — Tue, 14 Nov 2023 13:21:44 +0000

Open-Closed Principle (OCP)

The Open-Closed Principle (OCP) states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that we should be able to add new functionality to our code without having to modify existing code.

Here is an example of how the OCP can be violated:

public class Shape {
    private String type;

    public Shape(String type) {
        this.type = type;
    }

    public double getArea() {
        if (type.equals("circle")) {
            return Math.PI * radius * radius;
        } else if (type.equals("rectangle")) {
            return length * width;
        } else {
            throw new IllegalArgumentException("Invalid shape type: " + type);
        }
    }
}

This Shape class has two types of shapes: circles and rectangles. If we want to add a new type of shape, such as a triangle, then we will need to modify the getArea method to handle the new shape. This violates the OCP because the getArea method should not be modified to handle new shapes.

A better way to design this code would be to use a strategy pattern:

public interface ShapeAreaCalculator {
    double getArea();
}

public class CircleAreaCalculator implements ShapeAreaCalculator {
    private double radius;

    public CircleAreaCalculator(double radius) {
        this.radius = radius;
    }

    @Override
    public double getArea() {
        return Math.PI * radius * radius;
    }
}

public class RectangleAreaCalculator implements ShapeAreaCalculator {
    private double length;
    private double width;

    public RectangleAreaCalculator(double length, double width)

{
        this.length = length;
        this.width = width;
    }

    @Override


public

double

getArea()

{
        return length * width;
    }
}

public class Shape {
    private String type;
    private ShapeAreaCalculator shapeAreaCalculator;

    public Shape(String type, ShapeAreaCalculator shapeAreaCalculator) {
        this.type = type;
        this.shapeAreaCalculator = shapeAreaCalculator;
    }

    public double getArea() {
        return shapeAreaCalculator.getArea();
    }
}

This code follows the OCP because the Shape class is not modified to handle new shapes. Instead, we can create a new ShapeAreaCalculator implementation for each new type of shape.

***** More to Part 3 ***** **** 💻ALL THE BEST💻 ****

SOLID in Software Development - 1

ajay-8192 — Tue, 14 Nov 2023 13:18:20 +0000

What is meant by SOLID?

SOLID in Software Development is 5 principles that are a set of guidelines for designing and developing software systems that are object-oriented, reusable, maintainable, and extensible.

Single Responsibility Principle (SRP)
Open-Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)

Why SOLID?

Some of the benefits of following the SOLID principles:

Reduced code complexity: Helps to reduce the complexity of code by making it more modular and easier to understand. This makes it easier for developers to read, maintain, and modify the code.
Increased code reusability: Makes it easier to reuse code by making it more modular and independent of other parts of the codebase. This can save developers time and effort, and it can lead to more consistent and reliable code.
Improved code maintainability: Makes it easier to maintain code by making it more modular and easier to test. This can save developers time and effort, and it can help to prevent bugs from being introduced into the code.
Enhanced code extensibility: Makes it easier to extend code by making it more modular and easier to change. This allows developers to add new functionality to the code without breaking existing code.

Single Responsibility Principle (SRP)

The Single Responsibility Principle (SRP) is a class that should be responsible for a single functionality and should not be burdened with multiple responsibilities that are unrelated to its core purpose.

Here is an example of how the SRP can be violated:

public class Customer {
    private String name;
    private String email;
    private String address;
    private String phoneNumber;

    public void updateCustomerDetails(String name, String email, String address, String phoneNumber)

{
        this.name = name;
        this.email = email;
        this.address = address;
        this.phoneNumber = phoneNumber;
    }

    public void sendPasswordResetEmail() {
        // Send password reset email to the customer's email address
    }
}

This Customer class has two responsibilities: managing customer details and sending password reset emails. If the way that password reset emails are sent changes, then the updateCustomerDetails method will need to be changed as well. This violates the SRP because the updateCustomerDetails method should only be responsible for updating customer details.

A better way to design this code would be to split the Customer class into two classes: one for managing customer details and one for sending password reset emails:

public class CustomerDetails {
    private String name;
    private String email;
    private String address;
    private String phoneNumber;

    public void updateCustomerDetails(String name, String email, String address, String phoneNumber)

{
        this.name = name;
        this.email = email;
        this.address = address;
        this.phoneNumber = phoneNumber;
    }
}

public class PasswordResetService {
    private CustomerDetails customerDetails;

    public PasswordResetService(CustomerDetails customerDetails) {
        this.customerDetails = customerDetails;
    }

    public void sendPasswordResetEmail() {
        // Send password reset email to the customer's email address
    }
}

This code follows the SRP because the CustomerDetails class is only responsible for managing customer details, and the PasswordResetService class is only responsible for sending password reset emails. If the way that password reset emails are sent changes, then only the PasswordResetService class will need to be changed.

***** More to Part 2 ***** **** 💻ALL THE BEST💻 ****

Performance tab in Devtools

ajay-8192 — Mon, 30 Oct 2023 18:43:28 +0000

Analyze runtime performance

Runtime performance is how your page performs when it is running, as opposed to loading. In terms of the RAIL model, the skills you learn in this tutorial are useful for analyzing the Response, Animation, and Idle phases of your page.

Tutorial with example

Open a new tab in incognito mode
Open https://googlechrome.github.io/devtools-samples/jank/
Open devtools

Simulate a mobile CPU

Whenever you profile a page, use CPU Throttling to simulate how your page performs on mobile devices.

Open the Performance tab
The screenshots checkbox is enabled
Click Capture Settings. devTools reveals settings related to how it captures performance metrics.
For CPU, select 2x slowdown

Set up the demo

It’s hard to create a runtime performance demo that works for all readers of this website. This section lets you customize the demo to ensure that your experience is relatively consistent with the screenshots and descriptions

Keep clicking Add 10 until the blue squares move noticeably slower than before.
Click Optimize. The blue squares should move faster and more smoothly
Click Un-Optimize. The blue squares move slower and with more jank again.

Record runtime performance

When you run the optimized version of the page, the blue squares move faster. Both versions are supposed to move each square to the same amount of space in the same amount of time.

In DevTools, click Record. Devtools captures performance metrics as the page runs
Wait for a few seconds
Click Stop. Devtools stops recording, processes the data, and then displays the results on the Performance panel.

Analyze the results

Analyze frames per second

The main metric for measuring the performance of any animation is frames per second (FPS). The preferred value is 60 FPS.

Look at the FPS chart. Whenever you see a red bar above FPS, it means that the framerate dropped so low that it’s probably harming the UX. In general, the higher the green bar, the higher the FPS
Below the FPS chart, you see the CPU chart. The colors in the CPU chart correspond to the colors in the Summary tab, at the bottom of the Performance panel. The fact that the CPU chart is full of colour means that the CPU was maxed out during the recording. Whenever the CPU maxes out for long periods, it’s a cue to find ways to do less work.
Hover the mouse over the FPS, CPU or NET charts. Devtools shows a screenshot of the page at the point in time. Move your mouse left and right to replay the recording. This is called scrubbing, and it’s useful for manually analyzing the progression of animations.
In the Frames section, hover the mouse over one of the green squares. Devtools shows you the FPS for that particular frame. Each frame is probably well below the target of 60FPS

FPS meter one of the another handy tool for analyzing

Code to check on optimized and unoptimized for a better understanding of why we are able to see vast differences between optimized and unoptimized screen and performance data.
DevTool-Samples

Find the bottleneck

Now that we have measured and verified that the animation is not performing well, the next question to answer is: why?

In the summary tab. When no events are selected, this shows you a breakdown of the activity. The page spent most of its rendering. Since performance is the art of doing less work, our goal is to reduce the amount of time spent doing rendering work.
Expand the Main section. DevTools shows you a flame chart of activity on the main thread, over time. The x-axis represents the recording, over time. Each bar represents an event. A wider bar means that the event took longer. The y-axis represents the call stack. When you see the events stacked on top of each other, it means the upper events caused the lower events.
Zoom in on a single Animation Frame Fired event by clicking, holding, and dragging the mouse over the overview, which is the section that includes the FPS, CPU and NET charts. The Main and Summary tabs only display information for the selected portion of the recording
Note the red triangle in the top-right of the Animated Fram Fired event. Whenever you see a red triangle, it’s a warning that there may be an issue related to this event.
Click the Animation Frame Fired event. The summary tab now shows you information about that event. Note the reveal link. Clicking that jumps you to the relevant line in the source code.
Under the app.update event, there are a bunch of purple events. If they were wider, it looks as though each one might have a red triangle on it.
In the summary tab, click the app.js link under Layout Forced.

References:

Performance devtool documentation

Performance feature Reference

Timeline event reference

CODE for example website

Create a React app using Webpack 5

ajay-8192 — Mon, 30 Oct 2023 18:08:15 +0000

React

React is a Javascript library for building user interfaces. It is a declarative library, meaning you can describe what you want UI to look like, and React takes care of the rest.

React: React Learn

Webpack and Babel are used for React application because Webpack bundles and manage dependencies individually like JavaScript, CSS and assets and loads to the browser and Babel is used to transpile modern JavaScript applications into code that can run in all environments for React components.

Webpack

Webpack is a static module bundler for modern JavaScript applications. It creates dependency graphs from one or more entries and combines modules your project needs into one or more bundles, which are static assets to create content form.

Refer: Webpack Documentation

Babel

Babel is a JavaScript compiler or transpiler mainly used to convert ECMAScript2015+ to compatible versions of JavaScript in browsers.

Refer: Babel Documentation

Initial Step

Create a workspace or folder to create a project

mkdir project-for-react-using-webpack
cd project-for-react-using-webpack

Initialize with npm

Initializing with npm will create a package.json file to keep track of dependencies and metadata.

npm init -y

Add react and react-dom

npm install react react-dom

React provides tools to create a view of components or parts of the page.

ReactDOM provides DOM-specific methods that can be used at the top level for an efficient way of managing DOM elements.

Install webpack packages as devDependencies

npm install --save-dev webpack webpack-cli webpack-dev-server

Webpack is used to bundle the modules in the application.

Webpack CLI provides a flexible set of commands for developers to increase speed when setting up a custom webpack project.

Webpack Dev Server is a tool for starting a static server for your assets.

Install Babel related packages as devDependencies

npm install --save-dev  @babel/core babel-loader @babel/preset-react  @babel/preset-env

Babel Core The core module that wraps everything in our transform API, Transform syntax: Polyfill features that are missing in your target environment.

Babel Loader exposes a utility for building loaders that allows users to customize Babel's configuration for each processed file.

Babel Preset React allows you to write React components using JSX and other modern JavaScript features while still being able to run your code in older browsers or other environments that may not support these features out of the box.

Babel Preset Env allows you to use the latest JavaScript without needing to micromanage which syntax transforms (and optionally, browser polyfills) are needed by your target environment(s).

Install html-webpack-plugin package

npm install --save-dev html-webpack-plugin

HTML Webpack Plugin is added to simplify the creation of HTML files to serve your webpack bundles.

Configure webpack by adding required files

Create a directory src, add a file with the name index.js and add the below code in it.

import React from 'react';
import App from './App';
import { createRoot } from 'react-dom/client';
const container = document.getElementById('root');
const root = createRoot(container);
root.render(
  <React.StrictMode>
      <App/>
  </React.StrictMode>,
);

No need to worry about the above code and what it does.

Add App.js with below code

import React from 'react';

const App = () => <div>App</div>;

export default App;

Create a file of index.html inside the folder src

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <title>React App</title>
  </head>
  <body>
    <noscript>You need to enable JavaScript to run this app.</noscript>
    <div id="root"></div>
  </body>
</html>

Create a webpack configuration file name as webpack.config.js.

const path = require('path');
const HtmlWebpackPlugin = require('html-webpack-plugin');

module.exports = {
  entry: path.join(__dirname, "src", "index.js"),
  output: {
    path: path.resolve(__dirname, "dist"),
  },
  resolve: {
    extensions: ['js', 'jsx', 'ts'],
    alias: {
      '@': path.resolve(__dirname, 'src'),
      '@components': path.resolve(__dirname, 'src/Components'),
      '@config': path.resolve(__dirname, 'src/Config'),
      '@page': path.resolve(__dirname, 'src/Pages'),
      '@routes': path.resolve(__dirname, 'src/Routes'),
      '@services': path.resolve(__dirname, 'src/Services'),
      '@utils': path.resolve(__dirname, 'src/Utils'),
    },
  },
  module: {
    rules: [
        {
            test: /\.svg$/,
            use: ['@svgr/webpack'],
        },
        {
            test: /\.(png|jp(e*)g|svg|gif)$/,
            use: ['file-loader'],
        },
        {
            test: /\.css$/i,
            use: ["style-loader", "css-loader"],
        },
      {
        test: /\.?(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader",
          options: {
            presets: ['@babel/preset-env', '@babel/preset-react']
          }
        }
      },
    ]
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: path.join(__dirname, "src", "index.html"),
    }),
  ],
}

entry: An entry point indicates which module webpack should use to begin building out its internal dependency graph.

output: The output property tells webpack where to emit the bundles it creates and how to name these files.

resolve: A resolver is a library which helps in locating a module by its absolute path.

module: Allows you to preprocess files as they are loaded and since everything is a module in Webpack.

plugins: Plugins can be leveraged to perform a wider range of tasks like bundle optimization, asset management and injection of environment variables.

Replace scripts in package.json Replace the below snippet in package.json with scripts

"scripts": {
  "start": "webpack-dev-server --mode development",
  "build": "webpack --mode production",
},

Build modules and start the dev server

npm run build

Running the above command in the command prompt will create build modules in the output path provided in the webpack config

Note: Regarding `Create React App`😁

This Create React App wraps all the required dependencies like Babel and Webpack for the React project itself so that you can focus on coding the React app only.

Github Link: React Boilerplate