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

📌 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. ☕️

---

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

Talk about:

• export default
• named export
• why only one default export
• why named exports need braces
• how ES Modules store exports internally

Example:

// Button.jsx

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

import MyButton from "./Button";

Then explain why the name doesn't matter.

---

Then

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

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

Explain why braces are required.

Mention that 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:

0

to

1

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.

---

Then your counter example naturally comes next:

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

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

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

---

⚡ useState() with examples

Show

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

Then explain both values separately.

🟢 count

The actual value React remembers.

🔵 setCount

This does two important things:

1. Updates the state.
2. 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."

---

🔄 My First Counter

Show your counter code.

Explain clicking.

Explain render.

Make it conversational.

---

🤯 The Boolean Experiment That Confused Me

This will be the most interesting section because it's your 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.

Thanks for reading! 🚀

Comments

[Nazar Boyko]

The boolean experiment is the best thing in here, the false to false click doing nothing is exactly the kind of detail that makes the whole idea land for people. One friendly heads up though, it looks like a few of your outline notes slipped into the published version, the "Talk about:" list and the "Show your counter code / make it conversational" lines read like instructions to yourself rather than the post. Quick fix, and the rest reads really well. Day 5 on batching is going to pair nicely with what you found here about skipped renders.