DEV Community: Bismay.exe

🚀 Day 12 of Learning React: Understanding useEffect, Cleanup Functions, and API Calls

Bismay.exe — Mon, 13 Jul 2026 21:53:19 +0000

📌 Missed Day 11? Last time I finally understood why React has Context API, how it solves prop drilling, and how multiple components can share the same state without passing props through every level. You can read it here and then come back. I'll wait. ☕️

Bismay.exe

Jul 13

🚀 Day 11 of Learning React: Finally Understanding React Context API (And Why Prop Drilling Gets Annoying)

#react #javascript #webdev #beginners

6 min read

After spending the last few days learning about state, Context API, and sharing data between components, I thought I had a pretty solid understanding of React.

Then today's lesson completely changed the way I think about rendering.

I used to assume React somehow "knew" when it should fetch data, start a timer, or clean up resources.

It doesn't.

React only has one main responsibility:

Render the UI.

Anything that needs to happen after rendering is considered a side effect.

And that's exactly why React gives us a hook called useEffect().

By the end of today's class, I realized useEffect isn't just another hook to memorize.

It's React's way of saying:

"If you want something to happen after rendering, tell me exactly when to do it."

Let's dive in. 🚀

🧠 Quick Recap

Yesterday's big question was:

How can components share state without prop drilling?

Here's what I learned on Day 11:

🌐 Context API helps avoid prop drilling.
📦 createContext() creates a shared context.
🏗️ The Provider makes shared data available.
🎣 useContext() lets components access that data directly.

Today, a completely different question came up.

How does React know when to run code after rendering? 🤔

🤔 The Mistake I Didn't Know I Was Making

Suppose I have a function that fetches products from an API.

const getData = async () => {
  let res = await axios.get("https://fakestoreapi.com/products");
  setApiData(res.data);
};

My first instinct was simple.

Just call it inside the component.

function App() {
  getData();

  return <h1>Hello React</h1>;
}

Looks harmless...

Right?

Not really.

🔄 The Infinite Loop Problem

Here's what actually happens.

Component Renders
        ↓
getData() Runs
        ↓
setApiData()
        ↓
State Updates
        ↓
Component Renders Again
        ↓
getData() Runs Again
        ↓
...

React isn't doing anything wrong here.

Every time the state changes...

React renders again.

Since getData() is inside the component, it runs again too.

Which updates the state.

Which causes another render.

Which calls getData() again.

And the cycle never ends.

That was the moment I realized:

React doesn't know that I only wanted to fetch the data once.

I have to tell it.

🎣 Enter `useEffect()`

That's where today's star finally entered the picture.

useEffect(() => {
  getData();
}, []);

At first, this syntax looked strange.

Especially that empty array at the end.

What exactly is it doing?

Turns out...

That tiny array controls when the effect should run.

⚡ My First `useEffect`

Here's the exact code I used today.

useEffect(() => {
  getData();
}, []);

This tells React:

"After the component renders for the first time, run getData()."

The important part is the empty dependency array.

[]

It means:

Run this effect only once after the initial render.

Now the flow looks much cleaner.

Component Renders
        ↓
useEffect Runs
        ↓
API Request
        ↓
State Updates
        ↓
Component Re-renders
        ↓
Effect Doesn't Run Again ✅

That single change completely solved the problem.

🌐 My First API Request with Axios

Today's lesson also introduced me to Axios.

Before using it, I had to install it.

npm install axios

Then importing it was straightforward.

import axios from "axios";

Fetching data looked like this.

const getData = async () => {
  const res = await axios.get("https://fakestoreapi.com/products");

  setApiData(res.data);
};

This was my first time using Axios instead of the built-in fetch() API.

One thing I immediately noticed was how simple the response felt.

With Axios, the actual data is already available inside:

res.data

So after fetching the products, I simply updated my state.

setApiData(res.data);

React re-rendered the component, and the products became available to display.

That felt much cleaner than I expected.

📌 The Dependency Array Finally Made Sense

If I'm being honest...

The dependency array confused me more than useEffect() itself.

I kept wondering,

"Why is React asking me for an array?"

Eventually, I realized that the dependency array is simply React's way of knowing when an effect should run again.

There are three common patterns.

1️⃣ No Dependency Array

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

This runs after every render.

Render
   ↓
Effect

Render
   ↓
Effect

Render
   ↓
Effect

2️⃣ Empty Dependency Array

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

This runs only once.

First Render
      ↓
Effect Runs ✅

Next Render
      ↓
Skipped

3️⃣ Dependency Array with a Value

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

Now React watches count.

If count changes...

the effect runs again.

If it doesn't...

React skips it.

After seeing all three together, I stopped memorizing them and started thinking about what React was actually doing.

Dependency Array	When it Runs
No array	After every render
`[]`	Only after the first render
`[count]`	After the first render and whenever `count` changes

That tiny table made the dependency array much easier to remember.

🤯 The Experiment That Finally Made Cleanup Click

I thought today's biggest lesson would be fetching data from an API.

Surprisingly, the thing that impressed me the most had nothing to do with APIs.

It was understanding why React needs a cleanup function.

At first, I didn't understand why React lets us return a function inside useEffect().

useEffect(() => {
  console.log("About rendering...");

  return () => {
    console.log("Cleanup");
  };
}, []);

Why would I return a function from another function?

It felt... unusual.

Then I tried a small experiment.

⏱️ The Interval That Wouldn't Stop

Inside my About component, I created an interval.

let interval = setInterval(() => {
  console.log("Hey, I'm in About");
}, 1000);

Every second, the console printed:

Hey, I'm in About

Exactly as expected.

Then I switched from the About component to the Contact component.

Since the About component disappeared...

I expected the logging to stop.

It didn't.

The console kept printing:

Hey, I'm in About
Hey, I'm in About
Hey, I'm in About
...

That completely confused me.

The component wasn't even on the screen anymore.

So why was the interval still running?

💡 React Removes Components... Not JavaScript

This was probably the biggest realization of today's lesson.

When React removes a component from the screen...

it only removes the component itself.

It doesn't automatically stop timers, intervals, or event listeners created by JavaScript.

Those things continue running unless I stop them myself.

That's exactly why the cleanup function exists.

🧹 The Cleanup Function

Here's the version that fixed everything.

useEffect(() => {
  let interval = setInterval(() => {
    console.log("Hey, I'm in About");
  }, 1000);

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

Here's how I visualize it now:

About Component Mounts
        ↓
Interval Starts
        ↓
User Switches Page
        ↓
Component Unmounts
        ↓
Cleanup Function Runs
        ↓
Interval Stops ✅

That finally made the purpose of cleanup click for me.

React isn't cleaning things automatically.

It's simply giving me one last chance to clean up anything my component created before it disappears.

🔄 Mount, Re-render, and Unmount

Another thing I kept hearing today was:

Mount
Re-render
Unmount

At first, they sounded like complicated React terms.

But after today's examples, I started thinking about them much more simply.

Mount
↓
Component appears for the first time.

Re-render
↓
Component runs again because state or props changed.

Unmount
↓
Component is removed from the screen.

That also explained why the cleanup function runs during unmounting.

React is basically saying:

"Your component is leaving. If you started anything, now is the time to stop it."

🧠 My Mental Model

This is how I picture useEffect() now.

Component Renders
        ↓
React Updates the UI
        ↓
useEffect Runs
        ↓
Side Effect Happens
(API Call, Timer, Event Listener...)

And if the component is removed...

Component Unmounts
        ↓
Cleanup Function Runs
        ↓
Resources Are Released

Thinking about it this way made today's lesson much easier to remember.

💡 My Biggest Takeaways Today

🎣 useEffect() lets React run code after rendering.
🌐 API requests are a common use case for useEffect().
📦 The dependency array controls when an effect runs.
⚡ An empty dependency array ([]) runs the effect only once after the initial render.
🧹 Cleanup functions stop things like intervals and event listeners before a component unmounts.
🧠 React renders the UI—but side effects are still my responsibility.

📚 Learning Source

I'm currently learning React through React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article is based on my own class notes, code experiments, and understanding. Writing these posts helps me reinforce what I've learned, and hopefully makes things a little easier for other beginners too.

If I've misunderstood something, I'd genuinely appreciate any corrections in the comments. 😊

🙌 Final Thoughts

Today's lesson completely changed how I think about React.

Before today's class, I thought useEffect() was mostly for fetching data from APIs.

By the end of the lesson, I realized API calls are just one example of a side effect.

The real purpose of useEffect() is much bigger.

It's React's way of letting us run code after rendering, while also giving us a chance to clean everything up when a component disappears.

The cleanup function was my favorite part of today's lesson.

Watching an interval continue running after a component disappeared was confusing at first, but once I understood why cleanup exists, everything finally clicked.

I'm starting to notice something interesting about React.

Every hook I've learned so far exists because it solves a very specific problem.

The more I understand those problems, the more React itself starts making sense.

See you on Day 13! 🚀

💬 What confused you the most when you first learned useEffect()? Was it the dependency array, the cleanup function, or simply knowing when to use it? I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

🤖 AI Disclosure: This article is based on my own React learning journey, class notes, code experiments, and understanding. I used ChatGPT to help improve the writing, structure, and readability of this post. I reviewed and verified the technical explanations before publishing, and I take responsibility for everything shared here.

Thanks for reading! 🚀

🚀 Day 11 of Learning React: Finally Understanding React Context API (And Why Prop Drilling Gets Annoying)

Bismay.exe — Mon, 13 Jul 2026 19:17:06 +0000

📌 Missed Day 10? Last time I built my first CRUD application using React Hook Form, Local Storage, and nanoid(). It was the first project where I could create, update, and delete users while keeping the data even after refreshing the page. You can read it here and then come back. I'll wait. ☕️*

Bismay.exe

Jul 13

🚀 Day 10 of Learning React: My React Form Finally Became a Real CRUD App (Local Storage, Create, Update & Delete)

#react #javascript #webdev #beginners

6 min read

Yesterday, I was feeling pretty confident.

I knew how to lift state up.

If two components needed the same data, I could simply move the state to their common parent and pass it down using props.

Problem solved.

...or at least that's what I thought.

Today I realized that lifting state isn't always enough.

As applications grow, passing the same props through multiple components starts becoming frustrating.

That's exactly why React gives us Context API.

🧠 Quick Recap

Here's what I already knew before today's lesson.

State can live in a parent component.
Child components receive data through props.
Multiple components can share the same state by lifting it up.

That worked well for small examples.

But then I started wondering...

What happens when the component that needs the data is several levels deeper?

🤔 The Problem That Lifting State Couldn't Solve

On Day 7, I learned that components can share data by lifting state up.

That works really well...

until the component that needs the data is buried several levels deep.

Imagine this component tree:

App
 ├── Component A
      ├── Component B
            ├── Component C
                  └── Component D

Now suppose Component D needs some data that's stored in App.

Without Context API, the data has to travel through every intermediate component.

App
 ↓
Component A
 ↓
Component B
 ↓
Component C
 ↓
Component D

Even though Components A, B, and C don't actually use the data, they still have to receive it as props and pass it to the next component.

That pattern is called Prop Drilling.

For a small application, it isn't a huge problem.

But once the component tree starts growing, passing the same props through layer after layer quickly becomes difficult to manage.

That's the exact problem Context API is designed to solve.

🚀 Enter Context API

This is where Context API comes in.

Instead of sending props through every component,

React lets us create a shared place where multiple components can access the same data.

Then any component inside that tree can access it whenever it needs to.

My favorite way to think about it is this:

I started thinking of Context API as a shared storage room that every component inside the same application can access.

No more passing keys from one room to another.

🏗️ Creating a Context

The first thing I learned was that React needs a Context object.

import { createContext } from "react";

export const MyShop = createContext();

createContext() creates the shared context.

At this point, it doesn't contain any data yet.

It's simply preparing a place where shared data can live.

📦 The Provider

Creating the context isn't enough.

React also needs to know which components should have access to it.

That's where the Provider comes in.

<MyShop.Provider
  value={{
    isCartOpen,
    setIsCartOpen,
    cartItems,
    setCartItems,
  }}
>
  {children}
</MyShop.Provider>

The Provider makes shared state available to every component inside it.

The Provider wraps part (or all) of the application.

Everything inside it can now access the shared values.

Instead of manually passing props everywhere,

React makes them available automatically.

🎣 Accessing Shared Data With `useContext()`

Now comes the easiest part.

Any child component can read shared data using useContext().

For example:

const { setCartItems } = useContext(MyShop);

That's it.

No prop drilling.

No forwarding props through multiple components.

The component simply asks React for the data.

I honestly thought,

"Wait... that's all?"

It felt much simpler than I expected.

⚙️ Putting Everything Together

After learning each piece individually, I realized Context API follows a pretty simple workflow.

First, create the context.

export const MyShop = createContext();

Then wrap the part of the application that should have access to the shared data.

<MyShop.Provider value={{ cartItems, setCartItems }}>
  <App />
</MyShop.Provider>

Finally, inside any child component, access that data with useContext().

const { cartItems } = useContext(MyShop);

That's really all there is to it.

Instead of memorizing three different APIs, I started thinking of Context API as one simple flow.

Create Context
        ↓
Wrap Components with Provider
        ↓
Store Shared Values in value
        ↓
Read Them Anywhere Using useContext()

That mental model helped everything click for me.

🛒 My Shopping Cart Project

Today's class wasn't just theory.

We built a small shopping cart application.

My shopping cart project before adding any products to the cart.

The application had three main parts:

App
 ├── Navbar
 ├── Product Cards
 └── Cart

The interesting part was this.

The ProductCard component needed to add items to the cart.

The Cart component needed to display those same items.

Instead of passing cart data through several components,

both of them simply accessed the same Context.

Adding a product looked like this:

setCartItems((prev) => [...prev, product]);

And displaying the cart was just:

const { cartItems } = useContext(MyShop);

After clicking **Add to Cart, the product is instantly available in the Cart because both components are reading and updating the same Context.

Both components were reading and updating the exact same state.

I started picturing it like this.

ProductCard
      │
      │ Add Item
      ▼
Shared Context
      ▲
      │ Read Items
Cart

Neither component needed to pass props to the other.

They simply talked to the same Context.

That was the moment I understood why Context API exists.

🔄 How Data Flows

Here's the mental model I built while learning today.

createContext()
        │
        ▼
Provider stores shared data
        │
        ▼
Components call useContext()
        │
        ▼
Access the same shared values

This is the mental model I built while learning Context API.

Once I pictured it this way,

Context API became much easier to understand.

🤔 Is Context API State Management?

At first, I assumed Context API was React's built-in state management solution.

After experimenting with it, I realized that's not really its job.

The actual state still comes from hooks like useState().

Context API simply makes that state available to multiple components without passing props through every level of the component tree.

That small distinction cleared up a misunderstanding I had during today's lesson.

🤯 The Moment It Finally Clicked

At first, I kept thinking,

"Couldn't I just keep passing props?"

Technically...

Yes.

React wouldn't stop me.

But then I imagined adding five or six more components between App and Cart.

Every one of those components would have to accept props they didn't even use.

That's when I finally understood that Context API isn't about making React do something impossible.

It's about making the code easier to work with as an application grows.

That small shift completely changed how I think about sharing data between components.

💡 My Biggest Takeaways

Props work well until they have to travel through many components.
Passing props through intermediate components is called Prop Drilling.
createContext() creates a shared context.
The Provider makes shared values available to child components.
useContext() lets any component read those values directly.
Context API helps share state—it doesn't replace useState().

📚 Learning Source

I'm currently learning React through React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article is based on my own class notes, experiments, and understanding. It's written entirely in my own words to reinforce what I learned.

If I've misunderstood something, I'd genuinely appreciate any corrections in the comments.

🙌 Final Thoughts

Today's lesson answered a question I didn't even know I had.

On Day 7, lifting state up felt like the solution for sharing data.

Today I learned that it isn't always the final solution.

When data needs to travel through several layers of components, Context API gives React a much cleaner way to share it.

I'm sure I'll understand it even better as I build bigger projects, but for now, I finally understand why Context API exists.

And that feels like a big step forward in my React journey.

Tomorrow I'll continue exploring React and see what comes next.

See you on Day 12! 🚀

💬 When did Context API finally "click" for you? Was it when you first learned about prop drilling, or when you built a real project that needed shared state?

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 10 of Learning React: My React Form Finally Became a Real CRUD App (Local Storage, Create, Update & Delete)

Bismay.exe — Mon, 13 Jul 2026 18:55:53 +0000

📌 Missed Day 9? I explored how React Hook Form handles validation, why the errors object exists, and how register() and handleSubmit() work together to prevent invalid form submissions. You can **read it here* and then come back. I'll wait. ☕️*

Bismay.exe

Jul 13

🚀 Day 9 of Learning React: Why Every Form Needs Validation (React Hook Form Made It Surprisingly Easy)

#react #javascript #webdev #beginners

5 min read

Yesterday, I finally built a form that could collect user information.

It worked.

I could enter a name, email, mobile number, and image URL.

Click Add User...

The new user appeared on the screen.

Everything looked perfect.

Until I refreshed the page.

Every single user disappeared.

😐

That's when I realized something.

React wasn't losing my data...

It was doing exactly what I asked it to do.

The problem was that I was only storing everything in state.

Today, I learned how to make my application actually remember data—even after refreshing the browser.

And by the end of the class, my simple form had turned into my first CRUD application. 🚀

🧠 Quick Recap

Yesterday's big question was:

How can I make forms smarter with validation?

Here's what I learned on Day 9:

✅ React Hook Form simplifies form handling.
⚠️ Validation rules prevent invalid input.
📩 errors stores validation messages.
📝 register() connects inputs to React Hook Form.
🚀 handleSubmit() only runs when validation passes.

Today, we're answering a different question:

How can my application actually remember user data? 🤔

💾 The Problem With React State

At first, I stored my users like this:

const [users, setUsers] = useState([]);

Whenever I submitted the form, a new user appeared instantly.

Everything seemed fine.

Until I pressed refresh.

Add User
     ↓
User Appears
     ↓
Refresh Browser
     ↓
Everything Disappears 😶

That wasn't React making a mistake.

It was simply because React state only lives while the application is running.

Refreshing the page starts everything from scratch.

📦 Enter Local Storage

That's where I discovered Local Storage.

Unlike React state, Local Storage is built into the browser.

It stores data even after refreshing the page.

Instead of starting with an empty array, I initialized my state like this:

const [users, setUsers] = useState(
  JSON.parse(localStorage.getItem("users")) || []
);

At first, that line looked intimidating.

But after breaking it down, it made perfect sense.

🧩 Breaking It Down

First:

localStorage.getItem("users")

tries to read previously saved users.

But Local Storage stores everything as strings.

That's why React can't use it directly.

So I used:

JSON.parse(...)

to convert the string back into an array of objects.

Finally:

|| []

acts as a fallback.

If no users exist yet, React simply starts with an empty array.

💾 Saving Users

Loading data is only half of the story.

Whenever I created a new user, I also needed to save it.

localStorage.setItem(
  "users",
  JSON.stringify(arr)
);

This line does the opposite.

JavaScript Object
        ↓
JSON.stringify()
        ↓
String
        ↓
Saved in Local Storage

Now, even after refreshing the page...

My users were still there.

That was a really satisfying moment.

🆔 Every User Needs a Unique Identity

While building the CRUD application, I ran into another small but important problem.

Every user needed a way to be uniquely identified.

Without a unique ID, React wouldn't know exactly which user I wanted to update or delete.

There are several ways to generate unique IDs. Some common options are:

Using a database-generated ID
JavaScript's built-in crypto.randomUUID()
The popular uuid package
The lightweight nanoid package

For this project, I used nanoid because it's simple, lightweight, and generates unique IDs with very little setup.

📦 Installing Nano ID

npm install nanoid

After installing it, I imported it into my component:

import { nanoid } from "nanoid";

Whenever I created a new user, I generated a unique ID like this:

const newUser = {
  ...data,
  id: nanoid(),
};

Now every user has its own unique identifier.

That ID becomes incredibly useful later.

When I click Update or Delete, React can easily find the correct user by comparing IDs instead of relying on things like the user's name or their position in the array.

It might seem like a tiny detail, but adding unique IDs makes managing collections of data much more reliable—especially as applications grow larger.

❌ Deleting Users

The next feature I added was deleting users.

The logic turned out to be surprisingly clean.

const filteredUsers = users.filter(
  (user) => user.id !== id
);

The flow looks like this:

Click Delete
      ↓
Remove Matching User
      ↓
Update State
      ↓
Update Local Storage
      ↓
UI Updates ✨

One click...

And the selected card disappeared.

✏️ Reusing the Same Form for Updates

This was probably the coolest part of today's project.

My first thought was:

"Updating a user probably needs another form."

It turns out...

It didn't.

I reused the exact same form for both creating and updating users.

That felt much cleaner than building two separate forms.

📋 Filling the Form Automatically

When I clicked Update, I passed the selected user's data into the form.

defaultValues: updatedData

That tiny line made React Hook Form automatically fill every input.

Instead of seeing empty fields...

I immediately saw the existing user's information.

It felt like the form already knew what I wanted to edit.

🔄 Updating Only One User

Saving the updated data was another interesting part.

Instead of replacing the whole array, I only replaced the matching user.

setUsers((prev) =>
  prev.map((user) =>
    user.id === updatedData.id
      ? { ...data }
      : user
  )
);

Here's how I visualize it:

Users Array
      ↓
Loop Through Every User
      ↓
Matching ID?
      ↓
YES ✅ Replace It

NO ❌ Keep It

Only one object changes.

Everything else stays exactly the same.

That made map() feel much more practical than when I first learned it.

🧠 My Mental Model

Today's project finally connected a lot of concepts I'd learned over the past few days.

Fill Form
      ↓
React Hook Form Validates
      ↓
User Added
      ↓
Save in State
      ↓
Save in Local Storage
      ↓
Render User Cards
      ↓
Update or Delete User
      ↓
UI Updates Automatically ✨

Seeing everything work together made the project feel much more like a real application instead of isolated React examples.

💡 My Biggest Takeaways Today

💾 React state disappears after a refresh, but Local Storage doesn't.
📦 JSON.parse() converts stored strings back into JavaScript objects.
📝 JSON.stringify() prepares objects before saving them.
🆔 nanoid() makes it easy to generate unique IDs.
✏️ The same form can be reused for both creating and updating users.
🔄 map() makes updating a single object inside an array surprisingly clean.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article is based on my own class notes, code experiments, and understanding after today's session. Writing these posts helps me reinforce what I've learned, and hopefully helps other beginners following a similar path.

If I've misunderstood anything, I'd genuinely appreciate corrections in the comments. 😊

🙌 Final Thoughts

Today's project felt different from the previous ones.

Instead of learning a single React concept, I finally saw several concepts working together.

State stored the data.

React Hook Form handled user input.

Local Storage made the data survive page refreshes.

map() updated individual users.

filter() removed them.

For the first time, it felt like I wasn't just writing React code—I was building something that behaved like a real application.

Tomorrow's topic is Context API, and I'm curious to see how React lets components share data without passing props through every level.

See you on Day 11! 🚀

💬 When you built your first CRUD application, what feature felt the most satisfying to implement—Create, Update, Delete, or saving data with Local Storage?

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 9 of Learning React: Why Every Form Needs Validation (React Hook Form Made It Surprisingly Easy)

Bismay.exe — Mon, 13 Jul 2026 18:24:32 +0000

📌 Missed Day 8? I explored why React doesn't usually let us work directly with the DOM, how useRef() gives us access to real DOM elements, and why React Hook Form makes handling forms much cleaner. You can **read it here* and then come back. I'll wait. ☕️*

Bismay.exe

Jul 13

🚀 Day 8 of Learning React: Why Doesn't React Use the DOM Directly? Understanding useRef() & React Hook Form

#react #javascript #webdev #beginners

5 min read

Yesterday, I finally understood how React Hook Form simplified form handling.

I thought that was the hard part.

Turns out...

Building the form was only half the job.

Because no matter how beautiful a form looks, there's always one problem.

Users can type literally anything.

An empty name.

An invalid email.

A phone number with only five digits.

Without validation, my application would happily accept all of them.

Today's lesson wasn't about making forms prettier.

It was about making them smarter.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday's big question was:

Why doesn't React use the DOM directly?

Here's what I learned on Day 8:

🎣 useRef() lets React keep references to DOM elements.
🌳 React usually works with the Virtual DOM instead of the Real DOM.
📝 React Hook Form makes handling forms much cleaner.
🚀 register(), handleSubmit(), and reset() reduce repetitive form logic.

Today we're answering a different question:

How do we stop users from submitting invalid data? 🤔

🤔 A Form That Accepts Everything...

At first, my form looked perfectly fine.

<input {...register("name")} />
<input {...register("email")} />

Users could type...

Click Submit...

Everything worked.

Or at least...

It looked like it worked.

Then I started thinking about something.

The form before submission. At this point, nothing prevents users from entering invalid data.

What if someone submitted this?

Name:
"          "

Or this?

Email:
abc123

Or even left every field empty?

My form would still accept it.

That's when I realized something.

Collecting user input is easy. Trusting it is the difficult part.

🚫 My First Validation Rule

The first validation rule I added was surprisingly simple.

register("name", {
  required: "Name is required",
})

That one line completely changed the form.

If I clicked Submit without entering a name...

React Hook Form immediately displayed:

Name is required

And something interesting happened.

My formSubmit() function never ran.

Instead of giving me invalid data...

React Hook Form stopped everything before submission.

Validation errors appear before the form is submitted, preventing invalid data from reaching my submit function.

That felt really impressive.

📧 Making Sure Emails Actually Look Like Emails

The next field was email.

register("email", {
  required: "Email is required",
  pattern: {
    value: /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/,
    message: "Please enter valid email",
  },
})

The regular expression looked scary at first. 😅

I definitely wasn't trying to memorize it.

What mattered to me was understanding its job.

If the entered email doesn't match the expected format...

React Hook Form simply refuses to submit the form and shows my custom error message.

That made much more sense than manually checking every possible email format myself.

📱 Validating a Phone Number

Next came the mobile number.

register("mobile", {
  required: "Mobile is required",
  minLength: {
    value: 10,
    message: "Minimum 10 digits are required",
  },
  maxLength: {
    value: 10,
    message: "Maximum 10 digits are required",
  },
})

This one was interesting.

Using both minLength and maxLength meant the user had to enter exactly 10 digits.

Less than ten?

Error.

More than ten?

Still an error.

It was a simple way to enforce a rule without writing any custom logic.

🖼️ Even the Image Field Needed Validation

The image input looked straightforward.

register("image", {
  required: "Image is required",
})

Without it...

Someone could submit the form without providing an image.

The validation rule made sure every user card had all the information it needed before being created.

🚨 The `errors` Object Did All the Heavy Lifting

One thing I really liked was how React Hook Form keeps track of every validation error.

Displaying an error was as simple as:

{errors.name && (
  <p>{errors.name.message}</p>
)}

The same pattern worked for every field.

errors.email
errors.mobile
errors.image

That was much cleaner than writing lots of if statements myself.

I didn't need to manually check:

if (name === "") {
  ...
}

if (email === "") {
  ...
}

React Hook Form had already done that work for me.

I only needed to decide how the errors should appear on the screen.

📤 Validation Happens Before Submission

One thing finally clicked today.

I used to think clicking Submit immediately called my function.

That's not actually what happens.

The flow looks more like this.

User Clicks Submit
          ↓
React Hook Form Checks Every Rule
          ↓
Everything Valid?

YES ✅
Run formSubmit()

NO ❌
Fill the errors Object
Display Error Messages

That small flow completely changed how I think about forms.

💡 My Mental Model

Here's how I visualize today's lesson now.

User Types
      ↓
Validation Rules
      ↓
Valid Input?
      ↓
YES ✅ --------→ Submit Form
      ↓
NO ❌ --------→ Show Errors

Instead of blindly accepting everything...

The form now protects itself before any data is submitted.

💡 My Biggest Takeaways Today

📝 Building a form is only half the job—validation is just as important.
🚫 required prevents empty submissions.
📧 pattern helps validate formats like email addresses.
📱 minLength and maxLength can enforce rules such as a 10-digit phone number.
🚨 React Hook Form automatically stores validation errors inside the errors object.
⚡ Validation happens before the submit function is executed.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Yesterday, I learned how React Hook Form made building forms easier.

Today, I learned that forms aren't just about collecting data.

They're also responsible for protecting it.

That shift completely changed how I look at forms.

Instead of thinking:

Collect Input
      ↓
Submit

I now think:

Collect Input
      ↓
Validate Input
      ↓
Submit

It seems like a small difference.

But today's project showed me that validation isn't an extra feature.

It's part of building a reliable application.

See you on Day 10! 🚀

💬 When you first started building forms, did you add validation from the beginning, or did you realize its importance only after seeing users enter unexpected data? I'd love to hear your experience in the comments. 😊

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 8 of Learning React: Why Doesn't React Use the DOM Directly? Understanding useRef() & React Hook Form

Bismay.exe — Mon, 13 Jul 2026 17:39:31 +0000

📌 Missed Day 7? I explored why sibling components can't share state directly, how lifting state up works, and why moving state to the parent makes component communication much cleaner. You can **read it here* and then come back. I'll wait. ☕️*

Bismay.exe

Jul 13

🚀 Day 7 of Learning React: How Do Components Share Data? Understanding Lifting State Up

#react #javascript #webdev #beginners

5 min read

For the past few days, React has been doing almost everything for me.

Rendering components...

Updating the UI...

Handling state...

Managing events...

I barely had to think about the browser itself.

Today, that changed.

I needed something React usually hides from us.

The actual DOM.

That was my introduction to useRef().

But what surprised me even more was what came after that.

Once I understood useRef, learning React Hook Form suddenly made a lot more sense.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday's big question was:

How do multiple components share the same state?

Here's what I took away from Day 7:

⬆️ Shared state belongs in the nearest common parent.
📨 Props can pass both data and functions.
👨‍👧 Sibling components can't directly access each other's state.
🧩 React's data always flows from parent to child.

Today we're answering a different question:

If React has a Virtual DOM... how do we access the real DOM? 🤔

🌳 React Doesn't Work Directly with the Browser

One thing I learned today is that React usually protects us from working with the real DOM.

Normally, when we write React code, we're interacting with React itself.

Not directly with the browser.

The flow looks something like this.

My Code
     ↓
React
     ↓
Virtual DOM
     ↓
Real DOM

That means most of the time, React decides when and how the browser should update.

We don't touch the DOM ourselves.

🎯 What Exactly Is the Real DOM?

The Real DOM is simply the actual webpage the browser creates.

Every button...

Every heading...

Every input...

Everything you see on the screen exists inside the browser's Document Object Model (DOM).

That's also where browser APIs and events live.

Real DOM
├── Document
├── Elements
├── Browser APIs
└── Native Events

React normally keeps us away from it.

But sometimes...

We genuinely need access to it.

🎭 React Doesn't Even Give Us Native Events

This part surprised me.

When we write something like:

<button onClick={handleClick}>

We're not actually working with the browser's native event directly.

React wraps browser events into something called Synthetic Events.

The idea looks something like this:

Browser Event
        ↓
React Wraps It
        ↓
Synthetic Event
        ↓
Our Event Handler

That wrapper helps React provide a consistent experience across different browsers.

Another example of React hiding browser details from us.

🎣 So... How Do We Reach the Real DOM?

That's exactly why React provides another Hook.

const inputRef = useRef();

Instead of storing state...

useRef() stores a reference.

That reference can point to a real DOM element.

Then we connect it like this.

<input ref={inputRef} />

Now React gives us access to that input element whenever we need it.

📝 Building a Form with `useRef()`

Today's first form didn't use controlled inputs.

Instead, every input stored a reference.

Something like this:

ref={(element) => (formRef.current.productName = element)}

Then, when the form was submitted...

I could read the values directly.

const product = {
  pName: formRef.current.productName.value,
  price: formRef.current.price.value,
  category: formRef.current.category.value,
};

It actually worked really well.

Seeing values come directly from the DOM was pretty interesting.

🤔 But Something Started Feeling Repetitive...

As I added more inputs...

I noticed something.

Every field needed another reference.

formRef.current.productName
formRef.current.price
formRef.current.category
formRef.current.image

The larger the form became...

The more repetitive the code felt.

And that's when today's second topic entered the picture.

🚀 Enter React Hook Form

After writing a form manually...

I tried building the same thing using React Hook Form.

The first step was installing the package.

Then everything started with:

const {
  register,
  handleSubmit,
  reset,
} = useForm();

One thing I liked immediately was that I could destructure only the things I actually needed.

✨ `register()` Felt Like Magic

Instead of creating references manually...

Every input simply used register().

<input
  {...register("productName")}
/>

That's it.

No manual refs.

No repeated logic.

Every field automatically became part of the form.

That looked much cleaner.

📤 Submitting the Form Became Simpler Too

Instead of collecting every value manually...

React Hook Form handed everything to me.

const formSubmit = (data) => {
  console.log(data);
  reset();
};

The data object already contained every input value.

No need to write:

formRef.current.name.value

over and over again.

That was probably my favorite part.

🔄 Comparing the Two Approaches

Here's how I think about them now.

Using `useRef()`

Create Ref
      ↓
Attach Ref
      ↓
Access .current
      ↓
Read Value

Using React Hook Form

register()
      ↓
handleSubmit()
      ↓
Receive Form Data
      ↓
Done ✅

Both approaches work.

One simply removes a lot of repetitive work.

💡 My Mental Model

Here's how today's lesson connects in my head.

React Hides the DOM
          ↓
Need Direct Access?
          ↓
useRef()
          ↓
Building Bigger Forms?
          ↓
React Hook Form

That simple flow helped everything click.

💡 My Biggest Takeaways Today

🎣 useRef() lets React keep a reference to a real DOM element.
🌳 React normally works with the Virtual DOM instead of the Real DOM.
🎭 React wraps browser events into Synthetic Events.
📝 Forms built with useRef() work well but become repetitive as they grow.
🚀 React Hook Form removes much of that repetitive code.
📦 register(), handleSubmit(), and reset() make form handling much cleaner.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Today's class answered a question I hadn't really thought about before.

React usually keeps us away from the browser.

Most of the time, that's exactly what we want.

But sometimes...

We genuinely need access to the real DOM.

That's where useRef() comes in.

And after using it to build a form manually, I could immediately appreciate why libraries like React Hook Form exist.

They don't replace React.

They simply remove a lot of repetitive work while still using React's ideas under the hood.

I feel like today's lesson wasn't just about learning another Hook.

It was about understanding where React stops... and where we occasionally need to work a little closer to the browser.

See you on Day 9! 🚀

💬 When did useRef() finally click for you? Was it focusing an input, reading form values, or something completely different? I'd love to hear your experience in the comments. 😊

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 7 of Learning React: How Do Components Share Data? Understanding Lifting State Up

Bismay.exe — Mon, 13 Jul 2026 16:25:37 +0000

📌 Missed Day 6? I explored how React renders components, why immutable updates matter, how HMR works behind the scenes, and different approaches to handling forms. You can **read it here* and then come back. I'll wait. ☕️*

Bismay.exe

Jul 2

🚀 Day 6 of Learning React: The Day React's Rendering Finally Started Making Sense (HMR, Bundlers & Form Handling)

#react #javascript #webdev #beginners

8 min read

Yesterday, I spent most of my time learning how React updates the UI.

Today, I ran into a completely different problem.

I had a registration form.

I also had a list of user cards.

Whenever someone filled out the form and clicked Register, I wanted a new user card to appear automatically.

Sounds simple...

Except there was one problem.

The form and the user cards lived in different components.

That's when I learned one of React's most important patterns:

Lifting State Up.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday's big question was:

How does React know when something should be re-rendered?

Here's what I took away from Day 6:

🛍️ map() helps render multiple components from data.
🔄 React prefers immutable updates.
📝 Forms become much cleaner when using a single reusable change handler.
🚫 DRY (Don't Repeat Yourself) makes React code easier to maintain.

Today we're answering a different question:

How do two components share the same data? 🤔

🏗️ The Project

Today's project looked something like this.

App
├── Register
└── UserCard

The Register component collected user information.

The UserCard component displayed all registered users.

Pretty straightforward.

At first, I thought these two components could somehow communicate with each other directly.

They can't.

That misunderstanding was the beginning of today's lesson.

🤔 The Problem

Inside my Register component, I already had state.

const [formData, setFormData] = useState({
  name: "",
  email: "",
  password: "",
  image: "",
});

Submitting the form updated formData perfectly.

But another question appeared.

How does UserCard know a new user was registered?

It doesn't.

Because UserCard has absolutely no access to Register's state.

That state belongs only to the Register component.

🚫 Sibling Components Can't Read Each Other's State

This was probably the biggest realization of today's class.

Both components were children of the same parent.

App
├── Register
└── UserCard

That makes them siblings.

And sibling components cannot directly access each other's state.

For a while, I kept thinking there must be some way for one component to "look inside" another.

There isn't.

React doesn't work like that.

💡 The Solution Was Surprisingly Simple

Instead of trying to make the two components communicate...

I moved the shared state up.

From this:

Register
└── users state

To this:

App
├── users state
├── Register
└── UserCard

That small change solved everything.

And that's exactly why this pattern is called:

Lifting State Up.

We're simply moving shared state to the nearest common parent.

📦 The Parent Owns the State

Instead of storing users inside Register, I stored them inside App.

const [users, setUsers] = useState([]);

Now App became the single source of truth.

Instead of owning the users...

The child components simply used them.

📨 Props Started Making Much More Sense

Once the state lived inside App, everything connected beautifully.

Register received the updater function.

<Register setUsers={setUsers} />

Whenever someone submitted the form,

Register simply called:

setUsers((prev) => [...prev, formData]);

It wasn't updating its own state anymore.

It was asking App to update the shared state.

That tiny detail completely changed how I think about props.

They're not just for sending data.

They can also send functions.

🪄 Where Did the New User Card Come From?

This was my favorite part.

I never manually created a new card.

Instead, App rendered the cards like this:

{
  users.map((elem) => (
    <UserCard
      key={elem.email}
      user={elem}
    />
  ));
}

As soon as users changed...

React rendered another UserCard.

No DOM manipulation.

No extra logic.

Just a state update.

That pattern is becoming more and more familiar every day.

💡 My Mental Model

Here's how I visualize today's lesson.

User Fills Form
        ↓
Register Calls setUsers()
        ↓
App Updates users State
        ↓
App Re-renders
        ↓
Updated users Passed to UserCard
        ↓
New User Card Appears ✨

That flow made today's topic click for me.

🤝 Why Lift the State?

At first, moving state to another component felt unnecessary.

But after today's project, it actually made perfect sense.

Now there is:

✅ One place where the users are stored.
✅ One source of truth.
✅ Both components stay synchronized.
✅ No duplicated state.

Instead of each component trying to manage the same information...

They simply rely on the parent.

💡 My Biggest Takeaways Today

🏗️ Components don't automatically share state.
👨‍👧 Sibling components can't directly access each other's state.
⬆️ Shared state should live in the nearest common parent.
📨 Props can pass both data and functions.
🔄 Updating the parent's state automatically updates every child that depends on it.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Today's lesson wasn't about learning another Hook or another React API.

It was about learning where state actually belongs.

Earlier, I thought state should always stay inside the component that uses it.

Now I know that's not always true.

If multiple components need the same information, the best solution isn't to duplicate the state.

It's to move that state to their nearest common parent and let React's data flow do the rest.

That one idea made component communication feel much less mysterious.

See you on Day 8! 🚀

💬 When you first learned React, did you also try making sibling components share state directly, or did lifting state up click immediately for you? I'd love to hear your experience in the comments. 😊

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 6 of Learning React: The Day React's Rendering Finally Started Making Sense (HMR, Bundlers & Form Handling)

Bismay.exe — Thu, 02 Jul 2026 19:40:07 +0000

📌 Missed Day 5? I explored React's Automatic Batching, why calling setState(count + 1) three times only increments once, and how functional updates with prev solve that problem. You can **read it here* and then come back. I'll wait. ☕️*

Expanded update grouping since React 18

Bismay.exe

Jul 1

🚀 Day 5 of Learning React: Understanding Automatic Batching & Functional Updates

#react #javascript #webdev #beginners

5 min read

Yesterday's lesson answered one question:

Why doesn't React update immediately after every setState() call?

Today's class answered another one:

How does React know what to render?

At first, today's topics felt completely unrelated.

Rendering with map()...

Deleting product cards...

Hot Module Replacement...

Primitive and reference types...

Mutable and immutable values...

Form handling...

It honestly felt like React was throwing random concepts at me.

But somewhere in the middle of the class, something clicked.

Every single topic was connected by one idea:

React doesn't care that your data changed. It cares whether it can detect that something changed.

Once I started looking at today's lesson from that perspective, everything began making sense.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday's big question was:

Why doesn't setState() update immediately?

Here's what I took away from Day 5:

⚡ React automatically batches multiple state updates.
📦 State updates are stored in an internal update queue.
🔄 Functional updates with prev always receive the latest available state.
🚀 Multiple setState() calls don't always mean multiple renders.

Today we're answering a different question:

How does React know what needs to be rendered? 🤔

🛍️ One Component... Twenty Product Cards

Today's project was much more interesting than rendering static JSX.

Instead of writing the same product card over and over again, I created a reusable ProductsCard component.

Then I stored 20 product objects inside state.

Rendering them was surprisingly simple.

{
  productsData.map((elem) => {
    return (
      <ProductsCard
        key={elem.id}
        product={elem}
        del={deleteProduct}
      />
    );
  });
}

That single map() generated every product card on the screen.

If I had written twenty separate components manually...

I'd just be repeating the same code.

This reminded me of a programming principle we learned later in class:

DRY — Don't Repeat Yourself.

Instead of repeating UI, React encourages us to build reusable components and let data drive the interface.

That felt much cleaner.

🗑️ Simple Delete Function

Each product card had a Delete button.

Clicking it removed only that specific product.

The interesting part wasn't the button.

It was how React updated the screen.

const deleteProduct = (id) => {
  const products = productsData.filter(
    (elem) => elem.id !== id
  );

  setProductsData(products);
};

Notice something?

I never removed any HTML.

I never searched for a DOM element.

I never called remove().

All I did was create a new array without the deleted product.

Then I updated the state.

React compared the new array with the previous one...

Re-rendered the component...

And only the missing card disappeared from the UI.

That was another reminder that in React, we don't usually manipulate the DOM ourselves.

We change the state.

React takes care of the UI.

🔥 Saving a File Isn't Magic — It's HMR

One thing I had never really paid attention to was what happens after pressing Ctrl + S.

The browser updates almost instantly.

But what's actually happening?

That's where Hot Module Replacement (HMR) comes in.

The moment I save a file, Vite immediately detects that something has changed. I even noticed it printing messages like this in the terminal:

Every time I save a file, Vite logs an HMR update in the terminal, showing which modules were updated.

Seeing this made HMR feel much less "magical." Vite is constantly watching the project, and whenever a file changes, it knows exactly which module needs to be updated.

The process looks something like this:

Save File
      ↓
Vite Detects the Change
      ↓
Updates the Changed Module
      ↓
Browser Receives the Updated Code
      ↓
UI Updates Instantly ⚡

Instead of refreshing the entire application, Vite only replaces the module that changed.

That's why development feels incredibly fast.

📦 Bundlers Are Doing More Than I Thought

HMR also led us to bundlers.

Whenever our code changes, a bundler helps rebuild the project so the browser can understand it.

The flow looks like this:

React Files
      ↓
esbuild Transforms the Code
      ↓
Browser Executes JavaScript

We talked about two bundlers in particular:

⚡ esbuild — used during development because it's extremely fast.
📦 Rollup — used for production builds because it focuses on creating optimized bundles.

I had heard both names before.

Today I finally understood where they fit into the development process.

During development, Vite mainly relies on esbuild because it's extremely fast.

When creating a production build, Vite uses Rollup to generate optimized bundles.

🎣 Looking at `useState()` From a Different Perspective

We've spent the last couple of days working with useState(), but today we summarized what it actually does.

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

This tiny Hook is responsible for several important things:

🧠 Maintaining state.
✏️ Updating state.
🔄 Re-rendering its component.
⚡ Making the UI interactive.

It may look simple...

But it's doing a lot behind the scenes.

🤯 The Object Experiment That Completely Confused Me

Numbers behaved exactly how I expected.

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

Then I tried storing an object.

const [user, setUser] = useState({
  name: "New User",
});

I expected updating the object to work exactly like updating a number.

It didn't.

That confused me.

The solution turned out to be surprisingly simple.

Instead of changing the existing object...

I created a new object.

Suddenly everything worked.

That tiny change introduced me to one of the most important ideas in React.

🧩 Primitive vs Reference Types

To understand why the object behaved differently, we first talked about JavaScript values.

Primitive values include things like:

Number
String
Boolean

Reference values include:

Object
Array
Function

The biggest difference is that primitive values store the actual value.

Reference types store a reference to where that value lives in memory.

That difference becomes really important when React decides whether something has changed.

🔄 Mutable vs Immutable — The Example That Made It Click

This was probably my favorite explanation from today's class.

Imagine you have a notebook.

📝 Mutable

You erase what's written on page one.

Then you write something new on that same page.

The notebook is still the same notebook.

Only its contents changed.

Objects and arrays behave like this.

user.name = "Alex";

The object is still the same object.

Only one property changed.

📄 Immutable

Now imagine making a photocopy of that notebook first.

You leave the original untouched.

Then you edit the copied version.

That's what immutable updates look like.

const updatedUser = {
  ...user,
  name: "Alex",
};

Instead of changing the original object...

We create a brand new one.

React can easily detect that the reference has changed when you create a new object.

If you mutate the existing object, the reference stays the same, making it harder for React to know something changed.

That finally explained why creating a new object fixed my state update.

📝 One Form, Three Different Approaches

The last topic I explored today was form handling.

More specifically...

Input handling.

What I found interesting wasn't the form itself.

It was how the solution became cleaner with every new approach.

The goal never changed.

Collect the user's input.

Only the implementation did.

1️⃣ Brute Force

The first approach was the most straightforward.

Every input had its own state.

const [name, setName] = useState("");
const [email, setEmail] = useState("");
const [password, setPassword] = useState("");

Each input also had its own onChange.

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

There's nothing wrong with this approach.

But after looking at it for a minute, the repetition becomes obvious.

Every new input means another state...

Another onChange...

And another piece of nearly identical code.

2️⃣ Better Approach

The next version reduced that repetition by storing everything inside a single object.

const [formData, setFormData] = useState({
  name: "",
  email: "",
  password: "",
});

Updating an input looked like this:

<input
  onChange={(e) =>
    setFormData({
      ...formData,
      email: e.target.value,
    })
  }
/>

One state object was enough to store every field.

Definitely cleaner.

But every input still repeated almost the same onChange logic.

Only the property name changed.

3️⃣ Optimized Approach

The final version was easily my favorite.

Instead of creating separate handlers...

One function handled every input.

const handleChange = (e) => {
  const { name, value } = e.target;

  setFormData({
    ...formData,
    [name]: value,
  });
};

Now every input looked almost identical.

<input name="name" onChange={handleChange} />
<input name="email" onChange={handleChange} />
<input name="password" onChange={handleChange} />

The clever part was this line:

[name]: value

If the input's name is "email"...

React updates:

formData.email

If the input's name is "password"...

React updates:

formData.password

The same function works for every field.

No extra handlers.

No repeated logic.

Just one reusable solution.

That immediately reminded me of another principle from today's class:

DRY — Don't Repeat Yourself.

The optimized version wasn't just shorter.

It was much easier to maintain, especially as the number of inputs grows.

💡 DRY — Don't Repeat Yourself

Today's optimized form perfectly demonstrated one principle:

DRY — Don't Repeat Yourself.

I noticed React encourages this idea everywhere.

Instead of writing twenty product cards...

We use map().

Instead of writing three different change handlers...

We use one reusable function.

Instead of building separate components that look almost identical...

We reuse the same component with different props.

The more I work with React, the more I realize it's constantly pushing me toward writing cleaner, reusable code.

💡 My Mental Model

Here's how I connect today's topics in my head:

State Update
      ↓
React Compares the Previous State
      ↓
If Something Changed
      ↓
Component Re-renders
      ↓
Updated UI ✨

Whether it's deleting a product...

Updating an object...

Or typing inside a form...

The same rendering process keeps happening behind the scenes.

💡 My Biggest Takeaways Today

🛍️ map() lets us render large amounts of UI without repeating code.
🗑️ Updating state is enough for React to update the UI—we rarely touch the DOM directly.
🔥 HMR instantly updates changed modules, making development much faster.
📦 esbuild powers development, while Rollup creates optimized production builds.
🧩 Objects and arrays are reference types, while numbers, strings, and booleans are primitive values.
🔄 React prefers immutable updates because creating new objects and arrays makes changes easier to detect.
📝 Form handling becomes much cleaner when one reusable function manages every input.
🚫 DRY (Don't Repeat Yourself) is a principle that shows up everywhere in React.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Today's class looked overwhelming at first because it covered so many different topics.

But after connecting all the dots, I realized they all revolve around the same idea.

React needs a reliable way to know when something has changed.

Whether it's rendering a list with map(), deleting an item by updating state, creating a new object instead of mutating an old one, or building reusable form handlers, everything ultimately comes back to helping React render efficiently.

The more I learn React, the more I realize that most concepts eventually come back to one question:

How can React reliably detect that something has changed?

Today's class made that question much easier to answer.

See you on Day 7! 🚀

💬 Which concept took you the longest to understand when learning React—rendering, immutability, or form handling? I'd love to hear what finally made it click for you. 😊

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 5 of Learning React: Understanding Automatic Batching & Functional Updates

Bismay.exe — Wed, 01 Jul 2026 17:57:22 +0000

📌 Missed Day 4? I explored what React Hooks are, why useState() returns two values, how React remembers state, and why calling the setter function triggers a re-render. You can read it here and then come back. I'll wait. ☕️

Bismay.exe

Jun 25

🚀 Day 4 of Learning React: What Actually Makes React... React? (Hooks, useState, and State Explained)

#react #javasc #webdev #beginners

6 min read

Yesterday, I learned that calling setState() tells React to update the UI.

So naturally, I assumed something like this:

setCount(1);
setName("Dev");
setAge(24);

would make React render...

Three times.

Turns out, I was completely wrong.

Today I learned that React is much smarter than that.

Instead of rendering after every state update, React groups multiple updates together and performs only one render.

This optimization is called Automatic Batching.

And honestly...

Once I understood batching, a lot of React's behavior finally started making sense.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday's big question was:

How does React know when to update the UI?

Here's what I learned on Day 4:

🎣 Hooks give React components memory.
⚡ useState() returns the current state and a setter function.
🔄 Calling the setter updates the state and triggers a re-render.
🧠 React skips updates when the new state is the same as the old one.

Today we're answering a different question:

What happens when we call setState() multiple times? 🤔

⚡ React Doesn't Render After Every `setState()`

Suppose we write:

setCount(1);
setName("Dev");
setAge(24);

My first thought was:

"React must be rendering three separate times."

Nope.

React groups all of those state updates together before rendering.

The flow looks something like this:

Multiple State Updates
        ↓
React Batches Them
        ↓
Single Render
        ↓
Single Commit

Instead of doing unnecessary work, React waits, collects all the updates, and applies them together.

That's what Automatic Batching is all about.

It's one of React's built-in optimizations that helps improve performance.

🤯 The Counter Experiment That Confused Me

After learning about batching, I tried something interesting.

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

I expected the counter to jump like this:

0 → 3

Instead...

It became:

0 → 1

Wait...

I called setCount() three times.

Why did it only increase once?

🧩 What React Actually Sees

At first, it looked like I was asking React to increase the counter three times.

But that's not what's really happening.

Assume the current value of count is:

Every line becomes:

setCount(1);
setCount(1);
setCount(1);

React batches those updates together.

Since every update is trying to set the state to the same value, the final result is simply:

That's why the counter only increases once.

This was a really interesting moment because it showed me that setCount(count + 1) isn't saying:

"Increase the count."

It's actually saying:

"Set the count to this calculated value."

🔄 The Mysterious `prev`

Then our instructor introduced something new:

setCount((prev) => {
  return prev + 1;
});

At first, I wondered...

What exactly is prev?

The simplest way I understand it now is:

prev is the latest state React has available while processing the update queue.

It's basically the current state at that particular moment.

🤯 My Biggest "Wait... What?" Moment

I accidentally wrote this:

setCount((prev) => {
  prev + 1;
});

When I clicked the button...

The counter became:

undefined

🤯

For a second, I thought React was broken.

Turns out...

The problem was mine.

💡 Why Did It Become `undefined`?

Arrow functions with curly braces don't automatically return a value.

I forgot to write:

return prev + 1;

So React received:

undefined

instead of a number.

The correct version is:

setCount((prev) => {
  return prev + 1;
});

Or, even shorter:

setCount((prev) => prev + 1);

That tiny return completely changed the result.

🚀 Why Functional Updates Work

Now let's use the functional version three times.

setCount((prev) => prev + 1);
setCount((prev) => prev + 1);
setCount((prev) => prev + 1);

This time, the counter actually increases by 3.

Why?

Because React doesn't keep using the original value.

Instead, each updater receives the latest available state.

The process looks like this:

Initial State
count = 0
    │
    ▼
First updater
prev = 0
returns 1
    │
    ▼
count = 1
    │
    ▼
Second updater
prev = 1
returns 2
    │
    ▼
count = 2
    │
    ▼
Third updater
prev = 2
returns 3
    │
    ▼
Final State
count = 3

That was probably my favorite part of today's lesson.

I finally understood why React recommends functional updates whenever the next state depends on the previous one.

📦 React's Update Queue

Another thing I learned today is that React doesn't execute state updates immediately.

Instead, it stores them in something called an Update Queue.

Imagine writing:

setCount(1);
setCount(2);
setCount(3);

React doesn't instantly update the UI after each line.

The flow is more like this:

setState()
      ↓
Update Queue
      ↓
React Processes Updates
      ↓
Render
      ↓
Commit

This update queue is what makes features like batching and functional updates possible.

React collects everything first...

Then processes it efficiently.

💡 My Mental Model

Here's how I visualize today's lesson:

Multiple setState() Calls
          ↓
Stored Inside React's Update Queue
          ↓
React Batches Them Together
          ↓
Processes Every Update
          ↓
Renders Once
          ↓
Browser Shows Updated UI ✨

That flow made today's topic much easier to understand.

💡 My Biggest Takeaways Today

⚡ React automatically batches multiple state updates together.
🎯 Multiple setState() calls don't always mean multiple renders.
🧠 setCount(count + 1) uses the value from the current render, which is why calling it multiple times doesn't keep increasing the count.
🔄 Functional updates receive the latest available state through prev.
📦 React processes state updates through an internal update queue before rendering.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Before today's class, I thought every call to setState() immediately changed the state and re-rendered the component.

Now I know that's not how React works.

React first collects state updates, batches them together, and then processes them efficiently.

The biggest surprise for me wasn't batching itself.

It was realizing why the functional update form exists.

I used to think prev was just another parameter.

Now I understand it's React's way of giving each update the latest available state while processing the update queue.

That small detail completely changed how I think about multiple state updates.

Tomorrow's topic is State Lifting, and after today's lesson, I'm curious to see how different components can share the same state.

See you on Day 6! 🚀

💬 What confused you the most when you first learned React's batching behavior? Were you surprised that calling setState(count + 1) three times only updates the counter once, or did functional updates with prev take longer to click?

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 4 of Learning React: What Actually Makes React... React? (Hooks, useState, and State Explained)

Bismay.exe — Thu, 25 Jun 2026 18:03:57 +0000

📌 Missed Day 3? I covered what actually happens after running npm run dev, how bundlers work, JSX, components, and props. You can read it here and then come back. I'll wait. ☕️

Bismay.exe

Jun 24

🚀 Day 3 of Learning React: Understanding JSX, Components, Props, Bundlers, and What Happens After `npm run dev`

#react #javascript #webdev #beginners

6 min read

If someone asked me yesterday what makes React different from plain JavaScript, I probably would've talked about JSX or components.

Today, I'd give a completely different answer.

Hooks.

Until today, I thought Hooks were just another React feature.

Turns out, they're much more than that.

Hooks are special functions that let React components remember information between renders. Without them, every time a component ran, it would start from scratch with no memory of what happened before.

The simplest way I can describe them after today's class is this:

Hooks are what actually make React... react.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday we answered one question:

What actually happens after we run npm run dev?

Here's what I took away from Day 3:

⚙️ npm run dev starts a development server.
📦 A bundler processes and optimizes our files.
✨ JSX gets transformed into JavaScript.
🧩 Components help us build reusable UI.
📨 Props let components communicate.
🌳 React finally updates the DOM.

Today we're answering a different question:

How does React know when to update the UI? 🤔

That's where Hooks come in.

📦 Import & Export — Something I Thought I Already Knew

Example:

// Button.jsx

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

When you import it in another file, the name you give the import does not have to match the name defined in Button.jsx:

import MyButton from "./Button";

Why the name doesn't matter

When you use a default export, you are essentially telling the module: "Give me whatever is exported as default, and I will call it 'MyButton' in this file."

Behind the scenes, the module system only cares about the file path ("./Button"). Since there can only be one default export per file, the environment knows exactly which piece of code to grab, regardless of what you name it locally.

This is different from named exports, where you must use the exact name defined in the curly braces—for example: import { Button } from "./Button";.

export function Button() {}
export function Card() {}

import { Button, Card } from "./components";

Why braces are required?

Because internally, named exports are stored by their exported names, while the default export is stored under a special "default" binding.

🎣 My First Hook — `useState()`

Today's biggest highlight was finally learning my first React Hook.

That hook is:

const [state, setState] = useState(initialValue);

At first glance, this syntax looked... strange. 😅

Why is it returning an array?

Why are there two variables?

And what exactly are state and setState?

Once I understood what each one does, everything started making sense.

🧩 `useState()` Returns Two Things

One thing I learned today is that useState() doesn't return a single value.

It returns an array with exactly two elements:

const [state, setState] = useState(initialValue);

Conceptually, React is giving us something like this:

[
  currentState,
  updateStateFunction
]

Using array destructuring, we store those values into two variables:

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

Here:

count stores the current state value.
setCount is the function React gives us to update that value.

I finally understood why there are two variables instead of one.

One is the data.

The other is the way to change the data.

🟢 What Exactly Is `state`?

The first value returned by useState() is the state itself.

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

Here:

count

is simply the current value React is remembering.

If the value changes from:

then count will become 1 on the next render.

I like thinking of state as React's memory.

Unlike normal variables, state survives between renders.

That's what makes it special.

🔄 What Does `setState` Actually Do?

This was probably the biggest "aha!" moment for me today.

I originally thought setState only changed a variable.

Turns out, it does two very important things.

setCount(1);

1️⃣ It Updates the State

First, React stores the new value internally.

For example:

count = 0

↓

setCount(1)

↓

count = 1

Pretty straightforward.

But that's only half the story.

2️⃣ It Triggers a Re-render

This is the part I didn't know before today.

Calling setState() doesn't just update the value.

It also tells React:

"Something changed. Run this component again."

That means React calls the component function one more time with the updated state and generates a new UI.

That's why the screen updates automatically.

Without setState(), React wouldn't know anything changed.

💡 My Mental Model

Here's how I visualize it now:

User Clicks Button
        ↓
setState(newValue)
        ↓
React Updates State
        ↓
React Re-renders Component
        ↓
New UI is Generated
        ↓
Browser Shows Updated UI ✨

That simple flow made useState() click for me.

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

  return (
    <>
      <h2>{count}</h2>

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

🔵 `setCount`

This does two important things:

Updates the state.
Tells React to render the component again.

That second point surprised me the most.

I used to think it only changed a variable.

It actually tells React:

"Hey... something changed. Build the UI again."

🤯 The Boolean Experiment That Confused Me

This will be the most interesting section because it's my own discovery.

const [flag, setFlag] = useState(true);

Then tell the story.

I expected every button click to re-render.

But that's not what happened.

Then explain

setFlag(true);

No update.

Because...

React already has true.

Nothing changed.

So React skips everything.

Then

setFlag(false);

First click

true → false

React updates.

Second click

false → false

Nothing changed.

React ignores it.

That was a really cool moment because it showed me React isn't blindly rendering every time.

It first checks whether the new state is actually different.

📜 A Rule I Learned Today

setState(newValue)

↓

Is newValue different?

↓

YES ✅
Update state
Render component

NO ❌
Skip update
Skip render

💡 My Biggest Takeaways Today

📦 I finally understand the difference between default and named exports.
🎣 Hooks are what give React components memory.
⚡ useState() returns the current state and a setter function.
🔄 Calling the setter tells React to render again—but only if the value actually changes.
🧠 React avoids unnecessary renders by comparing the old and new state.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Today's class answered a question I didn't even know I had.

I always thought React automatically "noticed" when variables changed.

Now I know that's not true.

React only reacts to state, and the bridge between my code and React is Hooks.

Learning useState made me realize that React isn't watching every variable in my application. It's only watching the state that I choose to manage through Hooks.

That small detail completely changed how I think about React.

Tomorrow's topic is Batching, and after today's lesson, I'm really curious to see how React groups multiple state updates together to make applications even more efficient.

See you on Day 5! 🚀

💬 When you first learned useState, what surprised you the most? Was it that the setter function triggers a re-render, or that React completely skips updates when the value hasn't changed?

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 3 of Learning React: Understanding JSX, Components, Props, Bundlers, and What Happens After `npm run dev`

Bismay.exe — Wed, 24 Jun 2026 22:11:34 +0000

📌 Missed Day 2? I covered how React updates the UI internally—Reconciliation, the Diffing Algorithm, Render Phase, Commit Phase, Browser Paint, and React Fiber. You can read it here and then come back. I'll wait. ☕️

Bismay.exe

Jun 23

🚀 Day 2 of Learning React: Reconciliation, Diffing Algorithm, Render Phase, Commit Phase & React Fiber

#react #javascript #webdev #beginners

11 min read

Yesterday I finally understood how React updates the UI.

I thought that was enough.

But today's class made me realize I was still treating React like magic.

Every time I typed:

npm run dev

my project just started.

I never stopped to ask what actually happens after pressing Enter. 🤔

Today's session answered that question—and along the way, I also learned why JSX exists, how components communicate through props, and what a bundler is actually doing behind the scenes.

Let's dive in. 🚀

🧠 Quick Recap

Yesterday, we answered one big question:

How does React update the UI?

Here's what I took away from Day 2:

🔄 Reconciliation is React's strategy for comparing two Virtual DOM trees.
⚡ The Diffing Algorithm efficiently finds the minimum set of changes.
🎬 The Render Phase is where React plans the updates—it doesn't touch the DOM yet.
✅ The Commit Phase is where those changes are applied to the Real DOM.
🎨 Finally, the browser handles Layout, Paint, and Composite to display everything on the screen.
🧵 React Fiber makes the Render Phase interruptible, allowing React to keep applications responsive.

Yesterday was all about how React updates the UI.

Today, we're answering a different question:

What actually happens from the moment we type npm run dev until our React app appears in the browser? 🤔

And along the way, I finally understood JSX, bundlers, components, and props.

That's where today's journey begins. 🔽

💡 The Biggest Lesson of Today

One realization stood out above everything else:

React isn't magic. It's just a collection of tools working together in a smart way.

When I first saw React code, I imagined there was some hidden engine doing impossible things.

But after learning about bundlers, JSX, transpilation, and rendering, I realized that every step has a purpose.

Once you understand those steps, React becomes much easier to learn.

What Really Happens When You Run `npm run dev`?

Before today, I thought this command simply "started React."

npm run dev

Turns out, a lot happens behind the scenes.

Here's the simplified flow that finally made sense to me:

npm run dev
        │
        ▼
 Development Server Starts
        │
        ▼
 Bundler Processes Files
        │
        ▼
 JSX is Transpiled
        │
        ▼
 JavaScript is Bundled
        │
        ▼
 Browser Executes the Bundle
        │
        ▼
 React Creates/Updates the DOM

Seeing this pipeline helped me understand that React isn't directly executed by the browser.

The browser only understands JavaScript, HTML, and CSS.

Everything else has to be converted first.

⚙️ What Really Happens When I Run npm run dev?

When I type:

npm run dev

I'm not actually starting React itself.

Instead, I'm starting a development server, usually powered by tools like Vite.

This server:

Watches my files
Rebuilds the project when I save
Refreshes the browser automatically
Makes development much faster

This is why changes appear almost instantly without manually refreshing the page.

📦 Bundlers — The Part I Never Thought About

This was one of my favorite topics today.

A bundler collects all the files in a project and combines them into something the browser can understand efficiently.

Imagine a React project with:

App.jsx
Navbar.jsx
Footer.jsx
Button.jsx
styles.css
utils.js

Instead of sending dozens of separate files to the browser, the bundler organizes and prepares them into optimized bundles.

Popular bundlers include:

Vite (uses esbuild during development and Rollup for production)
Webpack
Parcel
Rollup

Without bundlers, managing large applications would be much more difficult.

🤯 JSX Isn't HTML... and It Isn't JavaScript Either

This surprised me the most.

I used to think JSX was just JavaScript.

It's not.

Consider this code:

function App() {
  return <h1>Hello React!</h1>;
}

Browsers don't understand:

<h1>Hello React!</h1>

Something has to convert it first.

That's where Babel (or another JSX transformer) comes in.

It transforms JSX into regular JavaScript.

Conceptually, it becomes something like:

function App() {
  return React.createElement("h1", null, "Hello React!");
}

The browser can execute the transformed JavaScript, not the original JSX.

Understanding this made JSX feel much less "magical."

✨ JSX Makes UI Easier to Read

Even though JSX is transformed behind the scenes, it makes code much more readable.

Instead of writing lots of createElement() calls, we can write something that looks like HTML.

Example:

function Welcome() {
  return (
    <div>
      <h2>Welcome 👋</h2>
      <p>I'm learning React!</p>
    </div>
  );
}

It's cleaner, easier to understand, and much more enjoyable to work with.

🧩 Components — Finally, They Clicked

Another concept that clicked today was components.

Instead of creating one giant HTML page, React encourages breaking the UI into small reusable pieces.

Example:

function Header() {
  return <h1>My Blog</h1>;
}

function Footer() {
  return <footer>Made with ❤️</footer>;
}

function App() {
  return (
    <>
      <Header />
      <Footer />
    </>
  );
}

This approach makes applications:

Easier to read
Easier to maintain
Easier to reuse
Easier to test

I can already see why React applications stay organized even as they grow.

📨 Props — How Components Talk to Each Other

Components become much more powerful when they receive data.

That's where props come in.

Here's a simple example:

function Greeting(props) {
  return <h2>Hello, {props.name} 👋</h2>;
}

function App() {
  return (
    <>
      <Greeting name="Alice" />
      <Greeting name="Bob" />
      <Greeting name="Charlie" />
    </>
  );
}

Instead of creating three different greeting components, we create one reusable component and pass different values through props.

This was my first glimpse into how React promotes reusable code.

🧠 My Mental Model of React So Far

After today's learning, here's how I now think about React:

Component
      │
      ▼
Returns JSX
      │
      ▼
JSX is Transformed
      │
      ▼
JavaScript Executes
      │
      ▼
React Creates UI
      │
      ▼
Browser Displays It

Breaking the process into steps makes it far less intimidating.

🌳 The Final Step — React Still Ends Up Updating the DOM

One question I had was:

"If something changes, does React rebuild the whole page?"

The answer is no.

React figures out what actually changed and updates only those parts of the page.

For example, if only a counter value changes:

Counter: 5

React doesn't recreate the entire application.

It updates only the specific element that changed, making applications faster and more efficient.

This efficient update strategy is one reason React feels so responsive.

💡 My Biggest Takeaways

Today's session taught me that learning React isn't just about memorizing syntax.

It's about understanding the journey from writing code to seeing something on the screen.

Here are the ideas that stuck with me the most:

⚙️ npm run dev does much more than simply "run React."
📦 Bundlers organize and optimize our application before it reaches the browser.
✨ JSX isn't valid JavaScript—it gets transformed before execution.
🧩 Components make building UIs modular and reusable.
📨 Props allow components to communicate by passing data.
🌳 Understanding what happens behind the scenes makes React feel far less magical.

These concepts have given me a much stronger foundation for the topics I'll learn next.

🚀 What's Next?

I'm excited to continue exploring React.

The next concepts on my list include:

State
Event handling
Hooks like useState
Rendering lists
Conditional rendering
Building small projects

I know there will be challenges ahead, but understanding the fundamentals has made me much more confident.

🙌 Final Thoughts

Day 3 wasn't about building flashy applications—it was about building understanding.

Before today, commands like npm run dev and concepts like JSX felt like magic. Now, I can see the moving parts behind the scenes. Knowing that a development server starts, a bundler prepares my files, JSX gets transformed into JavaScript, and React updates the DOM step by step has made the framework feel much more approachable.

I've realized that becoming a better developer isn't just about making things work. It's about understanding why they work. That mindset is something I want to carry throughout my entire learning journey.

If you're just starting React too, don't rush through the basics. The deeper your foundation, the easier everything else becomes.

Thanks for reading! If you're on your own React journey, I'd love to hear what clicked for you recently. Let's keep learning together, one component at a time. 🚀💙

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

💬 When you first started React, which concept confused you the most—JSX, components, props, or understanding what npm run dev actually does?

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 2 of Learning React: Reconciliation, Diffing Algorithm, Render Phase, Commit Phase & React Fiber

Bismay.exe — Tue, 23 Jun 2026 19:03:57 +0000

📌 Missed Day 1? I covered why React exists, the Real DOM, Virtual DOM, and React Elements. You can read it here and then come back. I'll wait. ☕

Bismay.exe

Jun 22

🚀 Day 1 of Learning React: Why React Exists, the Real DOM, Virtual DOM & React Elements

#react #javascript #webdev #beginners

4 min read

Today was genuinely one of those sessions where you go in confused and come out feeling like you unlocked a new level.

Yesterday I learned what React does—it keeps a Virtual DOM in memory and updates only the parts of the Real DOM that actually changed.

Cool. Makes sense.

But one question kept bugging me all night:

How does React actually know what changed? 🤔

Today's class answered that question. And honestly? It completely changed how I think about React.

Let's get into it. 🚀

🧠 Quick Recap

Yesterday we answered one question:

Why was React created?

Here's what I took away from Day 1:

🔧 Manually updating the DOM in large apps becomes unmanageable.
💡 React introduced UI = Function(State)—we describe what we want, React handles the updates.
📦 A React Element is just a plain JavaScript object that describes UI. It's not a real DOM node.
🌳 The Virtual DOM is a lightweight copy of the UI that lives entirely in JavaScript memory.
⚡ React compares changes in the Virtual DOM and updates only the necessary parts of the Real DOM.

Today we're answering a completely different question:

How does React actually update the UI?

That's where today's journey begins. 🔽

🔄 Reconciliation — How React Knows What Changed

This is the concept that finally tied everything together for me.

I kept thinking, "Okay, React compares two trees. But... how? And what does that even look like?"

Reconciliation is React's process for figuring out what changed between two renders.

Here's how I think about it. 🖊️

Imagine you're editing an essay. You've got the original version and a revised version side by side. Instead of rewriting the entire essay, you scan through both versions and find only the sentences that actually changed. Then you update just those.

That's essentially what React does—except it's comparing two Virtual DOM trees.

When something changes in your app (say, a button click updates some text), React doesn't throw away the entire UI and rebuild it from scratch. Instead, it:

Creates a new Virtual DOM tree based on the updated state.
Compares it with the previous Virtual DOM tree.
Figures out the minimum set of changes needed.
Applies only those changes to the Real DOM.

Here's a small example. Let's say our component renders this:

// Before state change
React.createElement("h1", {}, "Hello");

And after a state update, it renders this:

// After state change
React.createElement("h1", {}, "Hello React");

React compares these two trees and realizes: "The <h1> element is the same type, but the text inside changed from Hello to Hello React. I only need to update the text content."

That comparison process? That's reconciliation. 🔄

But here's the thing—reconciliation is just the strategy. The actual comparison happens through something more specific.

⚡ Diffing Algorithm — The Engine Behind Reconciliation

So how does React actually compare two Virtual DOM trees?

That's where the diffing algorithm comes in.

If reconciliation is the what ("figure out what changed"), diffing is the how ("here's how I compare the two trees").

Now, this part surprised me. 🤯

Comparing two trees might sound simple, but it's actually a hard computer science problem. A generic algorithm to compare two trees has a time complexity of O(n³)—which means for a tree with 1,000 elements, it could take a billion operations.

That's way too slow for a UI library.

I paused the video here. I was like, "Wait... React does this on every single update? How is it fast?"

That's when I learned about React's clever trade-off. Instead of finding the perfect difference between two trees, the React team made a few practical assumptions that are almost always true in real-world applications. That keeps comparisons incredibly fast.

They built their diffing algorithm on two key assumptions:

1. Different types? Different trees. 🔀

If React sees that a <div> changed to a <section>, it doesn't bother comparing their children. It destroys the old tree and builds a new one from scratch.

// Before
React.createElement("div", {}, 
  React.createElement("p", {}, "Hello")
);

// After
React.createElement("section", {}, 
  React.createElement("p", {}, "Hello")
);

Even though the <p> inside is identical, React tears down the entire <div> subtree and creates a new <section> subtree. Different type = different tree. No questions asked.

2. Same type? Compare what changed. 🔎

If the element type stays the same, React keeps the DOM node and only updates the attributes that actually changed.

// Before
React.createElement("h1", { className: "title" }, "Hello");

// After
React.createElement("h1", { className: "title active" }, "Hello");

Here, the <h1> is still an <h1>. React keeps the same DOM node and only updates the className. Much more efficient. ⚡

3. Keys help React identify list items 🔑

When rendering lists, React uses keys to track which items changed, moved, or were removed.

items.map(item => 
  React.createElement("li", { key: item.id }, item.name)
);

I'll cover keys in more depth later in this series, but for now, just know they exist to help the diffing algorithm identify list items efficiently.

💡 The biggest misconception I had

I honestly thought React compared the Virtual DOM against the Real DOM.

That's wrong. ❌

React compares the new Virtual DOM against the previous Virtual DOM. The Real DOM is never part of the comparison. It only gets involved later, when React applies the changes.

That distinction seems small, but once I understood it, the entire mental model just... clicked. 🧩

Thanks to these assumptions, React's diffing algorithm runs in O(n) time—one pass through the tree. That's what makes it fast enough for real-time UI updates.

So now React knows exactly what changed. But it hasn't touched the Real DOM yet.

What happens next? 🤔

🎬 Render Phase — Planning, Not Painting

This is where things got really interesting for me.

When I first heard "Render Phase," I assumed it meant React was drawing things on the screen.

Nope. Not even close. 😅

The Render Phase is a planning phase. React calls your components, builds the new Virtual DOM tree, and runs the diffing algorithm to figure out what needs to change. But it does not touch the Real DOM during this phase.

Think of it like an architect creating a blueprint. 📐 The architect plans every room, every wall, every window—but no construction has started yet. The Render Phase is React creating that blueprint.

Here's what happens step by step:

Something triggers a re-render (state change, prop change, etc.)
React calls your component function again.
Your component returns new React Elements.
React builds a new Virtual DOM tree from those elements.
React diffs the new tree against the previous tree.
React produces a list of changes that need to be applied.

Let me show a simple example:

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

  return React.createElement(
    "div",
    {},
    React.createElement("p", {}, "Count: " + count),
    React.createElement(
      "button",
      { onClick: () => setCount(count + 1) },
      "Increment"
    )
  );
}

When you click "Increment," React enters the Render Phase:

It calls Counter() again with the new state (count = 1).
It gets back a new tree where the <p> now says "Count: 1" instead of "Count: 0".
It diffs this against the old tree.
It notes: "Only the text inside <p> changed."

At this point, the screen still shows "Count: 0". Nothing visible has changed yet. 👀

I tried wrapping my head around this by opening VS Code and console-logging inside a component. The function runs again on every re-render—but the screen doesn't update until later. That's the Render Phase in action.

That leads us to the next phase.

✅ Commit Phase — Where the Real DOM Actually Changes

The Commit Phase is where React actually applies the changes to the Real DOM.

If the Render Phase is the architect drawing blueprints, the Commit Phase is the construction crew showing up and doing the work. 🏗️

During this phase, React takes the list of changes it prepared during the Render Phase and makes the actual DOM updates:

Adding new DOM nodes
Removing old DOM nodes
Updating attributes, text content, or event listeners

For our counter example, the Commit Phase would:

Find the <p> DOM node.
Update its text content from "Count: 0" to "Count: 1".

That's it. One targeted update instead of rebuilding the entire page. ✨

Here's the key difference between the two phases:

	🎬 Render Phase	✅ Commit Phase
What it does	Plans changes	Applies changes
Touches the DOM?	❌ No	✅ Yes
Can be paused?	✅ Yes	❌ No
Output	List of changes	Updated DOM

Notice that the Render Phase can be paused—I'll explain why that matters when we get to Fiber. 🧵

The Commit Phase is synchronous. Once React starts applying changes to the DOM, it finishes all of them in one go without interruption.

But even after the Commit Phase, we're not done. The DOM has been updated, but you still can't see anything different on screen. Something else needs to happen.

🎨 Browser Paint — From DOM to Pixels

Before today, I thought React drew everything on the screen.

Turns out... React never paints a single pixel.

The browser does.

React's job ends after updating the DOM. That was a surprisingly big realization for me.

After React updates the DOM in the Commit Phase, the browser takes over. Now it needs to turn those DOM changes into actual pixels on your screen.

This happens in three steps:

📐 Layout — The browser calculates the size and position of every element. If you changed the text inside a <p>, the browser recalculates how much space that paragraph needs, and whether anything around it shifts.

🎨 Paint — The browser fills in the pixels. It draws the text, backgrounds, borders, shadows—everything visual.

🧩 Composite — The browser combines different layers (if any) into the final image you see on screen. Think of it like stacking transparent sheets on top of each other.

The important thing I realized today is:

React updates the DOM. The browser paints the pixels. They're two separate steps. 💡

React can't directly draw on the screen. It can only modify the DOM. The browser's rendering engine handles the rest.

That's why React focuses so hard on making minimal DOM changes—because every change triggers the browser's layout, paint, and composite pipeline. Fewer changes = less work for the browser = smoother experience for the user. 🚀

🔁 The Complete React Update Cycle

Now let's put everything together.

This was the moment everything connected for me.

Until now, I had been learning these concepts individually. Reconciliation. Diffing. Render Phase. Commit Phase. Browser Paint. They all made sense on their own, but I couldn't see how they fit together.

Then I drew this out on paper during the class, and suddenly the entire system clicked. ✨

When something changes in a React app, here's the full journey:

  State Change
       ↓
  Render Phase  (React calls components, builds new Virtual DOM)
       ↓
  Reconciliation  (Compare new vs old Virtual DOM)
       ↓
  Diffing  (Find minimum changes)
       ↓
  Commit Phase  (Apply changes to Real DOM)
       ↓
  Browser Paint  (Layout → Paint → Composite)
       ↓
  Pixels on Screen ✨

Every single update—whether it's a button click, a form input, or data arriving from an API—follows this exact same cycle.

Seeing them as one continuous pipeline completely changed my mental model of React. It stopped feeling like magic and started making sense as a system.

But there's one more thing I learned today that tied everything together even further. 🧵

🧵 React Fiber — Why React Never Freezes Anymore

When I first heard "Fiber," I honestly thought, "Great... another React buzzword."

Turns out it's one of the most important architectural changes React has ever made. This section completely changed how I think about React's internals.

Before React 16 (released in 2017), React's rendering was synchronous. When React started rendering, it went through the entire component tree in one shot. It couldn't stop. It couldn't pause. It couldn't prioritize.

Imagine you're watching a movie and you can't pause it. 🎬 Not even to answer the door. Not even if your house is on fire. You have to watch the entire thing from start to finish before you can do anything else.

That was React before Fiber.

For small apps, this was fine. But for large applications with complex component trees, a single render could take a while. During that time, the browser was completely blocked—no scrolling, no typing, no animations. Everything froze until React finished. 🥶

I remember thinking, "Wait, React was like that? How did anyone build large apps with it?"

That's the problem React Fiber was built to solve.

Fiber is a complete rewrite of React's core algorithm, introduced in React 16. It didn't change what React does—it changed how React does it.

With Fiber, React can:

⏸️ Pause rendering work and come back to it later.
🎯 Prioritize different types of updates. A user typing in a text field is more urgent than a background data fetch.
▶️ Resume work that was paused without starting over.
🗑️ Abort work that's no longer needed.

Think of it like switching from watching a DVD (can't pause) to streaming on Netflix (pause, rewind, skip, switch to a different show, come back later). 📺

The key insight is that Fiber makes React's Render Phase interruptible. Remember how I said the Render Phase can be paused? That's because of Fiber. 💡

The Commit Phase is still synchronous—once React starts applying changes to the DOM, it finishes without interruption. But the planning phase (Render Phase) can now be broken into chunks and spread across multiple frames, keeping the browser responsive.

This is why modern React apps feel snappy even when dealing with complex updates. Fiber ensures that React never hogs the main thread for too long. ⚡

⚖️ Virtual DOM vs Fiber — They're Not the Same Thing

This was confusing for me at first. I kept thinking: "Wait, did Fiber replace the Virtual DOM? Are they the same thing?"

Nope. They're different concepts that work together. 🤝

	🌳 Virtual DOM	🧵 React Fiber
What it is	A JavaScript representation of the UI	React's reconciliation engine
Purpose	Describes what the UI should look like	Manages how and when updates happen
Introduced	React's original design	React 16 (2017)
Handles	UI structure (the "what")	Scheduling & prioritization (the "how")

Here's how they work together:

The Virtual DOM is still the concept—React keeps a lightweight JavaScript copy of your UI in memory and compares it to find changes. 🌳

Fiber is the engine that performs that comparison. It's the system that walks through the Virtual DOM tree, does the diffing, and decides when and how to apply updates to the Real DOM. 🧵

So the Virtual DOM is the data structure and Fiber is the algorithm that operates on it.

They're not competing concepts. Fiber is the reason the Virtual DOM approach works efficiently at scale. ⚖️

💡 My Biggest Takeaways Today

🔄 Reconciliation is React's strategy—compare two Virtual DOM trees and find the minimum changes.
⚡ The diffing algorithm runs in O(n) time because of two smart assumptions about how UIs typically change.
🎬 The Render Phase is just planning. No DOM changes happen here.
✅ The Commit Phase is where React actually updates the Real DOM.
🧵 Fiber makes the Render Phase interruptible, so React never freezes the browser.

📚 Learning Source

I'm currently learning React through the React Cohort 3.0 by Devendra Dhote at Sheriyans Coding School.

This article isn't a copy of the course.

It's my personal understanding after today's class, rewritten entirely in my own words.

Writing these articles helps me reinforce what I've learned, and hopefully helps other beginners who are on the same journey. 🤝

If I've misunderstood something, I'd genuinely appreciate your corrections in the comments. 😊

🙌 Final Thoughts

Day 2 gave me a much deeper appreciation for what's happening behind the scenes in React.

Yesterday I understood the what. Today I understood the how. And honestly, that shift in understanding makes me way more excited to keep going. 🔥

Tomorrow I'm moving to Day 3, where I'll finally start getting hands-on:

✏️ JSX
⚡ Vite
📁 Project Structure
🧩 Fragments
🔒 Strict Mode

I've been dying to write actual React code instead of just learning theory. Day 3 is where it gets real. 💻

See you there! 🚀

💬 When you first learned about React's update cycle, what was the hardest part to wrap your head around—Reconciliation, Fiber, or something else entirely?

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

🚀 Day 1 of Learning React: Why React Exists, the Real DOM, Virtual DOM & React Elements

Bismay.exe — Mon, 22 Jun 2026 19:28:37 +0000

Today marks Day 1 of my React journey.

I've decided to document everything I learn—not because I'm an expert, but because I believe sharing the learning process can help other beginners while also helping me understand concepts better.

Today's goal wasn't to build an app.

It was to answer one simple question:

Why was React created in the first place? 🤔

Let's dive in.

💡 Why Was React Created?

Before React existed, developers built interactive websites by directly manipulating the browser's DOM using JavaScript or jQuery.

For example:

const heading = document.querySelector("h1");
heading.textContent = "Hello World";

This works perfectly for small applications.

But imagine building something like Facebook.

📰 News Feed
💬 Messages
❤️ Likes
🔔 Notifications
💭 Comments
👥 Friends List

Each part of the page can update independently.

As applications grow larger, manually deciding:

Which DOM node should update
When it should update
What else depends on it

becomes increasingly difficult.

That's where React changed everything.

Instead of manually updating the UI, React introduced a much simpler idea:

UI = Function(State)

You describe what the UI should look like, and React figures out how to efficiently update the browser.

I think that's a really elegant way to think about building user interfaces.

🌳 What Is the Real DOM?

When the browser reads your HTML, it creates a tree-like structure called the Document Object Model (DOM).

For example:

<body>
  <main>
    <h1>Hello</h1>
  </main>
</body>

The browser sees something like this:

Document
└── body
    └── main
        └── h1
            └── Hello

This is called the Real DOM because it's managed directly by the browser.

Whenever something changes, the browser may need to:

📐 Recalculate layouts
🎨 Repaint elements
🖥️ Update the screen

These operations become expensive in large applications.

⚛️ What Is a React Element?

One thing that surprised me today was learning that React doesn't immediately create HTML elements.

When we write:

const element = React.createElement(
  "h1",
  {},
  "Hello React"
);

React actually creates a plain JavaScript object like this:

{
  type: "h1",
  props: {
    children: "Hello React"
  }
}

This object is called a React Element.

A React Element is simply a description of what the UI should look like.

It isn't a real DOM node.

That small distinction helped me understand React much better.

🧠 What Is the Virtual DOM?

The Virtual DOM is another concept I finally understood today.

It's basically a JavaScript representation of the UI that lives entirely in memory.

For example:

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

React internally represents it as something similar to:

{
  type: "div",
  children: [
    {
      type: "h1",
      children: ["Hello"]
    },
    {
      type: "p",
      children: ["World"]
    }
  ]
}

The important thing I learned is:

The Virtual DOM doesn't exist inside the browser. It only exists in JavaScript memory.

React compares changes in this virtual representation and updates only the parts of the Real DOM that actually changed.

That's one of the reasons React applications stay efficient.

🎯 What Happens During the First Render?

When React renders an application for the first time:

const root = ReactDOM.createRoot(
  document.querySelector("main")
);

root.render(
  React.createElement(
    "h1",
    {},
    "Hello React"
  )
);

The process looks something like this:

React Element
      ↓
Virtual DOM
      ↓
Real DOM
      ↓
Browser Screen

React creates the necessary DOM nodes and finally displays them in the browser.

✨ My Biggest Takeaway Today

Today's lesson completely changed how I thought about React.

Before today I assumed React was simply another JavaScript library.

Now I realize it's actually a different way of thinking about building user interfaces.

Instead of telling the browser how to update every single element...

React lets us describe what we want the UI to look like.

That shift in mindset is what makes React so powerful.

📚 What I'm Learning Next

Today's lesson covered:

✅ Why React?
✅ Problems React Solves
✅ History of React
✅ SPA vs MPA
✅ React Elements
✅ ReactDOM
✅ Virtual DOM

Tomorrow I'll continue with:

🔄 Reconciliation
⚡ Diffing Algorithm
🎨 Render Phase
✅ Commit Phase
🧵 React Fiber Architecture

I'll continue documenting everything I learn as I go. 🚀

📖 Learning Source

I'm currently learning React through the React course by Devendra Dhote at Sheriyans Coding School. These posts are my own notes and understanding of each day's lessons, written in my own words as I continue learning.

If I misunderstand any concept, feel free to correct me in the comments—I'm here to learn. 😊

🙌 Final Thoughts

This is only Day 1, but I'm already enjoying the journey.

I'm sure there will be confusing concepts, bugs, and plenty of mistakes along the way—but that's part of learning.

If you're also starting React from scratch, let's learn together.

See you in Day 2! 🚀

💬 What was the hardest React concept for you when you started?

I'd love to hear your experience in the comments. 😊

If you're following along with this series, you can also find me on GitHub, where I'll be sharing my projects and documenting my progress.

Bismay-exe (Bismay.exe) · GitHub

👋 Hi, I’m Bismay 💻 Developer passionate about building clean, minimal, and elegant apps 🚀 Focused on coding 🌱 Always learning, creating & new ideas - Bismay-exe

github.com

Thanks for reading! 🚀

DEV Community: Bismay.exe

🚀 Day 12 of Learning React: Understanding useEffect, Cleanup Functions, and API Calls

🧠 Quick Recap

🤔 The Mistake I Didn't Know I Was Making

🔄 The Infinite Loop Problem

🎣 Enter useEffect()

⚡ My First useEffect

🌐 My First API Request with Axios

📌 The Dependency Array Finally Made Sense

1️⃣ No Dependency Array

2️⃣ Empty Dependency Array

3️⃣ Dependency Array with a Value

🤯 The Experiment That Finally Made Cleanup Click

⏱️ The Interval That Wouldn't Stop

💡 React Removes Components... Not JavaScript

🧹 The Cleanup Function

🔄 Mount, Re-render, and Unmount

🧠 My Mental Model

💡 My Biggest Takeaways Today

📚 Learning Source

🙌 Final Thoughts

🚀 Day 11 of Learning React: Finally Understanding React Context API (And Why Prop Drilling Gets Annoying)

🧠 Quick Recap

🤔 The Problem That Lifting State Couldn't Solve

🚀 Enter Context API

🏗️ Creating a Context

📦 The Provider

🎣 Accessing Shared Data With useContext()

⚙️ Putting Everything Together

🛒 My Shopping Cart Project

🔄 How Data Flows

🤔 Is Context API State Management?

🤯 The Moment It Finally Clicked

💡 My Biggest Takeaways

📚 Learning Source

🙌 Final Thoughts

🚀 Day 10 of Learning React: My React Form Finally Became a Real CRUD App (Local Storage, Create, Update & Delete)

🧠 Quick Recap

💾 The Problem With React State

📦 Enter Local Storage

🧩 Breaking It Down

💾 Saving Users

🆔 Every User Needs a Unique Identity

📦 Installing Nano ID

❌ Deleting Users

✏️ Reusing the Same Form for Updates

📋 Filling the Form Automatically

🔄 Updating Only One User

🧠 My Mental Model

💡 My Biggest Takeaways Today

📚 Learning Source

🙌 Final Thoughts

🚀 Day 9 of Learning React: Why Every Form Needs Validation (React Hook Form Made It Surprisingly Easy)

🧠 Quick Recap

🤔 A Form That Accepts Everything...

🚫 My First Validation Rule

📧 Making Sure Emails Actually Look Like Emails

📱 Validating a Phone Number

🖼️ Even the Image Field Needed Validation

🚨 The errors Object Did All the Heavy Lifting

📤 Validation Happens Before Submission

💡 My Mental Model

💡 My Biggest Takeaways Today

📚 Learning Source

🙌 Final Thoughts

🚀 Day 8 of Learning React: Why Doesn't React Use the DOM Directly? Understanding useRef() & React Hook Form

🧠 Quick Recap

🌳 React Doesn't Work Directly with the Browser

🎯 What Exactly Is the Real DOM?

🎭 React Doesn't Even Give Us Native Events

🎣 So... How Do We Reach the Real DOM?

📝 Building a Form with useRef()

🤔 But Something Started Feeling Repetitive...

🚀 Enter React Hook Form

✨ register() Felt Like Magic

📤 Submitting the Form Became Simpler Too

🔄 Comparing the Two Approaches

Using useRef()

Using React Hook Form

💡 My Mental Model

🎣 Enter `useEffect()`

⚡ My First `useEffect`

🎣 Accessing Shared Data With `useContext()`

🚨 The `errors` Object Did All the Heavy Lifting

📝 Building a Form with `useRef()`

✨ `register()` Felt Like Magic

Using `useRef()`

🎣 Looking at `useState()` From a Different Perspective

⚡ React Doesn't Render After Every `setState()`

🔄 The Mysterious `prev`

💡 Why Did It Become `undefined`?