Hacker News Reader

Comment by danenania | Hacker News Reader

"{a?: number, b?: string} has 4 states, while the model you might have been trying to describe — {a: number} | {b: string} — still has just two."

The problem I've run into with the second approach as the number of states expand is 1 - you end up with tons of boilerplate to discriminate between types, and 2 - it becomes hard to treat objects polymorphically.

I sometimes end up doing {a: number, b?: undefined} | {b: string, a?: undefined} so that I can write `if (obj.a) doSomething()`, but it obviously gets unwieldy with a lot of properties and states. Imo it would be nice if TS did this automatically so that I could check for the existence of any property that might be defined on an object.

View on HN

Right, TS wants you to go full-on tagged union.

    {type: 'a', a: number} | {type: 'b', b: string}

When you do this you consume it with a switch(x.type) statement, not an if() statement, so that you can write `default: assertImpossible(x.type)` for some function `assertImpossible(y: never): never` that throws an exception of your choice.

This gives clear fail-at-runtime semantics if JS hands you some crap your types weren’t anticipating, but also fail-at-compile-time semantics if your pattern match is no longer exhaustive (i.e. you added a new case, now TypeScript tells you everything you need to change).

In general it's really nice to view any data structure as isomorphic to the control structure that consumes it. “lists” are consumed by for..of loops, “dicts” are consumed by for..of Object.keys() loops, sum types are consumed by switches, objects are consumed by property accesses, etc.

Right, tagged unions are what I use, but when you start having many variants, nested tagged unions, etc., it gets quite awkward imo when you need a big ol’ switch statement to get at some property or other instead of just a simple property check.

If your code is fully typed, you don't need the default, since you know at compile time that you've handled your cases (Playground link: [0]):

    type Props =
      | { type: 'a', a: number }
      | { type: 'b', b: string }

    function f(props: Props): number {
      switch (props.type) {
        case 'a': return 1
        case 'b': return 2
      }
    }

Unfortunately you're right that this breaks when using `if` instead of `switch` (unless you have a default return at the end of your function, or replace one of your `if`s with an `else`; Playground link: [1]):

    type Props =
      | { type: 'a', a: number }
      | { type: 'b', b: string }

    // Error TS2366: Function lacks ending return statement and return
    // type does not include 'undefined'.
    function f(props: Props): number {
      if (props.type === 'a') {
        return 3
      }
      if (props.type === 'b') {
        return 4
      }
    }

This second case is a bug in TSC, and is tracked in https://github.com/microsoft/TypeScript/issues/18319.

[0] https://www.typescriptlang.org/play/#code/AQ4FwTwBwU2AFATgey...

[1] https://www.typescriptlang.org/play/#code/AQ4FwTwBwU2AFATgey...

You can use an `in` check for this, since TypeScript version 2.7 [0].

Here's an example (Playground link: [1]):

    import * as React from 'react'

    type Props =
       | {a: number}
       | {b: string}

    function MyComponent(props: Props): JSX.Element {
      if ('a' in props) {
        return <div>a is {props.a}</div>
      }
      return <div>b is {props.b}</div>
    }

    let x = <MyComponent a={3} />
    let y = <MyComponent b="foo" />

[0] https://www.typescriptlang.org/docs/handbook/release-notes/t...

[1] https://www.typescriptlang.org/play/?jsx=2#code/JYWwDg9gTgLg...

Oh nice! I’ll give that a try, thanks.

Swift handles this exact problem quite elegantly with the "if case let" construct, allowing you to destructure sum types directly within an if statement.

https://alisoftware.github.io/swift/pattern-matching/2016/05...

I don't know TypeScript, but can't you expend a few lines to write a function 'getA : State -> number?'? Paired with the TypeScript equivalent of Swift's / Rust's if-let, it should be just as convenient.

The fundamental problem is that Typescript (and JavaScript) doesn't have tagged unions. In Rust or even C++ using std::variant this isn't a problem.

TypeScript does support tagged unions, actually: https://www.typescriptlang.org/docs/handbook/advanced-types....

As does Flow: https://flow.org/blog/2015/07/03/Disjoint-Unions/

Every language can do tagged unions with "kind" or "tag" markers and switch statement. But it's going to be verbose without pattern matching/destructuring combo.

It’s not that bad, to be honest. Maybe a few more keystrokes than Haskell, but so is everything else in a C-style language.

Definitely a fair point that it is a few more keystrokes, though.

Thankfully TypeScript's type system is powerful enough (and JS's syntax flexible enough) to decently simulate pattern matching:

https://gist.github.com/frankpf/cde7f792580f731dfe886ed2d91b... (see the second file for usage)

Reply on news.ycombinator.com