Sidali Assoul

Master Python Asyncio: A Comprehensive Guide

Mon, 20 Apr 2026 00:00:00 GMT

Introduction

If you are not leveraging asynchronous programming, your program is likely wasting most of its time waiting for external I/O-bound operations like network requests or database calls rather than actually processing data or handling user requirements.

In other words, your program is literally wasting time doing nothing rather than switching to another task. Asynchronous programming solves this problem by ensuring the program isn't blocked by I/O-bound tasks, allowing it to switch to other operations instead of staying idle.

In this guide, we will break down how to implement this effectively in your Python projects. By the end of this tutorial, you'll understand:

What "asynchronous" actually means and why it is the key to handling waiting I/O tasks.
How to choose between asyncio, threads, and subprocesses.
The fundamentals of coroutines, including writing your first async code, identifying the "sequential async trap," and understanding how the event loop runs tasks concurrently.
How to use Tasks, an abstraction above coroutines that allows us to schedule and manage concurrent execution.
The Future, the third type of awaitable in Python, and how it represents an eventual result.

So without any further ado let's dive in.

Mastering Asynchronous I/O: How to Handle Waiting Tasks

So what does async even mean? And how exactly does it help in handling I/O-bound computations?

Whatever the programming language, the framework, or the environment, when you hear about async, you should instantly think about I/O-bound tasks.

And by IO-bound tasks I mean literally any computing task where our process/program spends most of its time waiting for data. Think of:

Reading a file from disk.
Fetching data in the network via API calls...
User interaction: Waiting for a user to type something on the keyboard or to click on a button.
And so on.

Let's say you just woke up, prepared a cup of coffee, turned on your machine, and started typing on your keyboard, chuckling and sipping coffee with every keystroke.

You soon find out, however, that your task has a dependency on a teammate. In other words, you cannot proceed until your coworker finishes their task first.

"Okay, good, let's just take a walk in nature until John finishes the task. I'm blocked, after all; I can't do anything." That's what a synchronous program would have said.

But you aren't one. Instead of waiting for your coworker (a.k.a. the external I/O-bound task) to finish their work, you can just proceed asynchronously by switching to another task until they are done.

The same analogy can be applied to our program. If a part of the program is waiting for a record to be written to the database or a file to be saved to the disk, it should not stay idle. Instead, it can leverage that time to switch to other asynchronous tasks, such as fetching data from external APIs.

As you can see, async is not about executing tasks in parallel. It is all about avoiding doing nothing while our program stays idle waiting for an external I/O-bound operation to be completed. It’s about leveraging that wasted time to execute other operations.

How to Choose between Asyncio, Threads and Subprocesses

In software engineering, there is no silver bullet that works for everything and in all cases. That's why we need to make sure that we are employing the right solution for the right use case.

Asyncio, threads and multiprocessing three common ways to speed up a program. Here's what each one mean and where it exactly shines.

Asyncio: As we previously stated, whenever you hear the word "async," think about I/O-bound tasks. If you think that your program will deal with a lot of external systems such as databases, file system operations, or network requests, then asyncio is your best choice.
Threads: Use them for parallel (concurrent if GIL enabled) tasks that share data with minimal CPU use.

Threads are not really parallel in Python because of the Global Interpreter Lock (GIL). Which is a mutex ensuring that only one thread is executing python bytecode at a time
In the latest version of Python, they introduced a free-threaded build, but it's not enabled by default for compatibility reasons.

Multiprocessing: Unlike threads, each process has its own instance of the Python interpreter. This means you can truly utilize 100% of your multi-core processor.

Subprocesses cost more memory as each one has its own memory and instance of the Python interpreter.
But speed and isolation pays for that cost here; a crash in one subprocess won't affect the others.

Your First Async Code

Getting Started

Now that we understand the importance of asynchronous operations, let's write our first async code:

async def main():
    print("Start of main coroutine")

main()

To declare an async function, we use the built-in async keyword; adding async in front of a function transforms it into an async function or what's called a coroutine.

Trying to run the code above will result in printing the following runtime warning:

RuntimeWarning: coroutine 'main' was never awaited

You can notice as well that the main function's code never executes as well. Nothing gets printed except the warning.

Hmm, interesting. Let's try to print what's returned by the async main function


async def main():
    print("Start of main coroutine")

print(main()) # --> <coroutine object main at 0x10711bf40>

We can observe that the async function main returned a coroutine object. From this, we can conclude that when a function is defined with the async keyword, calling it does not execute the code immediately; instead, it returns a coroutine object.

But wait, what's a coroutine object? And how can we "await for it" to avoid the previous warning?

A coroutine object is one of the three awaitable objects in Python: coroutines, tasks, and futures. To await it, we need to import asyncio and wrap the main coroutine call with its run method.

"asyncio" is a built-in Python library, so there is no need to install anything.

import asyncio
async def main():
  print("Start of main coroutine")

asyncio.run(main())

We usually only use the run method at the top level of our code because it does two things: start the async event loop and await the passed coroutine "main."

Awaiting Sequentially: When Async Acts Like Sync

Let's declare another coroutine called fetch, which simulates an I/O-bound task. It stops execution for 2 seconds using the asyncio.sleep method and returns a 200 success code.

As we can't call the fetch coroutine without awaiting it, we need to use the await built-in keyword, which can only be used inside async functions.

So in the main coroutine, await the fetch call and get its result, then print it.


import asyncio
async def fetch():
   await asyncio.sleep(2) # 2 seconds delay, simulates I/O operation.
   return 200

async def main():

  print("Start of main coroutine")
  result = await fetch()
  print("result: {result}")
  
asyncio.run(main())

Output:


Start of main coroutine
result: 200

The main coroutine prints first, the program pauses for 2 seconds, and then the fetch function executes.

Let's now try to call the fetch coroutine three times in main, retrieve the result of each call, and then print them all.


import asyncio
import time

async def fetch():
   await asyncio.sleep(2)
   return 200


async def main():
 
  start_time = time.perf_counter()
  
  print("Start of main coroutine")

  start_time = time.perf_counter()
  result1 = await fetch()
  result2 = await fetch()
  result3 = await fetch()
  end_time = time.perf_counter()
  duration = end_time - start_time
  print(f"The time took {duration} to execute")

  print(f"results: {[result1,result2,result3]}")
  
asyncio.run(main())

Output:

Start of main coroutine
The time took 6.003185832989402 to execute
results: [200,200,200]

There is no performance gain here yet. The fetches are executing one after another. We are essentially waiting for each I/O task to finish before starting the next one, which defeats the purpose of being asynchronous.

In other words, we are not taking advantage of our event loop here.

Sequential (await one by one) — 6 seconds total:

  fetch 1:  |████████████|
  fetch 2:              |████████████|
  fetch 3:                          |████████████|
            0s           2s          4s           6s

With Tasks (concurrent) — 2 seconds total:

  task 1:   |████████████|
  task 2:   |████████████|
  task 3:   |████████████|
            0s           2s

What is the event loop?

Asynchronous execution of our program allows us to leverage the wasted waiting time of I/O-bound operations by switching from one blocked task to another until all tasks are executed. But how is that achieved in practice by asyncio?

That's where the Event Loop comes in.

The asyncio.run method creates what's called an event loop.


asyncio.run(main())

You can think of the event loop as the orchestrator that tracks all the async coroutines. And Here's how it works in practice:

Execution Start: When you call "asyncio.run(main())," the event loop starts and maintains a list of all the tasks that need to be executed. At any given moment, the loop is running exactly one task.
The Yield Point: The loop executes a task until it hits an "await," which is a signal that means that the task is waiting for an external I/O operation.
The Switch & Resume: Instead of waiting, the loop immediately switches to another ready task. It keeps track of the "waiting" tasks in the background and resumes them exactly where they left off the moment their I/O operation is finished.

 time ─────────────────────────────────────────────►

 Task 1  [runs]──► await ···················► [resume]──► done
                     │                             ▲
                     ▼                             │
 Task 2           [runs]──► await ············► [resume]──► done
                               │                    ▲
                               ▼                    │
 Task 3                     [runs]──► await ·····► [resume]──► done

         ◄──────────────── ~2 seconds ─────────────►

Scheduling Coroutines: An Introduction to Tasks

Creating Tasks manually

By default, asyncio does not schedule coroutines in the event loop; we need to wrap each coroutine object in a Task. Once wrapped, the event loop manages its execution immediately, allowing the program to switch between tasks while waiting for I/O operations.

  fetch()                       asyncio.create_task(fetch())
     │                                     │
     ▼                                     ▼
┌──────────────┐               ┌─────────────────────┐
│  coroutine   │               │        Task         │
│   object     │ ──wraps────►  │    (scheduled ✓)    │
│              │               │                     │
│  idle, not   │               │  event loop will    │
│  running ✗   │               │  pick this up       │
└──────────────┘               └─────────────────────┘

Let’s wrap the fetch calls from the previous example into tasks and execute the code:

async def main():
 
  start_time = time.perf_counter()
  
  print("Start of main coroutine")

  start_time = time.perf_counter()
  task1 = asyncio.create_task(fetch())
  task2 = asyncio.create_task(fetch())
  task3 = asyncio.create_task(fetch())
  result1 = await task1
  result2 = await task2
  result3 = await task3
  end_time = time.perf_counter()
  duration = end_time - start_time
  print(f"The time took {duration} to execute")

  print(f"results: {[result1,result2,result3]}")
  
asyncio.run(main())

Output:

Start of main coroutine
The time took 2.001712833996862 to execute
results: [200, 200, 200]

This time, the total execution is only 2 seconds, which matches the duration of the longest-running I/O task.

Since all three tasks are waiting for a sleep I/O operation to complete, the event loop starts with the first one. Once it encounters the await sleep call, it context switches to the second task. It continues this pattern, pausing each task at its respective await point. These I/O operations then progress concurrently in the background, completing the entire batch in just 2 seconds.

The Gather method

Creating tasks manually for each coroutine can be cumbersome sometimes; that's why the "asyncio.gather" method exists.

The "gather" method accepts any number of coroutine objects or "future types" and returns what's known as an "asyncio.Future" type, which is one of the three awaitable types in Python.

More about asyncio.Future later.

async def main():
 
  start_time = time.perf_counter()
  
  print("Start of main coroutine")

  start_time = time.perf_counter()
  results = await asyncio.gather(fetch(),fetch(),fetch())
  end_time = time.perf_counter()
  duration = end_time - start_time
  print(f"The time took {duration} to execute")

  print(f"results: {results}")

Output:

Start of main coroutine
The time took 2.0019387080101296 to execute
results: [200, 200, 200]

Just like before, the execution only takes 2 seconds. This proves that the three "fetch" calls ran concurrently, rather than being blocked by sequential I/O waiting.

By default, asyncio.gather does not stop other tasks if one fails. Even if an exception is raised in one of the tasks, the remaining ones continue running in the background.

To handle these errors gracefully without crashing, you can set return_exceptions=True to treat exceptions as returned values instead of raised errors. You can then iterate through the results and handle both the exceptions and the successfully returned results as needed.

import asyncio

async def fetch_success():
    await asyncio.sleep(1)
    return 200

async def fetch_fail():
    await asyncio.sleep(1)
    raise ValueError(500)

async def main():
    # With return_exceptions=True, the program won't crash
    results = await asyncio.gather(
        fetch_success(), 
        fetch_fail(), 
        return_exceptions=True
    )
    
    for res in results:
        if isinstance(res, Exception):
            print(f"Task failed with: {res}")
        else:
            print(f"Task succeeded with: {res}")

asyncio.run(main())

Output:

Task succeeded with: Success!
Task failed with: 500 (Internal Server Error)

When using **gather,** returning exceptions as values instead of raising them makes error handling much easier. As you can see from the logs, Gather did not stop the first task even though the second one failed.

Task Group

In Python 3.11, TaskGroups were introduced as a safer and more structured way to manage multiple tasks.

The biggest advantage of TaskGroup is what's known as structured concurrency. In other words, if one task in the group fails, the "TaskGroup" automatically cancels all the other ones.

This prevents uncanceled tasks, or "zombie tasks," from wasting resources when running in the background.

async def main():
  tasks = set()
 
  start_time = time.perf_counter()
  
  print("Start of main coroutine")

  start_time = time.perf_counter()
# The context manager ensures all tasks finish before exiting the block
  async with asyncio.TaskGroup() as tg:
      for _ in range(3):
          task = tg.create_task(fetch())
          tasks.add(task)

  end_time = time.perf_counter()
  duration = end_time - start_time
  
  # At this point, TaskGroup guarantees that all tasks have     completed successfully.
  results = [ task.result() for task in tasks]

  print(f"The time took {duration} to execute")

  print(f"results: {results}")
  
asyncio.run(main())

Start of main coroutine
The time took 2.001078375033103 to execute
results: [200, 200, 200]

Note that we are tracking the running tasks in a tasks set. This is done on purpose to prevent the garbage collector from cleaning up our tasks mid-execution.

The "async with" block is a Python feature known as an "async context manager."

It acts as a barrier. The program will not proceed to the results = ... line of code until every task created within that group has either finished successfully or raised an exception if one of them fails.

This replaces the boilerplate code you would otherwise have to write manually to manage task lifecycles when using asyncio.gather.

Bonus Information About Task Group

If multiple tasks fail inside a group, Python does not throw one error, but it throws an "ExceptionGroup." You can handle it using the except* syntax.

import asyncio

async def fail_fetch():
  asyncio.sleep(1) # simulate I/O-bound task
  raise ValueError(500)

async def main():
  try:
    async with asyncio.TaskGroup() as tg:
        tg.create_task(fail_fetch())
        tg.create_task(fail_fetch())
  except* ValueError as eg:
    for e in eg.exceptions:
        print(f"Caught a value error: {e}")

asyncio.run(main())

Output:

Caught a value error: 500
Caught a value error: 500

Future

Now that we have covered coroutines and tasks, let’s look at the third type of awaitable: the Future.

While you rarely use these at the application level, they are essential low-level objects representing a result that hasn't arrived yet. Think of a Future as a "promise" or a placeholder for a value that will be set later.

A Future is often used to bridge the gap between low-level, callback-based code and modern async/await syntax. When you await a future, your code pauses until a value is manually pushed into it, even if the background work that pushed the value continues to run.

  loop.create_future()
          │
          ▼
  ┌──────────────┐    future.set_result(2026)    ┌──────────────────┐
  │   PENDING    │ ───────────────────────────►  │ RESOLVED: 2026   │
  └──────────────┘                               └──────────────────┘
          │                                               │
     await future                                   await future
    (suspends here,                              (returns 2026 instantly,
     yields to loop)                              loop moves on)


import asyncio
import time

async def provide_data(future, value):
    await asyncio.sleep(2)
    # The Future is fulfilled here
    future.set_result(value)
    
    print("Future result set! Doing some background cleanup now...")
    await asyncio.sleep(5) 

async def main():
    start_time = time.perf_counter()

    loop = asyncio.get_running_loop()
    future = loop.create_future()
    
    # Schedule the provider
    asyncio.create_task(provide_data(future, 2026))
    
    # We wait specifically for the result, not the whole task
    result = await future
    print(f"Received the future's result: {result}")
    end_time = time.perf_counter()
    duration = end_time - start_time
    print(f"The program is executed in {duration} seconds")

asyncio.run(main())

In the above example, we are doing the following:

Retrieving the current running event loop and creating a new future object that belongs to it.
We pass the future object along with a value to a provide data coroutine, and then we wrap it inside a task to schedule it in the event loop.
We won't await the task itself, but just the future object that we created.
Inside the data_provider coroutine we pause the execution for 2 seconds using the sleep asyncio method, we set the future result and then we pause the execution again for 5 seconds.

Output:

Future result set! Doing some background cleanup now...
Received the future's result: 2026
The program is executed in 2.0018573330016807 seconds

You can notice that the program took only 2 seconds to execute, it didn't pause for 7 whole second waiting for the whole task to execute, as we just awaited for the future value itself not the whole task

Conclusion

So that's basically all you need to get started with asynchronous programming in Python. We covered coroutines, tasks, future, how the event loop is leveraged to manage and orchestrate concurrent running async jobs with all the necessary nitty-gritty details that you need to get you started.

Despite covering all of that, there is an important thing that we didn't mention yet.

As your application grows and the number of concurrent jobs increases, you may encounter race conditions because they all share the same process memory space.

Race conditions occur when multiple asynchronous tasks attempt to access the same variable simultaneously. Consider a "balance" variable accessed by concurrent debit and credit functions:

The credit function reads the balance as 100.
The debit function reads the balance as 100.
The credit function adds 10, updating the balance to 110.
The debit function subtracts 10 from the original value it read (100), updating the balance to 90.

credit function -> balance: 100, newBalance: 110
debit function  -> balance: 100, newBalance: 90 (Overwrites the credit function's modification!)

As illustrated, the debit function overwrote the credit function's update. This is a classic example of a race condition that leads to data corruption. However, race conditions can be even more severe; certain categories can lead to memory errors that cause the entire process to crash.

Race conditions are typically handled using semaphores and mutexes. In the next article, we will explore asyncio synchronization primitives, including Locks, Semaphores, BoundedSemaphores, Events, Conditions, and Barriers.

React State Snapshots Explained: Why State Values Don't Change During Renders

Wed, 09 Apr 2025 00:00:00 GMT


function App(){
  const [counter,seCounter] =useState(1)
return (
  <div>
    <p>{counter}</p>
    <button onClick={()=>{

      setCounter(counter + 1); 
      setTimeout(() => { 
    console.log(counter);
      }, 5000);

    }}></button>
  </div>
)
}

You may get shocked to know that this code, will not print 2 😮.

Despite incrementing the counter by 1, and then deferring the execution of the console log by 5 seconds using the setTimeout browser API,which means that by the time the console.log is executed the state will have been already incremented by 1.

But reality shows nothing but that, in fact, a 1 gets printed 🤯.

In this article, we will be clarifying what's exactly happening here under the scene while explaining the concept of a state snapshot in React. So without any further ado let's get started.

As you might know, State doesn't live inside the function component but it's stored within the React package itself!.

And provided as a snapshot or in other terms, as a copy of the original state via the useState hook.

In fact, useState is named a hook because **it's hooking into the external state stored in React itself 🤯! **

Components re-renders can be triggered via a state updates. Therefore when a given component re-renders or gets called by React a new snapshot mirroring the latest updated state value is given to it, and then based on that value the whole JSX including the attached event handlers gets re-created again.

So the deferred console.log in the previous code was printing 1, because it was referencing the state snapshot of the first render.

By the time the second render happens, the whole JSX including its corresponding attached event handlers will be re-created again with the new counter state value which will be equal to 2.

Therefore, Every render is associated with:

A state snapshot.
And a JSX code including event handlers.

Similarly, If you re-tried to re-click on the button again the counter state will be incremented to 3.

Then the component will re-render displaying 3 on the UI. After 5 seconds are elapsed 2 will be printed, because as we said previously the event handler was attached to the previous render hence the callback function is referencing the old state snapshot.

In other words, we can briefly say that:

The state that is returned by the useState hook is constant during every render, even if the event handler that is attached to one of the returned JSX elements was executing asynchronously, in the future when many potential renders may have already occurred.

Every render is allocated its own constant state snapshot, that never change before the next render.

All the derived JSX code including event listeners is tied to that specific render.

In more specific words, renders are totally isolated.

Render 1 can never access state snapshots in render 2.

Conclusion

To sum up, you can think of a re-render as a component starting a brand new life with a brand new state snapshot, JSX code and event handlers.

Now, imagine if we try to update the counter state using setCounter setter function two times sequentially. What would be the value of the counter state after the second render?

// counter = 1
setCounter(counter +1)
setCounter(counter +1)
// counter = ??

Well, that's what we are going to discover in the next article, where we introduce React State Batching.

Thank you for your attentive reading and happy coding 🧑‍💻.

React's Three Phases: Complete Guide to Trigger, Render, and Commit

Wed, 02 Apr 2025 00:00:00 GMT

Introduction

Did you know that a React component can re-render while the corresponding displayed UI segment has not been changed?

I know when we say rendering, we instinctively think that something has to be printed on the screen. But that's not necessarily the case for React 🤯.

Why DOM Updates Are Expensive

Updating your application's UI, which is displayed on your browser screen, involves performing a series of operations on the DOM, or the Document Object Model, which is an object representation of the parsed HTML code that is required to display the UI.

If React were updating the DOM every time a component had re-rendered, the number of DOM operations performed could become huge. Therefore, your application's performance would be negatively affected.

Moreover, we shall say that updating the DOM is considered a costly operation in general. Especially if performed too often because of the following reasons:

Browser Reflows

First, DOM operations trigger browser reflows, during which it has to recalculate the layout of the entire page, or a large part of it. For example, when an element gets removed from the DOM, the positions of the other elements need to be recalculated again. The more elements on the page, the more expensive these re-calculations become.

Browser Repainting

Secondly, after reflow, the browser may need to repaint the affected parts of the screen. Repainting involves redrawing elements (borders, shadows, colors, shapes, and so on). Despite being lighter than reflow, it's still not counted as a trivial operation.

DOM Updates are synchronous.

Finally, in addition to reflow and repaint, DOM updates are synchronous, which means that they can block UI interactions and ruin the entire user experience (UX).

Well, fortunately React does not touch the DOM when a component renders. Rendering is nothing more than the process of calling your function component by React, which is way faster than DOM updates.

The Three Phases

Instead of updating the DOM on every render, React is splitting the work into 3 phases: trigger, render, and commit. The DOM updates are deferred to the last phase (the commit phase).

1. Trigger Phase

The trigger phase consists of asking React to render or re-render a specific component.

A render can be triggered by two different reasons:

Initial Render:

Firstly, when the whole component tree gets initially rendered.

As you may know, your app gets initially rendered via the React root element, which is created by the createRoot function that is imported from "react-dom/client."

import { StrictMode } from 'react'
import { createRoot } from 'react-dom/client'
import App from './App.tsx'

const root = createRoot(document.getElementById('root')!);

root.render(
  <StrictMode>
    <App />
  </StrictMode>,
)

The createRoot function receives the wrapper DOM node, where the final rendered HTML that corresponds to your component's tree needs to be injected (root div). And then renders your component tree given the parent App component.

So the first render happens when the React root render method gets initially called.

State Updates:

Secondly, once your component tree has been initially rendered, you can trigger further renders by calling the setter function returned by the useState hook.

Whenever the setter function is called, React queues or schedules a future render. Even if you've called the setter function multiple times, the new state won't be reflected until the next render.

Put differently, using the setter function means just asking React for a future render while mentioning the state changes.

React will take that into consideration and schedule the next render with the new state value. Consequently, it will update the parts of the JSX code that are derived from the new state during the next render.

2. Render Phase

Now let's move into the second phase that comes after triggering a render, which is obviously rendering.

To put it in simple words, rendering is just when React decides to call your function component.

As we saw earlier, a render can be triggered either on app start, during which the root object triggers the initial render of the whole component tree, or on demand when a state gets updated in a specific component.

When a specific component's state changes, all of its direct or indirect children will re-render recursively. In other terms, if the grandpa re-renders, all of the descendant family will get re-rendered sequentially starting from the children to the grandchildren and so on.

Each component in the tree will return the JSX code that corresponds to the UI segment that it is responsible for.

As we saw in the JSX article, despite looking like HTML code, it's just a JavaScript language extension, meaning that it's getting converted into a bunch of objects representing the real HTML DOM nodes.

So during the initial render of the component's tree, React builds a virtual representation of the real DOM as raw JavaScript objects.

When a given component re-renders because of a state update, the component and its descendants will re-render as we saw previously, so the JSX returned by some components may differ compared with the initial re-render.

React will keep track of all the changes that are caused by the re-renders while calculating a minimal number of DOM operations that are needed to move from the previous state (before rendering) to the newest state (after rendering).

3. Commit Phase

After the process of re-rendering, during which React creates a bunch of objects representing the DOM elements and calculates a lot of information regarding the minimal required DOM operations to get from the oldest state to the newest.

React will finally start modifying the DOM during what is called the commit phase.

The commit phase happens in two cases:

Initial rendering: Just after rendering or calling all the components in the tree, React reads the collected information that consists of, remember, the constructed objects representing the DOM nodes. And then uses the DOM API to insert all the nodes inside the wrapping div whose ID is equal to root.

When re-rendering: React will use the information collected during the rendering phase and apply a minimal number of DOM operations in order to make it match the latest rendering output.

So React is smart enough to only change the DOM nodes that have been modified during the previous phase.

Conclusion

By delaying DOM operations to the commit phase and calculating the optimal number of DOM operations after re-rendering.

React manages to achieve great performance while simplifying the process of UI development by taking care of the complex stuff like DOM manipulation and providing you, the user, with a simple and descriptive language that allows you to model the UI as a function of its state using React components.

UI = fn(State)

In the next article, we will be diving more into the concept of state in React.

Thank you for your attentive reading and happy coding.

React useState Hook Tutorial: Complete Guide to Component State Management

Wed, 26 Mar 2025 00:00:00 GMT

Introduction

Modern web applications are highly interactive; users can click on buttons, fill out forms, toggle navbars, play a video, and so on.

Interactivity makes the UI, therefore the React components change as the time wheel rolls by.

When you type on an input field, the wrapper component should keep track of the last typed value.

If you toggle a navbar, it should always stay toggled and never get reset back to its previous state as long as we've never clicked on the toggle button again.

In other words, sometimes a React component needs some kind of local and personal memory to remember what's needed to accomplish its mission.

Understanding Component State

This specific type of memory is called a component's local state, and it's today's article topic. So without any further ado, let's get started.

Building a Counter Component

Let's say that we want to create a basic Counter component that supports incrementation, decrementation, and reset operations.

Or in other words, a React component that renders a count variable while providing buttons for incrementing, decrementing, and resetting that counter.

The count variable is declared locally using the let keyword and then rendered in the JSX via the curly brackets syntax.

function App(){
  let count;

  console.count("UI: Updated");

  return (
    <div>
    <div>Count is {count}</div>
    <div>
      <button onClick={(e)=>{
        count += 1;
        console.log(count)
      }}>Increment</button>

      <button onClick={(e)=>{
        count -= 1;
        console.log(count)
      }}>Decrement</button>

      <button onClick={(e)=>{
        count = 0;
        console.log(count)
      }}>Reset</button>
    </div>
    </div>
  )
}

Each button is attached to an event handler that changes the "count" variable depending on the operation.

Adding one on incrementing, subtracting one on the decrementation, and resetting the variable to zero when the reset button gets clicked.

Now, let's try to increment the "count" while checking the console logs in the inspect window in parallel.

The "count" variable is indeed getting incremented with every click, but the displayed "count" value in the UI is stuck at 0.

In other words, the component is not re-rendering the JSX when we increment the variable.

Notice also that the UI: Updated message got printed two times meaning that the component have only rendered one time. By default React uses Strict mode in development environment for debugging reasons, that's why the message got printed twice. In production environment, Strict mode gets disabled, thus only 1 render will occur.

Come on, how is it even possible to call this framework React if it's not reacting to the "count" variable changes by re-rendering the component and updating the UI?

Well, the reason behind that is that changes to the locally declared "count" variable can't trigger a re-render. Or in other terms, no one is telling React that the "count" variable has changed.

Even if we suppose that changing the "count" variable directly will trigger a component's re-render.

The "count" variable will be stuck at zero.

The reason is when the component's code runs, the "count" variable will be re-declared again and, therefore, re-initialized to zero.

So to summarize all that has been said, we need two built-in mechanisms to make the counter-example work:

Something that tells React that a given state variable has changed, therefore triggering a component's re-render and then updating the UI.
And a way to persist data or state between the component's re-renders so that our "count" variable value will never get reset or lost between re-renders again.

Fortunately React has to react to this and provide a utility function named useState.

Using useState

import {useState} from "react"
function App(){
  const stateTuple = useState()
  const [state, setState] = stateTuple

}

useState can be imported from "react" and used inside any component to declare a local state.

useState returns what is known as a tuple, or in other words, an array of two items, the first being the state variable that persists between re-renders, and the second one being a setter function, "setState," that updates the state while triggering a re-render.

To make this more convenient, we usually use the array destructuring syntax to store the two returned array items in two different variables without a lot of boilerplate code.

import {useState} from "react"
function App(){
  const [state, setState] = useState()
}

The items are usually named variableName followed by setVariableName, but you're free to name them as you prefer.

It's also worth mentioning that useState accepts an argument that consists of the initial value of the state; for example, in our case, we want to declare a state variable named "count" and a corresponding setter function named "setState" while ensuring that the "count" variable defaults to zero.

const [count, setCount] = useState(0)

Let's refactor the event handlers to set the "count" using the "setCount" setter function instead of mutating the variable directly.

function App(){
  import {useState} from 'react';
  const [count, setCount] = useState(0)
  console.count("UI: Updated")

  return (
    <div>
    <div>Count is {count}</div>
    <div>
      <button onClick={()=>{
        setCount(count+1)
      }}>Increment</button>

      <button onClick={()=>{
        setCount(count-1)
      }}>Decrement</button>

      <button onClick={()=>{
        setCount(0)
      }}>Reset</button>
    </div>
    </div>
  )

}

Now, let's try to increment, decrement, and reset the "count."

Unlike the previous example, now the UI is reacting to the count variable updates and changing whenever the count variable gets modified.

Or in other terms, the component re-renders when the "count" variable gets modified with the setter function.

Even though the code inside the component re-runs entirely when re-rendering, the state still gets persisted between all the re-renders.

Hooks Rules

In React, any function starting with "use" is called a hook.

Therefore, useState is one of React's built-in hooks.

In addition to the default hooks that get shipped with react you're free to create your own but that's another topic for another article.

It's true that hooks are ordinary JavaScript functions, but you can't use them everywhere in your JavaScript application.

Any happy marriage implies adhering to a bunch of predefined constraints, and so too does your relationship with React hooks.

The first rule is to always call your React hooks at the top level of your component.

In other words, just after the opening curly braces "{}" of the component's function declaration.

First Rule

Don't even think about using hooks inside loops, conditions, nested functions, try/catch/finally blocks, or JSX markup.

import { useState } from "react"
function App(){
  // Loops ❌

  while(true){ // ❌
    const [counter,setCounter] = useState(0) 
  }

  for(let i=0;i<5;i++){  // ❌

    const [counter,setCounter] = useState(0)
  }
  do{ // ❌

    const [counter,setCounter] = useState(0)
  }while(true)
  
}

import { useState } from "react"

function App(){
  if(true){ // Conditions ❌
    const [counter,setCounter] = useState(0)
  }
}

import { useState } from "react"
function App(){
  // Try Catch blocks
  try{ // Try Catch, Finally blocks ❌
    const [counter,setCounter] = useState(0)   //  Try Catch blocks ❌
  }catch(error){

    const [counter,setCounter] = useState(0) // Try Catch blocks ❌
  }finally{

    const [counter,setCounter] = useState(0) // Try Catch, Finally blocks ❌
  }
}

Instead always use them at the top level of your function component before any early return statement.

import {useState} from "react"
function App(){
      const [counter,setCounter] = useState(0) // ✅

      if(true){ // Early return
        return null
      }

      const [counter,setCounter] = useState(0) // ❌
      
}

Usually, React will let you know when you've broken one of these rules with a detailed error message.

Second Rule

The second rule is to never use hooks in any other place other than a React function component.

Using them in an ordinary function, class, or object will only cause you frustration and trouble.

import {useState} from "react"

function App(){
  const [counter,setCounter] = useState(0) // ✅
}

function add(a,b){

  const [counter,setCounter] = useState(0) // ❌
  return a + b;
}

class Counter{
  const [counter,setCounter] = useState(0) // ❌
}

const calculator = {
  add:(a,b)=>{
  const [counter,setCounter] = useState(0) // ❌
  }
  
}

How State Updates Work

Now let's get back to our previous "counter-example", and break what's happening under the hood slowly.

When we click on the increment button, the click event gets fired; therefore, the event handler will start running.

Inside the event handler's code, the "setCount" function gets called with the current count state value, which is equal to zero plus one, as an argument.

setCount(count + 1) // count=0

Calling the latter triggers a second re-render or tells React, "Hey, some state got updated here; please re-render the component and then update the UI."

Even though the "setCount" function executes on the current render, the "count" state value will remain equal to 0 until the next render.

function App(){
  // First Render

  //...code

  // count = 0

  return (
    <div>
    <div>Count is {count} {/* 0 */}</div>
    <div>
      <button onClick={()=>{
        setCount(count+1) // setCount(0+1)
        // count = 0 , It's scheduled to change on the Second render
      }}>Increment</button>
      {/** ... code */}

    </div>
    </div>
  )

}

In other terms, React queues all the updates of the current render in memory until the next render happens, where the UI will get constructed depending on the new state value.

On the second render, the "count" state will be incremented; therefore, it will be equal to 1, the component will execute from the top to the bottom, returning the JSX with the updated count state value, and finally React will update the real DOM in the user's browser.

function App(){
  // Second Render

  //...code

  // count = 1

  return (
    <div>
    <div>Count is {counter} {/* 1 */}</div>
    <div>
      <button onClick={()=>{
        setCount(count+1) // setCount(1+1)

        // count = 1 , It's scheduled to change on the Third render
      }}>Increment</button>
      {/** ... code */}

    </div>
    </div>
  )

}

Multiple Components and State

Let me ask you a question now. What would you expect if we had called the Counter component two times in the App component? What would happen if we incremented one of them?

function Counter(){
  /*Previous counter code*/
}

function App(){
  return(
    <div>
      <Counter/>  {/* count = 1*/}
      <Counter/>  {/* count = 0 */}
    </div>
  )
}

As we have said, from the beginning the state is private and personal. So incrementing the first counter will only affect the first called component.

Multiple State Variables

Another question that may traverse your mind is, can we use more than one state in a React component?

The answer is absolutely yes, we can do that.

Let's take this "Greeting" component as an example.

function UserGreeting() {
  const [name, setName] = useState('Guest');
  const [showGreeting, setShowGreeting] = useState(true);
  
  return (
    <div>
      {showGreeting && <p>Hello, {name}!</p>}
      <button onClick={() => setName(name === 'Guest' ? 'User' : 'Guest')}>
        Toggle Name
      </button>
      <button onClick={() => setShowGreeting(!showGreeting)}>
        {showGreeting ? 'Hide' : 'Show'} Greeting
      </button>
    </div>
  );
}

Here we are declaring two pieces of state: one holding the name, which can be either "Guest" or "User," and the other one is a boolean named "isGuest" controlling whether to show the greeting message or not.

  const [name, setName] = useState('Guest');
  const [showGreeting, setShowGreeting] = useState(true);

The component conditionally renders a greeting message at the top along with two action buttons at the bottom.

The greeting message is only shown when the "showGreeting" state is set to "true." The message consists of a "p" tag wrapping a "Hello" string and the current name state value.

      {showGreeting && <p>Hello, {name}!</p>}

The first action button is responsible for toggling the name state between "Guest" and "User."

      <button onClick={() => setName(name === 'Guest' ? 'User' : 'Guest')}>
        Toggle Name
      </button>

The second one toggles the "showGreeting" state between true and false.

      <button onClick={() => setShowGreeting(!showGreeting)}>
        {showGreeting ? 'Hide' : 'Show'} Greeting
      </button>

React is smart enough to determine which state variable corresponds to which "useState" call as long as you follow the Law of Hooks.

React is internally relying on the order of useState calls.

With all that being said, we can conclude that using two states or more is a completely viable and easily achievable option in React.

Conclusion

In the next article, we will be diving deeper into how React goes from rendering to displaying the UI on the user's browser screen.

Thank you for your attentive reading and happy coding!

React Event Handlers Tutorial: Complete Guide to onClick and Event Handling

Wed, 19 Mar 2025 00:00:00 GMT

Introduction

A button is meant to be clicked, and when it's clicked, we intrinsically expect something to happen, right?

Well, the thing that will happen is defined by you, the developer, as a JavaScript function doing something; let's say displaying an alert message as an example.

The function whose job is to respond to an event triggered by something like a user interaction such as clicking is called an event handler, and it's a normal JavaScript function declared within the component. This special function can be attached to any JSX element such as buttons, divs, inputs, and so on.

In this article, we will dive deeper into event handlers while exploring important concepts that every developer needs to master, such as:

Passing event handlers between React components.
Event propagation and why understanding it is so important.
And finally, how to stop event propagation and other browser default behaviors when needed.

So if that sounds interesting, let's dive in.

Event Handlers Basics

React makes attaching an event handler to a JSX element really straightforward.

Let's say that we've got a component rendering a button named "click me." Let's define an event handler named "handleClick" as a locally declared function within the component as we've discussed previously.

Usually, the React community follows the naming convention that consists of starting the event handler's name with "handle" followed by the event name. Some examples of that include handleClick, handleHover, handleFocus, and so on.

Now, we just have to assign the event handler (aka our locally declared function) to a special type of prop starting with "on" and then followed by the name of the event, such as onClick, onFocus, onHover, and so on. In our case let's pass it to onClick.

A mistake that's often repeated by most beginners is calling the function instead of just assigning the function name.

function Button(){

function handleClick(){
  alert("Stop Clicking")

}
return (
    <button onClick={handleClick}>Click me</button> {/* ✅ */}
    {/* <button onClick={handleClick()} />Click me </button> ❌ */ }
)
}

Doing so will just make the function run at every single render or component update, which is obviously not our goal here.

The function that is attached to the onClick prop is going to get called. Consequently, the alert message will pop up only when the button gets clicked by the user.

What if our component receives a username prop? Can we access it in the event handler?

function Button({username}){

function handleClick(){
  alert("Hi "+ username)

}
return (
    <button onClick={handleClick}>Click me</button> {/* ✅ */}
)
}

Yes, actually that's one of the advantages of declaring an event handler within the component. Doing so allows the event handler to access its parent's outer scope variables or functions, such as props or any other stuff.

Passing Event Handlers as Props

Okay, now what if you wanted to use the Button component in multiple places?

Declaring "handleClick" inside it makes it impossible to change the button's component's primary behavior, which is reacting to different events differently depending on where it's used. Therefore, it becomes less reusable.

So can we solve this with props? In addition to that, is it even possible to pass functions as props?

Functions are first-class citizens in JavaScript. Consequently, they can be passed to other functions, therefore, React components. So it's obviously possible to do that.

Now let's make our Button component accept a new prop called "onClick," assign it to the button's "onClick" prop, and then declare a handleClick event handler inside the parent component itself. And then pass it to the Button child component.

function Button({username,onClick}){

return (
    <button onClick={onClick}>Click me</button> 
)
}

function App(){

const username = "Sid Ali"

function handleClick(){
  alert("Hi "+ username)

}

  return (
    <div>
    <Button onClick={handleClick} username={username} />
    </div>

  )
}

By convention event handler props are named exactly as the JSX elements built-in events props.

So they should start with on followed by either the event name or the interaction that need to be performed such as onClick, OnUploadFile, onTryingToFindARandomName and so on.

Event Propagation and Bubbling

Now that we've tackled the basics of event handling, let's move on to a very important and interesting concept that is known as event bubbling or propagation.

But before that, let me ask you a simple question.

What will happen if you have clicked on the child component of two nested JSX elements, both having an event attached to their onClick prop? Which component will show its corresponding alert message?

function Parent(){
  return (
    <div onClick={()=>alert("Hello From Parent")}>
      <Child1 />
    </div>
  )
}

function Child(){
  return (
    <button onClick={()=>alert("Hello from Child")}>Click me</button>
  )
}

-> (1) Hello from Child
-> (2) Hello from Parent

The answer, as you may have guessed, is both but in a special order.

The alert message corresponding to the child component will get displayed first, and then the parent will follow after that.

We call what has just happened event propagation or bubbling. We say that the click event has propagated from the child to the parent.

Stopping Event Propagation

If you happen to be bothered by such default behavior, you can stop the propagation by doing as follows:

function Child(){
  return (
    <button onClick={(e)=>{
      e.stopPropagation()
      alert("Hello from Child")}
      }>Click me</button>
  )
}

Every event handler has access to an optional e argument which is a shorthand standing for event. You can use this argument to either read information about the event or perform actions on it.

Among those actions is being able to call the stopPropagation method to prevent the event from bubbling up to its parent.

Alternative to Propagation

To be in total control, you can stop the propagation and rely on passing props to decide whether you want to call the parent event handler or not.

You can achieve that by passing the parent's event handler as a prop and then calling it after stopping the propagation and running some code.

function Parent(){
  function handleClick(){
    alert("Hello From Parent")
  }
  return (
    <div onClick={handleClick}>
      <Child1  onClick={handleClick}/>
    </div>
  )
}

function Child({onClick}){
  return (
    <button onClick={(e)=>{
      e.stopPropagation();

      alert("Hello from Child");
      onClick()

    }}>Click me</button>
  )
}

-> (1) Hello from Child
-> (2) Hello from Parent

Preventing Default Browser Behavior

In addition to propagation, there is another annoying event that you will definitely want to prevent.

When you submit a form, by default the browser refreshes the page, therefore killing your entire React application and probably causing some side effects, like smashing your keyboard from anger when that happens.

function Form(){

  function handleSubmit(e){
    alert("Hello From Form")
  }

  return (
    <form onSubmit={handleSubmit}>
      <button>Submit</button>
    </form>
  )
}

So similarly to what we did to stop the propagation. All you need to do here is to go to the form's onSubmit-attached event handler, make sure to define the event parameter e, and then call the preventDefault method on the e object to prevent the default browser refresh behavior.

function Form(){

  function handleSubmit(e){
    e.preventDefault(); // This line prevents the browser's default behavior ✅
    alert("Hello From Form")
  }

  return (
    <form onSubmit={handleSubmit}>
      <button>Submit</button>
    </form>
  )
}

Conclusion

Events are happening all the time in a highly interactive web application.

But when an event fires, it's usually handled by modifying some components in the React application tree. Think about it: a dropdown changes from toggled to none toggled depending on the number of times that it's clicked, which leads us to a fundamental concept that we haven't discussed yet until now

In the next article of the series, we will finally explore how React reacts and remembers what has happened now and in the past after some series of interactions or events.

Thank you for watching and happy coding!

React Rendering Lists Tutorial: Complete Guide to Map Method and Keys

Wed, 12 Mar 2025 00:00:00 GMT

Introduction

In many situations you'll want to display multiple items that share the same structure and styling based on a collection of predefined data that might come from various sources, including external APIs, offline browser storages such as IndexedDB or LocalStorage, and so on.

Even though the data might come from various sources, it always ends up in a JavaScript array.

So in this article we will learn how to render a list of components or just raw JSX codes given an array of data.

And then we will understand how React can track those rendered components via something called keys. So without any further ado, let's dive in.

Take a look at this code.

<ol>
  <li style={{...}} >Item 1</li>
  <li style={{...}}>Item 2</li>
  ...
  <li style={{...}} >Item N</li>
</ol>

Writing code like this is the fastest way to make your project unmaintainable.

Let's say that you needed to render a list of items that have the same styling and structure but only differ in their content.

Solution: How to Map an Array of Item into JSX Code.

Instead of writing that whole code and repeating ourselves.

We can just define an array of strings that will host all of our data. And then use the array built-in map method to transform each element in the array into a different shape.

This is done by passing a callback function that defines this transformation.

The callback function will be written as follows: we take the function's argument, and then we return this JSX code that represents the targeted markup of each array element.

In our case we want to convert each item in the array from a string to JSX code, which consists of the <li> tags wrapping the string.

function App(){
  const  items = ["item 1","item2","item 3"]
  const JSXItems =  items.map(item=>(<li>{item}</li>))
  // [<li>Item 1</li>,<>Item 2</li>,<>Item 3</li>]

  return (
    /*...code*/
  )
}

Keep in mind, that the map method keeps the original array intact, and returns a new array that we can store in a newly created variable.

How to Render an Array of JSX Codes?

Okay, now what? We've got an array of JSX elements. But how can we render that?

React can only render two things: JSX code or an array of code. We can safely render the content of the new array directly in the JSX through the curly bracket syntax.

The result will look like this.

function App(){
  const  items = ["item 1","item2","item 3"]
  const JSXItems =  items.map(item=>(<li>{item}</li>)) // array of JSX elements.
  // [<li>Item 1</li>,<>Item 2</li>,<>Item 3</li>]

  return (
    <ol>
    {JSXItems}
    </ol>
  )
}

A Richer Example: Rendering an Array of Todos!

Now that we've got the basics, let's deepen our understanding by walking through a more involved example.

Picture this: we have an array of todo objects, each one possessing the following attributes:

An ID that uniquely identifies each object.
A todo name, description and a boolean variable representing whether a given todo is completed or not.

const todos = [
  {
    id: 1,
    name: "todo 1",
    description: "todo 1 description",
    completed: false,
  },
  {
    id: 2,
    name: "todo 2",
    description: "todo 2 description",
    completed: true,
  },
  {
    id: 3,
    name: "todo 3",
    description: "todo 3 description",
    completed: false,
  },
];

Similar to our previous example, we can use the map() array method to transform this array of objects into an array of JSX elements. In this snippet, each element represents the JSX structure for an individual todo item.

const todosJSX =  todos.map(item=>(
      <div>
        <h2>{item.name}</h2>
        <p>{item.description}</p>
        <p>{item.completed ? "✅"  : "❌"}</p>
      </div>
))

Now let's just render the array in the App component's JSX.

function App(){
  // ...code for todos
const todosJSX =  todos.map(item=>(
      <div>
        <h2>{item.name}</h2>
        <p>{item.description}</p>
        <p>{item.completed ? "✅"  : "❌"}</p>
      </div>))
  return (
    <div>
      {todosJSX}
    </div>

  )
}

That's how easy it is to render an array of objects. It's that simple; just map it to JSX elements, and you're good to go 😄.

Now as the JSX returned by the map's callback function is getting quite long and messy, let's substitute it or move it into its own react component

First, create a "TodoItem" component, receiving the necessary props and returning the previous JSX code.

function TodoItem({name,description,completed}){

  return (
      <div>
        <h2>{name}</h2>
        <p>{description}</p>
        <p>{completed ? "✅"  : "❌"}</p>
      </div>
  )
}

Then let's call it in the map's callback function and pass the props by spreading the todo object instead of passing each attribute separately.

function App(){
  // ...code for todos
const todosJSX =  todos.map(todo=>(<TodoItem {...todo}/>))
  return (
    <div>
      {todosJSX}
    </div>

  )
}

As you can see below spreading the todo object makes the component more readable and maintainable.

const todosJSX =  todos.map(todo=>(<TodoItem title={todo.title} description={todo.description} completed={todo.completed} />)) 

// VS
const todosJSX =  todos.map(todo=>(<TodoItem {...todo}/>)) // ✅ Better and more concise

Now our code is much cleaner and easier to read.

How can React track many rendered components?

So what are keys? Why are they so important to React?

When calling the same component twice or rendering an array of components, it's important to pass a unique key to each component.

In fact, if you try to render a list of items without passing the key prop into each one. The following warning gets displayed in your browser console.

⚠️ React Warning: Each child in a list should have a unique "key" prop.

When using the map method to render an array of items, we should always pass a string or a number key prop that uniquely identifies each item among other items in the array.

The keys help React to understand which array item each component corresponds to. Or you can think of it as a way to link your array data to the rendered components or JSX items.

That may seem not important when the array is not changing. But if it gets mutated or changed by either sorting it, deleting or inserting an item, and so on.

React can have a hard time tracking items because, by default, it's using the item's array index as a key, which is obviously not stable when deleting or inserting items or sorting the array.

The keys should also be stable, or in other terms, they should not change every time the component gets rendered in order to optimize updating the DOM tree, and therefore your application's performance when displayed on the user browser.

The easiest way to make sure that the ID is stable is to include it in the data itself, as we did previously when defining the todo list item object.

Right inside the "map's" callback function, let's assign the todo.id attribute to the component's key prop.

const todosJSX =  todos.map(todo=>(<TodoItem key={todo.id} {...todo}/>))

The same thing applies if JSX code was returned; just pass the key prop to the upper wrapping element as shown below.

const todosJSX =  todos.map(item=>(
      <div key={todo.id}>
        <h2>{item.name}</h2>
        <p>{item.description}</p>
        <p>{item.completed ? ✅  : ❌}</p>
      </div>))

An interesting case that we should absolutely highlight here is when returning multiple JSX items, we're required to use the fragment syntax because JSX does not allow returning multiple children, as you might know if you've read the previous JSX article.

If you have tried to set the prop key to the shorthand version of the React fragment syntax, your editor will highlight it as a syntax error. Because that's not allowed.

function Test({id}){

  return (
    <key = {id}> {/* Not allowed ❌*/}
    <h1>Title</h1>
    <div>Random description text</div>
    </>
  )
}

Instead, you're required to use the longer version, which consists of wrapping your returned children with the "React.Fragment" tag.

Then you can pass the key prop as you usually do with any JSX tag or component.

import React from "react"
function Test({id}){

  return (
    <React.Fragment key = {id}> {/*  allowed ✅*/}
    <h1>Title</h1>
    <div>Random description text</div>
    </React.Fragment>
  )
}

Conclusion

So that's how you simply render lists in React: just map your array to JSX code, create new subcomponents as needed, and most importantly, never forget your keys.

We’ve got our keys and our components, and our list is rendering perfectly. But there is one critical detail we’ve skipped.

The user can now see its todos, but what if he wanted to complete a todo? He needs to click on a "complete todo" button, right? Doing so will fire what's known as a browser event.

In the next article we're going to unveil how we can seamlessly respond to those events.

Thank you for your attentive reading, and happy coding 🧑‍💻.

React Conditional Rendering: Complete Guide with If Statements and JSX

Wed, 05 Mar 2025 00:00:00 GMT

Introduction

A React component is a building block that runs JavaScript logic and then returns the UI code in a special HTML-like syntax known as JSX.

Some UI elements like dropdowns, navbars, and so on need to display different things depending on different conditions.

In a React component there are two different ways to conditionally render the UI:

The first one is using if statements directly in the function's body and returning different JSX codes depending on the conditions.
The second approach consists of directly embedding the conditions in the JSX code within curly braces {}.

In this article, we're going to explore both cases and master JSX conditional rendering.

Conditional Rendering with If Statements

With these core concepts in mind, let's look at a practical example where an emoji component receives a "type" input prop that can be either "angry" or "smile."

The corresponding emoji gets rendered depending on the value of "type."

We have two ways to achieve this in React:

Right in the emoji component's body, we can use a branching control flow statement such as an "if" or "switch case" to return the right emoji's JSX code depending on the value of "type."

function Emoji({type}: {type: 'angry' | 'smile'}) {
  if(type === 'angry') {  
    return (
      <div>....</div>
    );
  } else if (type === 'sad') {
    return <div>,....</div>;
  } else {
    console.warn("An invalid type prop was passed to Emoji component");
    return null;
  }
}

function App() {
  return (
    <div style={{display: 'flex', gap: '20px'}}>
      <Emoji type="angry" />
      <Emoji type="sad" />
    </div>
  );
}

And then inside the app component, we can call the component multiple times while passing different values to the "type" prop.

That's nice and all, but imagine if we needed to update the style of one "div." With the current setup, we will have to add the styles to every if statement branch, which is repetitive and inconvenient.

One solution for that is to store the emoji in a shared local variable, and then depending on the type prop value, we assign the corresponding emoji.

After that we can wrap the value stored in the variable in a common shared "div."

function Emoji({type}: {type: 'angry' | 'smile'}) {
  let emoji;
  if(type === 'angry') {
    emoji = "...";
  } else if (type === 'sad') {
    emoji = "...";
  } else {
    console.warn("An invalid type prop was passed to Emoji component");
    return <>Wrong emoji type</>;
  }
  return <div style="">{emoji}</div>;
}

That was conditional rendering in the JavaScript land, let's now explore conditionally displaying elements directly inside the JSX code.

Conditional Rendering in JSX

If anything that you put inside the JSX curly braces syntax should always return an expression, is it possible to embed a condition directly within it?

Well, if you're thinking about an if statement, then the answer is no, because as the name implies, it's a statement. In other words, it does not return anything.

Hopefully, JavaScript has our backs covered with what's known as a ternary operator, which is a short way of representing an if statement that always returns something; it's an expression!

condition ? exprIfTrue : exprIfFalse;

You can read it as: if some condition is true (question mark) return this expression else (colon) return this alternative expression.

For example, let's say that we want to know the user's age category and then store it in a variable; we can use a ternary operator, which reads as follows: If age is greater than or equal to 18, return "adult"; else, return "minor."

const userAgeCategory = age >= 18 ? "adult" : "minor";

Using the ternary operator inside JSX will save us from the burden of creating a shared local variable as we did previously or duplicating the styles everywhere. Therefore, making the component more maintainable.

function Emoji({type}: {type: 'angry' | 'smile'}) {
  return <div style="">{type === 'angry' ? "..." : "..."}</div>;
}

Using the Logical AND Operator

While the ternary operator is great for conditions that switch between returning two values. It can be verbose for hide/display-like conditions. Let me explain.

Let's say that we've got an isUserLoggedIn boolean variable, and we want to display the emojis list only when the user is logged in.

We can easily do that with the ternary operator by displaying the emoji list when the isLoggedIn variable is set to it true and returning null when it's not.

isLoggedIn ? () : null

Setting "null" like that sounds verbose, right? Let's make it more concise by using the "&&" operator to only render the list when the isLoggedIn variable gets evaluated to "true." By default JavaScript ignores the second side of an and operator if the first side is set to "false."

Note that we should only use the && operator when we're absolutely sure that the left hand side of the expression is not a number.

A common mistake is to use a number as the condition, that works for most of the cases because Javascript will automatically convert any type used there into a boolean but if it's of a number type and its value is equal to 0. JavaScript will treat it a "0" string.

To fix that we can either add the negation operator ! two times just before the number or convert the number into a condition by comparing it with another "Number". For example, we can compare the age variable with 18: "age >= 18".

Conclusion

So with conditional rendering, we can make a React component display different things depending on a bunch of conditions. Those conditions are either defined on the "JavaScript Logic" side just before rendering the JSX or are directly embedded in the JSX markup.

While conditional rendering allows us to make decisions about what component should be rendered, they are not sufficient alone to deal with real-world data.

Real-world data often comes in collections of items such as an array of products, customers, and so on. So are the missing constructs that we need to master to avoid repeating ourselves when deleting such cases?

Yes, you guessed it right. In the next article, we're going to learn about another type of control flow statement. The kind that are not meant for making decisions but for not repeating ourselves. Yes, we are talking about loops in React.

Until then, happy coding.

PROPS in React explained.

Wed, 26 Feb 2025 00:00:00 GMT

Introduction

If you want to pass information from a parent component to a child component in React, props are exactly what you're looking for.

As you may know, in React we represent the user interface as components that are nested within each other, forming a tree.

Each component is responsible for its own Markup and logic.

React follows a unidirectional data flow model, meaning that information can only be passed from parent components to child components. In other words, the data only flows in one direction, starting from the top of the tree to the bottom.

Passing Props Between Components

function ChildComponent() {
  return <h1></h1>;
}

function ParentComponent() {
  return (
    <div>
      <ChildComponent />
    </div>
  );
}

Props are the medium that allow us to send data from a parent component to a child component. So how can we possibly do that in code?

Passing props from one component to another is straightforward. And here's how it's done:

Pass the data as attributes, similar to how you would pass normal attributes to an HTML tag element. Here we are passing a content attribute with a value of test.
Now, let's add a props parameter to the child component so that it can access the content attribute that we've passed before.
Finally, make the ChildComponent render the content value within an h1 tag.

function ChildComponent(props) {
  return <h1>{props.content}</h1>;
}

function ParentComponent() {
  return (
    <div>
      <ChildComponent content="test"/>
    </div>
  );

It's also possible to access the content attribute more conveniently using the destructuring syntax.

function ChildComponent({content}) {
  return <h1>{content}</h1>;
}

Unlike normal HTML attributes, props can include any JavaScript value such as: arrays, functions, or even JSX code.

function handleClick(){
console.log("Clicked!")
}
return(

<ChildComponent content="test" arr={[1,2,3]} onClick={handleClick}/>
)

Prop Forwarding and Spread Operator

Okay, now let's say that we have 3 levels of nesting:

A parent component App that renders a component named ChildComponent1 while passing 3 props to it: a title, a description and an image.
On the other hand, The ChildComponent1 renders the content of the title inside an h1 tag and then forwards the description and the image props to a third component named ChildComponent2.

App -{title,img,description}--> ChildComponent1 --{description,image}-> ChildComponent2

This can quickly get cumbersome as the number of forwarded props increases. Moreover, the components become less resistant to changes when we want to forward more props.

So instead of forwarding the props manually like that

We can only destructure the title, and use the spread operator syntax to store the remaining props in an object called restProps.

After that we can pass the rest props to the ChildComponent2 using this syntax <ChildComponent2 {...restProps}/>.

function ParentComponent() {
  return (
    <div>
      <ChildComponent1
        title={"This is a message from component 1"}
        description={"description"}
        image={<img src="...lorem picsum" alt="image alt" />}
      />
    </div>
  );
}

function ChildComponent1({ title, ...restProps }) {
  return (
    <div>
      <h1>{title}</h1>
      <ChildComponent2 {...restProps} />
    </div>
  );
}

function ChildComponent2({ description, image }) {
  return (
    <div>
      {description}
      {image}
    </div>
  );
}

Children Props and Layout Components

Some HTML tags can wrap other elements within them. Can we achieve that with components? Or in other words, is it possible for a parent component to act as the layout that wraps a child component?

To make a component wrap other components or any JSX code, we need to use a special prop called children. And as the name implies, it stores all the JSX code that is wrapped by the component.

function ChildComponent(){
  return (
  <div>I'm a just a child</div>
  )

}
function WrapperComponent({ children }) { // 
---
----- Higher order component
  return (
  <div>
    <h1>I'm the one who wraps...</h1>
    {children}
    <h1>I'm the one who knocks...</h1>
  <div/>
  );
}

function App(){

return (
  <HigherOrderComponent>
    <>
    <ChildComponent/>
    <button>click me</button>
    </>

  </HigherOrderComponent>

)

}

Conclusion

Your React component would be nothing more than a static snippet if it weren't for React props, which make it possible to reuse components in different scenarios.

But what if a component receives anisLoggedIn boolean value prop and needs to show either a Login button or a Logout button depending on that value?

That's where conditional rendering comes in!

In the next article, we will learn how to display different elements depending on specific conditions, using either if statements within the JavaScript logic of the component or a ternary operator inside the Markup itself.

Until then, happy coding 🧑‍💻.

Master JSX in 8 Minutes (Before You Write Your Next React Component) - React Tutorial

Wed, 19 Feb 2025 00:00:00 GMT

Introduction

So what the heck is JSX? And what does it have to do with HTML?

JSX is a syntax extension for JavaScript. Yes, you heard it right: it's an extension of JavaScript not HTML, despite what many people think. This means that JSX is eventually converted into valid JavaScript code 😮.

Under the hood, the conversion is handled by compilers like Babel or SWC. Consequently, the entire component tree representing our App is transformed into JavaScript. These objects are understood by the browser and used by the React runtime to render the final HTML code.

For example, the code below.

function Image() {
  return <img alt="Blog post image" src="https://picsum.photos/500/400" />;
}

function App(){
    return (
        <Image/>
    )
}

...will be converted by Babel or SWC into this:

import { jsx as _jsx } from "react/jsx-runtime";

function Image() {
  return /*#__PURE__*/ _jsx("img", {
    alt: "Blog post image",
    src: "https://picsum.photos/500/400",
  });
}
function App() {
  return /*#__PURE__*/ _jsx(Image, {});
}

The __jsx is imported from the react/jsx-runtime;it's used to build and return the object representing the JSX node.

We use JSX for its conciseness. It's easier to read and write because it closely resembles the final HTML that will be shipped to the user's browser.

In this article, we will walk through everything you need to know about JSX including:

The specific syntax rules that distinguish it from HTML.
How to embed JavaScript using the curly brace syntax.

JSX vs HTML: Key Differences

At first glance, JSX looks like HTML. In reality, its strictness may easily break your code if you're not careful.

So the first rule is simple: just be strict with your tags and you'll be fine

The rule consists of always closing tags, including self-closing ones like <img/> or wrapping tags like <div>s.

function App(){
 return (
   <div> // ✅

   <img> // ❌
   <img/> // ✅

   </div> // ✅
 )
}

In addition to being strict with the tags themselves, JSX also has some special rules regarding their attributes. Instead of kabab-case in HTML, you must use camel case when defining attributes.

<button tab-index={0}> </button>  // Kabab case ❌
<button tabIndex={0}> </button>  // Camel case ✅

Note that JavaScript's reserved keywords are not allowed as attribute names. As an example of that, the class keyword that is used to define classes is not allowed. That's why you need to use className instead.

As bonus information, there is one exception to the above rule, which is attributes that start with either data-* or aria-*.

<div class="..."> </div>  // ❌
<div className="..."> </div> // ✅

Moreover, when declaring a component we also do it in camel case, while making sure that the first character is in uppercase. Bonus: That's actually called Pascal case!

function my_component() {
  /*...*/
} // Snake case ❌
function MyComponent() {
  /*...*/
} // Camel case ✅

Now, let me ask you a question, can a JavaScript function return multiple objects without wrapping them in an array or a parent object?-- No that's a syntax error right?

function invalidFunction() {
  return { key: "sidali" }, { key: "I don't know" }; // ❌
}

function validFunction() {
  return [{ key: "Neovim" }, { key: "Btw" }]; // ✅
}

Using a div as a wrapper can be annoying sometimes, especially when styling elements. Instead, there is a built-in React component that literally does nothing but virtually wrapping its children without even showing in the browser DOM.

You can use it this way. Or more concisely using empty tags <></>

import React from 'react'
function CorrectComponent1(){ // ✅
  return (
    <React.Fragment>
      <h1>Title</h1>
      <div>Description </div>
    </React.Fragment>
  )

// Or more concisely

function CorrectComponent2(){ // ✅
  return (
    <>
      <h1>Title</h1>
      <div>Description </div>
    </>
  )

Using JavaScript in JSX

Sure we can perform any kind of JavaScript logic in the function's body before returning the JSX including if statements, for loops and so on.

But is there a built-in way to use JavaScript or reference a JavaScript value or object from within the JSX code itself?

Yes, and it's pretty simple; just use the curly bracket syntax {} and then reference any variable, value, function call, or any expression from the JavaScript world 🌎.

Rather than hardcoding the title value in the Markup here, we can store the h1 tag's inner content in a JavaScript variable as a string.

And then reference it in the Markup, using the curly bracket syntax like this.

function App(){
  const title = "This is my first react component";

  return (
    <div>
      <h1>{title}</h1>
      <ol>
        <li>Wake up</li>
        <li>Code</li>
        <li>Eat</li>
        <li>Sleep</li>
        <li>Repeat</li>
      </ol>
    </div>
  );
}

Think of the curly braces as a return statement. Anything that returns a string or JSX code can be used inside them.

Including functions.

function App(){
  const title = "This is my first react component";
  const createTitle = (title) => <h1>{title}</h1>;

  return (
    <div>
      {createTitle(title)}
      <ol>
        <li>Wake up</li>
        <li>Code</li>
        <li>Eat</li>
        <li>Sleep</li>
        <li>Repeat</li>
      </ol>
    </div>
  );
}

And variables.

const var1 = <h1>This is my first react component</h1>;
const var2 = (
  <div>
    {var1}
    <ol>
      <li>Wake up</li>
      <li>Code</li>
      <li>Eat</li>
      <li>Sleep</li>
      <li>Repeat</li>
    </ol>
  </div>
);

Beware of using if statements or loops inside the JSX. Only values, variables and expressions are allowed!

return (
if(true){   ❌



}else{

}

for (){}  ❌

while(){} ❌


)

Is it possible to reference attributes and styles?

All attributes except style can be set to strings, using the curly braces syntax.

function App(){

      const className = "cool-div"

    return(
    <>
      <div className={className}></div>
      </>
    )
}

In standard HTML we set the style attribute as a string that looks like this;

<div style="background-color:black; color:pink"/>

But things are a bit different, in the JSX realm.

We need to pass an object, that includes your CSS properties and values as key-value pairs. Such as the keys are written in camel case instead of kabab-case.

/* CSS kebab-case */
background-color: black;
color: pink;

function App(){

    const style = {
      backgroundColor: 'black',
      color: "pink"
    };

    return(
      <div style={style}/>
    )
}

Often people get tripped up by these double curly braces {{}}. They think that it's a special JSX syntax. But it's actually just a regular JavaScript object being passed inside the curly brackets.

<img style={{ backgroundColor: "red" }} />

function App() {
  const styleObj = { backgroundColor: "red" };

  return (
    <img style={styleObj} /> // Instead of style={{backgroundColor:'red'}}
  );
}

Congratulations! You've just earned a new badge: JSX Syntax Wizard! Now that you learned how the JSX magic works under the hood and gone through its spell book. You're officially ready to write clean, error-free React components.

Conclusion

But here's the catch: a Button component is practically useless if you can't reuse it with different titles, Right?

We need some sort of mechanism that allows us to pass data to a React component in order to make it generic and reusable.

In other words, we need to be able to pass a title argument to the Button component!

That's exactly what we are going to explore in the next article: we will learn about component arguments, also known as Props.

Until then... happy coding.

Creating Your First React Component is EASY

Wed, 12 Feb 2025 00:00:00 GMT

Introduction

Before creating your first component, you need a project, right? And honestly, what's better than a single command to do so, thanks to Vite CLI?

pnpm create vite@latest
# Or
npm create vite@latest

Going through the installation wizard steps should be straightforward, but if this is your first time exploring the React or the Node.js world, I highly advise you to check out the previous article in the series.

hello-world/
├── public/
│   └── vite.svg
├── src/
│   ├── App.css
│   ├── App.tsx
│   ├── index.css
│   ├── main.tsx
│   └── assets/
│       └── react.svg
├── node_modules/
│   └── ...
├── .gitignore
├── index.html
├── package.json
├── tsconfig.json
└── vite.config.ts

In this article, you'll learn all you need to know about creating React components.

Without any further ado let's dive in.

Creating Your First React Component

Now that we've initialized our Vite project, let's jump over to the App.tsx file, located within the src directory.

Once you've done so, you'll notice that Vite comes with a predefined counter-example.

As you can see, a React component is just a simple JavaScript function that starts with a capital letter and returns a code that looks just like HTML.

function App() {
  const [count, setCount] = useState(0);
  return (
    <>
      {/** more code here ... */}
      <div className="card">
        <button onClick={() => setCount((count) => count + 1)}>
          count is {count}
        </button>
      </div>
      {/** more code here ... */}
    </>
  );
}

Simplifying the App Component

Let's simplify this code by deleting everything inside the App function and making it return a simple container div that wraps an h1 header and an unordered list ol with a few random list elements li.

function App(){
  return (
    <div>
      <h1>This is my first react component</h1>
      <ol>
        <li>Wake up</li>
        <li>Code</li>
        <li>Eat</li>
        <li>Sleep</li>
        <li>Repeat</li>
      </ol>
    </div>
  );
}

Creating a New Image Component

When implementing UI interfaces in React code, we tend to mentally break it into many components. So how can we create another component that renders a random image and then reuse it inside the App component?

As we said before, it's a matter of wrapping your HTML in a function.

Let's place it just above the App component. The component returns an img HTML tag with the following attributes:

An alt attribute to support screen readers.
And an src attribute that we will set equal to a URL generated by Lorem Picsum. -- It's a website where you can get a URL that loads a random image every time the page gets refreshed.

function Image(){
  return <img alt="Blog post image" src="https://picsum.photos/500/400" />;
}

We didn't have to use the parentheses in the Image component because the returned code is only written in a single line, in contrast with the App component where we had to use parentheses because the code spanned more than one line.

Using the Image Component in App

Next, let's use it in App. We can call it as we call a normal function inside of the returned HTML, but there is a more optimized way to do it, which is using this tag syntax <Image/>.

function Image() {
  return <img alt="Blog post image" src="https://picsum.photos/500/400" />;
}
function App() {
  return (
    <div>
      <h1>This is my first react component</h1>
      <Image />
      <ol>
        <li>Wake up</li>
        <li>Code</li>
        <li>Eat</li>
        <li>Sleep</li>
        <li>Repeat</li>
      </ol>
    </div>
  );
}

Running the Development Server

The code is ready; all that remains is to start the development server by running the following:

pnpm run dev
# or
npm run dev

Subsequently, we need to head into http://localhost:5173 and inspect the page.

React injects the final HTML into a div known as the root div.

As you can see, the HTML that is returned by the App component and its child Image component got merged together and then injected inside the root div.

Organizing Components into Separate Files

While this works for a small demo, in a real web application, defining all the components in a single app is neither practical nor scalable.

So let's create a image.tsx file at the same directory level as app.tsx, then just copy the Image function declaration into its own dedicated file.

Every file in Javascript is considered its own closed module. So anything that is declared there is not accessible unless we explicitly export it.

Exporting Components

There are two ways to export our component:

We can add the export keyword next to it, and then import it in app.tsx like this:

image.tsx file:

export Image;

app.tsx file:

import { Image } from "./image.tsx";

This approach is called normal exporting; a file can have many normal exports.

import {C1, C2 , C3} from "file.tsx"

We can also add the default keyword before the function name when exporting it to indicate that this component is a default export for the image.tsx file.

image.tsx file:

export default Image;

app.tsx file:

import Image from "./image.tsx";

As the name implies, a file can only have a single default export.

Bonus Performance Information

Before moving on, there is one common mistake that can silently kill your app's performance: never declare a component inside another component.

Doing this forces React to treat the inner component as "brand new" on every single update. This destroys any chance of caching or optimization, leading to potential performance issues.

export function App(){
  // ❌
  function SubComponent(){
    return (
      <div>{/* code... */}</div>
    )
  }
  return ( /*code...*/);
}

HTML Files can get really big, and just making sure that tags are closing properly is honestly a big drag.

React takes a modular approach by dividing the problem of building complex interactive web pages into smaller sub-problems or building blocks known as components.

Conclusion

But there's an important point that we avoided talking about during this article.

Can you guess? -- Yes, that's right; we kept saying "HTML-like code." But we never explained why.

Well, because that's not HTML code; it's actually a syntax extension of JavaScript, and it's called JSX!

In the next article of the series, we will reveal more secrets 🤫 about this mystery. Until then, happy coding.

Just Created Your React Project? Don't PANIC, here's every file explained

Wed, 29 Jan 2025 00:00:00 GMT

You just created your first React project. Hopefully using Vite

npm create vite@latest

But you stumbled upon a bunch of weird files and folders.

So you started clicking around, trying to connect the dots, but the more files you opened, the more lost you felt.

We're going to break down every single file, one by one, while building a mental map of how they connect.

Project Structure Overview

At first glance we can see:

Three main folders src, public and node_modules.
Various config files that we can edit to customize our project.

hello-world/
├── public/
│   └── vite.svg
├── src/
│   ├── App.css
│   ├── App.tsx
│   ├── index.css
│   ├── main.tsx
│   └── assets/
│       └── react.svg
├── node_modules/
│   └── ...
├── .gitignore
├── index.html
├── package.json
├── tsconfig.json
└── vite.config.ts

Configuration Files

.gitignore

The .gitignore configuration file is used to tell Git which files and directories should be ignored when staging or committing your changes.

# All the directories or files listed below will be ignored by git
node_modules
dist
dist-ssr
*.local

package.json

So what about the package.json file?

Picture it this way: it's like a library's index: it lists all the top-level dependencies of the project.

As any package that you install may also have its own dependencies, which are known as peer or transitive dependencies

A .lock file is constantly managed and updated by your chosen package manager.

In fact, it's automatically updated every time you install dependencies by running either

npm install

npm install <package-name>

{
  "name": "hello-world",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview"
  },
  "devDependencies": {
    "typescript": "~5.8.3",
    "vite": "^6.3.5"
  }
}

In addition to listing top-level dependencies, the package.json file also exposes scripts, which are commands that you can run on the terminal, such as:

npm run dev which starts the development server
npm run build which generates the production-ready bundle.

node_modules

So if the package.json file only lists the top-level dependencies, and the .lock file stores their corresponding transitive or peer dependencies. Where does the actual code of the packages actually live?

That's where the node_modules folder comes in!

Think of it as the actual incubator of those dependencies.

All the third-party packages's codes reside there.

It's also known as the black hole folder in Javascript's memes literature because it simply takes a lot of disk space.

So always double-check that it's present in your .gitignore file, because you definitely don't want to push that to GitHub.

TypeScript Configuration

Now that we escaped the black hole, let's walk through these TypeScript configuration files.

hello-world/
├── public/
├── src/
├── node_modules/
├── tsconfig.app.json
├── tsconfig.json
└── tsconfig.node.json

Each one of these files helps you to customize the TypeScript type-checking experience according to your preferences: Think of these files as the environment-specific rules of the type-checking experience offered by TypeScript.

tsconfig.app.json sets the rules for your Frontend or React code.
tsconfig.node.json sets the rules for the Backend side or the logic that runs exclusively on the server.
tsconfig.json is the parent file that is read first by the ts-compiler; it holds references to the other two files.

Vite Configuration

vite.config.ts

We've already customized Git, TypeScript, and npm. But what about our engine, Vite?

That's where the vite.config.ts file enters the game.

The file simply exports a defineConfig function, which receives a configuration object we can use to fine-tune how Vite operates.

Since Vite works with most modern frameworks, we need to pass it the React SWC plugin to ensure the build process is compatible with React.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react-swc";

// https://vite.dev/config/
export default defineConfig({
  plugins: [react()],
});

Application Entry Point

index.html

React is just Javascript, and as you may know, Javascript can't exist in the browser without HTML. Similarly to how an athlete can't move his body without its bones.

index.html file is the entry point of the application, it defines the main HTML layout or template of all the pages that are served.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/vite.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite + TS</title>
  </head>
  <body>
    <div id="root"></div>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

Inside the <head/> tag we reference the /vite.svg file as a favicon. If you look closely, you'll see that it's located within the public folder.

Any static asset (such as an image or video) stored there is publicly served. You can reference those assets from anywhere in your code using a leading slash (/) followed by the path relative to the public folder.

Source Code Directory

The body of the index.html contains a script tag that imports the main.tsx file located within the src directory.

The src folder

The src folder holds all of our application's Typescript code including React components, their corresponding stylesheets and other logic.

main.tsx - The React Entry Point

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./index.css";
import App from "./App.tsx";

const divDomNode = document.getElementById("root")!
createRoot(divDomNode).render(
  <StrictMode>
    <App />
  </StrictMode>,
);

So where does all the Javascript action happen? It's main.tsx. React literally binds itself to the index.html here.

Inside the main.tsx file, we retrieve the DOM element of the div with the id of root using the document.getElementById('') method.

  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.tsx"></script>
  </body>

The element is passed to the createRoot, a function imported from react-dom/client. The function call returns the application's root object.

const divDomNode = document.getElementById("root")!
const applicationRootObject = createRoot(divDomNode)
 applicationRootObject.render(
  <StrictMode>
    <App />
  </StrictMode>,
);

After that, we make use of the render method of the root object to display the <App/> component -- Where an example counter component code resides.

Instead of passing <App/> directly to the render method, we wrap it in a StrictMode component because it makes catching bugs easier in dev mode.

Development Server and Testing

Now that we explained briefly, how React wires itself and injects the Counter example code defined inside the <App/> component inside the <div/> with the id of root. Let's start our app to see it happening!

Let's open our terminal, type npm or pnpm run dev in order to start the development server, open your browser, and then head straight to http://localhost:5173.

Once you've done so, you'll stumble upon this page.

Now, in order to confirm that the main.tsx file is really injecting the <App/> component inside the div with the id of root. Let's inspect the page.

Great! All the Counter's HTML code is here. And it gets even better the Html is updating whenever we increment the counter. React is indeed Reacting, and we are reacting to it! Isn't that crazy?

Conclusion

There is one missing piece that we didn't cover yet in this article.

Despite going through the project's files and folders and explaining how React injects the <App/> component into the <div/>, we haven't yet discussed what a React component actually is. We still need to explore how components are defined and why they are considered the fundamental building blocks of any React application that you can see out there.

Stick around for the next article, where we will address these topics in depth. Until then, Happy coding!

Creating A React App in 2026 is EASY with Vite

Wed, 15 Jan 2025 00:00:00 GMT

Introduction

Getting started with React is no longer as complicated as it was before.

In this video, we will learn about the fastest way to bootstrap a modern React project.

No, we are not going to use the deprecated CRA or create-react-app that has been causing pain for developers for centuries.

But we will employ something called Vite, which means blazingly fast in French.

Prerequisites

So what's the only thing that stands between you and your first React app? You need a runtime that lets you run Javascript outside the browser -- Node.js.

Start by heading to the official Node.js website, hit the Get Node.js button, and pick your operating system, then either copy and paste the shown commands to your terminal or download the corresponding binary.

After running the command or downloading the binary, let's confirm that it's indeed installed by opening our terminal, and typing

node --version

If a message that looks like this appears after running the command, then congratulations, Node.js is successfully installed.

Setting Up Vite

Now, that Node.js is ready, one command is all it takes to get your entire React project up and running.

Head over to the Vite website, hit get started, and scroll down until you find this command.

This command creates your project boilerplate and installs both Vite and React for you. Vite itself mainly handles two things:

It serves your code during development while offering features such as Hot reload.
It bundles your JavaScript, HTML and other assets together when you're ready for production.

Node.js comes with npm out of the box – a package manager that installs your project dependencies. But I personally use pnpm instead, and here's why it's better:

It caches your dependencies globally.
It reuses them across projects.

That makes everything way faster and more economical, especially if you use mobile data.

npm create vite@latest

So you can either copy this npm command and run it straight away or install pnpm globally:

npm install -g pnpm

In case you've gone the pnpm path and installed it globally, you just have to replace npm with pnpm in the previous command.

pnpm create vite@latest

Project Configuration

Now that we've run the command, Vite-cli is going to walk you through a quick setup.

Let's go with hello-world as a project name.

Since we are building a React app, let's select React.

Now it's asking us to choose between JavaScript or TypeScript. Honestly, I prefer TypeScript because its static typing improves IDE autocompletions and makes the developer experience much smoother.

You might be wondering about what SWC even is. It's a blazingly fast compiler that will speed up your development experience by almost 20X. Nobody hates speed, so let's select Typescript + SWC and hit enter.

Let's just skip the two remaining options.

Installing Dependencies

The moment you hit enter, Vite-Cli creates your project.

As soon as it's done, navigate to it by typing cd hello-world.

After that, install the dependencies by running "npm install" or "pnpm install".

npm install
# Or
pnpm install

Running The Development Server

Once the installation is done, let's run the following command.

pnpm run dev

The latter will start the development server on http://localhost:5173.

Just click on this URL while holding Ctrl or just copy-paste it into the browser.

Finally, your project is ready.

Open it using your preferred IDE, go into the App.tsx file located within the src folder, change something there, and voilà, the change is reflected instantly on the web page.

Conclusion

So this is all it takes to get your project up and running with VITE, LITERALLY, one single command!

But looking at this file tree might be a source of anxiety, right?

So instead of blowing everything, we must understand the generated boilerplate code.

In the next article of the series, we are going to explore every file and folder of this intimidating Halloween tree.

Until then... happy coding!