When I first heard developers talking about “state,” I nodded along like I understood. Spoiler: I didn’t. I thought it was just a fancy word for a variable. But once I actually used React’s useState hook, I realized oh, this is what makes React feel alive. Without state, your app is just a bunch of static divs dressed up in props. With state? It responds, reacts, breathes. But here’s the kicker—I also broke my app a dozen times by handling state the wrong way. So in this lesson, we're going deep into how state works in React, how to use useState like a pro (or at least not a total amateur), and what not to do unless you enjoy debugging at 1am.

State = Memory for Your UI (But Smarter)

Think of state as your app’s short-term memory. It’s how React remembers stuff between renders. Like: is the modal open? Which tab is active? What’s the user typing into that input?

When I realized state wasn’t just about data, but about interaction, things started clicking. State is how your UI reflects real-time decisions made by your user. No state? No interactivity. You’re just building a brochure.

Fun fact: the reason we call it “state” is because it's inspired by state machines. But don’t worry, you don’t need to dive into formal computer science just yet—unless you're really into that sort of thing.

useState: Your First Hook (And Your First Addiction)

This is the gateway drug. The hook that starts it all.

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

I remember typing this out and going, “Wait, what is this destructuring madness?” But soon, it made sense: count holds the value, setCount changes it, and useState(0) sets the starting point.

The magic? When you call setCount, React re-renders your component. Automatically. No document.getElementById. No jQuery spaghetti. It just works.

But useState can be addicting. I once had 12 separate state variables in a single component. That’s when I knew I needed an intervention (or at least some context or a reducer).

How I Broke My App with Bad State Management (Learn From My Pain)

Ah yes, the time I decided to store everything—literally everything—in state. API responses? In state. Scroll position? State. Refs? State. I ended up re-rendering on every scroll and crashed the whole UI.

Lesson learned: not everything belongs in state. Only store what affects rendering. If you just need to keep track of something outside the DOM, consider using a ref or a regular variable.

Another trap? Forgetting that setState is async. I tried to update state and immediately use the new value. Didn’t work. Spent 30 minutes wondering why. (Spoiler: because setState doesn't update immediately. It schedules the update for the next render.)

Up next, we’ll finally put this power to use with the useState: Let’s Make Stuff Actually Change lesson. We’re going to make a button that does something. It might not change the world, but it will change the UI.