Forem: DHANRAJ S

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.

Why We Use useState in React — Explained Simply with Real Examples

DHANRAJ S — Tue, 28 Apr 2026 17:07:12 +0000

Hey!

Let me ask you something before we start.

You built a counter in plain JavaScript. You clicked a button. The number went up. It worked.

So when you moved to React — you tried the same thing.

function Counter() {
  let count = 0;

  function handleClick() {
    count = count + 1;
    console.log(count); // this works fine
  }

  return (
    <div>
      <p>{count}</p>
      <button onClick={handleClick}>Click me</button>
    </div>
  );
}

You click the button. The console shows the number going up. But the screen? The screen stays at 0.

Nothing changes on the page.

And you wonder — what is going on?

That confusion is exactly why useState exists. And by the end of this blog, you will fully understand it.

1. Why Does the Screen Not Update?

Here is the thing about React.

React does not watch your normal variables. When you change let count = 0 — React has no idea that anything changed. So it does not re-render the component. The screen stays the same.

Think of it like this.

Imagine you are writing numbers on a whiteboard. You erase 0 and write 1. But the camera recording the whiteboard does not know you changed it — because nobody told the camera to look again.

React is the camera. Your variable change is you erasing and writing. React needs to be told — "hey, something changed, please look again and update the screen."

That is exactly what useState does.

2. What Is useState?

useState is a React hook that does two things:

It stores a value (your state)
It gives you a function to update that value — and when you use that function, React automatically re-renders the component and updates the screen

That is it. That is the whole idea.

Let us see the syntax first.

import { useState } from "react";

const [value, setValue] = useState(initialValue);

Let us break this down piece by piece.

useState(initialValue) — you call useState and pass the starting value. This can be a number, string, boolean, array, object — anything.

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

setValue — this is the function to update the state. When you call this, React updates the value AND re-renders the component.

const [value, setValue] — this is called array destructuring. useState returns two things in an array. You unpack them into two separate variables in one line.

Quick question for you.

Can you name the two things useState always gives you back?

The current value. And the function to update it. Always. Every time.

3. Fix the Counter — Using useState

Now let us fix the broken counter from the beginning.

import { useState } from "react";

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

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

  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={handleClick}>Click me</button>
    </div>
  );
}

Now when you click the button:

setCount(count + 1) is called
React updates count to the new value
React re-renders the component
The screen shows the updated number

The screen actually changes now. That is the difference.

Let us trace through exactly what happens step by step:

Page loads
  → count = 0
  → Screen shows: Count: 0

User clicks button
  → handleClick runs
  → setCount(0 + 1) is called
  → React updates count to 1
  → React re-renders Counter
  → Screen shows: Count: 1

User clicks again
  → setCount(1 + 1) is called
  → React updates count to 2
  → Screen shows: Count: 2

Every click triggers a re-render. Every re-render shows the latest value. That is useState working.

4. The Naming Convention

Before we go further — notice the naming pattern.

const [count, setCount] = useState(0);
const [name, setName] = useState("");
const [isOpen, setIsOpen] = useState(false);

The update function always starts with set followed by the state name.

count and setCount.
name and setName.
isOpen and setIsOpen.

This is not a rule enforced by React. It is a convention the whole React community follows. Stick to it — your code will be easier to read.

5. Example 1 — Toggle Show and Hide

Let us build something more practical.

A button that shows and hides a message.

import { useState } from "react";

function ToggleMessage() {
  const [isVisible, setIsVisible] = useState(false);

  function handleToggle() {
    setIsVisible(!isVisible);
  }

  return (
    <div>
      <button onClick={handleToggle}>
        {isVisible ? "Hide Message" : "Show Message"}
      </button>

      {isVisible && <p>Hello! I am visible now.</p>}
    </div>
  );
}

Quick question for you.

What does !isVisible do?

If isVisible is true — !isVisible makes it false.
If isVisible is false — !isVisible makes it true.

It flips the value every time. One click shows. Next click hides. Next click shows again.

And the button text changes too — {isVisible ? "Hide Message" : "Show Message"}. That is a ternary operator. If visible, show "Hide Message". If not, show "Show Message".

The UI reacts to the state. That is why it is called React.

6. Example 2 — Input Field

This one is used in almost every real React app.

Capturing what a user types in an input field.

import { useState } from "react";

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

  function handleChange(event) {
    setName(event.target.value);
  }

  return (
    <div>
      <input
        type="text"
        placeholder="Enter your name"
        value={name}
        onChange={handleChange}
      />
      <p>Hello, {name}!</p>
    </div>
  );
}

Every time you type a letter:

onChange fires
handleChange runs
event.target.value gets the current text in the input
setName updates the state
React re-renders
The <p> below shows the updated name instantly

Type "R" — screen shows "Hello, R!"
Type "Ra" — screen shows "Hello, Ra!"
Type "Ravi" — screen shows "Hello, Ravi!"

This pattern is called a controlled input. The input's value is always controlled by React state. It is the standard way to handle forms in React.

7. Example 3 — Like Button

Something you have seen on every social media app.

import { useState } from "react";

function LikeButton() {
  const [liked, setLiked] = useState(false);
  const [likeCount, setLikeCount] = useState(0);

  function handleLike() {
    if (!liked) {
      setLiked(true);
      setLikeCount(likeCount + 1);
    } else {
      setLiked(false);
      setLikeCount(likeCount - 1);
    }
  }

  return (
    <div>
      <button onClick={handleLike}>
        {liked ? "Unlike" : "Like"}
      </button>
      <p>{likeCount} Likes</p>
    </div>
  );
}

Notice something here — one component has two useState calls.

const [liked, setLiked] = useState(false);
const [likeCount, setLikeCount] = useState(0);

You can use as many useState hooks as you need in one component. Each one is completely independent.

liked tracks whether you liked or not.
likeCount tracks the number.

Click once — liked becomes true, count goes up by 1.
Click again — liked becomes false, count goes down by 1.

8. Example 4 — Background Color Changer

Let us do something visual.

import { useState } from "react";

function ColorChanger() {
  const [color, setColor] = useState("white");

  return (
    <div style={{ backgroundColor: color, padding: "40px", textAlign: "center" }}>
      <p>Current color: {color}</p>
      <button onClick={() => setColor("tomato")}>Red</button>
      <button onClick={() => setColor("steelblue")}>Blue</button>
      <button onClick={() => setColor("mediumseagreen")}>Green</button>
      <button onClick={() => setColor("white")}>Reset</button>
    </div>
  );
}

State here is a string — the color name.

Every time you click a button, setColor updates the state to a new color string. React re-renders. The background changes instantly.

This shows that state is not just for numbers and booleans. It can hold any value — strings, arrays, objects — anything your UI needs to track.

9. One Important Rule — Never Mutate State Directly

This is a mistake many beginners make.

// WRONG — never do this
count = count + 1;

// WRONG — never do this either
myArray.push(newItem);

// RIGHT — always use the setter function
setCount(count + 1);

// RIGHT — for arrays, create a new array
setMyArray([...myArray, newItem]);

Why?

Because if you change state directly — React does not know it changed. No re-render happens. The screen does not update.

Always use the setter function. Always. That is the only way React knows something changed and needs to re-render.

10. What Happens When State Changes — The Full Picture

Let us put it all together.

Component renders for the first time
  → useState gives you the initial value
  → Component displays that value on screen

User does something (click, type, hover)
  → You call the setter function with a new value
  → React schedules a re-render

React re-renders the component
  → useState now gives you the updated value
  → Component displays the new value on screen

User does something again
  → The cycle repeats

This cycle — render, interact, update, re-render — is the core of how React works. And useState is what drives it.

Quick Summary — 5 Things to Remember

Normal variables do not trigger re-renders — React does not watch them. Changing a normal variable does nothing to the screen.
useState stores a value and gives you a setter — const [value, setValue] = useState(initialValue). The setter is the only right way to update state.
Calling the setter re-renders the component — React updates the value and redraws the component automatically.
You can use multiple useState in one component — each one is independent. Use as many as your component needs.
Never update state directly — always use the setter function. Direct mutation skips React and the screen will not update.

useState is the first hook every React developer learns. And once it clicks — the way you think about building UIs changes completely.

You stop thinking about DOM manipulation. You start thinking about state — what data does this component need to track, and how should the UI look based on that data.

That shift in thinking is what React is really about.

Try building these examples yourself. Change the initial values. Add new buttons. Break things and fix them. That hands-on time will teach you more than any blog can.

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

Thanks for reading. Keep building.

React Explained — What It Is, Why You Need It, and How to Set It Up the Right Way

DHANRAJ S — Thu, 16 Apr 2026 16:06:08 +0000

Hey!

Before we start — have you ever built something with JavaScript and thought:

"Why is this getting so complicated so fast?"

You're not alone. Every developer hits that wall.

That's exactly why React exists. And by the end of this blog, you'll know what React is, why it matters, and how to get started with it the right way.

Let's go.

1. What Is React?

React is a JavaScript library built by Facebook (now Meta) in 2013.

It is used to build user interfaces — the part of the app that users see and interact with.

React does not replace JavaScript. It is written in JavaScript. But it gives you a smarter, cleaner way to build complex UIs.

Think of it like this.

JavaScript is like raw ingredients — flour, eggs, butter. You can make a cake with them, but it takes a lot of effort and the process can get messy fast.

React is like a baking kit — everything is organized, structured, and designed to make the process faster and less error-prone.

Same ingredients. Much better result.

2. Why Do We Need React Instead of JavaScript?

This is the most important question. Let's be honest about it.

Plain JavaScript works. You can build anything with it. But as your app grows — things start to break down.

Here is a real example.

Imagine you are building a social media feed. You have:

A list of posts
A like button on each post
A comment count that updates when someone comments
A notification bell that updates when something changes
A user profile section at the top

In plain JavaScript — every time something changes, you have to manually find the right element in the DOM and update it.

// Plain JavaScript — updating manually every time
document.getElementById("like-count").innerText = newCount;
document.getElementById("notification-bell").innerText = newNotifications;
document.getElementById("comment-count").innerText = newComments;

Now imagine doing this for 50 different parts of the page.

It gets messy. It gets slow. And one mistake breaks everything.

React solves this with one core idea — components and a virtual DOM.

3. How React Solves the Problem

React introduces two things that change everything.

Components

A component is a small, reusable piece of UI.

Instead of writing one giant HTML file — you break your page into small independent pieces.

function LikeButton() {
  return <button>Like</button>;
}

function Post() {
  return (
    <div>
      <p>This is a post</p>
      <LikeButton />
    </div>
  );
}

Each component manages its own logic and display. You build once — use anywhere.

Virtual DOM

Quick question for you.

When you click "like" on a post — should the entire page reload? Or just the like count?

Obviously just the like count.

But in plain JavaScript, you have to figure that out yourself and manually update the right element.

React handles this automatically using a Virtual DOM.

Here is how it works:

React keeps a copy of the real DOM in memory — this is the Virtual DOM
When something changes, React creates a new Virtual DOM
It compares the old and new Virtual DOM
It finds exactly what changed
It updates only that part in the real DOM

The result? Faster updates. Less work. No manual DOM hunting.

4. What Is a Single Page Application (SPA)?

Before we go further — you need to understand this concept. Because React is built for it.

Traditional websites reload the entire page every time you click a link.

You click "About" — the browser sends a request to the server, the server sends back a whole new HTML page, the browser loads it from scratch.

That is a Multi Page Application (MPA).

A Single Page Application works differently.

The browser loads one HTML page at the start. After that — React takes over. When you navigate, React swaps out just the content on screen. No full page reload. No request to the server for a new page.

Think of it like a TV.

When you change channels — the TV itself does not restart. Only what is playing on screen changes.

That is exactly how an SPA works.

5. Single Page Application vs Multi Page Application

	Single Page Application (SPA)	Multi Page Application (MPA)
How it works	One HTML file, content swaps on screen	Separate HTML page for every route
Page reload	No full reload on navigation	Full reload on every navigation
Speed after load	Very fast	Depends on server response
Initial load	Slightly slower (loads everything upfront)	Faster initial load
SEO	Needs extra setup for SEO	Naturally good for SEO
Best for	Dashboards, apps, tools	Blogs, e-commerce, content sites
Examples	Gmail, Notion, Figma	Wikipedia, news sites, Amazon

Quick question for you.

When you use Gmail — do you notice the page never fully reloads when you open an email? You just see the email content appear on the right side.

That is a Single Page Application in action.

6. How to Set Up React

There are two popular ways to set up a React project:

Create React App (CRA)
Vite

Let's understand both before you pick one.

7. Create React App (CRA)

CRA was the official way to start a React project for a long time.

You run one command and it sets up everything for you — React, Webpack, Babel, and a development server.

npx create-react-app my-app
cd my-app
npm start

That's it. Your React app runs at http://localhost:3000.

The project structure looks like this:

my-app/
  node_modules/
  public/
    index.html
  src/
    App.js
    index.js
  package.json

src/App.js is where you write your React code.
public/index.html is the single HTML file React injects into.

8. Vite

Vite is a newer and faster build tool.

It was not built specifically for React — but it supports React very well and has become the preferred choice for most developers today.

npm create vite@latest my-app -- --template react
cd my-app
npm install
npm run dev

Your React app runs at http://localhost:5173.

The project structure looks like this:

my-app/
  node_modules/
  public/
  src/
    App.jsx
    main.jsx
  index.html
  package.json
  vite.config.js

Quick Summary — 5 Things to Remember

React is a JavaScript library — used to build user interfaces with reusable components.
React solves the DOM problem — instead of manually updating the page, React figures out what changed and updates only that part using the Virtual DOM.
React is built for SPAs — Single Page Applications load once and swap content without full page reloads, making them fast and smooth.
SPA vs MPA — SPAs are best for apps and dashboards. MPAs are best for content-heavy sites that need SEO out of the box.
Use Vite, not CRA — CRA is deprecated. Vite is faster, lighter, and actively supported. It is the right choice for every new React project today.

React can feel like a big jump at first. But once you understand components, state, and how the Virtual DOM works — everything starts to click.

The best way to learn React is to build something with it. Start small. A counter. A todo list. A weather card.

Pick one and build it.

If this helped you understand React better, drop a comment below. What are you planning to build first?

Thanks for reading. Keep building.

I Built a Todo List App with HTML, CSS & JS — Here's What I Learned

DHANRAJ S — Tue, 07 Apr 2026 15:35:51 +0000

Hey!

I built a Todo List app.

Simple? Yes. But this project taught me some JavaScript concepts I was avoiding for a long time.

localStorage. Dynamic DOM. Event listeners. Array methods.

All in one small project.

Let me walk you through what I built — and what actually clicked for me.

You can check out all my frontend projects right here.

1. What This Todo App Does

Type a task and press Add
Task appears in the list below
Click a task → it gets a strikethrough (marked as done)
Press Delete → task is removed
Refresh the page → tasks are still there (thanks to localStorage)

That last point is the interesting one. Let's get into it.

2. The HTML — Just the Skeleton

<input id="inputText" type="text" placeholder="Enter your task" />
<button class="add-btn" id="btn">Add</button>

<ul id="list"></ul>

That's honestly all the HTML needed.

<input id="inputText"> → where you type the task.

<button id="btn"> → the Add button.

<ul id="list"> → the list that shows all tasks. Starts empty. JavaScript fills it in.

No tasks are hardcoded in HTML. Everything is created dynamically by JS. That was new for me.

3. The CSS — Two Things I Really Liked

The gradient background:

body {
  background:
    radial-gradient(at top left, #9d61ba, transparent),
    radial-gradient(at bottom right, #718777, #554f75);
}

Two radial-gradient layers stacked together — purple top left, green bottom right. They blend in the middle. Looks way better than a solid color.

The gradient text on the heading:

h1 {
  background: linear-gradient(135deg, #f97aff 0%, #7afff0 100%);
  -webkit-background-clip: text;
  background-clip: text;
  -webkit-text-fill-color: transparent;
}

Quick question for you

How do you make text show a gradient color?

You apply a gradient as the background — then clip it to the text shape — then make the text color transparent so the background shows through.

Three lines working together. The result? Pink to cyan gradient text.

4. The JavaScript — This Is Where I Learned the Most

Instead of dumping the full code at once — let me show you how the app is broken into 4 clear responsibilities:

What it does	Function
Save tasks to browser	`saveTodos()`
Draw tasks on screen	`renderTodos()`
Add a new task	`btn` click event
Load tasks on startup	`renderTodos()` called once at the end

Every action in this app goes through these 4 things.

Add a task → save → redraw.
Delete a task → save → redraw.
Mark done → save → redraw.

Simple pattern. Repeated every time. Once I saw that — the whole JS made sense.

Let's go through the parts that taught me the most.

5. localStorage — Tasks That Don't Disappear

This was the biggest thing I learned in this project.

Normally — when you refresh a page, everything resets. Variables are gone. Your tasks vanish.

localStorage fixes that. It saves data in the browser — and it stays there even after a refresh.

Saving data:

localStorage.setItem("todos", JSON.stringify(todos));

localStorage only stores strings. So JSON.stringify() converts our array into a string first.

todos (array) → JSON.stringify → "[{...},{...}]" (string) → saved in browser.

Loading data:

let todos = JSON.parse(localStorage.getItem("todos")) || [];

localStorage.getItem("todos") → gets the saved string back.

JSON.parse() → converts it back into a real array.

|| [] → if nothing is saved yet, start with an empty array.

Quick question for you

Why do we need both JSON.stringify and JSON.parse?

Because localStorage only understands strings — not arrays or objects. So we convert to string when saving, and convert back when loading.

String in. String out. JS array in between.

6. renderTodos() — Drawing the List Every Time

function renderTodos() {
  ul.innerHTML = "";

  todos.forEach((todo, index) => {
    const li = document.createElement("li");
    // ...build each task item
    ul.appendChild(li);
  });
}

Every time something changes — add, delete, mark done — we call renderTodos().

It clears the list with ul.innerHTML = "" and redraws everything fresh.

document.createElement("li") → creates a new <li> element in JavaScript. No HTML needed.

ul.appendChild(li) → adds it to the page.

I never created HTML elements from JavaScript before this project. Now it feels natural.

7. Marking a Task as Done — Toggle Logic

li.addEventListener("click", () => {
  todos[index].done = !todos[index].done;
  saveTodos();
  renderTodos();
});

When you click a task — it toggles between done and not done.

!todos[index].done → if it's true, make it false. If it's false, make it true.

That ! flips the value every time. One line. Clean toggle.

In CSS, when a task is done — we add the class done which adds a strikethrough:

li.done span {
  text-decoration: line-through;
  color: #9ca3af;
}

JS handles the logic. CSS handles the look. They work together perfectly.

8. Deleting a Task — splice()

delBtn.addEventListener("click", () => {
  todos.splice(index, 1);
  saveTodos();
  renderTodos();
});

todos.splice(index, 1) → removes 1 item from the array at position index.

So if you have ["Buy milk", "Read book", "Go gym"] and delete index 1:

Result → ["Buy milk", "Go gym"].

"Read book" is gone. Array updated. Save. Redraw. Done.

9. The Add Button — Putting It All Together

btn.addEventListener("click", () => {
  const value = inputText.value.trim();
  if (value === "") return;

  todos.push({ text: value, done: false });
  saveTodos();
  renderTodos();
  inputText.value = "";
});

.trim() → removes empty spaces from the start and end. So just pressing spacebar doesn't add a blank task.

if (value === "") return → if the input is empty, stop. Don't add anything.

todos.push({ text: value, done: false }) → add a new task object to the array. Every task has a text and a done status.

Then save → redraw → clear the input.

Every. Single. Time.

10. What This Project Actually Taught Me

localStorage — saving and loading data in the browser. JSON.stringify to save. JSON.parse to load. I use this in every project now.
document.createElement() — building HTML elements with JavaScript instead of hardcoding them. Powerful once it clicks.
splice() — removing items from an array by index. Simple but I always forgot how it worked before this.
Toggle with ! — flipping a boolean value in one character. Clean and satisfying.
renderTodos() pattern — clear and redraw. Simple state management without any library.
Gradient text with CSS — background-clip: text + transparent fill. Looks great. One trick I'll use everywhere now.

Quick Summary

localStorage.setItem + JSON.stringify → saves array as string in browser
localStorage.getItem + JSON.parse → loads it back as a real array
document.createElement() → builds HTML elements from JavaScript
Every action follows one pattern → save → redraw → done
!todo.done → toggles between true and false
renderTodos() → clears and redraws the list every time something changes

You can see my project here: https://dhanraj166.github.io/frontend-projects/todo.

Build this yourself. It's the perfect beginner project.

If you build your own version — drop it in the comments. I'd love to see what you make.

Thanks for reading! Keep building — one project at a time.

I Built a Calculator with HTML, CSS & JS — Here's What I Learned

DHANRAJ S — Sat, 04 Apr 2026 17:36:05 +0000

Hey!

I built a calculator using HTML, CSS, and JavaScript.

It's a small project. But it taught me things that hours of tutorials didn't.

Let me walk you through what I built — and what clicked for me along the way.

1. What the Calculator Does

Type numbers and operators on the screen
Press = or Ans to get the result
Press C to clear everything
Press Del to delete the last character

Simple. Clean. And building it yourself hits different.

2. The HTML — Screen + Buttons

<input type="text" id="result">

<div class="btn">
  <button onclick="clearDisplay()">C</button>
  <button onclick="appendValue('/')">÷</button>
  <button onclick="appendValue('*')">×</button>
  <button onclick="deleteLast()">Del</button>
  <!-- number and operator buttons -->
  <button class="equal" onclick="calculate()">=</button>
</div>

<input id="result"> → the display screen. Shows numbers and the final answer.

Every button has onclick → clicking it runs a JavaScript function.

That's the whole structure. Nothing fancy.

3. The CSS — Dark Look with Grid Layout

Background gradient:

body {
  background: linear-gradient(135deg, #0f2027, #203a43, #2c5364);
}

Three colors blending together — gives that rich dark feel.

The button grid:

.btn {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
  gap: 10px;
}

repeat(4, 1fr) → 4 equal columns. Grid handles all the positioning automatically.

*Quick question for you *

Why does the 0 button look wider than the rest?

.zero {
  grid-column: span 2;
}

span 2 → the zero button takes up 2 columns instead of 1. One line. That's it.

Hover effect:

button:hover {
  background: #555;
  box-shadow: 0 1px 6px rgba(174, 167, 167, 0.91);
}

transition: 0.2s on the button makes the hover smooth — not a sudden jump. Makes the calculator feel alive.

4. The JavaScript — Just 4 Functions

const result = document.getElementById("result");

function appendValue(value) {
  result.value += value;
}

function calculate() {
  result.value = eval(result.value);
}

function clearDisplay() {
  result.value = "";
}

function deleteLast() {
  result.value = result.value.slice(0, -1);
}

4 functions. That's the whole brain of this calculator. Let's go through each one.

5. appendValue() — Builds the Expression

function appendValue(value) {
  result.value += value;
}

Every button click adds a character to the screen.

Press 4 → screen shows 4.
Press + → screen shows 4+.
Press 3 → screen shows 4+3.

Just adding characters one by one. Simple.

6. clearDisplay() and deleteLast()

function clearDisplay() {
  result.value = "";        // wipes everything
}

function deleteLast() {
  result.value = result.value.slice(0, -1);  // removes last character
}

clearDisplay → sets screen to empty. Fresh start.

deleteLast → .slice(0, -1) means "keep everything except the last character."

So 123+ becomes 123. Press again → 12. That's your backspace.

7. calculate() and eval() — The Interesting One

function calculate() {
  result.value = eval(result.value);
}

Quick question for you

If the screen shows "45+3" — that's just a string. Plain text.

How does JavaScript know it's math?

That's where eval() comes in.

eval("45+3")   // 48
eval("10*5")   // 50
eval("100/4")  // 25

eval() takes a string and runs it as JavaScript code. So "45+3" becomes actual math — and returns 48.

One line. Whole calculator works.

One thing I learned though →

eval() is powerful but risky in real apps. If someone types harmful code, eval will run it. For a personal project like this — totally fine. For a real app — use a safer math library.

Good to know.

8. What This Project Actually Taught Me

CSS Grid — I always used Flexbox. This project made me finally use Grid properly.
grid-column: span 2 — one line to make a button wider. Didn't know this before.
.slice(0, -1) — negative numbers in slice. Small but useful trick.
eval() — what it does, why it works, and when not to use it.

You don't learn these things from tutorials. You learn them when you need them.

You can see my project here: https://dhanraj166.github.io/frontend-projects/calculator.html/

Thanks for reading! Keep building

JavaScript Promises Explained — With a Real Online Shopping Flow

DHANRAJ S — Sun, 29 Mar 2026 17:03:34 +0000

Hey!

You've probably seen the word Promise in JavaScript and thought —

"What is this? Why does it exist? Why can't JavaScript just... do things normally?"

Fair question. Let's fix that today.

We're going to use a real online shopping flow to understand Promises — step by step, together.

And by the end, this code will make complete sense to you.

1. What Is a Promise? (Before We Touch the Code)

Imagine you order food online.

The app doesn't freeze while your food is being made. You go about your day. When it's ready — you get a notification.

That notification? That's a Promise resolving.

In JavaScript, a Promise is an object that says:

"I'll give you a result — but not right now. Give me some time. I'll get back to you."

A Promise has 3 possible states:

Pending — still working, no result yet
Resolved — finished successfully, here's your result
Rejected — something went wrong, here's the error

Now let's see this in real code.

2. The Full Code — Look at It Once

function checkInternet() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const online = true;
      if (online) {
        resolve("Internet connected ✅");
      } else {
        reject("No internet connection ❌");
      }
    }, 1000);
  });
}

function loginUser() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("User logged in ✅");
    }, 1000);
  });
}

function checkStock() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const stockAvailable = true;
      if (stockAvailable) {
        resolve("Product in stock ✅");
      } else {
        reject("Product out of stock ❌");
      }
    }, 1500);
  });
}

function processPayment() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const paymentSuccess = true;
      if (paymentSuccess) {
        resolve("Payment successful ✅");
      } else {
        reject("Payment failed ❌");
      }
    }, 2000);
  });
}

function placeOrder() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("Order placed successfully ✅");
    }, 1000);
  });
}

function sendConfirmation() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("Confirmation message sent ✅");
    }, 1000);
  });
}

checkInternet()
  .then(result => {
   console.log(result);
   return loginUser();
   })
  .then(result => {
   console.log(result); 
   return checkStock();
   })
  .then(result => {
   console.log(result);
   return processPayment();
   })
  .then(result => {
   console.log(result);
   return placeOrder(); })
  .then(result => {
   console.log(result);
   return sendConfirmation();
   })
  .then(result => {
   console.log(result);
   console.log("Order completed successfully!");
   })
  .catch(error => {
   console.log("❌ Error:", error);
   });

Looks long, right?

Don't worry. We'll break it into small pieces. Each piece is actually very simple.

3. What's Actually Happening Here? — The Big Picture

This code simulates a complete online order flow.

Think of it like this — when you buy something online, the app runs these steps one after another:

Check Internet
     ↓
  Login User
     ↓
 Check Stock
     ↓
Process Payment
     ↓
  Place Order
     ↓
Send Confirmation
     ↓
   Done!

Each step waits for the previous one to finish before starting.

That's exactly what Promises and .then() do.

4. Let's Understand One Promise First

Let's take the simplest one — checkInternet.

function checkInternet() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      const online = true;
      if (online) {
        resolve("Internet connected ✅");
      } else {
        reject("No internet connection ❌");
      }
    }, 1000);
  });
}

Let's read this line by line 👇

return new Promise((resolve, reject) => {
→ We're creating a new Promise. It takes two things — resolve and reject. These are functions JavaScript gives us.

setTimeout(() => { ... }, 1000)
→ Wait 1 second before doing anything. This simulates real network delay.

const online = true
→ This is our fake condition. In a real app, this would check your actual internet.

if (online) { resolve("Internet connected ✅") }
→ If internet is available — call resolve. Promise is successful. ✅

else { reject("No internet connection ❌") }
→ If no internet — call reject. Promise failed. ❌

That's it. That's one complete Promise.

*5. Quick Question for You *

Look at loginUser:

function loginUser() {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("User logged in ✅");
    }, 1000);
  });
}

Did you notice something different from checkInternet?

Take a second. Look carefully.

...

It only has resolve — no reject.

Why? Because in this code, login always succeeds. There's no failure case written for it. So we only need resolve.

Simple — but important to notice. 👀

6. Now Let's Talk About resolve and reject

These two are the heart of every Promise.

resolve → "Everything went well. Here's the result. Move to the next step."

reject → "Something went wrong. Stop here. Jump to .catch()."

Here's a clear picture of which functions can fail and which always succeed:

Function	Can Fail?	Why
`checkInternet()`	✅ Yes	Internet might be off
`loginUser()`	❌ No	Always resolves
`checkStock()`	✅ Yes	Item might be out of stock
`processPayment()`	✅ Yes	Payment might fail
`placeOrder()`	❌ No	Always resolves
`sendConfirmation()`	❌ No	Always resolves

Functions that can fail have both resolve and reject.
Functions that always succeed only have resolve.

7. What Does .then() Actually Do?

Now the fun part. Look at how we run all 6 steps:

checkInternet()
  .then(result => {
    console.log(result);
    return loginUser();
  })
  .then(result => {
    console.log(result);
    return checkStock();
  })
  .then(result => {
    console.log(result);
    return processPayment();
  })
  ...

Let's understand .then() clearly.

.then() runs only when the previous Promise resolves successfully.

It receives the resolved value as result — and you can use it however you want.

Then — you return the next Promise inside it. That's what creates the chain.

Think of it like a relay race :

Runner 1 finishes → passes the baton → Runner 2 starts → passes the baton → Runner 3 starts...

Each .then() is one runner. Each return is passing the baton.

8. Step-by-Step Output — Let's Walk Through It Together

Here's what happens when you run this code:

Waits 1 second...

Internet connected ✅

Waits 1 more second...

User logged in ✅

Waits 1.5 seconds...

Product in stock ✅

Waits 2 seconds...

Payment successful ✅

Waits 1 second...

Order placed successfully ✅

Waits 1 second...

Confirmation message sent ✅
 Order completed successfully!

Each step runs one at a time, in order. The next step never starts before the previous one finishes.

That's the power of Promise chaining.

9. What About .catch()? — The Safety Net

.catch(error => {
  console.log("❌ Error:", error);
});

This is your safety net.

If any Promise in the entire chain calls reject — the whole chain stops and jumps straight to .catch().

Let's say you change this in checkStock:

const stockAvailable = false; //  changed to false

The output would be:

Internet connected ✅
User logged in ✅
❌ Error: Product out of stock ❌

Everything after checkStock — payment, order, confirmation — none of it runs.

One failure. Whole chain stops. .catch() handles it.

Clean. Safe. Controlled.

*10. Small Challenge for You *

Before you move on — try this mentally.

What happens if you change this line in processPayment:

const paymentSuccess = false; //

What will the output be?

Think about it.

...

Answer:

Internet connected ✅
User logged in ✅
Product in stock ✅
❌ Error: Payment failed ❌

The chain ran fine until payment failed. Then .catch() caught it. Order never placed. Confirmation never sent.

Makes sense, right? That's exactly how real apps work.

Quick Summary — 5 Things to Remember

A Promise = a future result — it's either going to succeed (resolve) or fail (reject). Not both.
resolve = success — moves to the next .then() in the chain.
reject = failure — skips everything and jumps straight to .catch().
.then() chains steps — each step waits for the previous one to finish before starting.
.catch() is your safety net — one place to handle any error from anywhere in the chain.

Promises feel confusing at first because they're about time — things happening later, not immediately.

But once you see it as a relay race — one step finishing and passing to the next — it starts to click.

Try running this code yourself. Change true to false in different places and watch what happens. That hands-on experiment will teach you more than any explanation.

Got a question? Drop it in the comments. No question is too basic — ask away.

Thanks for reading! Keep building, one Promise at a time.

Why Problem-Solving Is More Important Than Programming Languages

DHANRAJ S — Sat, 28 Mar 2026 06:13:57 +0000

Hey!

Quick question before we start.

When someone asks you "which programming language should I learn first?" — what do you usually say?

Python? JavaScript? Java? C++?

Here's the thing. That question itself might be the wrong question.

And today, let's talk about why.

1. The Mistake Almost Every Beginner Makes

When most people start coding, they spend weeks asking:

"Should I learn Python or JavaScript?"
"Is Java still worth it?"
"What language do big companies use?"

Sound familiar?

It's okay. We've all been there.

But here's what nobody tells you early enough — the language is just a tool. What actually matters is whether you know how to think through a problem before you even open your code editor.

*2. Let's Try Something Together *

Forget code for a second.

Imagine your friend asks you:

"I have a box of 10 chocolates. I want to share them equally with 4 people. Can I do it?"

You didn't need Python to answer that. You didn't need JavaScript.

You just thought through it.

That thinking — breaking a problem into pieces, figuring out what's possible, finding the answer — that's problem-solving.

And that's exactly what programming is. The language is just how you write the solution down.

3. Here's a Real Example in Code

Let's say someone asks you:

"Find the largest number in a list."

A beginner who only focused on syntax might freeze. They'll think — "What method do I use? Is it .max()? .sort()? How do I write this?"

But a developer who thinks in problems first does this:

Start with the first number. Assume it's the largest.
Go through every other number.
If you find a bigger one, update your answer.
At the end, you have the largest.

Now the code almost writes itself:

function findLargest(numbers) {
  let largest = numbers[0];

  for (let i = 1; i < numbers.length; i++) {
    if (numbers[i] > largest) {
      largest = numbers[i];
    }
  }

  return largest;
}

console.log(findLargest([3, 7, 1, 9, 4]));
// Output: 9

See what happened there?

The logic came first. The code came second.

That's the mindset shift everything depends on.

*4. Quick Question for You *

If someone took that same logic and wrote it in Python — would it still work?

def find_largest(numbers):
    largest = numbers[0]

    for num in numbers[1:]:
        if num > largest:
            largest = num

    return largest

print(find_largest([3, 7, 1, 9, 4]))
# Output: 9

Same logic. Different language. Same result.

The problem-solving didn't change. Only the syntax did.

That's the whole point.

5. So Why Do People Focus on Languages So Much?

Honestly? Because languages are visible.

You can google "Python tutorial." You can finish a course and say "I learned Python." It feels like progress.

But problem-solving is invisible. It's harder to measure. It grows slowly. And nobody gives you a certificate for it.

So people avoid it — without even realizing they're avoiding it.

But here's the truth:

A developer who thinks clearly can pick up any language in weeks.
A developer who only knows syntax will struggle in every language.

*6. Think About It This Way *

Imagine two people want to build a house.

Person A studies every tool in the toolbox. Hammer. Drill. Saw. They know the names, the brands, the specs.

Person B learns how buildings actually work. Foundations. Load-bearing walls. How rooms connect.

Now give both of them a new tool they've never seen.

Who figures it out faster?

Person B. Every time.

Languages are the tools. Problem-solving is understanding how buildings work.

7. What Does "Thinking Like a Developer" Actually Look Like?

Here's what it looks like in practice. Someone gives you a problem:

"Check if a word is a palindrome." (a word that reads the same forwards and backwards — like racecar)

Before writing a single line of code, a good developer asks:

What exactly am I checking?
What does the input look like?
What should the output be?
What's the simplest way to check this?

And then they think:

"If I reverse the word and it's the same — it's a palindrome."

function isPalindrome(word) {
  const reversed = word.split("").reverse().join("");
  return word === reversed;
}

console.log(isPalindrome("racecar")); // true
console.log(isPalindrome("hello"));   // false

The solution is clean because the thinking was clear.

That's not about JavaScript. That's about how you approached the problem.

*8. A Small Challenge for You *

Try this without looking anything up.

Write the logic — not the code — to check if a number is even or odd.

Just words. No syntax. No googling.

...

Done? Great.

If you said something like "divide the number by 2 and check if there's a remainder" — you just problem-solved.

Now the code is easy:

function isEven(number) {
  return number % 2 === 0;
}

console.log(isEven(4));  // true
console.log(isEven(7));  // false

You didn't need to know JavaScript to figure that out.

You needed to think.

9. Does This Mean Languages Don't Matter?

Not at all!

Languages absolutely matter. You need to know the syntax. You need to understand how a language works. That's real and important.

But think of it like learning to drive.

Understanding road rules, reading traffic, making decisions — that's the core skill.

The car you drive is the language. A good driver can switch cars. A person who only memorized one car's dashboard will struggle in a different one.

Learn the language. But build the thinking first.

10. How Do You Actually Get Better at Problem-Solving?

Here's what actually works — and you can start today:

Read problems out loud before coding. Understand what's really being asked.
Write your logic in plain English first. If you can't explain it in words, you can't write it in code.
Practice on paper or a whiteboard. No autocomplete. No shortcuts. Pure thinking.
Do easy problems on platforms like LeetCode or HackerRank — not to grind hard problems, but to build the habit of breaking things down.
After solving, ask yourself — is there a simpler way?

None of these require a specific language.

All of them make you better in every language.

Quick Summary — 3 Things to Take Away

Languages are tools, not the skill — knowing 5 languages with weak problem-solving won't take you far. Strong thinking with one language will.
Logic first, syntax second — always understand what you're solving before you think about how to write it.
Problem-solving transfers everywhere — learn it once, use it in Python, JavaScript, Java, whatever comes next.

Thanks for reading! Keep thinking, keep building. ✨

JavaScript Closures — Explained with a Bank Account You'll Never Forget

DHANRAJ S — Thu, 26 Mar 2026 14:43:22 +0000

Hey!

Before we start — have you ever tried to understand closures and ended up more confused than before?

Yeah. Most beginners have. And it's not your fault.

The definitions are dry. The examples feel random. Nothing clicks.

So today, let's skip the textbook stuff. We'll use a real bank account to understand closures — step by step, together.

1. What Is a Closure?

Here's the simplest way to think about it.

Imagine a bank. When you open an account, the bank keeps your balance locked inside a private vault. You can't just walk in and grab it. You have to go through the bank's system — deposit, withdraw, check balance.

That vault? That's a closure in JavaScript.

A closure is when an inner function remembers the variables from its outer function — even after the outer function has stopped running.

We'll see exactly what that means in code. Keep reading.

2. Here's Our Bank Account Code

Let's look at the full example first. Don't worry if you don't get everything right away — we'll walk through it piece by piece.

function createAccount(userName, initialBalance) {
  let balance = initialBalance;    //  private — no one can touch this directly
  let accountNumber = Math.floor(Math.random() * 100000);

  function deposit(amount) {
    balance += amount;
    return `${userName} deposited ₹${amount}. Balance: ₹${balance}`;
  }

  function withdraw(amount) {
    if (amount > balance) {
      return "Insufficient balance";
    }
    balance -= amount;
    return `${userName} withdrew ₹${amount}. Balance: ₹${balance}`;
  }

  function getBalance() {
    return `${userName}'s balance is ₹${balance}`;
  }

  return { accountNumber, deposit, withdraw, getBalance };
}

createAccount is the outer function — it's like the bank itself.

balance and userName are private variables — they live inside the bank vault.

deposit, withdraw, and getBalance are the inner functions — they're the only keys to that vault.

3. So Where Does the Closure Happen?

Here's the interesting part.

When createAccount finishes running — it's done. Gone. But look what we return:

return { accountNumber, deposit, withdraw, getBalance };

We're returning the inner functions. And those functions still remember balance and userName from inside createAccount.

That memory? That's the closure.

Think of it this way — even after a bank branch closes for the day, your account data is still safely stored inside. The branch is gone, but your balance is alive and well.

4. Let's Create Some Accounts and See It in Action

const user1 = createAccount("Ravi", 1000);
const user2 = createAccount("Anu", 5000);
const user3 = createAccount("Karthik", 200);

Each call to createAccount creates a separate closure — a separate private vault for each user.

Ravi has his own balance. Anu has hers. Karthik has his.

They don't share anything.

Now let's use them:

console.log(user1.getBalance());
// Ravi's balance is ₹1000

console.log(user1.deposit(500));
// Ravi deposited ₹500. Balance: ₹1500

console.log(user2.withdraw(1000));
// Anu withdrew ₹1000. Balance: ₹4000

Notice — when Anu withdraws ₹1000, Ravi's balance doesn't change at all. Each closure is its own world.

5. Quick Question for You 🤔

Try guessing this before you read the answer.

What happens when you do this?

console.log(user1.balance);

Go on, take a guess.

...

The answer is undefined.

Why? Because balance is not part of the returned object. It's locked inside the closure. The only way to read it is through getBalance() — not directly.

That's data privacy, powered by closures.

6. There's a Sneaky Bug — Did You Spot It?

Look at these two lines:

console.log(user2.getBalance)   // ❌ oops
console.log(user1.getBalance()) // ✅ correct

See the difference? The first one is missing ().

Without (), you're not calling the function — you're just pointing at it. JavaScript will print this instead:

[Function: getBalance]

Always use () when you want to actually run a function. Small thing — big difference.

7. The Mental Model — Vault + Keys 🗝️

Here's a picture to lock this in:

createAccount("Ravi", 1000)
│
├── 🔒 Private Vault (the closure)
│     ├── balance = 1000
│     └── userName = "Ravi"
│
└── 🗝️ Your Keys (returned methods)
      ├── deposit()    → adds to balance
      ├── withdraw()   → subtracts from balance
      └── getBalance() → reads the balance

You hold the keys. But the vault stays hidden.

No one else can open it. No one else can change the balance — unless they go through the keys you have.

8. One More Thing — Try This Yourself!

Open your browser console or a JS playground and run this:

const user3 = createAccount("Karthik", 200);

console.log(user3.withdraw(500));
// What do you think this prints?

Take a guess before you run it.

...

It prints "Insufficient balance" — because Karthik only has ₹200 and tried to withdraw ₹500.

The withdraw function checked balance through the closure and protected the account. 💪

Quick Summary — 3 Things to Remember

A closure remembers — inner functions keep access to outer variables even after the outer function is done.
Each call is its own world — every createAccount call creates a fresh, isolated closure. Ravi and Anu never share data.
Closures = privacy — balance isn't exposed directly. You can only interact with it through the functions returned. That's intentional and powerful.

Thanks for reading! Keep building, keep asking questions. ✨

🔐 JavaScript Closures Explained with a Bank Account (Beginners, This One's for You!)

DHANRAJ S — Thu, 26 Mar 2026 14:33:50 +0000

Ever wondered how a bank keeps your balance private — so no one else can just walk in and change it?

That's exactly what a closure does in JavaScript. It locks your data away and only lets you touch it through specific actions — like a deposit or withdrawal.

Let's break it down with a real banking example. 🏦

1. What Is a Closure?

Imagine you open a bank account. The bank creates a private locker for you — your balance, your account number. No one else can access it directly. You can only interact with it through the bank's services: deposit, withdraw, check balance.

In JavaScript, a closure is when an inner function "remembers" the variables from the outer function — even after the outer function has finished running.

That's it. That's the whole idea. 🎉

2. What Does the Code Look Like?

Here's the full createAccount function we'll be working with:

function createAccount(userName, initialBalance) {
  let balance = initialBalance;    // private
  let accountNumber = Math.floor(Math.random() * 100000);

  function deposit(amount) {
    balance += amount;
    return `${userName} deposited ₹${amount}. Balance: ₹${balance}`;
  }

  function withdraw(amount) {
    if (amount > balance) {
      return "Insufficient balance";
    }
    balance -= amount;
    return `${userName} withdrew ₹${amount}. Balance: ₹${balance}`;
  }

  function getBalance() {
    return `${userName}'s balance is ₹${balance}`;
  }

  return {
    accountNumber,
    deposit,
    withdraw,
    getBalance
  };
}

createAccount is the outer function. It holds balance and userName as private variables inside it.

deposit, withdraw, and getBalance are the inner functions. Each one is a closure — they can all see and use balance even after createAccount has finished running.

3. Why Can Inner Functions Still Access balance?

When createAccount runs and returns, you'd think balance is gone forever, right?

Nope. 🙅

JavaScript keeps balance alive in memory because the inner functions still hold a reference to it. This "remembered environment" is called the closure.

Think of it like this — even after the bank teller goes home, your locker is still safely locked inside the vault. The locker doesn't disappear. It stays as long as you still hold the keys.

4. How Does Each User Get Their Own Private Balance?

const user1 = createAccount("Ravi", 1000);
const user2 = createAccount("Anu", 5000);
const user3 = createAccount("Karthik", 200);

Every call to createAccount creates a brand new closure — a completely separate private environment.

user1 gets its own balance starting at ₹1000
user2 gets its own balance starting at ₹5000
user3 gets its own balance starting at ₹200

Ravi's deposit will never affect Anu's balance. Each account is fully isolated. 🔒

5. How Do You Use the Returned Methods?

console.log(user1.getBalance());
// Ravi's balance is ₹1000

console.log(user1.deposit(500));
// Ravi deposited ₹500. Balance: ₹1500

console.log(user2.withdraw(1000));
// Anu withdrew ₹1000. Balance: ₹4000

Every time you call user1.deposit(500), the closure remembers Ravi's balance and updates it. The next time you call user1.getBalance(), it shows the updated value.

The closure is keeping score behind the scenes — silently, reliably. 📝

6. There's a Bug in the Code — Did You Catch It?

Look at this line from the original code:

console.log(user2.getBalance)   // ❌ Missing ()
console.log(user1.getBalance()) // ✅ Correct

user2.getBalance without () does not call the function. It just prints the function itself:

[Function: getBalance]

Always add () when you actually want to call the function and get a result. Easy mistake — now you'll never forget! 😄

7. Why Is balance Considered "Private"?

Try accessing balance directly from outside:

console.log(user1.balance); // undefined

It returns undefined because balance is not part of the returned object. It lives only inside the closure.

The only way to read or change it is through deposit(), withdraw(), or getBalance(). That's data privacy powered by closures — no one can sneak in and tamper with it directly.

8. The Mental Model — Picture It Like This

createAccount("Ravi", 1000)
│
├── 🔒 Private Vault (closure)
│     ├── balance = 1000
│     └── userName = "Ravi"
│
└── 🗝️ Keys Returned to You
      ├── deposit()    → updates balance
      ├── withdraw()   → updates balance
      └── getBalance() → reads balance

The vault is the closure. The keys are the inner functions. You can only touch what's inside through the keys.

Quick Summary — 3 Golden Rules of Closures

Inner functions remember outer variables — even after the outer function has finished running, the inner functions still hold on to those variables.
Each function call creates its own closure — user1, user2, and user3 each have their own private balance that never leaks into each other.
Closures give you data privacy — if balance isn't in the returned object, no one outside can access or modify it directly.

Closures sound scary at first — but once you picture them as a private vault with keys, they just click. 🔑

Drop a comment if you have questions. And if this made closures finally make sense, smash that ❤️ and share it with a friend who's learning JavaScript. 🚀