DEV Community: Kathirvel S

Mastering useReducer in React — The Hook That Simplifies Complex State

Kathirvel S — Tue, 12 May 2026 15:16:44 +0000

From Simple State to Scalable Logic

Welcome back to another episode of “Let’s Master React Hooks Together”.

React always feels easy at the beginning.

You learn components.
You learn props.
You learn useState.

Everything feels smooth.

But then real applications arrive.

And suddenly state logic starts growing fast:

multiple form fields
loading states
error handling
API responses
step-based flows
conditional updates

And your component slowly becomes harder to manage.

This is where most developers get stuck.

Because useState works perfectly… until it doesn’t.

That’s where useReducer enters.

Not as a replacement.

But as a way to bring structure when state starts becoming complex.

In This Episode, You’ll Learn

What useReducer actually is
How state flows through it
How actions connect everything
How dispatch triggers updates
Real-world patterns
Multi-step form logic
When to use it and when not to

And most importantly…

You’ll see how scattered state turns into a clean, predictable flow.

What is useReducer in React?

At its core, useReducer follows one simple idea:

Instead of changing state directly, you describe what happened, and React figures out how the state should change.

That movement always follows the same path:

Action → Reducer → New State

Each part has a role:

Action carries the event
Reducer decides the change
State stores the result

Why This Pattern Exists

Think about a login screen.

You are dealing with multiple values:

email
password
loading
error
success

If each one is handled separately, updates happen in different places, and logic becomes scattered.

Over time, it becomes harder to track how everything connects.

The idea of a reducer is to bring all these changes into one controlled place where every update follows the same path.

The Foundation

Everything starts with this line:

const [state, dispatch] = useReducer(reducer, initialState)

This creates a connection between three things:

state → holds current values
dispatch → sends a signal
reducer → decides what happens next

Nothing changes yet — this only sets up the system.

State Begins the Journey

Now imagine state starting like this:

{
  count: 0
}

This becomes the single source of truth.

Every change in the future will create a new version of this structure instead of modifying it directly.

That’s why React can reliably update the UI — because every update is a fresh object.

Dispatch Starts Everything

Now something happens in the UI.

Instead of changing state directly, a message is sent:

dispatch({ type: "increment" })

At this point, nothing has changed yet.

This is just an instruction saying:

“something happened”.

That instruction now moves to the central decision point.

The Decision Point

Everything reaches this function:

function reducer(state, action) {
  switch (action.type) {

    case "increment":
      return {
        count: state.count + 1
      }

    case "decrement":
      return {
        count: state.count - 1
      }

    default:
      return state
  }
}

Now break this flow mentally:

state gives current value
action tells what happened
switch chooses the path

Each path creates a new version of state.

Nothing is modified directly — everything is replaced with a new result.

Connecting It All in a Component

Now everything comes together:

const initialState = {
  count: 0
}

This sets the starting point.

Now the reducer defines how this value will change over time:

function reducer(state, action) {
  switch (action.type) {

    case "increment":
      return { count: state.count + 1 }

    case "decrement":
      return { count: state.count - 1 }

    default:
      return state
  }
}

Now the component connects everything:

function Counter() {

  const [state, dispatch] = useReducer(reducer, initialState)

  return (
    <div>

      <h1>{state.count}</h1>

      <button onClick={() =>
        dispatch({ type: "increment" })
      }>
        +
      </button>

      <button onClick={() =>
        dispatch({ type: "decrement" })
      }>
        -
      </button>

    </div>
  )
}

Now follow the full loop:

User clicks button → dispatch sends action → reducer receives it → state updates → UI re-renders

Everything stays inside one predictable cycle.

Actions Carry Intent

An action is always simple:

dispatch({
  type: "increment"
})

It does not change anything directly.

It only describes what happened so the reducer can decide what to do.

When Data Is Needed

Sometimes actions carry extra information:

dispatch({
  type: "ADD_USER",
  payload: {
    name: "John"
  }
})

Now the reducer uses that data:

case "ADD_USER":
  return {
    users: [...state.users, action.payload]
  }

Now the same pattern continues:

event → action → reducer → new state

Real Flow — Multi-Step Form

Now this pattern expands into real applications.

A form usually has multiple connected parts:

step tracking
form data
validation errors

So everything is grouped together:

const initialState = {
  step: 1,

  formData: {
    name: "",
    email: ""
  },

  errors: {}
}

Now every change must respect this structure.

Updating Form Fields

Instead of writing separate logic for each input, everything flows through one pattern:

function reducer(state, action) {
  switch (action.type) {

    case "UPDATE_FIELD":
      return {
        ...state,
        formData: {
          ...state.formData,
          [action.field]: action.value
        }
      }

    case "NEXT_STEP":
      return {
        ...state,
        step: state.step + 1
      }

    default:
      return state
  }
}

Now focus on the flow:

existing state is copied
only one field inside formData changes
everything else stays intact

That’s how structure is preserved.

Input Connection

Each input follows the same path:

onChange={(e) =>
  dispatch({
    type: "UPDATE_FIELD",
    field: "name",
    value: e.target.value
  })
}

Now every keystroke follows the same cycle:

user input → dispatch → reducer → state update → UI refresh

No duplication. No scattered logic.

When It Makes Sense

This approach becomes useful when:

state starts interacting with other state
updates depend on previous values
logic becomes harder to manage
component starts growing fast

When It Doesn’t

If state is simple and isolated:

const [open, setOpen] = useState(false)

there is no need for extra structure.

The Core Idea

Simple state changes are independent.

Reducer-based state changes are structured flows.

That difference becomes important as applications scale.

Why Developers Prefer It

Because it naturally brings:

predictable updates
centralized control
scalable structure
clean separation of logic
easier debugging

Redux Connection

This same pattern evolves into Redux:

actions → reducers → dispatch → store updates

So understanding this now builds a strong foundation for larger systems later.

Final Thoughts

At this stage, React is no longer just about writing UI.

It becomes about designing how data moves.

Because the real difference between simple apps and scalable apps is not syntax…

It’s structure.

And useReducer introduces that structure.

Instead of asking:

“How do I change this value?”

You start asking:

“How should this value change over time?”

That shift is what separates writing code from designing applications.

What to Remember

When state starts feeling scattered:

Bring it into one flow.
Let actions describe events.
Let reducers decide outcomes.

That single mindset shift is what levels up your React thinking.

Next Episode

In the next episode of “Let’s Master React Hooks Together”, we’ll explore advanced React patterns that build on this foundation and take your applications closer to production-level architecture.

Stay consistent.

What Building a Quiz Web App Taught Me About React

Kathirvel S — Mon, 11 May 2026 15:30:27 +0000

From Confusion to Confidence — Building My Quiz Web App with React

As part of my React learning journey at Payilagam, this Quiz Web App project was guided by Vijaya Ragavan sir.
This project helped me understand how real React applications work practically instead of only learning concepts theoretically.

What started as a simple quiz application slowly became one of the most exciting and confidence-building projects in my learning journey

Live Project Link

👉 Try My Quiz Web App Here:
[https://react-projects-rjy7.vercel.app/]

The Idea Behind the Project

While learning React, I didn’t want to just watch tutorials and memorize syntax.

I wanted to build something interactive where I could actually apply:

React Hooks
Routing
State Management
Dynamic Rendering
User Interaction

That’s when I started building this Quiz Web App

The application flow is simple and user-friendly:

✅ User enters their name
✅ Quiz starts
✅ Questions appear one by one
✅ User selects answers
✅ Final score gets displayed
✅ User can restart the quiz again

Even though the concept sounds simple, building it taught me many important frontend development concepts.

React Concepts I Used

This single project helped me work with several important React concepts like:

useState
useEffect
useContext
useRef
useNavigate
BrowserRouter
Routing & Navigation
Protected Routes
JSON Data Handling
Conditional Rendering
Event Handling
Dynamic UI Rendering

Instead of learning these concepts separately,
this project helped me understand how everything connects together inside a real application.

Setting Up Routing Using BrowserRouter

The first thing I worked on was setting up routing for the application.

I used:

BrowserRouter
Routes
Route
Navigate

to create separate pages for:

User Page
Quiz Page
Result Page

<BrowserRouter>
  <Routes>
    <Route path='/' element={<User />} />
    <Route path='/quiz' element={<Quiz />} />
    <Route path='/result' element={<Result />} />
  </Routes>
</BrowserRouter>

This made the application feel like a real website instead of a single static page.

When page navigation started working smoothly without reloading the browser, it honestly felt amazing

Designing the User Page

The User page is where the quiz experience begins.

I created a simple and clean interface with:

Input field
Start Quiz button
Auto-focus functionality
Name formatting logic

One small feature I liked was automatically focusing the input box using useRef and useEffect.

useEffect(() => {
  userRef.current.focus()
}, [])

This may look like a small thing,
but it improves user experience and gives a professional feel to the application.

Name Formatting Logic

I also added logic to automatically format the entered user name properly.

Example:

❌ vIjAy rAgAvAn
✅ Vijay Ragavan

const formatted = e.target.value
  .split(" ")
  .map(word =>
    word.charAt(0).toUpperCase() +
    word.slice(1).toLowerCase()
  )
  .join(" ")

While writing this logic, I understood how JavaScript string methods can be used effectively inside React applications.

Understanding useState Through Real Application Logic

This project helped me understand the actual purpose of useState.

I used states for:

Current question
Selected option
User score
User name
Route access permission

const [crntQz, setCrntQz] = useState(0)
const [optChosen, setOptChosen] = useState("")

Whenever the state changes,
React automatically updates the UI.

That real-time re-rendering experience made React much easier to understand for me.

useContext — The Most Important Concept in This Project

Among all the hooks I used,
useContext became the most important one in this project.

Instead of passing props manually through multiple components,
I created a global context:

export const QuizData = createContext()

Using this context, I shared:

User name
Score
Permission state

across all pages easily.

This made the code:
✅ Cleaner
✅ Easier to manage
✅ More organized

Before this project, useContext felt confusing.
But implementing it practically made the concept much clearer.

Protected Route Logic

One feature that made the application feel more realistic was route protection.

I didn’t want users to directly access the /quiz page without entering their name first.

So I added this condition:

<Route
  path='/quiz'
  element={
    userPer ? <Quiz /> : <Navigate to="/" />
  }
/>

If the user tries to open the quiz page directly,
they are automatically redirected back to the home page.

This feature gave the project a more professional feel.

Building the Main Quiz Logic

This was the core part of the project.

I implemented:

Question navigation
Option selection
Next button functionality
Finish button logic
Score calculation
Dynamic rendering

Questions were stored inside a JSON file:

import questions from "../assets/questions.json"

This helped me understand how applications handle external structured data.

Dynamic Rendering Using map()

Instead of manually creating option buttons,
I dynamically rendered them using .map().

["A", "B", "C", "D"].map((opt, index) => (
  <button key={index}>
    {questions[crntQz][`option${opt}`]}
  </button>
))

This was one of the moments where React’s power became very clear to me.

The code became shorter, cleaner, and easier to maintain.

Score Calculation Logic

The application checks whether the selected answer matches the correct answer.

if(optChosen == questions[crntQz].answer ){
   setScore((prev)=>prev+1)
}

Each correct answer increases the score.

Simple logic…
but implementing it successfully gave me a lot of confidence as a beginner developer.

Result Page

After completing the quiz,
users are redirected to the Result page.

The page displays:

User name
Final score
Restart button

<h2>{name}, Your Score is {score} / 5 </h2>

I also added a “Start Quiz Again” button to improve interaction and make the app reusable.

Challenges I Faced

Building this project was exciting,
but there were definitely challenging moments too.

Some issues I faced:

State update confusion
Route navigation problems
Score calculation bugs
Option reset issues
Context-related mistakes
Conditional rendering confusion

Sometimes a very small bug took a long time to solve

But those debugging moments improved my logic-building and problem-solving skills a lot.

What This Project Taught Me

This project taught me much more than just React syntax.

It helped me understand:

How React applications are structured
How hooks work practically
How components communicate
How state controls UI updates
How routing improves user experience
How frontend logic is built step by step

Most importantly,
it taught me that real learning happens while building projects.

Final Thoughts

This Quiz Web App may be a beginner-level project,
but for me, it represents a huge learning milestone.

This was the project where:

React started making sense
Hooks became easier to understand
My coding confidence started growing

And honestly…

Seeing my own application work successfully from start to finish felt incredibly satisfying

If you’re also learning React or web development,
don’t wait until you feel “perfect.”

Start building.
Experiment.
Debug.
Improve.

Because every project teaches something new

The Hidden Reason Python Became the Face of AI

Kathirvel S — Sun, 10 May 2026 08:37:14 +0000

Why Python Is the #1 Language for AI

Welcome back to Sunday Source – I Break It, Then Explain It

This is Episode #2, and today we’re talking about something almost impossible to ignore in tech right now:

Why does almost every AI tool, tutorial, and startup somehow end up using Python?

Seriously.

Chatbots? Python.

Machine learning? Python.

AI automation? Again… Python.

At this point, it almost feels illegal to build AI without it 😅

But here’s the real question:

Why Python?

Why not Java?

Why not C++?

Why not JavaScript?

Is Python actually the most powerful language for artificial intelligence… or is it just the most popular?

In this episode, I’ll break down:

why Python became the default language for AI,
what makes developers love it,
and whether Python truly deserves the crown.

And don’t worry — no boring textbook explanations here.

Let’s break it down.

Why AI Needed a Language Like Python

Artificial intelligence is full of heavy concepts:

Math
Data
Algorithms
Neural networks
Endless experiments

Now imagine doing all that in a language with complicated syntax.

Sounds painful, right?

AI developers need to test ideas quickly. They don’t want to spend hours fixing semicolons or writing 20 extra lines just to print something on the screen.

Python made AI development feel simpler.

Here’s a tiny example.

Python:

print("Hello AI")

Java:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello AI");
    }
}

Be honest…

Which one feels less stressful?

Exactly.

That simplicity matters a LOT in artificial intelligence.

The Biggest Reasons Python Dominates AI

1. Python Is Easy to Read

Python almost looks like normal English.

That means:

Beginners learn faster
Teams collaborate better
Bugs become easier to find
Developers focus more on AI logic instead of syntax

And in AI projects, clarity is everything.

Because trust me — debugging a neural network is already confusing enough.

2. Python Has Powerful AI Libraries

This is probably Python’s biggest superpower.

Instead of building everything from scratch, developers can use powerful libraries.

Some famous ones are:

TensorFlow
PyTorch
NumPy
Pandas
Scikit-learn

These libraries save thousands of hours of work.

For example:

NumPy handles fast mathematical calculations
Pandas works with datasets
TensorFlow helps train deep learning models
PyTorch is loved by AI researchers

Without these tools, AI development would be much slower.

Imagine building a car by first inventing the wheel every single time.

That’s life without libraries.

3. Python Is Perfect for Beginners

Let’s be real.

AI already feels intimidating.

There are terms like:

Transformers
Neural networks
Backpropagation
Gradient descent

Now imagine learning all that while also fighting a difficult programming language.

Python reduces that learning pressure.

That’s why most universities and online courses teach Python for AI first.

It lets beginners focus on understanding AI instead of struggling with syntax.

4. Fast Experimentation Matters in AI

AI is not just coding.

It’s testing ideas constantly.

Sometimes developers train models for hours… only to realize the idea doesn’t work.

Painful? Absolutely.

That’s why fast experimentation matters.

Python helps developers:

Write code quickly
Test models faster
Change ideas easily
Build prototypes rapidly

This is one reason startups LOVE Python.

Speed of development often matters more than raw performance.

Quick Summary

Why is Python the best language for AI?

Simple syntax
Massive AI libraries
Beginner friendly
Huge community
Faster experimentation
Strong machine learning ecosystem

Is Python Actually Fast?

Here’s where things get interesting.

Python itself is actually slower than languages like C++.

Wait… what?

Then why use it for AI?

Because most AI libraries are secretly powered by super-fast languages underneath.

For example:

TensorFlow uses optimized C++ code
PyTorch uses CUDA for GPU acceleration
NumPy runs highly optimized computations internally

So while developers write simple Python code…

The heavy lifting happens behind the scenes using GPUs and faster low-level systems.

Sneaky, right?

Python vs Other Languages for AI

Let’s compare quickly.

Language	Good For	Problem
Python	AI, ML, beginners	Slightly slower
Java	Enterprise systems	More complex syntax
C++	High performance	Harder to learn
JavaScript	Web AI apps	Smaller AI ecosystem

So does this mean other languages are bad?

Not at all.

C++ is amazing for performance-heavy systems.

JavaScript works great for browser AI.

But Python gives the best balance between:

simplicity
power
speed
community support

And that balance changed everything.

Real Companies Using Python for AI

Still wondering if Python in artificial intelligence is truly a big deal?

Some of the world’s biggest companies use it.

Google

Uses Python in machine learning and AI research.

OpenAI

Python plays a major role in AI model development.

Netflix

Uses Python for recommendation systems and data analysis.

And honestly…

When companies handling billions of users trust Python for AI, that says a lot.

The Real Secret Behind Python’s Success

Here’s something people don’t talk about enough.

Python removes friction.

It helps developers turn ideas into experiments quickly.

That changes creativity.

Because when coding feels easier, people build more things.

And AI grows through experimentation.

Maybe Python didn’t win because it was the fastest language.

Maybe it won because it made AI feel accessible to everyone.

That’s powerful.

Before You Scroll away

Python became the #1 language for AI because it made complicated things feel simpler.

It gave developers:

easy syntax
powerful tools
faster workflows
and a huge community ready to help.

And honestly, in a field as complex as artificial intelligence, simplicity becomes a superpower.

Maybe Python didn’t dominate AI because it was the fastest language.

Maybe it won because it removed friction between human ideas and machine learning.

And that changed everything.

That’s it for Episode #2 of Sunday Source – I Break It, Then Explain It

If you enjoyed this breakdown Then the this series doing it's work perfectly

See you next Sunday for another Sunday Source episode.

The Smart Way to Share State —Master useContext in React

Kathirvel S — Thu, 07 May 2026 13:20:40 +0000

The Prop Drilling Problem Every React Developer Hits

Welcome back to Let’s Master React Hooks Together — the series where we learn React Hooks the practical way, like real-world developers actually use them.

In the previous episodes, we explored hooks like useState, useEffect and useNavigate . But now we’re entering a stage where React apps start becoming real applications — with shared state, nested components, themes, authentication, and global UI behavior.

And that’s exactly where developers hit one frustrating problem:

prop drilling.

You create a piece of state in a parent component, but suddenly you’re passing it through 4 or 5 layers of components just so one deeply nested child can use it.

Your component tree starts looking like this:

App → Layout → Header → Navbar → Button

And somewhere deep inside that tree, a button just needs the current theme or logged-in user.

The result?

messy props
unnecessary component coupling
harder maintenance
painful refactoring

React introduced the Context API to solve this problem.

And later, hooks made it dramatically cleaner with useContext.

In this episode, we’ll learn:

what useContext is
why React introduced it
how it works mentally
when to use it
when NOT to use it
performance pitfalls developers often miss

Let’s master it properly.

The Problem: Prop Drilling in React

Imagine you want to pass theme and user data to a deeply nested component.

function App() {
  return <Layout theme="dark" user={user} />;
}

function Layout({ theme, user }) {
  return <Header theme={theme} user={user} />;
}

function Header({ theme, user }) {
  return <Navbar theme={theme} user={user} />;
}

function Navbar({ theme, user }) {
  return <Button theme={theme} user={user} />;
}

Notice the issue?

Layout, Header, and Navbar may not even care about theme or user.

They’re just forwarding props downward.

This creates unnecessary complexity:

components become harder to read
props explode over time
refactoring becomes risky
maintenance gets annoying

Mentally, it looks like this:

App → Layout → Header → Navbar → Button → Theme

As applications grow, this pattern becomes difficult to manage.

React needed a cleaner way for components to access shared data directly.

That’s where Context comes in.

What is Context API?

The Context API is React’s built-in shared state mechanism.

It allows components to access common data without manually passing props through every level.

Think of it like a WiFi router.

Any device inside the network can access the internet without needing a direct cable connection to the source.

Similarly, components inside a Context Provider can access shared data directly.

React Context mainly consists of 3 parts:

1. Create Context

const ThemeContext = createContext();

2. Provider

<ThemeContext.Provider value={theme}>

3. Consumer (`useContext`)

const theme = useContext(ThemeContext);

That’s the core idea.

Simple concept. Massive improvement in component architecture.

What is `useContext`?

useContext is a React Hook that lets a component read data from a Context.

const value = useContext(MyContext);

In simple words:

“Give me the nearest value from this context.”

Before hooks existed, developers used Context.Consumer, which quickly became deeply nested and difficult to read.

Hooks made Context usage much cleaner and more natural.

Slightly Technical Understanding

When React renders a component using useContext, it searches upward through the component tree for the nearest matching Provider.

If the Provider value changes, React re-renders the components consuming that context.

That’s the main mental model.

Real Example: Theme Switching

Let’s build a simple dark/light theme system.

Create Context

import { createContext, useState } from "react";

export const ThemeContext = createContext();

Create Provider

export function ThemeProvider({ children }) {
  const [theme, setTheme] = useState("light");

  const toggleTheme = () => {
    setTheme(prev => (prev === "light" ? "dark" : "light"));
  };

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme }}>
      {children}
    </ThemeContext.Provider>
  );
}

Consume Context

import { useContext } from "react";
import { ThemeContext } from "./ThemeContext";

function Button() {
  const { theme, toggleTheme } = useContext(ThemeContext);

  return (
    <button onClick={toggleTheme}>
      Current theme: {theme}
    </button>
  );
}

Now any component inside ThemeProvider can directly access the theme.

No prop drilling.

No unnecessary intermediary props.

Cleaner architecture.

How `useContext` Works (Mental Model)

Here’s the simplest mental model:

When React sees this:

useContext(ThemeContext)

it walks upward through the component tree searching for:

<ThemeContext.Provider>

The nearest provider wins.

Think of it like searching for the nearest WiFi signal.

If the Provider value changes:

value={newValue}

React re-renders components consuming that context.

That re-render behavior is important for performance.

When to Use `useContext`

useContext works best for shared application-wide state.

Great use cases include:

theme systems
authenticated user data
language switching
sidebar visibility
app settings
cart information

A simple rule:

If many distant components need the same data, Context is usually a good fit.

When NOT to Use `useContext`

This is where many developers misuse Context.

Avoid Frequently Changing State

Examples:

typing inputs
mouse movement
animations
rapidly updating values

Why?

Because every context update can trigger many component re-renders.

Avoid Replacing Local State

If only one component needs the state, useState is usually better.

Not everything belongs in global state.

Overusing Context creates bloated architectures that become difficult to maintain.

Performance Concerns (Important)

Here’s a very common mistake:

<Provider value={{ user, setUser }}>

Why is this problematic?

Because a new object is created on every render.

React compares references, not deep values:

{} !== {}

So all consuming components re-render.

Even if user didn’t actually change.

Better Approach

Memoize the value:

const value = useMemo(() => ({ user, setUser }), [user]);

Another important optimization:

Split Contexts by Concern

Instead of one massive global context:

AppContext

prefer smaller focused contexts:

ThemeContext
AuthContext
LanguageContext

This reduces unnecessary re-renders and improves maintainability.

Best Practices

Keep Context Small

Focused contexts are easier to manage.

Split by Responsibility

Separate auth, theme, language, cart, etc.

Avoid Giant Global Contexts

Large contexts become difficult to debug and optimize.

Keep Provider Values Stable

Memoize objects and functions when necessary.

Use Custom Hooks

Cleaner API:

const theme = useTheme();

instead of repeatedly calling useContext.

Real-World Examples

Authentication System

Store logged-in user data globally so navbar, dashboard, and profile pages can access it instantly.

Theme System

Dark/light mode is one of the best examples of Context usage.

Language Switcher

Allow the entire application to switch languages consistently.

Shopping Cart

E-commerce apps often share cart count and cart items across many components.

Interview Questions (Quick Revision)

What is useContext?

A hook that allows components to consume values from React Context.

What problem does it solve?

Prop drilling.

Does useContext replace Redux?

No. Context helps with shared state, but Redux handles more advanced global state patterns.

Why do consumers re-render?

Because the Provider value changes.

When should you avoid Context?

For fast-changing or highly local component state.

What does “nearest provider wins” mean?

React uses the closest matching Provider above the component in the tree.

Final Summary

In Episode 5 of Let’s Master React Hooks Together, we learned that useContext exists to solve one major React problem:

prop drilling.

It allows components to access shared state directly without passing props through every layer.

Use it for:

themes
authentication
language settings
shared UI state

Avoid it for:

rapidly changing values
highly local state
giant global stores

And most importantly:

Context is powerful, but every update can trigger re-renders.

Use it thoughtfully, keep contexts focused, and your React architecture will stay clean and scalable.

In the next episode of Let’s Master React Hooks Together, we’ll explore one of React’s most misunderstood hooks:

`useRef` — how React remembers values without causing re-renders.

Stop Using Links the Wrong Way — Master useNavigate in React

Kathirvel S — Wed, 06 May 2026 14:43:20 +0000

Hey… welcome back 👋

If you made it here, you’re not just learning React anymore —
you’re starting to think like a React developer.

In Episode 3, we set up the foundation with Browser Router — basically giving our app a navigation system.

But now comes the real question…

“Okay… routing is set. But how do I actually control navigation with logic?”

Because let’s be honest —
real apps don’t just wait for users to click links.

They:

redirect after login
protect private pages
move users based on conditions
respond to actions instantly

👉 And this… is exactly where useNavigate steps in.

What is useNavigate?

Let’s slow this down and really understand it.

At its core, useNavigate is a React hook that lets you change routes (pages) using JavaScript code instead of user clicks.

In simple terms:

It gives you control over when and where a user should move inside your app.

Normally in a website, navigation happens when a user clicks something.
But with useNavigate, navigation can happen because your logic decided it should happen.

What does that actually mean?

You don’t have to wait for a user to click a link
You can trigger navigation inside functions, conditions, API responses, or events
Your app becomes smarter and more responsive

Think of it like this:

Instead of the user driving the app, sometimes the app drives the user.

Why Does useNavigate Exist?

To understand this properly, you need to compare traditional websites vs React apps.

Traditional Website Navigation

In a normal website:

User clicks a link
Browser requests a new page from the server
Entire page reloads

This is slow and breaks the user experience.

React (Single Page Application) Navigation

React works differently.

It’s a Single Page Application (SPA), which means:

The page does not fully reload
Only the required components update
Navigation feels instant and smooth

But here’s the catch:

If there are no full page reloads… how do we move between pages?

That’s where React Router comes in (Episode 3).
And useNavigate is part of that system.

The Real Reason useNavigate Exists

Let’s move into real-world thinking.

Modern apps are not just about showing pages. They are about flows.

Real-Time Scenarios

After login → go to dashboard
After form submission → go to success page
If user is not logged in → redirect to login
If payment is successful → show confirmation page

These are not user-click actions. These are logic-driven decisions.

That is exactly why useNavigate exists.

Real-Time Examples

1. After Login

import { useNavigate } from "react-router-dom";

function Login() {
  const navigate = useNavigate();

  const handleLogin = () => {
    const isAuthenticated = true;

    if (isAuthenticated) {
      navigate("/dashboard");
    }
  };

  return <button onClick={handleLogin}>Login</button>;
}

2. After Form Submission

const handleSubmit = () => {
  navigate("/thank-you");
};

3. Protecting Private Routes

if (!user) {
  navigate("/login");
}

4. Auto Redirect After Delay

setTimeout(() => {
  navigate("/");
}, 3000);

Where Can You Use useNavigate?

Important rule:

useNavigate can only be used inside:

React functional components
Custom hooks

How to Use useNavigate (Step by Step)

1. Import

import { useNavigate } from "react-router-dom";

2. Initialize

const navigate = useNavigate();

3. Use

navigate("/home");

Additional Useful Patterns (Real Understanding)

These patterns are used heavily in real applications.

1. Go Back to Previous Page

navigate(-1);

Meaning

Works like browser back button.

-1 → go back one page
-2 → go back two pages

Example Flow

Home → Products → Product Details

navigate(-1);

You return to Products page.

2. Replace Current Page (No Back Navigation)

navigate("/home", { replace: true });

Meaning

Replaces current page in history.

User cannot go back to previous page.

Real Example: Login

const handleLogin = () => {
  navigate("/dashboard", { replace: true });
};

Without replace → user goes back to login page
With replace → login page is removed from history

3. Pass Data While Navigating

navigate("/profile", {
  state: { name: "John" }
});

Meaning

Send temporary data to another page.

Receiving Data

import { useLocation } from "react-router-dom";

function Profile() {
  const location = useLocation();
  console.log(location.state.name);
}

Real Use Case

navigate("/profile", {
  state: { userId: 5, name: "John" }
});

Link vs useNavigate

Scenario	Use
User clicks navigation	Link
Logic decides navigation	useNavigate

Common Mistakes Beginners Make (and How to Avoid Them)

1. Using useNavigate Outside Component

Hooks only work inside components.

2. Forgetting Router Setup

Make sure BrowserRouter is configured (Episode 3).

3. Overusing useNavigate

Don’t replace all links with it.

4. Navigating Before Logic Completes

Always wait for API success or conditions.

5. Ignoring Edge Cases

Handle failures before redirecting.

Simple Way to Remember

User action → Link
App logic → useNavigate

Final Thoughts

useNavigate is not just about switching pages.

It allows you to:

Control user flow
Build real-world app behavior
Create smooth, intelligent navigation

Once you understand this, you stop thinking in pages and start thinking in user journeys.

See you in next one

This is Episode 4 of the series “Let’s Master React Hooks Together.”

Full series here:
👉 https://dev.to/kathirvel-s/series/39103

In the next episode, we’ll explore another powerful concept that helps your React apps become even more dynamic and interactive.

Until then, try building a small project using useNavigate. That’s where real understanding begins.

Stop Using Links the Wrong Way — Master useNavigate in React

Kathirvel S — Wed, 06 May 2026 14:43:20 +0000

Hey… welcome back 👋

If you made it here, you’re not just learning React anymore —
you’re starting to think like a React developer.

In Episode 3, we set up the foundation with Browser Router — basically giving our app a navigation system.

But now comes the real question…

“Okay… routing is set. But how do I actually control navigation with logic?”

Because let’s be honest —
real apps don’t just wait for users to click links.

They:

redirect after login
protect private pages
move users based on conditions
respond to actions instantly

👉 And this… is exactly where useNavigate steps in.

What is useNavigate?

Let’s slow this down and really understand it.

At its core, useNavigate is a React hook that lets you change routes (pages) using JavaScript code instead of user clicks.

In simple terms:

It gives you control over when and where a user should move inside your app.

Normally in a website, navigation happens when a user clicks something.
But with useNavigate, navigation can happen because your logic decided it should happen.

What does that actually mean?

You don’t have to wait for a user to click a link
You can trigger navigation inside functions, conditions, API responses, or events
Your app becomes smarter and more responsive

Think of it like this:

Instead of the user driving the app, sometimes the app drives the user.

Why Does useNavigate Exist?

To understand this properly, you need to compare traditional websites vs React apps.

Traditional Website Navigation

In a normal website:

User clicks a link
Browser requests a new page from the server
Entire page reloads

This is slow and breaks the user experience.

React (Single Page Application) Navigation

React works differently.

It’s a Single Page Application (SPA), which means:

The page does not fully reload
Only the required components update
Navigation feels instant and smooth

But here’s the catch:

If there are no full page reloads… how do we move between pages?

That’s where React Router comes in (Episode 3).
And useNavigate is part of that system.

The Real Reason useNavigate Exists

Let’s move into real-world thinking.

Modern apps are not just about showing pages. They are about flows.

Real-Time Scenarios

After login → go to dashboard
After form submission → go to success page
If user is not logged in → redirect to login
If payment is successful → show confirmation page

These are not user-click actions. These are logic-driven decisions.

That is exactly why useNavigate exists.

Real-Time Examples

1. After Login

import { useNavigate } from "react-router-dom";

function Login() {
  const navigate = useNavigate();

  const handleLogin = () => {
    const isAuthenticated = true;

    if (isAuthenticated) {
      navigate("/dashboard");
    }
  };

  return <button onClick={handleLogin}>Login</button>;
}

2. After Form Submission

const handleSubmit = () => {
  navigate("/thank-you");
};

3. Protecting Private Routes

if (!user) {
  navigate("/login");
}

4. Auto Redirect After Delay

setTimeout(() => {
  navigate("/");
}, 3000);

Where Can You Use useNavigate?

Important rule:

useNavigate can only be used inside:

React functional components
Custom hooks

How to Use useNavigate (Step by Step)

1. Import

import { useNavigate } from "react-router-dom";

2. Initialize

const navigate = useNavigate();

3. Use

navigate("/home");

Additional Useful Patterns (Real Understanding)

These patterns are used heavily in real applications.

1. Go Back to Previous Page

navigate(-1);

Meaning

Works like browser back button.

-1 → go back one page
-2 → go back two pages

Example Flow

Home → Products → Product Details

navigate(-1);

You return to Products page.

2. Replace Current Page (No Back Navigation)

navigate("/home", { replace: true });

Meaning

Replaces current page in history.

User cannot go back to previous page.

Real Example: Login

const handleLogin = () => {
  navigate("/dashboard", { replace: true });
};

Without replace → user goes back to login page
With replace → login page is removed from history

3. Pass Data While Navigating

navigate("/profile", {
  state: { name: "John" }
});

Meaning

Send temporary data to another page.

Receiving Data

import { useLocation } from "react-router-dom";

function Profile() {
  const location = useLocation();
  console.log(location.state.name);
}

Real Use Case

navigate("/profile", {
  state: { userId: 5, name: "John" }
});

Link vs useNavigate

Scenario	Use
User clicks navigation	Link
Logic decides navigation	useNavigate

Common Mistakes Beginners Make (and How to Avoid Them)

1. Using useNavigate Outside Component

Hooks only work inside components.

2. Forgetting Router Setup

Make sure BrowserRouter is configured (Episode 3).

3. Overusing useNavigate

Don’t replace all links with it.

4. Navigating Before Logic Completes

Always wait for API success or conditions.

5. Ignoring Edge Cases

Handle failures before redirecting.

Simple Way to Remember

User action → Link
App logic → useNavigate

Final Thoughts

useNavigate is not just about switching pages.

It allows you to:

Control user flow
Build real-world app behavior
Create smooth, intelligent navigation

Once you understand this, you stop thinking in pages and start thinking in user journeys.

See you in next one

This is Episode 4 of the series “Let’s Master React Hooks Together.”

Full series here:
👉 https://dev.to/kathirvel-s/series/39103

In the next episode, we’ll explore another powerful concept that helps your React apps become even more dynamic and interactive.

Until then, try building a small project using useNavigate. That’s where real understanding begins.

Browser Router in React JS — Why It Exists, What It Solves, and How to Actually Use It

Kathirvel S — Mon, 04 May 2026 02:54:56 +0000

If you’ve ever built a React app and thought,

“Why does my page reload every time I click a link?”

you’re not alone.

That moment is usually where things start getting interesting…

and where something like Browser Router quietly steps in to save your user experience.

And if you’re following along with my series

"Mastering React Hooks Together",

this is the 3rd episode

and trust me, this piece matters more than it looks.

Because before jumping into hooks like useNavigate, there’s something fundamental you need to understand first… and that’s exactly what we’re unpacking here.

Let’s break it down in a way that actually makes sense — no robotic explanations, no unnecessary jargon. Just real understanding.

So… Why Does Browser Router Even Exist?

React is built for speed and smoothness. It updates parts of the page without refreshing the whole thing. But here’s the catch:

👉 Browsers don’t work that way by default.

When you click a normal link (<a href="/about">), the browser reloads the entire page. That means:

Your app resets
State is lost
It feels slow and clunky

Not exactly the “modern app” experience we want.

This is where Browser Router comes in — it lets your React app behave like a real single-page application (SPA), where navigation feels instant.

But how does it actually pull that off?

What is Browser Router (Official + Simple)

Official idea:
Browser Router is a routing component that uses the browser’s History API to keep your UI in sync with the URL.

Now in plain English:

👉 It watches the URL and decides what component to show — without refreshing the page.

Think of it like a smart traffic controller:

URL changes → Browser Router reacts → React renders the right component

No reloads. No flicker. Just smooth transitions.

And once you see it in action, you’ll realize it’s not just “nice to have” — it’s essential.

The Problem It Actually Solves

Let’s paint a quick picture.

Imagine you’re building a simple app:

Home page
About page
Contact page

Without routing, you’d either:

Reload the page every time (bad UX), or
Manually control everything with state (messy and hard to scale)

Neither feels right.

Browser Router solves this by:

Keeping the UI and URL in sync
Letting users bookmark/share links
Enabling back/forward navigation
Avoiding full page reloads

Basically, it gives your React app a real navigation system.

And once navigation is handled cleanly, the next natural question becomes…

How Do You Actually Use Browser Router?

Let’s keep this practical — but this time, not just what to write… also why each line exists, so nothing feels like magic.

Step 1: Install React Router

npm install react-router-dom

This installs the routing library your app doesn’t have by default. React itself doesn’t handle routing — so you’re bringing in the tool that will.

Step 2: Wrap Your App

import { BrowserRouter } from "react-router-dom";

function App() {
  return (
    <BrowserRouter>
      {/* Your routes go here */}
    </BrowserRouter>
  );
}

Let’s break this down:

import { BrowserRouter }...
👉 You’re importing the component that enables routing using the browser’s URL.
<BrowserRouter>
👉 This is the engine of your routing system.
It listens to URL changes and provides routing context to everything inside it.
{/* Your routes go here */}
👉 This is where your app’s pages will live — but they only work because they’re inside Browser Router.

So at this point:
👉 Your app is now aware of URLs.

But it still doesn’t know what to render for each URL… and that leads us to the next step.

Step 3: Define Routes

import { Routes, Route } from "react-router-dom";

function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/" element={<Home />} />
        <Route path="/about" element={<About />} />
      </Routes>
    </BrowserRouter>
  );
}

Here:

import { Routes, Route }...
👉 These help you define which component should show for which URL.
<Routes>
👉 Think of this as a container that holds all your route rules.
<Route path="/" element={<Home />} />
👉 When the URL is /, React renders the Home component.
<Route path="/about" element={<About />} />
👉 When the URL is /about, React switches to the About component.

Now something important just happened:
👉 Your app can now map URLs to UI.

But how does the user actually move between these URLs without reloading?

Step 4: Navigate Without Reloading

import { Link } from "react-router-dom";

<Link to="/about">Go to About</Link>

Let’s unpack it:

import { Link }...
👉 This replaces the normal <a> tag in React apps.
<Link to="/about">
👉 Instead of reloading the page, it updates the URL internally.
Go to About
👉 What the user clicks.

So when clicked:
👉 URL changes → Browser Router detects it → सही component renders → no reload

And now everything connects:

Browser Router watches the URL
Routes decide what to render
Link changes the URL smoothly

That’s the full loop.

And once this loop clicks in your head, navigation stops feeling confusing… and starts feeling powerful.

When Should You Use Browser Router?

Short answer?

👉 Almost always — if you're building a web app.

But let’s be specific.

Use it when:

You have multiple pages/views
You want clean URLs
You care about user experience
You don’t want page reloads

Avoid it only if:

Your app is extremely small (like a single static view)
Or you’re using a different routing strategy (like hash-based routing for legacy setups)

Otherwise, Browser Router is your go-to.

And once navigation is set up, clicking links is just one part of the story…

Is Browser Router Just for useNavigate?

Not exactly — but it makes it possible.

Browser Router is the foundation.
Hooks like useNavigate are tools built on top of it.

Without Browser Router:
👉 useNavigate won’t work.

With Browser Router:
👉 You can programmatically move users around your app.

And this is exactly why understanding Browser Router comes before learning useNavigate.

Because:

useNavigate depends on routing context
That context is created by Browser Router
Without it, navigation logic simply has nowhere to run

So if you jump straight into useNavigate without this base, things will feel confusing or even break entirely.

Example:

import { useNavigate } from "react-router-dom";

function Home() {
  const navigate = useNavigate();

  return (
    <button onClick={() => navigate("/about")}>
      Go to About
    </button>
  );
}

This is where things shift from “basic routing” to “controlled user flow.”

Now you’re not just linking pages — you’re guiding users.

Bringing It All Together

Browser Router isn’t just another library piece you install and forget.

It’s what transforms your React app from:
👉 A collection of components
into
👉 A real, navigable application

It:

Eliminates full page reloads
Keeps URLs meaningful
Improves performance and UX
Enables powerful navigation patterns

And once you start using it, you’ll wonder how you ever built apps without it.

One Last Thought

If you’re continuing this journey with

“Mastering React Hooks Together”,

this 3rd episode sets the stage for everything that comes next.

Because when we step into hooks like useNavigate, you won’t just memorize syntax — you’ll actually understand what’s happening under the hood.

And that’s the difference between using React… and mastering it.

The First Website on the Internet (And the Problem It Solved)

Kathirvel S — Sun, 03 May 2026 06:05:23 +0000

A random question… or the start of something bigger?

Some conversations don’t feel important when they start… but they stay with you.

This happened at Payilagam Institute.

It was one of those normal days — nothing planned, nothing serious.

Me and my friends — Mohanakumar, Hariharan, Dhanraj, and Vinayagam — were just sitting together, casually talking tech.

And like always… React entered the conversation 😄

Then came the question:

“Why do we even use React?”

Not in a deep, interview-type way. Just casually.

Hariharan stepped in and said,

“Back in the 1990s, websites were static… no interactivity, nothing dynamic.”

That one line changed the vibe.

I started thinking…

Static websites?
No updates?
No user interaction?

Then what were websites even for?

And without even planning it, I asked:

“Okay… then which was the first website ever created? And who created it?”

There was a small pause.

No one had a clear answer.

And that silence?

That’s where this story started.

Welcome to the series

This is Episode 1 of:

Sunday Source – I Break It, Then Explain It

Here, I pick one concept, break it into simple ideas, and explain it like we’re just talking.

Because understanding > memorizing.

And today… we’re going back to the origin of the web.

Why I named this series “Sunday Source – I Break It, Then Explain It”

Before we go deeper, let me tell you why this series even exists.

The name is not random.

👉 “Sunday Source” — because every Sunday, I pick one core idea (a source)

👉 “I Break It, Then Explain It” — because complex things only make sense when you break them down

No over-complication.
No memorizing definitions.

Just understanding things from the root.

Because most of the time, we don’t struggle with learning…

We struggle with how it’s explained.

This series fixes that.

The First Website Ever Created

Let’s go back to 1991.

The very first website in the world was created by Tim Berners-Lee.

👉 You can still visit it here: http://info.cern.ch/

Open it.

It feels… almost empty.

No styling. No images. Just plain text and links.

But this wasn’t just a website.

This was the starting point of the World Wide Web.

Why was it named like that? (info.cern.ch)

At first glance, the name info.cern.ch might look random.

But it actually tells a story.

info → because the website was meant to share information
cern → the organization where Tim Berners-Lee was working
.ch → the country domain for Switzerland (where CERN is located)

So the name literally means:

“Information at CERN”

No branding. No marketing thinking.

Just pure purpose.

And that itself tells you something about the early web:

It was built to share knowledge, not to impress.

Who is Tim Berners-Lee?

Tim Berners-Lee is a British scientist.

But more importantly…

He is the person who made the web usable.

He wasn’t trying to create social media, startups, or apps.

He was trying to solve a very real, very practical problem.

While working at CERN, he saw something frustrating:

People had information… but no easy way to share it.

The problem he faced

At CERN:

Different systems couldn’t communicate properly
Files were stored in different formats
There was no single place to access information
You had to manually figure out where things were

It was messy.

Time-consuming.

And inefficient.

The idea that changed everything

Tim thought:

“What if all this information could be connected?”

Not copied. Not moved.

Just… connected.

So that you could jump from one document to another instantly.

That’s where the idea of hyperlinks came in.

Click → move → explore.

Sounds normal today.

Back then?

Revolutionary.

How he made it real

Ideas are easy.

Building them is not.

But Tim Berners-Lee actually built the system from scratch.

He created:

HTML → to structure content
HTTP → to transfer data
URL → to locate resources

And then:

The first web server
The first browser
The first website

Everything we use today…

Started from these building blocks.

What the first website actually did

The first website wasn’t for fun or business.

It was a guide.

It explained:

What the World Wide Web is
How to create web pages
How to link documents
How to access information

In a way…

The first website was teaching people how to use the web itself.

Why this still matters

Think about your daily life.

Every click you make…
Every link you open…
Every page you visit…

All of it traces back to this one idea:

Connecting information in a simple way

From that one page…

Came everything:

Search engines
Social media
Modern frameworks like React

So when we ask “why do we use React?”

We’re actually continuing a journey that started in 1991.

A better way to look at it

That small question I asked that day…

“Who created the first website?”

It wasn’t just about history.

It was about understanding something deeper.

Every tool we use today exists because:

Someone had a problem… and decided to solve it.

Once again Read it

Someone had a problem… and decided to solve it.

Tim Berners-Lee didn’t build the web to become famous.

He built it because sharing information was hard.

That’s it.

Simple problem. Powerful solution.

So next time you learn a new technology…

Don’t just ask:

“How does this work?”

Ask:

“Why was this created in the first place?”

Because when you understand the why…

Everything else starts making sense.

If this made you pause, think, or look at the internet a little differently…

Then this series is doing its job.

👉 Sunday Source – I Break It, Then Explain It

Simple ideas. Clear understanding. Real connection.

And next time you open a website…

You’ll know where it all started.

See you in the next Sunday Source.

useEffect in React — the invisible engine behind real apps

Kathirvel S — Fri, 01 May 2026 14:04:44 +0000

In Part 1 of “Let’s Master React Hooks Together” we focused on useState — how React remembers things, updates UI, and keeps everything in sync.

You learned how to control your app.

But then comes the next question:

What happens when your app needs to talk to the outside world?

You open Instagram, blink once… and boom — your feed is alive.

Posts load. Stories appear. Notifications sneak in. Everything feels instant.

But here’s what most beginners don’t realize:

👉 React didn’t do that.
👉 React only rendered the empty screen.

Everything after that — fetching data, syncing with APIs, setting up listeners…

That’s where useEffect steps in.

This is where React stops being just about state…
and starts becoming interactive with the real world.

And once you truly understand this hook:

You stop just managing state… and start thinking like React.

So what is `useEffect`… really?

Let’s skip the robotic definition for a second.

👉 useEffect lets your component do things after it renders.

Now the official version (just so you’re covered):

“The Effect Hook lets you perform side effects in function components.”

Cool. But what does that actually mean?

“Side Effects” — sounds scary, isn’t.

Relax. It’s simpler than it sounds.

A side effect is anything your component does that is not just returning UI.

Think about real apps:

Fetching data from a server
Updating the page title
Listening to scroll or clicks
Running a timer
Saving something in local storage

👉 These don’t directly render JSX — but they make your app feel alive.

Why does `useEffect` even exist?

Because React is strict about one thing:

Rendering must stay pure.

That means:

Same input → same UI output
No hidden behavior
No randomness during render

But real apps? Total chaos

Let’s bring back the Instagram example:

Open app → fetch posts
Like a post → send data to server
Scroll → load more content

👉 None of this is “rendering UI.”

So React needed a safe place for this “messy” stuff.

And it basically said:

“Do whatever you want… just don’t do it during render.”

That safe place = useEffect.

The exact problem it solves (this is the aha moment)

Imagine writing this:

function Feed() {
  const data = fetchPosts(); // ❌ dangerous

  return <div>{data}</div>;
}

Looks innocent. But here’s what really happens:

→ Component renders
→ fetchPosts() runs
→ Data changes → triggers render
→ It runs again
→ And again…

You’ve just created a loop.

Now watch the same thing done properly:

function Feed() {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    fetchPosts().then(setPosts);
  }, []);

  return <div>{posts.length} posts</div>;
}

First render → UI shows empty state
Then useEffect runs → fetch starts
Data arrives → state updates
Component re-renders → UI updates

👉 No chaos. No loops. Just control.

The mental model that changes everything

Forget technical jargon. Think like this:

“What should happen after the screen updates?”

That answer = your useEffect.

How to actually use `useEffect`

Here’s the shape:

useEffect(() => {
  // effect logic

  return () => {
    // cleanup logic
  };
}, [dependencies]);

Now let’s feel what each part does.

Effect running every time

useEffect(() => {
  console.log("Rendering happened");
});

Render → effect runs
Render again → runs again

👉 No control. Just chaos checking everything.

Run only once (most common beginner case)

useEffect(() => {
  console.log("Component loaded");
}, []);

Component appears → effect runs once
Never again

👉 Perfect for API calls, initial setup.

Run when something changes

useEffect(() => {
  console.log("User changed");
}, [user]);

Initial render → runs
If user changes → runs again
If nothing changes → does nothing

👉 This is where real apps live.

Cleanup — the part most people ignore (big mistake)

useEffect(() => {
  const interval = setInterval(() => {
    console.log("Checking notifications...");
  }, 3000);

  return () => {
    clearInterval(interval);
  };
}, []);

Component loads → interval starts
Every 3 seconds → it runs

Now imagine leaving the page…

Without cleanup:
The interval keeps running
Multiple intervals stack
App slows down

With cleanup:
React removes the interval cleanly
Nothing leaks
Everything stays predictable

👉 Cleanup runs:

Before the effect runs again
When the component disappears

Lifecycle… but explained like a human

Forget the textbook words.

Here’s what actually happens:

🟢 Component shows up
→ UI renders
→ useEffect runs

🟡 Something changes
→ React updates UI
→ useEffect checks dependencies
→ Runs only if needed

🔴 Component goes away
→ Cleanup runs

That’s the whole story.

Where you should use `useEffect`

Use it when your app needs to:

✔ Fetch data (feeds, dashboards, profiles)
✔ Listen to events (scroll, resize, clicks)
✔ Sync with APIs or storage
✔ Run timers or intervals
✔ Handle subscriptions (live chats, notifications)

When NOT to use it (this saves hours of frustration)

Bad pattern:

useEffect(() => {
  setFullName(first + last);
}, [first, last]);

This creates unnecessary re-renders.

Better:

const fullName = first + last;

Nothing async
No external system
No side effect

👉 Then you don’t need useEffect.

Real-world example (Instagram-style thinking)

function Stories({ userId }) {
  const [stories, setStories] = useState([]);

  useEffect(() => {
    let active = true;

    fetch(`/api/stories/${userId}`)
      .then(res => res.json())
      .then(data => {
        if (active) setStories(data);
      });

    return () => {
      active = false;
    };
  }, [userId]);

  return (
    <div>
      {stories.map(story => (
        <img key={story.id} src={story.image} />
      ))}
    </div>
  );
}

Component appears → empty stories render
Effect runs → fetch starts for current user
When data returns → it checks if component is still active
If yes → updates state → UI refreshes

Now if user switches quickly:
Cleanup runs → marks previous request inactive
Old data won’t overwrite new UI

👉 This is how real apps avoid subtle bugs.

The shift that makes you dangerous (in a good way)

Most beginners ask:

“How do I use useEffect?”

But better developers ask:

“Should this even be an effect?”

That one question will level you up faster than anything else.

Next time you open an app…

Whether it’s Instagram, YouTube, or anything dynamic…

Ask yourself:

What ran after the UI loaded?
What triggered that update?
What got cleaned up when I left?

That curiosity turns confusion into clarity.

Final takeaway

So in this second part of “Let’s Master React Hooks Together” you moved beyond useState…

…and stepped into useEffect.

Not just a hook — but a mindset shift.

Because useEffect is the bridge between:

React’s clean, predictable state world
The messy, asynchronous real world

When you understand that bridge:

You stop writing “just code.”
You start designing behavior.

You know when things should run.
You know why they run.

And that’s when React starts to feel less like magic…
and more like a tool you actually control.

In the next part, we’ll keep building on this — making your hooks cleaner, smarter, and more predictable.

React Hooks Made Simple: Mastering useState (Without Losing Your Mind)

Kathirvel S — Tue, 28 Apr 2026 15:26:15 +0000

Let’s be honest—when you first hear “React Hooks”, it sounds a bit intimidating. Like something only senior developers casually throw around while sipping coffee

But here’s the truth: Hooks are not scary.
In fact, once you understand just one of them—useState—you unlock a huge part of React.

Think of this as building something step by step. Each piece adds meaning, and suddenly everything makes sense.

And that’s exactly why this is part of a series called “Let’s Master React Hooks Together”.

Because learning React (or honestly, anything in tech) becomes much easier when you don’t try to swallow everything at once. A series gives you structure. It keeps you consistent. It removes confusion about what to learn next. And most importantly, it builds discipline—one small concept at a time, instead of random jumping between topics.

When you follow a guided path like this, you’re not just learning React Hooks… you’re training your mind to learn efficiently, stay consistent, and actually finish what you start.

So instead of rushing, we go step by step—starting with useState and building real confidence along the way.

So… Why Do We Even Need `useState`?

useState exists to help your component remember things over time and update the UI when those things change.

Imagine you’re writing a number on a whiteboard:

function Counter() {
  let count = 0;
  return <h1>{count}</h1>;
}

function Counter() → this creates a component that React will run every time it renders
let count = 0; → a normal variable is created and always starts fresh at 0
return <h1>{count}</h1>; → React displays the current value on screen

You write 0. Someone says “increase it”… but every time the component runs again, it goes back to 0.

That’s exactly what happens here:

Every render resets the value
Nothing is remembered

So your app behaves like it has no memory at all.

➡️ We need a way to remember what happened before.

What Exactly is `useState`?

useState gives your component a memory slot that survives re-renders.

Let’s upgrade that whiteboard to something smarter:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);
  return <h1>{count}</h1>;
}

import { useState } from "react"; → brings the state feature into your component
function Counter() → React runs this function to render UI
const [count, setCount] = useState(0); →

count holds the current value
setCount is used to update it
0 is the starting value

return <h1>{count}</h1>; → displays the stored value

Now imagine a digital display:

it remembers the number
it doesn’t reset unless you tell it to

Now that we can store it… how do we change it?

How to Use `useState` (The Simple Way)

We need a way to update the value.

<button onClick={() => setCount(count + 1)}>
  Increment
</button>

<button> → creates a clickable element
onClick={() => ...} → tells React what to do when clicked
() => setCount(count + 1) →

takes current value
adds 1
sends it to React

setCount(...) → updates the stored value
React sees the update → re-renders the component → new value appears

It’s like pressing a counter device:

click
number increases
display updates instantly

Let’s bring everything together into one working piece.

Let’s Build Something: Counter App

Here’s the full setup:

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <h1>{count}</h1>

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

export default Counter;

import { useState } from "react"; → enables state in this component
function Counter() → defines the UI logic
useState(0) → sets starting value
count → holds current number
setCount → updates that number

<h1>{count}</h1> → shows the current value

onClick={() => setCount(count + 1)} →

user clicks
value increases
React updates UI

export default Counter; → allows this component to be used elsewhere

Picture a scoreboard:

starts at 0
every click adds a point
display updates instantly

Now that you’ve seen it working, let’s understand when to use this.

When Should You Use `useState`?

Use useState when something changes over time and needs to be shown on screen.

Imagine filling out a form:

const [name, setName] = useState("");

useState("") → starts with empty text
name → stores what user types
setName → updates it

When connected to input:

user types
value updates
UI reflects instantly

It’s like typing on your phone—each letter appears immediately.

But not everything needs this kind of memory.

When NOT to Use `useState`

Sometimes, keeping track is unnecessary.

const title = "Welcome";

const title → simple fixed value
No updates → no re-render needed

Like a printed poster:

always the same
no interaction

Now let’s see where it becomes really powerful.

Real-Life Situations Where `useState` Shines

Here’s where things get exciting.

1. Form Input

<input
  value={name}
  onChange={(e) => setName(e.target.value)}
/>

value={name} → input shows current state
onChange → listens for typing
e.target.value → gets typed text
setName(...) → updates state
React re-renders → input stays in sync

2. Toggle Feature

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

<button onClick={() => setIsOpen(!isOpen)}>
  Toggle
</button>

isOpen → current state (true/false)
setIsOpen → updates it
!isOpen → flips value

Click → value changes → UI updates

3. Conditional Rendering

{isOpen && <p>Visible now</p>}

isOpen && → checks condition
If true → show content
If false → hide content

State controls visibility.

Now let’s sharpen how we update things.

Pro Tips (That Make You Look Smart)

setCount(prev => prev + 1);

prev → latest value from React
prev + 1 → safe update
Prevents outdated values

Useful when multiple updates happen quickly.

Common Beginner Mistakes

count = count + 1; // ❌ wrong

This changes the variable… but:

React doesn’t track it
No re-render happens
UI stays the same

Correct approach:

setCount(count + 1);

React sees update → re-renders → UI updates

So What Did We Learn?

You started with something that resets every time…
and turned it into something that remembers, updates, and reacts.

Now your UI:

keeps track of changes
updates instantly
feels alive

That’s the magic of useState.

What’s Next? (And Why You Should Care)

Now you know how to store and update values.

But what if:

something needs to happen automatically after rendering?
you fetch data from an API?
you deal with timers or external events?

That’s where the next step comes in…

👉 useEffect

Once you combine both, you move from simple interactions to real-world applications.

Before You Go…

Try this:

👉 Add a decrement button
👉 Stop it from going below 0
👉 Add a reset button

Watch how every action:

updates the value
refreshes the UI
keeps everything in sync

That’s when it really clicks.

Once you start seeing it this way, React stops feeling confusing…
and starts feeling like something you can actually control

How React + Vite Actually Works Behind the Scenes Breakdown

Kathirvel S — Sun, 26 Apr 2026 07:03:58 +0000

You type npm run dev, press Enter… and your React app shows up instantly in the browser.

It feels effortless.

But here’s the thing — it shouldn’t feel like magic if you really want to get good at this.

As A2D Nandha puts it:

“If you want to crack it, you need to understand the system.”

That idea hits hard, especially in development. Because behind that one simple command, a full system wakes up — a dev server spins up, modules start flowing, transformations happen in milliseconds, and your browser begins assembling your app piece by piece.

So naturally, the question comes up:

What actually just happened after I hit that command?

If you’ve ever been curious about that moment — not just using the tool, but truly understanding it — you’re in the right place.

Let’s walk through it like you’re watching the whole system come alive in real time.

Dev Server Initialization (`npm run dev` & Vite CLI)

The moment you run this command, your system reads the package.json file and executes the script mapped to "dev" — usually something like:

vite

This starts a development server on your machine.

A development server is simply a local program that:

Serves your files to the browser
Watches for changes
Updates your app instantly

Think of it less like “running your app” and more like “making your app available to the browser on demand.”

Quick picture in your head:
It’s like opening a live streaming room. You haven’t started the content yet — but the room is ready, the camera is on, and viewers (your browser) can now connect.

At this point, nothing is bundled. Nothing is optimized. Vite is just getting ready to serve files as they are.

And that’s where things start getting interesting.

On-Demand Module Serving (Vite Dev Server vs Bundlers)

Traditional tools like Webpack bundle your entire app before showing anything in the browser.

Vite flips that idea completely.

Instead of preparing everything upfront, Vite:

Starts the server instantly
Waits for the browser to request files
Sends only what’s needed

This is possible because modern browsers understand something powerful: ES Modules.

Imagine this:
You walk into a library. Instead of getting a giant stack of every book you might need, you just ask for one book at a time — exactly when you need it.

Less waiting. Less overload. More speed.

Native ES Modules (ESM) in the Browser

In older setups, browsers couldn’t handle import and export directly. Everything had to be bundled into one big file.

Now, with ES Modules:

Each file is treated as a module
The browser can request them individually
Dependencies are resolved step-by-step

So when your browser loads your app, it doesn’t download one giant file.

Instead, it reads your entry file and follows the import chain like a map.

Think about it like Google Maps:
You don’t load the entire world map in full detail. You zoom into your route, and more details load as needed.

That’s exactly how your app is being loaded.

Application Entry Point (`main.jsx` Bootstrapping)

Your app begins execution from a file like:

main.jsx

This file usually does something like:

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

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

This is the root of your application.

From here:

The browser loads App.jsx
Then any components inside it
Then their dependencies

It’s a chain reaction — one import leads to another.

Picture this:
It’s like turning the first domino. Once it falls, everything else follows in sequence — clean, predictable, and controlled.

JSX Transpilation (ESBuild & React Transform)

Here’s something important:

Browsers do not understand JSX.

This:

<h1>Hello</h1>

…is not valid JavaScript.

So before the browser can execute your code, JSX must be converted into plain JavaScript.

Vite uses ESBuild to do this transformation on the fly.

For example:

<h1>Hello</h1>

becomes something like:

React.createElement("h1", null, "Hello");

This transformation happens:

Instantly
In memory
Without slowing down your app

Think of it like subtitles in a movie:
You’re watching content in one language (JSX), but your brain (browser) understands another (JavaScript). Vite quietly translates it in real time — no delay, no interruption.

Hot Module Replacement (HMR) Runtime

You change one line of code… hit save… and your app updates immediately.

No refresh needed.

This is Hot Module Replacement (HMR).

Here’s what’s actually happening:

Vite detects a file change
It identifies which module changed
It sends an update to the browser
The browser replaces only that part

So instead of reloading the entire page, only the affected component updates.

This is why:

Your app state is preserved
Updates feel instant
Development feels smooth

Imagine editing a Google Doc with live sync:

You change one sentence — and it updates instantly for everyone, without reloading the whole document.

That’s HMR in action.

File System Watching (Chokidar / FS Events)

Vite uses a file watcher running in the background.

This watcher:

Monitors your project files
Detects changes immediately
Triggers updates when needed

It’s constantly active while your dev server is running.

Think of it like auto-save on steroids:

The moment you hit save, something is already reacting — no button clicks, no manual refresh.

Browser Module Graph & Request Lifecycle

When you open http://localhost:5173, the browser:

Requests the HTML file
Reads the <script type="module"> tag
Loads your entry file (main.jsx)
Follows every import
Requests each module from Vite

Each request goes back to the Vite server, which:

Transforms code if needed
Sends it back immediately

So your app is built on demand, piece by piece.

Visualize this:

It’s like assembling a Lego model — but instead of getting the full set at once, each piece arrives exactly when you need to place it.

React Virtual DOM & Reconciliation Process

Now here’s where React itself steps in.

What is Virtual DOM?

The Virtual DOM is a lightweight JavaScript representation of the real DOM (the actual UI in the browser).

Instead of directly updating the browser UI every time something changes, React:

Creates a virtual copy of the UI
Compares it with the previous version (diffing)
Updates only the parts that changed

Why does this matter?

Direct DOM updates are slow.

React avoids unnecessary work by being smart about what actually needs to change.

Let’s make this click:

Imagine you’re editing a large Excel sheet.

You change just one cell.

Would you:

Recreate the entire sheet from scratch ❌
Or update just that one cell ✅

React chooses the second option.

Another way to see it:
Think of a food delivery app UI.

If you add one item to your cart, the whole page doesn’t reload. Only the cart section updates.

That’s Virtual DOM working behind the scenes — calculating the smallest possible change and applying it efficiently.

Production Build Pipeline (Rollup Bundling & Optimization)

When you run:

npm run build

Everything changes.

Now Vite:

Bundles your code using Rollup
Removes unused code (tree shaking)
Minifies files
Optimizes assets

Instead of many small module requests, your app becomes a few optimized files.

Think of development vs production like this:

Development → flexible, fast, easy to change
Production → compact, efficient, optimized

It’s like working with raw ingredients vs serving a finished dish.

End-to-End Execution Flow (React + Vite Architecture Summary)

Here’s the full flow in simple terms:

You start the dev server
The browser requests your app
Vite serves files as ES Modules
JSX gets transformed instantly
Dependencies load one by one
React uses Virtual DOM to update efficiently
Changes update via HMR

No heavy startup time. No unnecessary work.

Just fast, on-demand execution.

One Thing to Try Right Now (Trace the Module Graph)

Open your project and follow this flow manually:

Start at main.jsx
Jump to App.jsx
Then open a component inside it

Now imagine the browser doing the same thing — file by file.

That’s exactly how your app runs.

Once you see this clearly, React + Vite stops feeling like a tool…

…and starts feeling like a system you actually understand.

If you want, we can go deeper next — like what exactly you’ll see in the Network tab and how Vite handles caching and requests internally.

React Concepts That Finally Click (Vite, JSX, Components & Folder Structure, npm vs npx and Dev Server)

Kathirvel S — Sun, 19 Apr 2026 08:38:59 +0000

You know that moment…

You open a React project, stare at the files, run a command, and everything works —
but deep inside you're thinking:

“I don’t fully get what just happened.”

Not because you’re not capable.
But because most explanations skip the why and rush into the how.

So here’s a different approach.

Instead of throwing definitions at you, we’re going to decode what’s actually happening behind the scenes — the kind of understanding that sticks even when you close the tab.

As you read, don’t just move your eyes.

Pause. Question things. Try to connect ideas.

Because if you do that, somewhere in this blog…
something will click — and once it clicks, it doesn’t go away.

1. React + Vite Folder Structure (also known as “What am I even looking at?”)

You open your project and suddenly it feels like someone dumped a suitcase full of files in front of you.

But here’s the thing — nothing in there is random.

A React + Vite folder structure is simply a well-organized system where every file has a purpose, making your app easier to build, debug, and scale as it grows.

Think about moving into a new house. You don’t just throw your clothes, utensils, and books into one room and hope life works out. You create spaces — kitchen for cooking, bedroom for sleeping, storage for things you don’t use daily.

Your project works the same way.

src/ is your living room — this is where your actual app lives
components/ is your furniture set — reusable pieces you place anywhere
assets/ is your storage shelf — images, fonts, icons
public/ is like the front porch — things that don’t change much
node_modules/ is that locked warehouse — full of dependencies you don’t touch

And then there are two files that quietly control everything:

main.jsx → the entry gate where your app starts
App.jsx → the root of your UI tree

Once you see it like this, the chaos turns into a map.

But wait… you didn’t manually create all this, right?

Something built this structure for you in seconds.

So who’s doing that heavy lifting?

2. npm vs npx (The Most Confusing Duo Ever)

This is where most beginners get tripped up — not because it’s complex, but because no one explains it clearly.

npm is your package manager. It installs tools, stores them, and lets you reuse them anytime.
npx, on the other hand, is more like a temporary executor — it runs something instantly without permanently installing it.

Imagine this:

You’re hungry.

One option is going grocery shopping, storing everything, and cooking daily — that’s npm
The other is ordering food when you need it, eating it, and moving on — that’s npx

When you run:

npx create-vite

You’re basically saying:

“Hey, I need this tool right now… use it and don’t clutter my system.”

It’s clean. Fast. No commitment.

Now your project is created, dependencies installed, everything looks ready…

And then you open a file and see something illegal-looking:

return <h1>Hello</h1>

Wait… JavaScript doesn’t look like this.

Or does it?

3. What is JSX? (HTML inside JavaScript?!)

JSX is where React stops feeling like programming… and starts feeling like building.

It lets you write UI in a syntax that looks like HTML, but it’s actually JavaScript under the hood. React reads this and transforms it into real browser instructions.

Instead of writing long, boring DOM manipulation code like:

create element → set text → append child → repeat

You just describe what you want:

const element = <h1>Hello World</h1>;

That’s it.

It’s like explaining something to a friend instead of writing a technical manual.

Imagine describing your dream room.

You wouldn’t say:

“Create four walls, apply paint, attach lighting…”

You’d say:

“I want a cozy room with warm lights and a desk.”

JSX is that natural language for UI.

So… how does Vite understand `<h1>` inside JavaScript?

Here’s where things get really interesting.

Because the truth is — JavaScript itself has no idea what <h1> means.

So how is this even working?

When you run a Vite + React app, Vite doesn’t directly “understand” JSX. Instead, it uses a fast compiler (usually esbuild during development) along with React’s JSX transform to convert JSX into plain JavaScript before the browser ever sees it.

Let’s break that illusion.

When you write this:

const element = <h1>Hello World</h1>;

Vite transforms it behind the scenes into something like this:

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

const element = _jsx("h1", { children: "Hello World" });

Now suddenly… it is valid JavaScript.

That <h1> wasn’t HTML — it became a function call.

🧠 What’s really happening step-by-step?

You write JSX in your .jsx file
Vite intercepts that file during development
esbuild compiles JSX → JavaScript instantly
React’s runtime (react/jsx-runtime) takes over
It creates a virtual representation of your UI (Virtual DOM)
React later turns that into real DOM in the browser

All of this happens so fast that it feels like magic.

🎬 A quick mental picture

Imagine you’re speaking in your native language (JSX), but the browser only understands English (JavaScript).

Vite acts like a real-time translator sitting between you and the browser.

You say:

<h1>Hello</h1>

Vite hears it, translates instantly, and tells the browser:

“Create an h1 element with this text”

And the browser says:

“Got it.”

⚡ Why this feels insanely fast in Vite

Older tools (like CRA with Webpack) used to bundle everything before running.

Vite doesn’t wait.

It compiles files on demand
Uses native ES modules
Only processes what you actually open

That’s why your app starts instantly and updates feel instant.

Now here’s the real power move…

You don’t just write JSX once.

You reuse it.

Over and over.

🧱 4. Components in React (The LEGO System)

React isn’t about writing big chunks of UI.

It’s about breaking everything into small, reusable pieces called components.

A component is just a function that returns UI.

That’s it. Nothing magical.

But what makes it powerful is how you use it.

Think about LEGO blocks.

You don’t rebuild a door every time you need one. You create it once, then reuse it across houses, buildings, even entire cities.

Same here.

function Button() {
  return <button>Click Me</button>;
}

Now imagine using it everywhere:

<Button />
<Button />
<Button />

One definition. Infinite usage.

This is why React apps stay clean instead of becoming spaghetti code.

But here’s something that feels unnecessarily strict at first…

Why does React complain if you try to return multiple elements?

Why is it so obsessed with “only one root”?

5. Why React Components Return Only One Element

At first, this rule feels annoying.

You try this:

return (
  <h1>Hello</h1>
  <p>World</p>
);

And React says: “Nope.”

The reason is actually simple — React needs a single root node to efficiently track and update what changes in your UI.

Think of it like sending a package.

If you ship five loose items separately, tracking becomes messy. But if you pack everything into one box, it’s easier to manage, deliver, and update.

That “box” in React is your parent element.

When you don’t want extra divs messing up your design, React gives you a clean solution:

<>
  <h1>Hello</h1>
  <p>World</p>
</>

No extra HTML. Just structure.

Now that you’re noticing syntax details…

You might have seen tags like this:

<img />
<input />

Why don’t they have closing tags?

Lazy coding?

Not really.

6. Why Self-Closing Tags Exist

Some elements don’t need children.

They just exist, do their job, and leave.

That’s exactly what self-closing tags are — elements that don’t wrap anything inside them.

Think of a vending machine.

You press a button → it gives you a drink.

There’s no conversation, no wrapping, no nesting.

Same idea here.

<img src="image.png" />
<input type="text" />

They’re complete on their own.

Cleaner code, less noise.

Alright… now comes the part where everything finally comes alive.

You type one command:

npm run dev

And boom — your app appears in the browser.

But what actually just happened?

7. What Happens When You Run `npm run dev`

This isn’t just “run the project.”

This command starts a development server, and that server is constantly watching your code.

The moment you make a change, it updates the browser instantly.

No refresh. No waiting.

It’s like having a chef cook right in front of you.

You say:

“Add more spice”

And immediately, the dish changes.

Behind the scenes, Vite is doing some serious magic:

It spins up a lightning-fast server
Uses modern JavaScript modules instead of heavy bundling
Injects updates into the browser instantly
Keeps everything insanely fast

This is why Vite feels so smooth compared to older setups.

But there’s one small detail you probably noticed without thinking much…

Why does Vite always run on 5173
while Create React App sticks to 3000?

That’s not random.

🔌 7.1 Why Vite Uses Port 5173 and CRA Uses 3000

Every time you run a dev server, your app needs a port — basically a channel through which your browser talks to your local machine.

A port is just a numbered endpoint.
Your computer has thousands of them.

So when you open:

http://localhost:5173

You’re not just opening a website —
you’re connecting to a specific doorway inside your system.

💻 Think of your laptop like this…

Your laptop is like a device hub with different ports.

USB port → for devices
HDMI port → for display
Charging port → for power

Each port has a purpose.

Now imagine if everything tried to use the same port.

Nothing would work properly.

Same idea in software

CRA uses 3000 as its default port
Vite uses 5173 as its default port

Why?

Because ports are like reserved seats in a system.
Each service picks a seat that’s usually free and less likely to conflict.

Port 3000 became popular early, so many tools used it.
Vite chose 5173 to avoid clashes and start fresh.

🎬 Simple mental image

Think of your laptop like a hotel.

Each app gets a room number (port):

React app (CRA) → Room 3000
Vite app → Room 5173

If room 5173 is busy, Vite just moves to another room automatically.

No panic. No crash. Just relocation.

Now that you see this…

Even something as small as a number becomes part of a system that actually makes sense.

8. Create React App vs Vite

At their core, both Create React App (CRA) and Vite are tools that help you set up and run a React application without manually configuring everything from scratch.

They both aim to solve the same problem:

“How do I start a React project quickly without dealing with complex setup?”

But the way they solve it is completely different.

Let’s go back to that earlier vibe…

CRA is like a traditional classroom teacher — structured, step-by-step, but a bit slow when you want to move fast.

Vite feels like learning from a creator who gets straight to the point — no waiting, no unnecessary setup, just instant results.

Same story… but clearer now

Imagine two ways of cooking:

CRA way:

First, prepare all ingredients
Then cook everything together
Only after everything is ready → you can taste

Vite way:

Start cooking immediately
Prepare things as needed
Taste and adjust in real-time

CRA bundles everything before you see anything.
Vite lets you see things as they happen.

Another way to see it (Aeroplane Mode ON)

Think of building and running your app like preparing a flight.

CRA is like a flight that waits for all passengers, luggage, and checks to complete before takeoff.

Long waiting time ⏳
Everything is processed upfront
Once it starts, it’s stable… but slow to begin

Vite is like a private jet.

You hop in
Engine starts instantly
Adjustments happen while moving

No long queues. No heavy delay.

Just speed.

What’s actually happening under the hood

CRA uses Webpack, which bundles the entire app before serving
Vite uses native ES modules and serves files on demand
CRA reloads the whole app
Vite updates only what changed

That’s why Vite feels insanely fast — because it avoids unnecessary work.

Quick Comparison

Feature	Create React App	Vite
Startup Time	Slow	⚡ Instant
Build System	Webpack	Native ES Modules
Performance	Heavy	Lightweight
Developer Experience	Okay	Smooth & fast

CRA bundles everything before running.

Vite skips that delay and serves files instantly.

That’s the game changer.

Before You Close This Tab… Pause.

Don’t just scroll past this part.

Ask yourself honestly:

Could you explain JSX to someone without googling?
Do you now know what actually happens when you run npm run dev?
When you see a React folder… does it still feel like chaos?

If even one of those shifted in your head — something changed.

Not surface-level “I saw this before” knowledge…
but internal clarity.

What You Actually Walk Away With

You didn’t just “learn React basics.”

You trained your brain to:

See folders as systems, not files
See JSX as transformed logic, not magic syntax
See components as reusable thinking patterns, not just functions
See errors as signals, not problems
See tools like Vite as accelerators, not black boxes

And most importantly…

👉 You moved from

“what is this?”

“oh… I know what’s happening here.”

That shift?

That’s the moment people stop being beginners.

Bonus: Why React & Vite Logos Look Like That

Now here’s something most people never think about — the logos you see every day actually represent the philosophy of the tools.

⚛️ React Logo (the atom)

The React logo looks like an atom with orbiting electrons.

That’s not random.

It represents the idea of building UIs from small, independent pieces (components).

The center = core UI logic
The orbiting circles = reusable components
The movement = data flow between them

In short:
👉 React = everything is made of small reusable “particles” that build big applications.

⚡ Vite Logo (lightning bolt)

The Vite logo is a lightning bolt wrapped in a geometric shape.

That symbolizes one thing: speed.

Lightning = instant response
Sharp angles = modern minimal tooling
Energy feel = fast dev experience

In short:
👉 Vite = “your app, but instantly powered and ready”

Final thought on logos

If React is the structure of thinking,
Vite is the speed of execution.

One tells you how to build.
The other makes it fast.

Next time you open a React project…

Don’t rush to code.

Look at it.

Understand it.

Break it.

Fix it.

Because that’s where real developers are made

DEV Community: Kathirvel S

Mastering useReducer in React — The Hook That Simplifies Complex State

From Simple State to Scalable Logic

In This Episode, You’ll Learn

What is useReducer in React?

Why This Pattern Exists

The Foundation

State Begins the Journey

Dispatch Starts Everything

The Decision Point

Connecting It All in a Component

Actions Carry Intent

When Data Is Needed

Real Flow — Multi-Step Form

Updating Form Fields

Input Connection

When It Makes Sense

When It Doesn’t

The Core Idea

Why Developers Prefer It

Redux Connection

Final Thoughts

What to Remember

Next Episode

What Building a Quiz Web App Taught Me About React

From Confusion to Confidence — Building My Quiz Web App with React

Live Project Link

The Idea Behind the Project

React Concepts I Used

Setting Up Routing Using BrowserRouter

Designing the User Page

Name Formatting Logic

Understanding useState Through Real Application Logic

useContext — The Most Important Concept in This Project

Protected Route Logic

Building the Main Quiz Logic

Dynamic Rendering Using map()

Score Calculation Logic

Result Page

Challenges I Faced

What This Project Taught Me

Final Thoughts

The Hidden Reason Python Became the Face of AI

Why Python Is the #1 Language for AI

Why AI Needed a Language Like Python

Python:

Java:

The Biggest Reasons Python Dominates AI

1. Python Is Easy to Read

2. Python Has Powerful AI Libraries

3. Python Is Perfect for Beginners

4. Fast Experimentation Matters in AI

Quick Summary

Is Python Actually Fast?

Python vs Other Languages for AI

Real Companies Using Python for AI

Google

OpenAI

Netflix

The Real Secret Behind Python’s Success

Before You Scroll away

The Smart Way to Share State —Master useContext in React

The Prop Drilling Problem Every React Developer Hits

The Problem: Prop Drilling in React

What is Context API?

1. Create Context

2. Provider

3. Consumer (useContext)

What is useContext?

Slightly Technical Understanding

Real Example: Theme Switching

Create Context

Create Provider

Consume Context

How useContext Works (Mental Model)

When to Use useContext

When NOT to Use useContext

Avoid Frequently Changing State

Avoid Replacing Local State

Performance Concerns (Important)

3. Consumer (`useContext`)

What is `useContext`?

How `useContext` Works (Mental Model)

When to Use `useContext`

When NOT to Use `useContext`

`useRef` — how React remembers values without causing re-renders.