TypeScript is wonderful. Been using it more and more and I love it. 🥰

There’s something magical about useful autocomplete suggestions, object blobs with property hints, and auto imports. That’s right, auto imports.

Press enter and VSCode adds import { FieldTypes } from './types' at the top.

And check this out: I got a form builder that takes JavaScript blobs as configuration. VSCode is smart enough to tell me when they’re wrong. 👌

This works:

Got a field with a name and a placeholder. Remove one and o-oh.

The error is cryptic type vomit. You get used to that. Means that one of your blobs doesn’t match any known field type.

But get this, add type: "email" and no need for a placeholder 😮

Whoa

whoa giphy

So what’s going on here? What’s TypeScript doing to support this? And why do we need a type property if we’re using a typed language?

Static analysis

Static analysis is where TypeScript shines. Its main design goal 👉 enable static analysis of JavaScript

Static program analysis is the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing.

Static analysis uses static types to understand your code. Editors use this understanding to help you write better code.

Everything from autocompletion, hints on object properties, and squiggly lines when you get something wrong. Some editors even integrate with documentation and give you help right in the editor.

TypeScript with VSCode brings all that to JavaScript.

You get a better coding experience most of the time. Sometimes you fight the type system, but it’s got your back … mostly. Great for large teams and large codebases.

Know your code has at least a remote chance of being correct without running every single line? Love it ❤️

Dynamic analysis

In contrast to static analysis you have dynamic analysis. That’s JavaScript’s normal mode.

Dynamic program analysis is the analysis of computer software that is performed by executing programs on a real or virtual processor. For dynamic program analysis to be effective, the target program must be executed with sufficient test inputs to produce interesting behavior.

To analyze a dynamic language, you gotta run it. That’s where test driven development comes in.

You don’t have a static type system saving your butt for some classes of errors. You gotta run the thing and see if it works. And you better make sure you run every line of code.

If you don’t, I promise your users will 😉

Duck typing

duck giphy

Duck typing is a strange beast most popular in the land of Lisp. It falls under dynamic typing, but statically typed duck languages exist also. Wikipedia classifies it as the 4th major category next to static, dynamic, and nominal typing.

If it walks like a duck and it quacks like a duck, then it must be a duck

The duck test 🦆

You’re duck typing every time you write code like if (object.property && object.property.value === 'something')

Verify the object is a duck, has a property, then use it like a duck.

Type guards in TypeScript

That brings us to TypeScript’s biggest flaw.

From TypeScript Design Goals

Impose no runtime overhead on emitted programs.
Emit clean, idiomatic, recognizable JavaScript code.

TypeScript is a static analysis tool only. No types at runtime. No type checking. No validations. Nothing.

Great for program size and understandability. Not great for useful type system.

Say you’ve got a form builder with two field types like I mentioned before.

Click through for source

A union FieldTypes type saves typing in a bunch of places.

Then we got a CoreFieldProps interface that defines properties all fields share. Every field needs a name, optionally an initialValue too.

Specific field types extend the core props and add their own. Most importantly they add the type field.

That’s how TypeScript knows what you mean when you write

Click through for source

Looks at the first two blobs, sees they match TextFieldProps. They’ve got a name and a placeholder, no type.

The last blob uses type: "email" so TypeScript knows it’s okay that there’s no placeholder. Optional in emails.

Duck typing at runtime

Static analysis worked great in the editor. What about when you want to render different fields based on their type?

You’re using a typed language right, how hard can it be.

Click through for source

Not so fast buster.

JavaScript has no idea about your types. typeof props evaluates to object. That’s not gonna match your artisanally crafted types you worked so hard to build 😉

Instead, you’ll have to use TypeScript Type Guards

Two types of guards prove useful in the wild:

  1. Duck typing
  2. Explicit type property

Duck typing

A duck typed type guard uses the duck test. If property exists on object, do the things.

Click through for source

An animal is a duck if it can both swim and fly. The in operator checks for the existence of a key (or property) on an object.

Explicit type property

The other approach works best in an object blob situation. You provide a type attribute, define types with hardcoded values, then make sure they’re defined.

Use those values at runtime to decide what to do

Click through for source

An object constructor can help too. new EmailFieldProps() and it sets this.type to email by default.

But I prefer blobs for passing data and use duck typing when dealing with actual objects. If it can do what I need, what do I care what type it is?

Quack

And that’s how you can use ducks to solve TypeScript’s biggest flaw – lack of type support at runtime.

Hope this was useful ✌️

Cheers,
~Swizec

Learned something new? Want to improve your skills?

Join over 10,000 engineers just like you already improving their skills!

Here's how it works 👇

Leave your email and I'll send you an Interactive Modern JavaScript Cheatsheet 📖right away. After that you'll get thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over my 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

PS: You should also follow me on twitter 👉 here.
It's where I go to shoot the shit about programming.