DEV Community: DHANRAJ S

Java Data Types Explained — Simply, With Examples

DHANRAJ S — Fri, 29 May 2026 06:42:30 +0000

Hey!

Before we start — let me ask you something.

You are filling out a form. One field asks for your name. Another asks for your age. Another asks for your phone number. Another asks — are you a student? Yes or No.

All four fields take different kinds of data. Name is text. Age is a number. Phone number is digits. Yes or No is just true or false.

Java works exactly the same way.

Every piece of data has a type. And Java makes you say that type clearly before you use it.

That is what data types are. And by the end of this blog — every Java data type will make complete sense.

1. What Is a Data Type?

A data type tells Java two things.

First — what kind of value this variable holds.
Second — how much memory to give it.

int age = 25;

int — the type. Tells Java this is a whole number.
age — the name of the variable.
25 — the value.

Java reads this and thinks — "okay, age is a whole number. I will give it exactly enough memory for a whole number. Nothing more."

That is why data types matter. Java is efficient. It does not guess. You tell it exactly what you need.

2. Two Categories of Data Types

All data types in Java fall into two categories.

Primitive Data Types — basic, built-in types. They hold simple values directly.

Non-Primitive Data Types — complex types like String, Array, and Objects. They hold references to data.

Today we will focus on primitive types — because these are the foundation. Everything else builds on top of them.

Java has exactly 8 primitive data types. Let us go through each one.

3. The 8 Primitive Data Types — Overview

Type	What it stores	Size	Example
`byte`	Small whole number	1 byte	`10`
`short`	Medium whole number	2 bytes	`1500`
`int`	Whole number	4 bytes	`50000`
`long`	Very large whole number	8 bytes	`9999999999L`
`float`	Decimal number	4 bytes	`3.14f`
`double`	Precise decimal number	8 bytes	`3.14159265`
`char`	Single character	2 bytes	`'A'`
`boolean`	True or false	1 bit	`true`

Do not try to memorise all of this right now. Read through each one. It will click as you see examples.

4. Integer Types — Whole Numbers

These four types all store whole numbers. The difference is just how big the number can be.

byte

Stores numbers from -128 to 127.

byte temperature = 36;
byte smallNumber = -50;

System.out.println(temperature);  // 36

Use byte when you know the number will be very small. Saves memory.

Quick question for you.

What do you think happens if you try to store 200 in a byte?

byte b = 200;  // Error!

Java will give you a compile error. 200 is outside the range of -128 to 127. Java catches this mistake before your program even runs.

short

Stores numbers from -32,768 to 32,767.

short population = 25000;
short year = 2025;

System.out.println(year);  // 2025

Bigger than byte. Still smaller than int. Use it when your number fits in this range and memory matters.

int

The most commonly used integer type. Stores numbers from about -2 billion to 2 billion.

int age = 25;
int salary = 75000;
int distance = 1000000;

System.out.println(salary);  // 75000

When you are not sure which integer type to use — use int. It is the default choice for whole numbers in Java.

long

Stores very large numbers. When int is not big enough — use long.

long worldPopulation = 8000000000L;
long distanceToSun = 149600000000L;

System.out.println(worldPopulation);  // 8000000000

Notice the L at the end of the number. That is required. Without it — Java treats the number as an int and it overflows.

Quick question for you.

Why do we need L at the end of a long value?

By default, Java reads any whole number as an int. If the number is too big for an int — Java gets confused before it even assigns it. The L tells Java — "this is a long, not an int." Now Java handles it correctly.

5. Decimal Types — Numbers With a Dot

float

Stores decimal numbers. Less precise. Uses 4 bytes.

float price = 99.99f;
float height = 5.8f;

System.out.println(price);  // 99.99

Notice the f at the end. Same reason as L for long — Java reads decimal numbers as double by default. The f tells Java this is a float.

double

Stores decimal numbers. More precise than float. Uses 8 bytes.

double pi = 3.14159265358979;
double bankBalance = 150000.75;

System.out.println(pi);  // 3.14159265358979

No letter needed at the end. double is Java's default for decimal numbers.

Quick question for you.

When should you use float over double?

When memory is tight — like in embedded systems or when storing millions of values. float uses half the memory of double. But for most everyday programs — just use double. The extra precision is worth it.

6. char — Single Character

char stores exactly one character. Always use single quotes.

char grade = 'A';
char initial = 'R';
char symbol = '@';

System.out.println(grade);   // A
System.out.println(symbol);  // @

Always single quotes for char. Double quotes are for Strings.

char letter = 'A';    // correct
char letter = "A";    // wrong — this is a String, not a char

Something interesting about char — every character has a number behind it called a Unicode value.

char letter = 'A';
System.out.println((int) letter);  // 65

'A' is actually stored as the number 65. 'B' is 66. 'a' is 97.

You can even do arithmetic with chars.

char letter = 'A';
System.out.println((char)(letter + 1));  // B

7. boolean — True or False

boolean stores only two values — true or false. Nothing else.

boolean isLoggedIn = true;
boolean hasDiscount = false;
boolean isAdult = true;

System.out.println(isLoggedIn);   // true
System.out.println(hasDiscount);  // false

This is used everywhere — conditions, flags, checking states.

boolean isEven = (10 % 2 == 0);
System.out.println(isEven);  // true

Quick question for you.

What do you think boolean isEven = (7 % 2 == 0) gives?

7 % 2 gives 1 — the remainder when 7 is divided by 2. 1 == 0 is false. So isEven is false. 7 is not even.

8. Putting It All Together — One Example

Let us use all 8 types in one program.

public class DataTypes {
    public static void main(String[] args) {

        byte age = 25;
        short year = 2025;
        int salary = 75000;
        long worldPopulation = 8000000000L;

        float height = 5.9f;
        double pi = 3.14159265358979;

        char grade = 'A';
        boolean isStudent = false;

        System.out.println("Age: " + age);
        System.out.println("Year: " + year);
        System.out.println("Salary: " + salary);
        System.out.println("World Population: " + worldPopulation);
        System.out.println("Height: " + height);
        System.out.println("Pi: " + pi);
        System.out.println("Grade: " + grade);
        System.out.println("Is Student: " + isStudent);
    }
}

Output:

Age: 25
Year: 2025
Salary: 75000
World Population: 8000000000
Height: 5.9
Pi: 3.14159265358979
Grade: A
Is Student: false

Eight types. One program. All working together.

9. Type Casting — Converting One Type to Another

Sometimes you need to convert one type to another.

There are two kinds.

Widening — automatic, safe

Going from a smaller type to a bigger type. Java does this automatically.

int num = 100;
long bigNum = num;       // int to long — automatic
double decimal = num;    // int to double — automatic

System.out.println(bigNum);    // 100
System.out.println(decimal);   // 100.0

No data is lost. The smaller type fits perfectly inside the bigger one.

Narrowing — manual, you do it yourself

Going from a bigger type to a smaller type. You have to do this manually because data might be lost.

double price = 99.99;
int roundedPrice = (int) price;

System.out.println(roundedPrice);  // 99

(int) tells Java — "I know what I am doing. Convert this double to an int."

The .99 is cut off. Not rounded. Just cut. That is narrowing casting — you lose the decimal part.

Quick question for you.

What do you think (int) 9.9 gives? 9 or 10?

It gives 9. Java does not round — it truncates. Just drops everything after the decimal point. Keep that in mind.

10. Common Mistakes Beginners Make

Forgetting L for long

long big = 9999999999;   // Error — Java reads this as int, too big
long big = 9999999999L;  // Correct

Forgetting f for float

float price = 9.99;    // Error — Java reads this as double
float price = 9.99f;   // Correct

Using double quotes for char

char letter = "A";  // Error — this is a String
char letter = 'A';  // Correct

Storing a value outside the type's range

byte b = 200;   // Error — byte only goes up to 127
int i = 200;    // Correct

Quick Summary — 8 Types in Plain English

byte — tiny whole numbers. -128 to 127. Rare use.
short — small whole numbers. -32,768 to 32,767. Rare use.
int — your go-to whole number type. Use this by default.
long — very large whole numbers. Add L at the end.
float — decimal numbers, less precise. Add f at the end.
double — decimal numbers, more precise. Your go-to decimal type.
char — single character. Always use single quotes.
boolean — only true or false. Used in conditions everywhere.

Data types are the very foundation of Java. Every variable you ever create will have one.

The good news is — in practice, you use int, double, boolean, and char for 90% of everything. The others exist for specific situations.

Try writing the full program from section 8 yourself. Change the values. Try storing a number outside the range. See the error Java gives you. That hands-on experience will make all of this stick.

If you have a question — drop it in the comments below.

Thanks for reading. Keep building.

Java Explained — What It Is, Why It Exists, and How It Actually Runs

DHANRAJ S — Wed, 27 May 2026 14:31:52 +0000

Hey!

Let me ask you something.

You write a program on your Windows laptop. Your friend opens it on a Mac. Your college server runs Linux.

Does the program work on all three?

In most languages — no. You would need to rewrite or recompile it for each system.

Java said — why should that be a problem?

And that one idea changed everything.

1. What Is Java?

Java is a programming language created by James Gosling at Sun Microsystems in 1995.

It is one of the most widely used languages in the world. Android apps, banking systems, enterprise software, web backends — Java is behind a huge part of the technology we use every day.

But what makes Java different from other languages?

One line answers it.

Write once. Run anywhere.

You write Java code once. It runs on Windows, Mac, Linux, Android — without changing a single line.

That is not just a tagline. It is how Java actually works. We will see exactly how in a moment.

2. Why Java? — Before Java, What Was the Problem?

Quick question for you.

Imagine you are a developer in 1990. You write a program in C or C++.

Your program works perfectly on Windows. But your client uses a different operating system. What do you do?

You rewrite the code. Or recompile it specifically for that system. Sometimes both.

Every operating system speaks a different language at the hardware level. A program built for Windows cannot just run on Linux.

This was a real headache for developers and companies. Especially as the internet grew and software needed to run everywhere.

Java solved this with a clever idea — the Java Virtual Machine.

3. How Does Java Actually Run?

This is the part most beginners skip. But it is the most important part to understand.

Let us go step by step.

Step 1 — You write Java code

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

This is your source code. Saved as a .java file.

Step 2 — The compiler converts it to bytecode

When you compile your Java file — the Java compiler does not convert it to machine code for Windows or Mac or Linux.

It converts it to something called bytecode. Saved as a .class file.

Bytecode is not tied to any operating system. It is a middle language. Universal.

Step 3 — The JVM runs the bytecode

Every operating system has its own JVM — Java Virtual Machine — installed.

The JVM on Windows reads the bytecode and translates it for Windows.
The JVM on Mac reads the same bytecode and translates it for Mac.
The JVM on Linux does the same for Linux.

Your Java Code (.java)
        ↓
   Java Compiler
        ↓
   Bytecode (.class)
        ↓
  ┌─────┼─────┐
  ↓     ↓     ↓
 JVM   JVM   JVM
 Win   Mac  Linux

Same bytecode. Different JVMs. Works everywhere.

That is how "write once, run anywhere" actually works. The JVM does the translation work so you do not have to.

4. JDK, JRE, and JVM — What Is the Difference?

These three terms confuse every beginner. Let us clear them up simply.

JVM — Java Virtual Machine

Runs the bytecode. Every OS has its own JVM. This is what makes Java platform-independent.

JRE — Java Runtime Environment

JRE = JVM + libraries needed to run Java programs.

If you just want to run a Java program — install the JRE.

JDK — Java Development Kit

JDK = JRE + compiler + development tools.

If you want to write and compile Java programs — install the JDK.

Simple rule.

User who just runs Java apps → JRE.
Developer who writes Java code → JDK.

5. Your First Java Program — Let Us Read It

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

Quick question for you.

Before reading the explanation — can you guess what System.out.println does?

System.out.println("Hello, World!") — prints the text to the screen. Like print() in Python or console.log() in JavaScript.

public static void main(String[] args) — this is the entry point. Every Java program starts running from here. It is the first thing Java looks for when it runs your program.

public class Hello — in Java, everything lives inside a class. The class name must match the file name. This file must be saved as Hello.java.

6. Features of Java

These are the reasons Java has lasted 30 years and is still going strong.

Platform Independent

Already explained. Write once. Run anywhere. The JVM handles the rest.

Object Oriented

Everything in Java is built around objects and classes. This makes large programs easier to organize, reuse, and maintain.

Real world example — a Car class has properties like color and speed, and actions like start() and stop(). You create as many car objects as you need from that one class.

Strongly Typed

In Java — you must declare the type of every variable.

int age = 25;
String name = "Ravi";
double price = 99.99;

You cannot put a string where a number is expected. Java catches this mistake before your program even runs. That means fewer bugs in production.

Automatic Memory Management

In C or C++ — you manage memory yourself. You allocate it. You free it. Forget to free it — your program leaks memory and slows down.

Java has a garbage collector. It automatically cleans up memory that is no longer needed. You focus on the logic. Java handles the memory.

Multithreading

Java can run multiple tasks at the same time.

Think of a banking app. One thread handles your login. Another thread processes a transaction. Another thread refreshes your balance. All happening together — without one waiting for the other.

Java has built-in support for this.

Secure

Java runs inside the JVM — which acts as a sandbox. Your Java program cannot directly access your operating system or hardware without permission. This makes Java a safer choice for web and enterprise applications.

Robust

Java checks for errors at two stages — when you compile and when you run. It has strong exception handling. Programs do not just crash silently. Errors are caught and handled properly.

7. Where Is Java Used Today?

Quick question for you.

Can you guess which mobile operating system runs on Java?

Android. Every Android app was traditionally written in Java. Even today — Kotlin, the newer Android language, runs on the same JVM.

Beyond mobile — Java is used in:

Banking and finance systems — most major banks run Java backends
Web applications — Spring is one of the most popular backend frameworks, built on Java
Enterprise software — large companies like Amazon, LinkedIn, and Uber use Java in their backend
Big Data — Hadoop and Kafka, which process massive amounts of data, are written in Java
Embedded systems — Java runs on smart cards, set-top boxes, and other devices

8. Java vs Other Languages — A Simple Comparison

	Java	Python	JavaScript
Speed	Fast	Slower	Medium
Syntax	Verbose but clear	Very clean	Flexible
Typing	Strongly typed	Dynamically typed	Dynamically typed
Best for	Enterprise, Android, Big Data	Data science, scripting, AI	Web frontend and backend
Platform	JVM — runs anywhere	Interpreter per OS	Browser or Node.js
Learning curve	Moderate	Easy	Easy to start

Java is more verbose than Python. But that verbosity makes large codebases easier to read and maintain. When you are working in a team on a million-line codebase — clarity matters more than brevity.

Quick Summary — 5 Things to Remember

Java was created in 1995 — and is still one of the most used languages in the world. Banking, Android, enterprise software — Java is everywhere.
Write once, run anywhere — Java compiles to bytecode, not machine code. The JVM on each OS runs that bytecode. Same code. Every platform.
JDK to write code. JRE to run code. JVM to execute bytecode — install JDK if you are learning Java.
Strongly typed and object oriented — every variable has a type. Everything is built around classes and objects. This makes Java safe and organized.
Automatic garbage collection — Java manages memory for you. No manual allocation or freeing.

Java might look more complex than Python or JavaScript at first. More lines. More structure. More rules.

But that structure is exactly what makes Java reliable for large, serious applications.

Once you get comfortable with the syntax — you will appreciate how organized Java forces you to be.

Start with the Hello World program above. Then try creating a simple class with a few variables and methods. That is where Java starts to make sense.

If you have a question — drop it in the comments below.

Thanks for reading. Keep building.

Python Loops Explained — With a Frog Trying to Escape a Tank

DHANRAJ S — Tue, 26 May 2026 06:27:18 +0000

Hey!

Before we start — let me give you a small puzzle.

A frog is stuck at the bottom of a 50 feet tall tank.

Every day — it jumps up 2 feet.
Every night — it slides back down 1.25 feet.

How many days does it take for the frog to escape the tank?

Take a guess. Write down your answer.

We are going to solve this with Python loops. And by the end — you will understand loops better than most beginners do.

Let us start.

1. What Is a Loop?

A loop is a way to run the same code again and again — until a condition is met.

Think of it like an alarm clock.

It keeps ringing. Every minute. Every minute. Every minute. Until you wake up and turn it off.

That "until you turn it off" part — that is your condition.

In Python — there are two types of loops.

for loop — runs a fixed number of times
while loop — runs until a condition becomes false

2. The for Loop

A for loop runs for a specific number of times. You know the count before it starts.

for i in range(5):
    print(i)

Output:

range(5) gives numbers from 0 to 4. Five numbers. Loop runs five times.

Quick question for you.

What do you think range(1, 6) gives?

for i in range(1, 6):
    print(i)

Output:

range(start, stop) — starts at 1, stops before 6. So 1 to 5.

3. The while Loop

A while loop keeps running as long as a condition is true. You do not need to know the count upfront. It just keeps going until something changes.

count = 0

while count < 5:
    print(count)
    count += 1

Output:

while count < 5 — keep running as long as count is less than 5.

count += 1 — increase count by 1 every time. Without this — the loop runs forever.

Quick question for you.

What happens if you forget to write count += 1?

The count stays 0 forever. 0 < 5 is always true. The loop never stops. That is called an infinite loop. Your program hangs.

Always make sure your while loop has a way to eventually become false.

4. break and continue — Two Useful Keywords

break — stops the loop immediately.

for i in range(10):
    if i == 5:
        break
    print(i)

Output:

When i hits 5 — break exits the loop. 5, 6, 7, 8, 9 never print.

continue — skips the current step and goes to the next one.

for i in range(6):
    if i == 3:
        continue
    print(i)

Output:

When i is 3 — continue skips it. The loop continues from 4.

5. Now — The Frog Problem

Let us read it again carefully.

Tank height: 50 feet
Frog starts at: 0 feet
Day jump: +2 feet
Night slide: -1.25 feet
Question: How many days to escape?

Before you see the code — think about this.

What kind of loop should we use here — for or while?

We do not know how many days it will take. We keep going until the frog escapes.

That means — while loop. We run until the frog's position reaches 50 feet.

6. The Python Code

tankHeight = 50
nightSlide = 1.25
dayJump = 2
day = 0

while tankHeight > 0:
    tankHeight = tankHeight - dayJump + nightSlide
    day += 1

print(day)

Clean. Simple. Short.

Let us read it line by line.

tankHeight = 50 — the tank starts at 50 feet. This is the remaining height the frog needs to cover.

nightSlide = 1.25 — how much the frog slides back every night.

dayJump = 2 — how much the frog jumps every day.

day = 0 — day counter starts at zero.

while tankHeight > 0 — keep looping as long as there is tank height remaining.

tankHeight = tankHeight - dayJump + nightSlide — every loop reduces the remaining height. Frog jumps 2 feet up — so we subtract 2. But slides 1.25 feet back — so we add 1.25 back. Net reduction per day = 0.75 feet.

day += 1 — count the day.

print(day) — when the loop ends, print how many days it took.

Quick question for you.

Why do we write - dayJump + nightSlide and not - dayJump - nightSlide?

Because tankHeight is the remaining distance. When the frog jumps up — remaining distance goes down. So we subtract dayJump. When the frog slides back — remaining distance goes up again. So we add nightSlide back.

Subtracting progress. Adding back the slide. That is the logic.

7. What Is the Output?

Run it and see.

That is it. The frog escapes on day 49.

No extra print statements. No step-by-step logging. Just the answer — clean and direct.

Quick question for you.

Did you guess 49 at the start?

Most people guess something between 30 and 45. Because they think — "50 divided by 0.75 is about 66." But that formula is wrong. The frog does not slide back on the last day. So the actual answer is less.

The loop handles this correctly because it checks tankHeight > 0 after each full day including the slide. When the tank height goes to 0 or below — the loop stops and we count that day.

That is the beauty of loops. No formula needed. Just describe what happens each day — and let the loop repeat it until the condition is met.

8. What Did We Learn About Loops From This?

The frog problem taught us something important.

You do not always know how many times a loop will run.

Sometimes you just know the condition — "keep going until the frog escapes." That is a while loop.

Sometimes you know the exact count — "do this 10 times." That is a for loop.

And break is your emergency exit — when something happens mid-loop and you need to stop immediately.

In the frog problem — break is the moment the frog jumps out. We do not let it fall back. We stop right there.

Quick Summary — 5 Things to Remember

for loop — use when you know how many times to repeat. for i in range(n).
while loop — use when you do not know the count. Keep running until a condition is false.
break — exits the loop immediately. Used when the goal is reached mid-loop.
continue — skips the current step and moves to the next one.
Always have an exit condition in while loops — otherwise your loop runs forever and your program hangs.

Loops are everywhere in programming. Search results. Payments. Games. Animations. Any time something needs to repeat — there is a loop behind it.

The frog problem is a great way to practice because it has a real-world feel. Days passing. A goal to reach. A condition to check each step.

Try changing the numbers. Make the tank 200 feet. Make the frog jump 5 feet but slide back 4.9 feet. See how many days it takes.

Then try writing it without looking at the code above.

That is when you know loops have clicked.

If you have a question — drop it in the comments below.

Thanks for reading. Keep building.

Redux Explained — Why It Exists and How to Use It Simply

DHANRAJ S — Fri, 22 May 2026 09:18:22 +0000

Hey!

Before we start — let me show you a situation.

You are building a medium-sized React app. You have a logged-in user. Their name shows in the Navbar. Their profile shows on the Profile page. Their orders show on the Orders page.

All three need the same user data.

So you put the user in the top-level component and pass it down through props.

It works. But then your app grows.

More components need the user. More props get passed. More levels get added. You already learned about useContext — and yes, it helps.

But now imagine this.

Your app has a shopping cart. A notification system. A theme setting. A logged-in user. All of this is global data. All of it needs to be accessible from many places. All of it can change at any time.

You have multiple contexts. Multiple providers wrapping each other. Managing all these state changes becomes messy. Debugging becomes harder. "Which context changed and why?" becomes a real question.

That is the problem Redux solves.

1. What Is Redux?

Redux is a state management library.

It gives you one central place to store all your app's data. One single source of truth. Every component reads from it. Every component updates through it.

Think of it like a government database.

Every department — health, transport, education — does not keep its own separate records. They all read from and write to one central database. One source. Always accurate. Always in sync.

That central database is your Redux store.

2. The Three Core Ideas in Redux

Redux is built on three simple ideas. Understand these and everything else makes sense.

Store — the single source of truth

The store holds your entire app's state in one object.

{
  user: { name: "Ravi", role: "admin" },
  cart: { items: [], total: 0 },
  theme: "dark"
}

One object. Your whole app's state. Right there.

Action — describing what happened

An action is a plain object that describes what event just happened.

{ type: "ADD_TO_CART", payload: { id: 1, name: "Laptop", price: 50000 } }
{ type: "REMOVE_FROM_CART", payload: 1 }
{ type: "LOGOUT_USER" }

type — what happened.
payload — any extra data needed.

You never change the store directly. You send an action and say "this happened."

Reducer — deciding what changes

The reducer is a function that takes the current state and an action — and returns the new state.

function cartReducer(state = { items: [] }, action) {
  switch (action.type) {
    case "ADD_TO_CART":
      return { items: [...state.items, action.payload] };
    case "REMOVE_FROM_CART":
      return { items: state.items.filter(item => item.id !== action.payload) };
    default:
      return state;
  }
}

Sound familiar? Yes — same idea as useReducer. Redux takes this concept and makes it work at the app level.

3. The Redux Flow — How It All Connects

This is the part most beginners find confusing. Let us make it crystal clear.

User does something
      ↓
Component dispatches an Action
      ↓
Reducer receives Action + current State
      ↓
Reducer returns new State
      ↓
Store updates
      ↓
All components that need that data re-render

One direction. Always. No shortcuts.

This is called unidirectional data flow. And it is what makes Redux so predictable and easy to debug.

Quick question for you.

Why do you think having one direction for data flow makes debugging easier?

Because you always know where to look. Something went wrong? Check what action was dispatched. Check what the reducer did with it. The trail is always clear. No guessing which component updated which state.

4. Setting Up Redux in a React App

Modern Redux uses Redux Toolkit — the official recommended way. It removes a lot of the old boilerplate.

Install it:

npm install @reduxjs/toolkit react-redux

5. A Simple Example — Counter With Redux

Let us build the simplest possible Redux example. A counter.

Step 1 — Create a slice

A slice is a piece of your Redux store. It holds the state and the reducers for one feature.

// store/counterSlice.js
import { createSlice } from "@reduxjs/toolkit";

const counterSlice = createSlice({
  name: "counter",
  initialState: { count: 0 },
  reducers: {
    increment(state) {
      state.count += 1;
    },
    decrement(state) {
      state.count -= 1;
    },
    reset(state) {
      state.count = 0;
    }
  }
});

export const { increment, decrement, reset } = counterSlice.actions;
export default counterSlice.reducer;

createSlice handles the action creators and reducer for you. No need to write them separately.

Step 2 — Create the store

// store/store.js
import { configureStore } from "@reduxjs/toolkit";
import counterReducer from "./counterSlice";

const store = configureStore({
  reducer: {
    counter: counterReducer
  }
});

export default store;

Step 3 — Provide the store to your app

// main.jsx
import { Provider } from "react-redux";
import store from "./store/store";

ReactDOM.createRoot(document.getElementById("root")).render(
  <Provider store={store}>
    <App />
  </Provider>
);

Provider makes the store available to every component inside it. Just like Context Provider — but for Redux.

Step 4 — Use it in a component

// Counter.jsx
import { useSelector, useDispatch } from "react-redux";
import { increment, decrement, reset } from "./store/counterSlice";

function Counter() {
  const count = useSelector(state => state.counter.count);
  const dispatch = useDispatch();

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => dispatch(increment())}>+1</button>
      <button onClick={() => dispatch(decrement())}>-1</button>
      <button onClick={() => dispatch(reset())}>Reset</button>
    </div>
  );
}

useSelector — reads data from the store. Like saying "give me this piece of the store."

useDispatch — gives you the dispatch function. You use it to send actions to the store.

Quick question for you.

Can you use useSelector in two different components — and both will always show the same up-to-date value?

Yes. Because both are reading from the same store. When the store updates — both components re-render with the latest value automatically. That is the power of a single source of truth.

6. What Does the Full Flow Look Like?

Let us trace through clicking the +1 button:

User clicks +1
      ↓
dispatch(increment()) fires
      ↓
Redux sends action { type: "counter/increment" } to the reducer
      ↓
Reducer runs: state.count += 1
      ↓
Store updates: count is now 1
      ↓
Counter component re-renders
      ↓
Screen shows: Count: 1

Every step is visible. Every step is traceable.

7. useContext vs Redux — Which One to Use?

This is the question everyone asks. Both manage global state. So when do you use which?

	useContext	Redux
Best for	Simple global data — theme, user, language	Complex state with many interactions
Setup	Very simple	More setup needed
Dev tools	No	Yes — powerful Redux DevTools
Scalability	Gets messy at large scale	Built for large apps
When state changes	All context consumers re-render	Only components that use that slice re-render

Simple rule.

Small app with simple global state — useContext is enough.

Large app with complex state, many features, many interactions — Redux is worth it.

Do not reach for Redux on day one. Start simple. Add Redux when you actually feel the pain of managing state without it.

8. Why Redux Is Still Worth Learning

You might be thinking — "this feels like a lot of setup for a counter."

Fair point. For a counter — it is overkill.

But Redux is used in large production apps for real reasons.

Redux DevTools let you time-travel through every state change. You can replay actions, inspect what changed, and debug issues in seconds.

Every state change has a clear action and a clear trail. No mystery updates. No wondering which component changed what.

Teams working on the same codebase can follow the same pattern. Everyone knows where the state is and how it changes.

Quick Summary — 5 Things to Remember

Redux is a central store for all your app state — one place, one source of truth, every component reads from it.
Actions describe what happened — you never change the store directly. You dispatch an action and let the reducer handle it.
Reducers decide the new state — they take the current state and the action, and return what the state should look like next.
useSelector reads from the store. useDispatch sends actions — these two hooks are how your components talk to Redux.
Use Redux when your app is actually complex — for simple apps, useContext is enough. Redux shines when state management becomes genuinely hard.

Redux felt intimidating when it first came out. The old way had a lot of boilerplate. Redux Toolkit fixed most of that.

Today — setting up Redux is straightforward. And once you see the DevTools in action, time-travelling through state changes, you will understand why large teams rely on it.

Try the counter example. Add a new slice for a theme toggle. See how two completely separate slices live in the same store and work independently.

That is the moment Redux starts to make sense.

If you have a question — drop it in the comments below.

Thanks for reading. Keep building.

useRef in React — Why It Exists and How to Use It Simply

DHANRAJ S — Wed, 20 May 2026 17:54:42 +0000

Hey!

Let me ask you something.

You have an input field in React. When the page loads — you want the cursor to automatically focus on that input. So the user can start typing right away without clicking it first.

How do you do that?

In plain JavaScript it is simple.

document.getElementById("myInput").focus();

But in React — you do not touch the DOM directly like that. React manages the DOM for you.

So how do you access a real DOM element in React?

That is exactly what useRef is for.

1. What Is useRef?

useRef is a React hook that gives you a way to directly access a DOM element or store a value that does not cause a re-render when it changes.

It returns an object with one property — current.

const myRef = useRef(null);

// myRef looks like this:
// { current: null }

When you attach it to a DOM element — current holds that element. You can then do anything you would normally do with a DOM element.

Think of it like putting a sticky note on a specific element in your app. Whenever you need that element — you check the sticky note and find it instantly.

2. The Problem Without useRef

Let us say you want to focus an input when the page loads.

Without useRef — you might try this:

function SearchPage() {
  document.getElementById("search").focus(); // too early — element not ready yet

  return <input id="search" type="text" placeholder="Search..." />;
}

This does not work.

When this line runs — the input is not in the DOM yet. React has not rendered it. So getElementById returns null and .focus() crashes.

useRef solves this cleanly.

3. The Syntax

import { useRef } from "react";

function MyComponent() {
  const inputRef = useRef(null);

  return <input ref={inputRef} type="text" />;
}

useRef(null) — creates a ref with current set to null at first.

ref={inputRef} — you attach it to the element. Once React renders the input — inputRef.current points to that real DOM element.

Now you can call any DOM method on it — .focus(), .blur(), .scrollIntoView().

4. Example 1 — Auto Focus Input

import { useRef, useEffect } from "react";

function SearchPage() {
  const inputRef = useRef(null);

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

  return (
    <div>
      <input ref={inputRef} type="text" placeholder="Search..." />
    </div>
  );
}

What happens here:

Page loads
  → React renders the input
  → useEffect runs once
  → inputRef.current is now the real input element
  → .focus() puts the cursor there automatically

The user lands on the page. Cursor is already in the input. Ready to type.

Quick question for you.

Why do we put .focus() inside useEffect and not directly in the component body?

Because the component body runs before React renders anything to the screen. The input does not exist yet at that point. useEffect runs after the render — so the element is there and ready.

5. Example 2 — Store a Value Without Re-Rendering

This is the second use of useRef — and it surprises most beginners.

useRef can also store any value — not just DOM elements. And when that value changes — the component does not re-render.

That is the key difference from useState.

import { useRef, useState } from "react";

function Timer() {
  const [isRunning, setIsRunning] = useState(false);
  const intervalRef = useRef(null);

  function start() {
    setIsRunning(true);
    intervalRef.current = setInterval(() => {
      console.log("tick");
    }, 1000);
  }

  function stop() {
    setIsRunning(false);
    clearInterval(intervalRef.current);
  }

  return (
    <div>
      <p>{isRunning ? "Running..." : "Stopped"}</p>
      <button onClick={start}>Start</button>
      <button onClick={stop}>Stop</button>
    </div>
  );
}

intervalRef stores the timer ID from setInterval.

When you click Stop — intervalRef.current gives you that ID and clearInterval stops the timer.

Quick question for you.

Why not use useState to store the interval ID instead of useRef?

Because updating state causes a re-render. You do not need the screen to update when the interval ID changes — you just need to remember it so you can clear it later. useRef stores it silently. No re-render. No side effects.

6. useRef vs useState — The Key Difference

This is the thing that confuses most beginners.

Both store values. But they behave very differently.

	useState	useRef
Re-renders on change	Yes	No
Shows value on screen	Yes	No
Access DOM elements	No	Yes
Best for	UI values — count, input, toggle	DOM access, timers, previous values

Simple rule.

If changing the value should update what the user sees — use useState.

If you just need to remember something quietly in the background — use useRef.

7. One Common Mistake

Reading ref.current too early — before React has rendered the element.

function MyComponent() {
  const inputRef = useRef(null);

  console.log(inputRef.current); // null — element not rendered yet

  useEffect(() => {
    console.log(inputRef.current); // the real input element — safe to use here
  }, []);

  return <input ref={inputRef} />;
}

Always access ref.current inside useEffect or inside an event handler — never directly in the component body.

By the time useEffect runs or a user clicks a button — React has already rendered the element. It is safe.

Quick Summary — 4 Things to Remember

useRef gives you access to DOM elements — attach it with the ref prop and use ref.current to call DOM methods like .focus().
useRef stores values without re-rendering — perfect for storing timer IDs, previous values, or anything you need to remember but not show on screen.
ref.current starts as null — it only gets the real element after React renders it. Always access it inside useEffect or event handlers.
useRef vs useState — useState triggers re-renders and updates the UI. useRef stores silently. Use the right one for the right job.

useRef is one of those hooks that feels unnecessary at first — until you need to focus an input or stop a timer and you realise it is the cleanest way to do it.

Try the auto focus example. Build it. Load the page. See the cursor land in the input automatically. Then try the timer. Start it. Stop it. See how the interval ID is stored and cleared cleanly.

That hands-on time will make it stick.

If you have a question — drop it in the comments below.

Thanks for reading. Keep building.

Debouncing and Throttling in JavaScript — Explained Simply

DHANRAJ S — Tue, 19 May 2026 16:50:16 +0000

Hey!

Let me ask you something.

You have a search input. Every time the user types a letter — you send an API request to search.

User types "react" — that is 5 letters. That is 5 API calls. In under a second.

Now imagine 1000 users doing the same thing. Your server gets hammered with thousands of unnecessary requests. All for results the user never even waited to see.

That is a real problem. And debouncing is one of the ways to fix it.

But there is another situation too.

User scrolls a page. You want to run some code on every scroll event. The scroll event fires hundreds of times per second. Your code runs hundreds of times per second. Your app slows down noticeably.

That is a different problem. And throttling is the fix for that one.

Same goal — control how often something runs. Different approach. Let us understand both.

1. What Is Debouncing?

Debouncing means — wait until the user stops doing something, then run the function once.

Think of it like an elevator.

The elevator doors start to close. Someone puts their hand in. Doors open again. Timer resets. They wait. Another person runs in. Timer resets again.

The elevator only moves when nobody interrupts for a full few seconds.

That is debouncing. The function only fires after a pause in activity.

2. The Problem Without Debouncing

const input = document.getElementById("search");

input.addEventListener("input", () => {
  console.log("API call for:", input.value);
});

User types "react" quickly.

API call for: r
API call for: re
API call for: rea
API call for: reac
API call for: react

Five API calls. For one word. Most of them useless.

The user only cared about the result for "react" — not "r", "re", "rea", or "reac".

3. Debouncing — The Fix

function debounce(func, delay) {
  let timer;

  return function(...args) {
    clearTimeout(timer);
    timer = setTimeout(() => {
      func(...args);
    }, delay);
  };
}

Let us understand this step by step.

timer — stores the setTimeout reference.

Every time the function is called — clearTimeout(timer) cancels the previous timer. A new timer starts.

If the function is called again before the timer finishes — the timer resets. Again. And again.

Only when the user stops for the full delay duration — the timer completes and the function runs. Once.

4. Using Debounce on the Search Input

function searchAPI(value) {
  console.log("API call for:", value);
}

const debouncedSearch = debounce(searchAPI, 500);

const input = document.getElementById("search");

input.addEventListener("input", () => {
  debouncedSearch(input.value);
});

Now when the user types "react" quickly:

typing r   → timer starts
typing e   → timer resets
typing a   → timer resets
typing c   → timer resets
typing t   → timer resets
...500ms pause...
API call for: react   ← fires once

One API call. For the complete word. That is debouncing.

Quick question for you.

What happens if the user types very slowly — one letter every second — with a 500ms debounce?

Each letter has more than 500ms of pause after it. So the API fires after every single letter. Debounce does not batch them — it just waits for a pause. If the pause is long enough between each letter — each one triggers separately.

5. What Is Throttling?

Throttling means — run the function at most once every X milliseconds. No matter how many times it is triggered.

Think of it like a tap with a flow controller.

You can open the tap fully. But the controller limits how much water comes out per second. The flow is controlled. Steady. Not a flood.

That is throttling. Steady execution at a fixed rate — no matter how fast events are firing.

6. The Problem Without Throttling

window.addEventListener("scroll", () => {
  console.log("scroll fired");
});

Scroll down for 2 seconds.

scroll fired
scroll fired
scroll fired
scroll fired
... (hundreds of times)

The scroll event fires maybe 100 times per second. If your scroll handler is doing heavy work — calculating positions, animating elements, fetching data — your app starts to stutter.

7. Throttling — The Fix

function throttle(func, limit) {
  let lastCall = 0;

  return function(...args) {
    const now = Date.now();

    if (now - lastCall >= limit) {
      lastCall = now;
      func(...args);
    }
  };
}

lastCall — stores the timestamp of the last time the function actually ran.

Every time the function is triggered — it checks how much time has passed since the last run.

If enough time has passed — it runs and updates lastCall.

If not enough time has passed — it skips. No run.

8. Using Throttle on the Scroll Event

function handleScroll() {
  console.log("scroll handled at:", Date.now());
}

const throttledScroll = throttle(handleScroll, 500);

window.addEventListener("scroll", throttledScroll);

Now when you scroll continuously for 3 seconds:

scroll handled at: 1000ms
scroll handled at: 1500ms
scroll handled at: 2000ms
scroll handled at: 2500ms
scroll handled at: 3000ms

Runs once every 500ms. Steady. Controlled. Your app stays smooth.

Quick question for you.

What is the difference between what debounce and throttle would do here?

Debounce would wait until you stop scrolling — then fire once. Throttle fires regularly while you are still scrolling — just at a controlled rate.

For scroll — throttle makes more sense. You want the handler to run during scrolling, just not hundreds of times per second.

9. Debounce vs Throttle — Side by Side

	Debounce	Throttle
When it runs	After the user stops	At regular intervals while active
Fires	Once after a pause	Once every X milliseconds
Best for	Search input, resize handler	Scroll, mouse move, button spam
Think of it as	Wait for silence	Steady drip

10. Where Are These Used in Real Life?

Debounce is used for:

Search inputs — wait until user stops typing, then search
Window resize — wait until user stops resizing, then recalculate layout
Form validation — wait until user stops typing, then validate

Throttle is used for:

Scroll events — run handler steadily while scrolling
Mouse move — track position without firing every pixel
Button clicks — prevent double submitting a form

Quick Summary — 3 Things to Remember

Debounce — waits for the user to stop, then fires once. Good for search inputs and resize events.
Throttle — fires at a fixed rate no matter how many events come in. Good for scroll and mouse move.
Both control how often a function runs — debounce delays until quiet, throttle limits to once per interval.

These two are asked in almost every JavaScript interview. Not just because they are useful — but because understanding them shows you actually think about performance.

Try building the search input example. Open the console. Type fast. Watch only one API call fire. Then remove the debounce. Type fast again. Watch the difference.

That hands-on comparison will make it stick better than any explanation.

If you have a question — drop it in the comments below.

Thanks for reading. Keep building.

useMemo in React — Why It Exists and How to Use It Simply

DHANRAJ S — Thu, 14 May 2026 17:01:28 +0000

Hey!

Let me ask you something first.

Every time state changes in React — what happens?

The component re-renders. Every line inside it runs again from top to bottom.

Most of the time — that is fine. But what if one of those lines is doing a heavy calculation? Something that takes real time to compute?

That calculation runs again. Every single render. Even when nothing related to it changed.

That is the problem useMemo fixes.

1. What Is the Problem?

Let us see it in code.

import { useState } from "react";

function App() {
  const [count, setCount] = useState(0);
  const [input, setInput] = useState("");

  function slowCalculation(num) {
    console.log("Calculating...");
    let result = 0;
    for (let i = 0; i < 1000000000; i++) {
      result += num;
    }
    return result;
  }

  const result = slowCalculation(count);

  return (
    <div>
      <p>Result: {result}</p>
      <button onClick={() => setCount(count + 1)}>Increment Count</button>

      <input
        value={input}
        onChange={e => setInput(e.target.value)}
        placeholder="Type something..."
      />
    </div>
  );
}

Quick question for you.

When you type in the input box — does slowCalculation need to run again?

No. The count did not change. The calculation result is still the same.

But React does not know that. It just re-renders everything. So slowCalculation runs again on every keystroke.

Type one letter — calculation runs.
Type another — calculation runs again.

Your app feels slow and unresponsive. All because of an unnecessary recalculation.

That is exactly where useMemo helps.

2. What Is useMemo?

useMemo is a React hook that remembers the result of a calculation.

It only recalculates when the values it depends on actually change.

If nothing it depends on changed — it skips the calculation and returns the saved result from last time.

Think of it like a calculator with memory.

You calculate 2345 * 6789. You press the memory button. Next time someone asks for the same result — the calculator gives it from memory instantly. No recalculating.

useMemo is that memory button for your React components.

3. The Syntax

const result = useMemo(() => {
  return someHeavyCalculation(value);
}, [value]);

() => { return ... } — the function that does the calculation.

[value] — the dependency array. useMemo only recalculates when value changes.

If value did not change since last render — useMemo skips the function and returns the saved result.

Looks familiar? Yes — the dependency array works exactly like useEffect.

4. Fixing the Problem With useMemo

Let us fix the slow example from above.

import { useState, useMemo } from "react";

function App() {
  const [count, setCount] = useState(0);
  const [input, setInput] = useState("");

  function slowCalculation(num) {
    console.log("Calculating...");
    let result = 0;
    for (let i = 0; i < 1000000000; i++) {
      result += num;
    }
    return result;
  }

  const result = useMemo(() => {
    return slowCalculation(count);
  }, [count]);

  return (
    <div>
      <p>Result: {result}</p>
      <button onClick={() => setCount(count + 1)}>Increment Count</button>

      <input
        value={input}
        onChange={e => setInput(e.target.value)}
        placeholder="Type something..."
      />
    </div>
  );
}

Now what happens when you type in the input?

input changes. Component re-renders. But count did not change. So useMemo skips slowCalculation and returns the saved result instantly.

console.log("Calculating...") does not even fire.

Type in the input — smooth. No slowdown.

Click Increment — count changes. Now useMemo recalculates. Because count is in the dependency array.

5. A Simple Real Example — Filtered List

Let us build something more practical.

You have a list of names. A search input filters the list. The filtering runs only when the list or search term changes — not on every render.

import { useState, useMemo } from "react";

const names = ["Ravi", "Anu", "Karthik", "Priya", "Arjun", "Meena", "Vijay"];

function NameList() {
  const [search, setSearch] = useState("");
  const [count, setCount] = useState(0);

  const filteredNames = useMemo(() => {
    console.log("Filtering names...");
    return names.filter(name =>
      name.toLowerCase().includes(search.toLowerCase())
    );
  }, [search]);

  return (
    <div>
      <input
        value={search}
        onChange={e => setSearch(e.target.value)}
        placeholder="Search names..."
      />

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

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

Quick question for you.

When you click the button — does the filter run again?

No. search did not change. useMemo returns the saved filtered list.

When you type in the search box — search changes. Now useMemo runs the filter. Because search is in the dependency array.

The filter only runs when it actually needs to. Not on every button click. Not on every unrelated state change.

6. When Should You Use useMemo?

useMemo is useful — but it is not for everything.

Use it when:

You have a calculation that is genuinely slow or complex
The calculation result is used in rendering
The component re-renders often but the calculation inputs do not always change

Do not use it when:

The calculation is simple — adding two numbers, filtering a small array of 5 items
The component rarely re-renders
You are just trying to "optimise everything" — that is over-engineering

Quick question for you.

Should you wrap 2 + 2 inside useMemo?

No. useMemo itself has a small cost — it needs to store the result and check the dependencies on every render. For something as simple as 2 + 2 — that overhead is more expensive than just calculating it again.

Use useMemo only when the calculation is actually heavy.

7. useMemo vs useEffect — What Is the Difference?

These two both have a dependency array. Beginners sometimes mix them up.

	useMemo	useEffect
What it does	Remembers a calculated value	Runs side effects
Returns	The calculated value	Nothing
When it runs	During render	After render
Use for	Expensive calculations	Fetch, timers, subscriptions

Simple way to remember.

useMemo — "give me a value, but only recalculate when needed."

useEffect — "run this code after something changes."

8. One Common Mistake

Using useMemo for everything — even simple things.

// Overkill — this is too simple to need useMemo
const double = useMemo(() => count * 2, [count]);

// Just do this
const double = count * 2;

useMemo adds overhead. For simple operations — it makes your code slower, not faster.

Only reach for useMemo when you actually feel the slowness. Premature optimisation makes code harder to read for no real gain.

Quick Summary — 4 Things to Remember

React re-renders run every line again — including heavy calculations that did not need to run.
useMemo remembers the result — it only recalculates when the values in the dependency array change.
Use it for genuinely heavy calculations — filtering large lists, complex math, expensive data transformations.
Do not overuse it — simple operations do not need useMemo. The hook itself has a cost. Use it only when you feel the performance problem.

useMemo is one of those hooks you do not need until you need it badly.

When your app starts feeling slow in a specific spot — check if there is a heavy calculation running on every render. Wrap it in useMemo. Watch it become smooth again.

Try the filtered list example above. Add more names. Make the list bigger. Type in the search box and watch the console. Then click the button and see useMemo skip the filter entirely.

That moment when you see it skip — that is when it clicks.

If you have a question — drop it in the comments below.

Thanks for reading. Keep building.

useReducer in React — Why It Exists and How to Use It Simply

DHANRAJ S — Wed, 13 May 2026 17:24:35 +0000

Hey!

Before we start — let me show you a problem.

You are building a simple counter. You use useState.

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

Works perfectly. No complaints.

Now the requirements change.

Your counter needs to:

Increment by 1
Decrement by 1
Reset to 0
Increment by a custom amount
Decrement by a custom amount

So you start adding more logic.

function increment() {
  setCount(count + 1);
}

function decrement() {
  if (count > 0) {
    setCount(count - 1);
  }
}

function reset() {
  setCount(0);
}

function incrementByAmount(amount) {
  setCount(count + amount);
}

function decrementByAmount(amount) {
  if (count - amount >= 0) {
    setCount(count - amount);
  }
}

Five separate functions. All of them scattered around your component. All of them touching the same state in different ways.

Now imagine your component has 3 or 4 pieces of state — not just a counter. All with their own update functions.

Your component becomes a mess. Hard to read. Hard to debug. Hard to maintain.

That is the problem useReducer solves.

1. What Is the Real Problem With useState?

useState is great. For simple state — a number, a boolean, a string — it is perfect.

But when your state has many ways to update — things fall apart.

Here is specifically what goes wrong:

Logic is scattered.

Every update has its own function. Those functions are spread all over the component. When a bug appears — you have to hunt through all of them to find it.

Hard to see the full picture.

When you read the component — you cannot easily answer "what are all the ways this state can change?" You have to read every function one by one.

State updates depend on each other.

Sometimes changing one value should affect another. With multiple useState calls — coordinating this gets messy fast.

Quick question for you.

Imagine you have a shopping cart with items, totalPrice, and itemCount. Every time you add an item — all three need to update together. How would you handle that with useState?

You would need to call three setters every single time. Miss one — your UI shows wrong data.

That is where useReducer shines.

2. What Is useReducer?

useReducer is a React hook that manages state through a single function called a reducer.

Instead of calling different setter functions — you send an action. The reducer decides how the state changes based on that action.

Think of it like a bank teller.

You do not walk into a bank and directly change the numbers in the computer yourself. You give the teller an instruction — "deposit 500" or "withdraw 200". The teller looks at your current balance, applies the instruction, and gives you the new balance.

The teller is the reducer.
Your instruction is the action.
The balance is the state.

3. The Syntax

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

Let us break this down.

state — the current state. Whatever is stored right now.

dispatch — the function you call to trigger a state change. You pass it an action.

reducer — a function you write that takes the current state and the action, and returns the new state.

initialState — the starting value of your state.

4. What Is a Reducer Function?

The reducer is where all your state logic lives. In one place.

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return state + 1;
    case "decrement":
      return state - 1;
    case "reset":
      return 0;
    default:
      return state;
  }
}

state — what the state currently is.

action — an object that describes what happened. It has a type property that tells the reducer what to do.

The reducer reads the action.type and returns the new state.

That is it. Nothing magic. Just a function with a switch statement.

5. Fixing the Counter — Using useReducer

Let us rewrite the messy counter from the beginning using useReducer.

import { useReducer } from "react";

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return state + 1;
    case "decrement":
      return state > 0 ? state - 1 : state;
    case "reset":
      return 0;
    case "incrementByAmount":
      return state + action.payload;
    case "decrementByAmount":
      return state - action.payload >= 0 ? state - action.payload : state;
    default:
      return state;
  }
}

function Counter() {
  const [count, dispatch] = useReducer(reducer, 0);

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => dispatch({ type: "increment" })}>+1</button>
      <button onClick={() => dispatch({ type: "decrement" })}>-1</button>
      <button onClick={() => dispatch({ type: "reset" })}>Reset</button>
      <button onClick={() => dispatch({ type: "incrementByAmount", payload: 5 })}>+5</button>
      <button onClick={() => dispatch({ type: "decrementByAmount", payload: 5 })}>-5</button>
    </div>
  );
}

Notice what changed.

The component has no update functions anymore. It just dispatches actions.

All the logic — every possible way the state can change — lives inside the reducer. One function. One place.

Quick question for you.

If a bug appears and the decrement is not working correctly — where do you look?

The reducer. Just the reducer. You do not have to hunt through the entire component. All the logic is in one spot.

That is the real benefit.

6. What Is payload?

You probably noticed action.payload in the example above.

dispatch({ type: "incrementByAmount", payload: 5 });

payload is any extra data you want to send along with the action.

type tells the reducer what to do.
payload tells the reducer what to do it with.

"Increment" — no payload needed. The amount is always 1.
"IncrementByAmount" — needs a payload because the amount changes.

Think of it like an instruction to a chef.

"Make a pizza" — no extra info needed.
"Make a pizza with extra cheese" — that "extra cheese" is the payload.

7. useState vs useReducer — When to Use Which

Both manage state. So how do you decide?

	useState	useReducer
Best for	Simple values — number, string, boolean	Complex state with multiple update types
Update logic	Spread across multiple functions	All in one reducer function
Number of states	One value per useState	Multiple related values in one object
Readability	Great for simple cases	Better when logic grows
Debugging	Can get messy with many setters	All cases visible in one place

Simple rule.

If you are updating state in more than 3 or 4 different ways — consider useReducer.

If your state is an object with multiple fields that update together — useReducer is the better choice.

If it is just a simple toggle or a counter with one action — useState is perfectly fine.

8. One Common Mistake — Mutating State Directly

The reducer must always return a new state. Never change the existing state directly.

If you mutate state directly — React does not detect the change. No re-render. The screen does not update.

Always return a fresh object or value from the reducer.

Quick Summary — 5 Things to Remember

useState struggles with complex state — when there are many update functions scattered around, it gets hard to manage.
useReducer puts all logic in one place — the reducer handles every possible state change. One function. Easy to find. Easy to debug.
You dispatch actions — not call setters — dispatch({ type: "increment" }) tells the reducer what happened. The reducer decides what to do.
payload carries extra data — when your action needs more info, add it as payload in the action object.
Never mutate state — always return a new value from the reducer. React needs a new reference to detect the change and re-render.

useReducer feels like extra work at first. The reducer, the actions, the dispatch — it seems like a lot for something useState could handle in one line.

But when your state grows — and it will grow — you will be glad everything is in one place.

If something did not click — drop a comment below. Happy to explain it differently.

Thanks for reading. Keep building.

useContext in React — Why It Exists and How to Use It Simply

DHANRAJ S — Mon, 11 May 2026 09:27:26 +0000

Hey!

Before we start — let me show you something.

You have a React app. You want to show the logged-in user's name in three places - the Navbar, the Sidebar, and the Profile page.

So you store the name in the top-level component and pass it down.

function App() {
  const user = "Ravi";

  return <Navbar user={user} />;
}

Simple enough. But then Navbar does not use user directly. It just passes it to another component inside it.

function Navbar({ user }) {
  return <UserMenu user={user} />;
}

And UserMenu passes it further down.

function UserMenu({ user }) {
  return <p>Welcome, {user}</p>;
}

Navbar received user — but never used it. It just passed it along like a postman delivering a package it has no interest in.

Now imagine this happening across 5 levels of components.

That is the problem. And it has a name.

1. What Is Prop Drilling?

Prop drilling is when you pass data through multiple components just to get it to the one that actually needs it.

The components in the middle do not use the data. They just pass it down. Every. Single. Level.

App (has user data)
  ↓ passes user
  Navbar (does not need user — just passes it)
    ↓ passes user
    UserMenu (does not need user — just passes it)
      ↓ passes user
      Avatar (finally uses user here)

Quick question for you.

What happens when you need to change the prop name from user to currentUser?

You have to update every single component in that chain. Navbar. UserMenu. Avatar. Every one of them.

For a small app — annoying. For a large app — a real nightmare.

That is exactly the problem useContext was built to fix.

2. What Is useContext?

useContext is a React hook that lets any component access data directly — without it being passed through props at every level.

You put the data in one place. Any component in your app can reach in and grab it. No passing. No middlemen.

Think of it like a noticeboard in an office.

Instead of the manager telling Team Lead, who tells the developer, who tells the intern about a policy change — the manager just pins it on the noticeboard. Anyone who needs it reads it directly.

useContext is that noticeboard.

3. Three Steps to Use useContext

useContext works in three steps. Every time. No exceptions.

Step 1 — Create the context

import { createContext } from "react";

const UserContext = createContext();

This creates the noticeboard. It does not hold any data yet — it is just the container.

Step 2 — Provide the data

function App() {
  const user = "Ravi";

  return (
    <UserContext.Provider value={user}>
      <Navbar />
    </UserContext.Provider>
  );
}

UserContext.Provider wraps your components and gives them access to the data. The value prop is what you want to share.

Any component inside the Provider can now access user.

Step 3 — Consume the data

import { useContext } from "react";

function Avatar() {
  const user = useContext(UserContext);

  return <p>Welcome, {user}</p>;
}

useContext(UserContext) reads the value from the Provider. Directly. No props needed. Avatar does not care how many components are above it — it just grabs the value straight from the context.

4. Fixing the Prop Drilling Problem

Remember the messy chain from the beginning? Let us fix it with useContext.

Before — with prop drilling:

function App() {
  const user = "Ravi";
  return <Navbar user={user} />;
}

function Navbar({ user }) {
  return <UserMenu user={user} />;
}

function UserMenu({ user }) {
  return <Avatar user={user} />;
}

function Avatar({ user }) {
  return <p>Welcome, {user}</p>;
}

After — with useContext:

const UserContext = createContext();

function App() {
  return (
    <UserContext.Provider value="Ravi">
      <Navbar />
    </UserContext.Provider>
  );
}

function Navbar() {
  return <UserMenu />;
}

function UserMenu() {
  return <Avatar />;
}

function Avatar() {
  const user = useContext(UserContext);
  return <p>Welcome, {user}</p>;
}

Look at Navbar and UserMenu now. No more user prop. They do not know about it. They do not care.

Only Avatar — the component that actually needs the data — goes and gets it.

Clean. Direct. No middlemen.

5. Example 1 — Theme Toggle (Light and Dark Mode)

This is one of the most common real uses of useContext.

import { createContext, useContext, useState } from "react";

const ThemeContext = createContext();

function App() {
  const [theme, setTheme] = useState("light");

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

function Page() {
  const { theme, setTheme } = useContext(ThemeContext);

  return (
    <div style={{
      background: theme === "dark" ? "#111" : "#fff",
      color: theme === "dark" ? "#fff" : "#111",
      padding: "30px"
    }}>
      <p>Current theme: {theme}</p>
      <button onClick={() => setTheme(theme === "light" ? "dark" : "light")}>
        Toggle Theme
      </button>
    </div>
  );
}

The theme and setTheme are shared through context.

Any component inside the Provider — no matter how deep — can read the theme or change it. No prop drilling at all.

Quick question for you.

What would happen if you added a Navbar, Sidebar, and Footer — and all of them needed the theme?

Without context — you pass theme as a prop to all three. Then to their children. Then their children's children.

With context — they all just call useContext(ThemeContext) and get the theme directly. One line. Done.

6. Example 2 — Logged-In User Across Pages

Another very common use case. Once the user logs in — you want their name and role available everywhere.

import { createContext, useContext } from "react";

const AuthContext = createContext();

function App() {
  const loggedInUser = { name: "Ravi", role: "admin" };

  return (
    <AuthContext.Provider value={loggedInUser}>
      <Dashboard />
    </AuthContext.Provider>
  );
}

function Dashboard() {
  return (
    <div>
      <Header />
      <MainContent />
    </div>
  );
}

function Header() {
  const user = useContext(AuthContext);
  return <h2>Welcome, {user.name}</h2>;
}

function MainContent() {
  const user = useContext(AuthContext);
  return <p>You are logged in as: {user.role}</p>;
}

Header and MainContent are both inside Dashboard. Neither of them received user as a prop.

But both of them read it directly from the context. No passing. No drilling.

7. When Should You Use useContext?

useContext is useful — but it is not for everything.

Use it when:

Data needs to be accessed by many components at different levels — theme, language, logged-in user, currency
You find yourself passing the same prop through 3 or more components just to get it somewhere
The data is truly global — something the whole app cares about

Do not use it when:

Only two components need the data — just pass a prop directly, it is simpler
The data changes very frequently — too many context updates can cause unnecessary re-renders
You just started and the app is still small — do not add complexity before you need it

Quick question for you.

You have a button and a modal on the same page. Clicking the button opens the modal. Should you use useContext for this?

Probably not. The button and modal are close to each other. A simple useState in the parent component and a prop to the modal is cleaner. useContext would be over-engineering for something this small.

8. useContext vs Prop Drilling — Side by Side

	Prop Drilling	useContext
How data moves	Passed through every component	Any component reads it directly
Middle components	Must receive and pass the prop	Do not need to know about it
Best for	Data used by 1 or 2 nearby components	Data needed across many levels
Code complexity	Gets messy as app grows	Stays clean regardless of depth
When to use	Small, simple data flow	Global data — theme, user, language

Quick Summary — 4 Things to Remember

Prop drilling is the problem — passing data through components that do not need it, just to reach the one that does.
useContext is the solution — any component inside the Provider can read the data directly. No middlemen.
Three steps always — create the context with createContext(), wrap components with Provider, read the value with useContext().
Do not overuse it — useContext is for truly global data. For simple cases between nearby components, a prop is still the right choice.

useContext is one of those things that feels unnecessary — until your app grows and prop drilling starts hurting.

Once you hit that wall — this is the hook you reach for.

Try building the theme toggle example above. Add a Navbar and a Footer that also read the theme from context. See how clean it feels compared to passing props everywhere.

If something did not click or you have a question — drop it in the comments below.

Thanks for reading. Keep building.

Git & GitHub Explained — What It Is, Why It Exists, and Why Every Developer Uses It

DHANRAJ S — Sun, 10 May 2026 11:18:58 +0000

Hey!

Let me ask you something.

You are working on a project. You have been coding for 3 days straight. Everything is going well.

Then you make a change. Something breaks. You try to fix it. Now something else breaks.

You think — "I just want to go back to how it was yesterday."

But you cannot. Because you kept saving over the same file. The old version is gone.

Sound familiar?

That is the exact problem Git was built to solve.

1. What Was Life Like Before Git?

Before Git existed — developers had it rough. And not in a small way.

Imagine a team of 5 developers working on the same project.

Developer 1 works on the login page.
Developer 2 works on the dashboard.
Developer 3 fixes a bug in the payment flow.

How do they share their work?

They emailed files to each other.

Yes. Literally. ZIP files over email.

And here is what happened every single day:

Developer 2 sends an updated file to the team
Developer 3 already made changes to the same file
Developer 3 copies Developer 2's changes manually into their own version
They miss one line
The app breaks
Nobody knows whose change caused it
Hours wasted trying to figure it out

This was the reality.

And it was not just small teams. Large companies faced the same chaos. A project with 50 developers sharing files over email or a shared folder was a nightmare nobody woke up from easily.

2. The Real Problems Teams Faced

Let us be specific about what actually went wrong before Git.

No history.

You saved a file. The old version is gone. If something broke — you had no way to see what changed or go back to a working version.

No collaboration.

Two people editing the same file at the same time meant one person's work would overwrite the other. Someone always lost their work.

No way to experiment safely.

Want to try a new feature? You had to copy the entire project folder, rename it something like project-v2-final-FINAL-new, and work in that. Messy and confusing.

No record of who did what.

A bug shows up in production. Who wrote that code? When? Why? Nobody knows. No trail. No history. Just chaos.

3. What Is Git?

Git is a version control system.

In simple words — Git tracks every change you make to your code. It keeps a full history of your project. You can go back to any point in time. You can see exactly what changed, when, and who changed it.

Think of it like this.

Imagine you are writing a long document. Every time you save — Google Docs keeps a version history. You can go back to how it looked yesterday, last week, last month.

Git does that for your code. But much more powerful.

Git was created by Linus Torvalds in 2005. Yes — the same person who created the Linux operating system. He built Git because he needed a better way to manage code contributions from thousands of developers around the world.

4. What Is GitHub?

Quick question for you.

If Git lives on your computer — how do you share your code with your team?

That is where GitHub comes in.

GitHub is a website that hosts your Git repositories online.

Git is the tool. GitHub is the place where you store and share your work.

Think of it this way.

Git is like Microsoft Word — the software you use to write documents.
GitHub is like Google Drive — the place where you store and share those documents with others.

You use Git on your machine to track changes. You push those changes to GitHub so your team can see them, review them, and work on them together.

5. How Git Actually Works

Let us understand the core idea behind Git.

Every time you make a meaningful change to your project — you create a commit. A commit is like a save point in a video game.

Initial project
     ↓
Added login page        ← commit 1
     ↓
Fixed login bug         ← commit 2
     ↓
Added dashboard         ← commit 3
     ↓
Broke something         ← commit 4
     ↓
Go back to commit 3     ← you can do this anytime

Each commit stores what changed, when it changed, and who changed it.

If something breaks — you go back. No panic. No lost work.

6. Branches — The Feature That Changes Everything

This is where Git gets really powerful.

A branch is like a separate copy of your project that you can work on without touching the main code.

Imagine your app is live and working perfectly. You want to add a new feature — a dark mode.

Without Git — you would change the main code directly. If something breaks — your live app breaks too.

With Git — you create a branch.

main branch (live app — working perfectly)
     |
     |----dark-mode branch (you work here safely)

You work on dark mode in the branch. The main code is untouched. Users are not affected.

When dark mode is ready and tested — you merge it back into the main branch.

If dark mode turns out to be a bad idea — you delete the branch. Main code is still perfectly fine.

Quick question for you.

What do you think would happen if 5 developers all worked directly on the main code at the same time?

Conflicts everywhere. Someone's work overwrites someone else's. Bugs appear with no clear cause. The whole team slows down trying to clean up the mess.

Branches solve this completely. Each developer works in their own branch. They merge when ready. Conflicts are handled cleanly.

7. The Basic Git Workflow

Here is how you use Git in a real project every day.

# Start tracking a project
git init

# Check what changed
git status

# Stage your changes (prepare them for saving)
git add .

# Save a snapshot with a message
git commit -m "Added login page"

# Push to GitHub so your team can see it
git push origin main

git init — tells Git to start tracking this folder.

git status — shows you what files changed since your last commit.

git add . — stages all the changed files. You are saying "I want to include these in my next save."

git commit -m "message" — saves a snapshot of your code with a description of what you did.

git push — uploads your commits to GitHub so others can access them.

8. Why Do We Use GitHub Specifically?

There are other platforms like GitLab and Bitbucket. But GitHub became the most popular by far.

Here is why developers love it:

Pull Requests.

When you finish working on a branch — you open a Pull Request on GitHub. This is a formal way of saying "I made changes, please review them before merging."

Your team reviews the code, leaves comments, suggests improvements. Only when everyone is happy — the code gets merged.

This is how quality is maintained in real teams.

Issues.

GitHub has a built-in system to track bugs, tasks, and feature requests. Every issue can be assigned to someone, labeled, and linked to a specific commit that fixed it.

Open Source.

GitHub is where the world's open source code lives. React, Node.js, VS Code, Linux — all on GitHub. You can read the source code of any public project, report bugs, or even contribute improvements.

GitHub Actions.

You can automate things directly on GitHub. Every time you push code — automatically run tests, build the project, or deploy to production. All without doing it manually.

9. Advantages of Git and GitHub

Let us put it all together clearly.

Full history of every change.

Every commit is stored. You can see every change ever made, who made it, and when. Nothing is ever truly lost.

Work without fear.

Create a branch. Experiment. Break things. Fix them. Merge when ready. The main code is always safe.

Team collaboration without chaos.

Multiple developers work on the same project without overwriting each other. Merge conflicts are visible and manageable.

Go back to any point.

Something broke in production? Roll back to the last working commit in seconds. No manual digging through backup folders.

Code review built in.

Pull Requests mean code gets reviewed before it goes live. Bugs get caught early. Knowledge gets shared across the team.

Works for any project size.

A solo developer building a personal project. A team of 10 in a startup. A company with 5000 engineers. Git works the same way for all of them.

10. Git vs GitHub — One More Time

A lot of beginners mix these two up. Let us be very clear.

	Git	GitHub
What is it	A tool installed on your computer	A website on the internet
What it does	Tracks changes to your code locally	Hosts your code online for sharing
Can it work alone	Yes — Git works without GitHub	No — GitHub needs Git
Created by	Linus Torvalds, 2005	Founded in 2008, owned by Microsoft
Similar to	The act of saving versions	Google Drive for your code

Git is the engine. GitHub is the garage where you park and share your car.

11. A Quick Real-World Picture

Let us see how a real team uses Git and GitHub together.

Developer A creates a new branch
     ↓
Works on a new feature for 2 days
     ↓
Commits regularly with clear messages
     ↓
Pushes branch to GitHub
     ↓
Opens a Pull Request
     ↓
Team reviews the code, leaves comments
     ↓
Developer A makes fixes based on feedback
     ↓
Pull Request is approved
     ↓
Code is merged into main branch
     ↓
Automated tests run on GitHub Actions
     ↓
Code is deployed to production

Every step is visible. Every change is tracked. Every decision has a record.

That is how professional software is built today.

Quick Summary — 5 Things to Remember

Before Git — chaos. Teams shared files over email, overwrote each other's work, and had no history to fall back on.
Git tracks every change. Every commit is a save point. You can go back to any version anytime.
Branches let you work safely. Experiment without touching the main code. Merge when ready.
GitHub hosts your code online. It adds collaboration tools — Pull Requests, Issues, Actions — on top of Git.
Git and GitHub are not the same. Git is the tool. GitHub is the platform. One lives on your machine. The other lives on the internet.

Thanks for reading. Keep building.

useNavigate in React — Explained Simply with Real Examples

DHANRAJ S — Tue, 05 May 2026 17:16:44 +0000

Hey!

Tell me if this sounds familiar.

You built a login page in React. User fills in the details, clicks login, and — nothing happens. The page just sits there.

You wanted to send the user to the dashboard after login. But how?

You cannot just use a link — the user did not click anything. The redirect needs to happen from your code, based on logic.

That is exactly what useNavigate solves.

1. What Is useNavigate?

useNavigate is a hook from React Router.

It gives you a function that you can call to move the user to a different page — from inside your code, not from a link they click.

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

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

  function handleClick() {
    navigate("/dashboard");
  }

  return <button onClick={handleClick}>Go to Dashboard</button>;
}

useNavigate() returns a function. You store it in navigate. Then you call navigate("/path") whenever you want to go somewhere.

Simple as that.

2. Before You Use It — Set Up React Router

useNavigate only works if React Router is set up properly.

Install it first:

npm install react-router-dom

Wrap your app with BrowserRouter in main.jsx:

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

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

Define your routes in App.jsx:

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

function App() {
  return (
    <Routes>
      <Route path="/" element={<Home />} />
      <Route path="/login" element={<Login />} />
      <Route path="/dashboard" element={<Dashboard />} />
    </Routes>
  );
}

Done. Now useNavigate will work inside any component in your app.

3. Basic Syntax — What Can You Do With navigate?

const navigate = useNavigate();

navigate("/about");    // go to about page
navigate(-1);          // go back — like browser back button
navigate(1);           // go forward
navigate("/dashboard", { replace: true }); // go without adding to history

Quick question for you.

What do you think navigate(-1) does?

It takes the user back to the previous page — exactly like pressing the back button in the browser. No need to know the path. React Router figures it out from the history.

4. Link vs useNavigate — Which One to Use?

This confuses a lot of beginners. Both do navigation. So what is the difference?

	Link	useNavigate
Who triggers it	The user clicks it	Your code triggers it
Best for	Navbar, menu links	After login, form submit
Visible on screen	Yes — shows as a link	No — runs in background

The simple rule:

If the user is clicking to go somewhere — use <Link>.

If your code needs to redirect based on logic — use useNavigate.

5. Example 1 — Login and Redirect

User logs in. Credentials are correct — go to dashboard. Wrong — show an error.

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

function Login() {
  const navigate = useNavigate();
  const [error, setError] = useState("");

  function handleLogin(e) {
    e.preventDefault();

    const username = e.target.username.value;
    const password = e.target.password.value;

    if (username === "admin" && password === "1234") {
      navigate("/dashboard");
    } else {
      setError("Wrong username or password");
    }
  }

  return (
    <div>
      <h2>Login</h2>
      <form onSubmit={handleLogin}>
        <input name="username" placeholder="Username" />
        <input name="password" type="password" placeholder="Password" />
        <button type="submit">Login</button>
      </form>
      {error && <p style={{ color: "red" }}>{error}</p>}
    </div>
  );
}

Walk through what happens:

User types username and password
  → clicks Login
  → handleLogin runs
  → if correct → navigate("/dashboard") fires
  → user lands on dashboard page

  → if wrong → setError runs
  → error message shows below the form

Navigation only happens when the condition is met.

That is the whole point — logic first, then navigate.

6. Example 2 — Go Back Button

You are on a product detail page. You want a back button that takes the user to wherever they came from.

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

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

  return (
    <div>
      <button onClick={() => navigate(-1)}>Go Back</button>
      <h2>Product Detail Page</h2>
      <p>Here are the product details...</p>
    </div>
  );
}

navigate(-1) goes back one step in browser history.

No hardcoded path needed. You do not need to know where the user came from. React Router handles it.

7. replace: true — Controlling Browser History

By default — every time you navigate, a new page is added to browser history.

So the user can press back and return to where they were.

But sometimes you do not want that.

After login — you do not want the user pressing back and landing on the login page again.

// Default — adds to history, user can press back
navigate("/dashboard");

// replace: true — replaces the current page, no going back
navigate("/dashboard", { replace: true });

With replace: true — the login page is replaced by dashboard in the history. Back button will not take them to login.

Quick question for you.

Can you think of another case where replace: true is useful?

A payment success page. After paying — you do not want the user pressing back and submitting the payment again. replace: true prevents that.

8. Passing Data While Navigating

Sometimes you want to send some data to the next page without putting it in the URL.

// Send data with navigate
navigate("/profile", { state: { name: "Ravi", userId: 101 } });

// Read it on the next page using useLocation
import { useLocation } from "react-router-dom";

function Profile() {
  const location = useLocation();
  const { name, userId } = location.state;

  return <p>Welcome {name}. Your ID is {userId}.</p>;
}

You pass a state object as the second argument to navigate.

On the next page — useLocation() gives you access to that state.

Clean. Simple. No URL clutter.

9. One Mistake Everyone Makes

Using useNavigate without wrapping the app in BrowserRouter.

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

You will get this error:

useNavigate() may be used only in the context of a <Router> component.

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

If you ever see that error — go to main.jsx and check if BrowserRouter is wrapping your app. That is almost always the fix.

Quick Summary — 5 Things to Remember

useNavigate returns a function — store it in navigate and call it with a path.
Use it for logic-based navigation — after login, form submit, or any condition. Not for regular links.
navigate(-1) goes back — uses browser history, no path needed.
replace: true — replaces the current page in history so the user cannot press back to return.
Must be inside a Router — always wrap your app with BrowserRouter. Otherwise it throws an error.

useNavigate feels small — but you will use it in almost every React app you build.

Try building the login example. Enter the wrong password and see the error. Enter the right one and watch the redirect happen. That is the best way to make it click.

Got a question? Drop it in the comments below.

Thanks for reading. Keep building.

Why We Use useEffect in React - Explained Simply

DHANRAJ S — Fri, 01 May 2026 17:01:25 +0000

Hey!

Let me ask you something.

You are building a React component. When the page loads — you want to fetch some data from an API.

So you try this:

function UserProfile() {
  const [user, setUser] = useState(null);

  fetch("https://api.example.com/user")
    .then(res => res.json())
    .then(data => setUser(data));

  return <div>{user ? user.name : "Loading..."}</div>;
}

Run it. Check your network tab.

The fetch is firing again. And again. And again. Infinite loop.

Every fetch updates state. Every state update re-renders the component. Every re-render calls fetch again. It never stops.

That is the problem. And useEffect is the solution.

1. Why Does This Happen?

Every time state changes — React re-renders the component. That means every line of code inside the function runs again from top to bottom.

So the fetch runs. It updates state. State triggers a re-render. Fetch runs again. Forever.

For things like fetching data or setting up a timer — you do not want them running on every render. You want them to run at specific times.

That is exactly what useEffect does.

2. What Is useEffect?

useEffect is a React hook that lets you run code at a specific time — not on every render.

Think of it like a trigger. You tell React — "when this specific thing happens, run this code."

import { useEffect } from "react";

useEffect(() => {
  // code you want to run
}, [dependencies]);

Let us break this down.

() => { } — the code you want to run. This is called the effect.

[dependencies] — the dependency array. This controls when the effect runs. This is the most important part.

3. The Dependency Array — How It Controls useEffect

There are three ways to write it. Each behaves differently.

No array — runs after every render

useEffect(() => {
  console.log("runs every render");
});

Rarely what you want.

Empty array — runs only once on mount

useEffect(() => {
  console.log("runs once when component loads");
}, []);

Perfect for fetching data when the page loads.

Array with a value — runs when that value changes

useEffect(() => {
  console.log("runs when count changes");
}, [count]);

Runs once on mount — and again every time count changes.

Quick question for you.

If you want to fetch user data only once when the page loads — which one should you use?

Empty array. The fetch runs once. Data comes back. State updates. Screen shows the result. No loop.

4. Fix the Infinite Loop

Now let us fix the broken code from the beginning.

// Broken
function UserProfile() {
  const [user, setUser] = useState(null);

  fetch("https://api.example.com/user")
    .then(res => res.json())
    .then(data => setUser(data));

  return <div>{user ? user.name : "Loading..."}</div>;
}

// Fixed
function UserProfile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch("https://api.example.com/user")
      .then(res => res.json())
      .then(data => setUser(data));
  }, []);

  return <div>{user ? user.name : "Loading..."}</div>;
}

The fetch is now inside useEffect with an empty array.

Runs once. Gets the data. Updates state. Screen shows the name. No loop.

One small change. Completely different behavior.

5. The Component Lifecycle

Every React component goes through three stages.

Mount — the component appears on screen for the first time.

Update — the component re-renders because state or props changed.

Unmount — the component is removed from the screen.

useEffect connects to all three stages.

Component mounts
  → useEffect with [] runs here

State changes
  → Component updates
  → useEffect with [value] runs here

Component unmounts
  → Cleanup function inside useEffect runs here

6. Example 1 — Fetch Data on Page Load

import { useState, useEffect } from "react";

function PostList() {
  const [posts, setPosts] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    fetch("https://jsonplaceholder.typicode.com/posts")
      .then(res => res.json())
      .then(data => {
        setPosts(data);
        setLoading(false);
      });
  }, []);

  if (loading) return <p>Loading posts...</p>;

  return (
    <ul>
      {posts.slice(0, 5).map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

What happens step by step:

Component loads
  → loading is true → "Loading posts..." shows
  → useEffect fires once
  → fetch gets the data
  → setPosts saves the data
  → setLoading sets to false
  → Component re-renders
  → Posts show on screen

Empty array. Fetch runs once. That is all you need.

7. Example 2 — Timer with Cleanup

import { useState, useEffect } from "react";

function Timer() {
  const [seconds, setSeconds] = useState(0);

  useEffect(() => {
    const interval = setInterval(() => {
      setSeconds(prev => prev + 1);
    }, 1000);

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

  return <p>Time: {seconds} seconds</p>;
}

Two parts inside this useEffect.

Setup — starts a timer that increases seconds every 1 second.

Cleanup — the return () => {} part. This runs when the component is removed from the screen.

Why do you need cleanup?

If the component is removed but the timer keeps running — it will try to update state on a component that no longer exists. That causes memory leaks and errors.

Think of it like this. You turn a fan on when you enter a room. When you leave — you turn it off. You do not leave it running.

The cleanup function is you turning the fan off.

Quick question for you.

What happens if you remove the return () => clearInterval(interval) line?

The timer keeps running even after the component is gone. Every second it tries to update state on something that no longer exists. That is a memory leak.

Always clean up what you set up.

8. One Common Mistake

Missing a value in the dependency array.

// Wrong — count is used inside but missing from array
useEffect(() => {
  console.log(count);
}, []);

// Right
useEffect(() => {
  console.log(count);
}, [count]);

If you use a value inside useEffect — it must be in the dependency array.

If you forget it — the effect uses the old stale value and gives you wrong results.

Quick Summary — 4 Things to Remember

useEffect runs code at specific times — not on every render. The dependency array controls when.
Empty array [] — runs once when the component mounts. Use this for fetching data on load.
Array with a value [value] — runs on mount and every time that value changes.
Cleanup function — return a function from useEffect to stop timers or subscriptions when the component unmounts. Always clean up what you set up.

useEffect feels confusing at first because it is about timing — when does this code run and why.

But once that clicks — you will see it used everywhere. Data fetching. Timers. DOM updates. All of it lives inside useEffect.

Try the examples above. Change the dependency array. Add a console.log inside. Watch when it fires. That hands-on time builds real understanding.

If something did not click — drop a comment below. Happy to explain it differently.

Thanks for reading. Keep building.