Zero → Hero: “Understanding TypeScript Types the Right Way”

So Recently, I got into a TS bug and I had to go through various stackoverflow, reddit posts and gpt stuff. I literally got 2-3 points which challenged my TS fundamentals so here is the complete blog on TS.

Types Are Sets, Not Labels: Look into the eyes of TypeScript👀

When I first started learning TypeScript, I treated types like sticky notes.
“Slap a label on a variable and you’re done.”

That worked… until it didn’t.
Suddenly I was facing any, unknown, never, and a dozen confusing red squiggles.
It felt like TypeScript was fighting me instead of helping me.

But then I had a mindset shift:

👉 Types aren’t labels. They’re sets of possible values.

Read it again:
👉 Types aren’t labels. They’re sets of possible values.

And once I saw it this way, everything clicked.

The Red Squiggle Problem

Let’s start with the three “troublemaker” keywords:

• any → The escape hatch.

  “I give up. Accept anything.”
  Great for quick prototyping. Terrible for production.

• unknown → The cautious friend.

  “I’ll accept this… but I won’t trust it until you check.”
  Safer than any, because it forces you to validate before using.

• never → The impossible.

  “This should literally never happen.”
  Used for cases like exhaustive switch checks, or impossible return values.

Understanding these alone reduced half my headaches.

Types as Sets (The Aha Moment)

This was the big unlock for me:

• type A = number | string
  👉 A is the set of all numbers + all strings.

• type B = X & Y
  👉 B is the set of values common to both X and Y.

Instead of seeing type as a label, I started thinking in Venn diagrams.
Unions = combine circles.
Intersections = overlap circles.

This made complex types so much less scary.

Interface vs Type (Stop the Debate)

At first, I thought there was a “winner” between interface and type.
Turns out, it’s not a fight at all:

• Interface → best for describing objects:

    interface User {
      id: number;
      name: string;
    }
  

• Type → more flexible:

    type ID = number | string;
  

Types can do unions and intersections. Interfaces can’t.
But interfaces can be extended and merged nicely.

Moral? Use whichever fits the job. They coexist peacefully.

---

Generics (Learning…)

Generics felt like rocket science at first.
All I knew was they show up as <T> everywhere.

Example:

const [curr, setCurr] = useState<string>("hello");

Here, string is the generic type we pass into useState.
It tells React exactly what type of state to expect.

Generics basically mean:

“Don’t hardcode the type. Let me decide later.”

I’m still exploring advanced use cases but even knowing this made React code way more predictable.

---

Conclusion

Once I flipped my thinking from:
❌ “Types are labels”
✅ “Types are sets of possible values”

TypeScript stopped feeling like a gatekeeper and started feeling like a safety net.

I’m not a TS guru yet (generics still scare me a little 👀), but now I see TypeScript as a teammate, not an enemy.

So if you’re struggling with TS:

• Stop fighting the squiggles.

• Start thinking in sets.

• And don’t be afraid to learn out loud.

Because honestly? Writing this blog probably taught me as much as the docs did.

Let’s connect if you loved my work.
Feel free to share in comments or mail at : guraaseessingh389@gmail.com

Linkedin | X | Github