Practical introduction to algebraic datatypes (ADTs) in TypeScript

[lalaithion]

I think this article makes the "sum" and "product" terms out to be very complicated, when in fact it's quite simple. If we have two enums

    enum Bool {
        True,
        False
    }

    enum Status {
        Waiting,
        Successful,
        Failed
    }

We can combine them into a product type, like a tuple, or a sum type, like a union.

    type Product = (Bool, Status)
    type Sum = Bool | Status

Now, we ask ourselves, what are the valid values of type Product?

    (True, Waiting)
    (True, Successful)
    (True, Failed)
    (False, Waiting)
    (False, Successful)
    (False, Failed)

There are two Bool values, and three Status values, so there are 2×3=6 values for the product of Bool and Status. Now, what about the Sum type?

    True
    False
    Waiting
    Successful
    Failed

We have 2+3=5 total values for the sum of Bool and Product.

Now, obviously, this math doesn't quite work out for types with infinite values, like strings or bigints or arrays, but that's where the analogy comes from.

If you extend this further, you can even figure out what an exponential type would be: the exponential type Bool^Status is a function that takes a Status as its argument and returns a Bool.

[ronenlh]

The Sum is called Union in the TypeScript docs, as it narrows the valid values to the overlapping elements.

In the switch statement it becomes a Sum value (as shown in the article).

In ReScript (shown as well, which uses OCaml under the hood) the syntax is that of a Variant, in which each element is a different nominal type.

[adverbly]

First I've heard of exponential type... to make sure I get it, you're saying there are 2^3 possible functions which take a status and return a bool? So if the enum inputs are success, wait, fail, you'd have

Fff

Tff

Ftf

Fft

Ttf

Tft

Ftt

Ttt

All as possible implementations of that function. Neat...

[rualca]

> I think this article makes the "sum" and "product" terms out to be very complicated, (...)

Indeed it would drive the point home if instead of simply mentioning product they referred to Cartesian product.

I guess sum types imply adding together two domain, but unless there's a subtlety then union would be clearer as well.

[infogulch]

This is a great explanation for its length, thanks!

[jimsimmons]

This helps handle IO in pure functional languages because? Is it because functions can have more than 1 type?

[benrbray]

Definitely take a look at fp-ts [1]! It's mentioned at the end of the article, but I want to emphasize just how cool it is.

[1] https://github.com/gcanti/fp-ts

[douglasisshiny]

I know there are a bunch of small guides / articles written by the author of fp-ts, but is there a good book, guide, etc. for diving in for someone who is kind of familiar with functional concepts but not quite ready for going full haskell? A book on haskell?

[myvoiceismypass]

Another one to look at is effect-ts[1] which is inspired by both fp-ts and also the scala library/framework ZIO

[1] https://github.com/Effect-TS/core

[g_delgado14]

I spoke about this with Feross Aboukhadijeh last week at SpeakeasyJS:

https://www.youtube.com/watch?v=QyunIFfKLIU

[inssein]

ADTs like the one described here for remote data is a good start, but I haven’t yet found a good way to compose multiple pieces of data that is in potentially different states.

We use another class based concept on top at work where you can compose multiple pieces of remote data together, but it really only works well for the happy path.

[ramesh31]

The switch case is still a bit redundant and inelegant, particularly considering how out of place switch case syntax feels in a Javascript codebase in general. Early returns are the way to go.

[elnygren]

The point of the switch-case is to mimic pattern matching and TS is smart enough tell you whether you handled all cases.

Would you prefer that it's a if-elseif-else based structure instead? I guess that would work too but I feel like it could be easier to write it in a way where you accidentally forget to handle some case (since your else / last return is a potential catch-all).

I personally don't mind switch-case because I'm so accustomed to it in ReasonML/ReScript already.

[ducharmdev]

Although I don't mind switch statements, I was thinking similarly about using early returns instead. But this is where switch/match expressions like in Rust or C# would really shine; it's too bad JavaScript/Typescript doesn't support them though.