Starting with TypeScript

#typescript #tutorial #beginners

It all started with a conversation between my friend Narendran and I. Then, it became a twitter thread🧵.

Atila 🧉

@atilafassina

If you have @typescript on your “Must check it out” list and aren’t sure when/how to start. I have a few tips, if you want.

Follow the 🧵

10:50 AM - 14 May 2020

Now, it’s time to put code out to back those points. If you’ve been interested in TypeScript but haven’t found the time to deep your toes into the water, or you simply didn’t figure it out how to start, or even so: it’s hard to convince your teammates of the tradeoffs. This post is for you!!

In 4 easy-to-follow tips, I’ll remove all blockers you may have for adopting TypeScript. I’ll help you get confident with it and take out the fear of getting started. Ready? Don’t blink or you might miss it!! 😎

1. TypeScript without TypeScript

The title sounds controversial, I wanted to hook you up (🎣). It’s actually quite straightforward and simple.

TypeScript is compiled with tsc (TypeScript Compiler), and the CLI accepts a few configurations. One of them enables tsc to compile also JavaScript, that’s extremely useful for mixed codebases (third party stuff, migration stuff, etc). But it has an additional benefit which I don’t see getting much attention.

When you allow your TypeScript Compiler to read/parse your JavaScript code, it also checks its types.

But, how? 🦆

The answer for that is Duck Typing, you can skip this section if you’re familiar with the term.

If it walks like duck, talks like a duck, quacks like a duck. Then it must be a duck!

TypeScript compiler is able to infer a great amount of types straight from your code, saving you the time to annotate them. Those are the types your JavaScript can be checked against. So, it’s not as complete as full-fledged TypeScript, but it gives you a good start to progressively adopt the language is your familiarity and comfort grow.

Adding the proper config

I believe it goes without saying that you still need to have typescript in your machine for this approach to work. Even if you’re not using the .ts(x) extensions, the compiler still needs to come from somewhere.

Create in the root of your project a tsconfig.json. The bare minimum config you need to have is:

{
  "compilerOptions": {
    "target": "es5",
    "lib": ["es2019", "dom"]
  }
}

Copy paste this and you’re good to go for some client-side code.

❗️Note:
I recommend using it with parcel, it’s a zero-config, very fast bundler. It takes a bunch of the annoying best practices automation from your hands and allow you to focus on what matters: your app. Perfect for small projects (and perhaps even some big ones).

2. `any` can be a friend

The first commandment of TypeScript is:

Thou shall not use of any

But in all honesty, I don’t really think this applies to beginners (or even in some advanced cases. Let’s save that for a future post, though).

Why is any so terrible?

any is a type value, as you may have assumed: it says that any type value can be assigned to that given key. So, whenever you use any, you’re buying your way out of TypeScript. No more warnings, everything goes. And that’s bad if you look at the specific unit your working on, but it’s even worse if you look at the broad perspective.

An application is as reliable as its least reliable piece. So, a single use of any can compromise type-safety for your entire app. Be aware of that.

So, why the heck should I use it?

For once: can compromise. For numerous possible reasons, sometimes we are confronted with types that are really (really!) hard to declare. These types will eat your time and motivation up if you’re just starting. No one enjoys having a broken build for hours when you know your code works. In these cases, slap an any there, get your task done and come back later with a fresh head.

In a nutshell: use any, but accepts it’s a technical debt for any (pun intended) TypeScript codebase, and be sure to proper evaluate the risk before shipping code to production like that.

3. Pick only the right battles

This section is actually a follow-up from the previous. But integration is a beast of its own (in my opinion) when it comes to TypeScript. Strong-typing code you have no control over is specially tough. Nowadays, many many libraries and frameworks are migrating (or already have) their core to TypeScript. Which is awesome, simply by adding TS to your project you get autocompletion and self-documenting as a big welcome gift.

shawn swyx wang

@swyx

⚛️📜 React ecosystem libraries that have rewritten their core to @TypeScript (not just offering TypeScript support):

✅Next.js
✅@ReactNative CLI
✅React Router
✅@expo
✅Redux
✅@Yarnpkg
✅@fbjest
✅@storybookjs
✅@apollographql
🔜@Gatsbyjs
❌@Reactjs

…act-typescript-cheatsheet.netlify.app/docs/migration…

11:01 AM - 14 May 2020

But in other cases, you may want to refrain from that and strong-type your own code first. Which also smoothly brings us to the last point.

4. Community has your back

As I mentioned above, many frameworks and libraries have migrated their code to TypeScript. What about the ones which didn’t?

No worries, you won’t need to single-handedly strong-type your dependencies in order to migrate fully into TypeScript. 😅

DefinitelyTyped is an open-source repository maintained by the community with virtually every type you may need for other open-sourced projects. You’re a few npm searches away from strong-typing your dependencies.

Seriously! Community 👏 has 👏 your 👏 back!!

5. Bonus

If you want another gentle nudge into getting started with TypeScript, Scope Leak has a playlist called Simplified TypeScript where I take more complex aspects of TypeScript and simplify them in byte-sized videos for you to hit the ground running!

Really, 5 minutes tops, give it a try!! 🔥