Swizec Teller - a geek with a hatswizec.com

    TypeScript's biggest flaw and how you can use ducks to fix it

    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 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
    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
    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
    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
    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
    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?



    And that's how you can use ducks to solve TypeScript's biggest flaw โ€“ lack of type support at runtime.

    Hope this was useful โœŒ๏ธ


    Did you enjoy this article?

    Published on June 17th, 2019 in Computer Science, Front End, Technical

    Learned something new?
    Want to become an expert?

    Here's how it works ๐Ÿ‘‡

    Leave your email and I'll send you thoughtfully written emails every week about React, JavaScript, and your career. Lessons learned over 20 years in the industry working with companies ranging from tiny startups to Fortune5 behemoths.

    Join Swizec's Newsletter

    And get thoughtful letters ๐Ÿ’Œ on mindsets, tactics, and technical skills for your career. Real lessons from building production software. No bullshit.

    "Man, love your simple writing! Yours is the only newsletter I open and only blog that I give a fuck to read & scroll till the end. And wow always take away lessons with me. Inspiring! And very relatable. ๐Ÿ‘Œ"

    ~ Ashish Kumar

    Join over 14,000 engineers just like you already improving their careers with my letters, workshops, courses, and talks. โœŒ๏ธ

    Have a burning question that you think I can answer?ย I don't have all of the answers, but I have some! Hit me up on twitter or book a 30min ama for in-depth help.

    Ready to Stop copy pasting D3 examples and create data visualizations of your own? ย Learn how to build scalable dataviz components your whole team can understand with React for Data Visualization

    Curious about Serverless and the modern backend? Check out Serverless Handbook, modern backend for the frontend engineer.

    Ready to learn how it all fits together and build a modern webapp from scratch? Learn how to launch a webapp and make your first ๐Ÿ’ฐ on the side with ServerlessReact.Dev

    Want to brush up on your modern JavaScript syntax?ย Check out my interactive cheatsheet: es6cheatsheet.com

    By the way, just in case no one has told you it yet today: I love and appreciate you for who you areย โค๏ธ

    Created bySwizecwith โค๏ธ