Emulating TypeScript union types with ReasonML

YESTERDAY Gary Bernhardt posted a compelling write-up about the benefits they got from converting a JavaScript application to TypeScript. One of the really cool examples in that post is how TypeScript can automatically generate a union type for you by examining a JavaScript object literal during typechecking. That got me to thinking about how ReasonML/OCaml might be able to do the same thing.

The TypeScript version

Here's a simplified version of the TypeScript example:

const icons = {
  arrowDown: {label: 'Down Arrow'},
  arrowLeft: {label: 'Left Arrow'},
}

type IconName = keyof typeof icons

function iconLabel(iconName: IconName): string {
  return icons[iconName].label
}

console.log(iconLabel('arrowLeft'))
// "Left Arrow"

/* console.log(iconLabel('bob'))

   ERROR: Argument of type '"bob"' is not assignable to parameter of type
   '"arrowDown" | "arrowLeft"'. */

The key (no pun intended) line is this one: type IconName = keyof typeof icons. TypeScript is examining the icons object during typechecking, making a list of all its keys, and turning that into a union of the keys as strings:

arrowDown, arrowLeft => 'arrowDown' | 'arrowLeft'

TypeScript is able to do this because it enforces that all the object keys must be known during typechecking. It doesn't allow you to, for example, assign a new key like icons.bob = 'Bob Arrow', because once it sees the object literal's keys, it decides those are the only ones that are allowed.

This is great for all the reasons that Bernhardt goes into detail in his post, but long story short it's a convenient way to automatically tie together the icon data to the icon label getter function and make sure they never go out of sync with each other.

When I saw this I wondered if a straight translation to Reason would be possible, because Reason doesn't have TypeScript's level of support for union types. It does, however, have polymorphic variant types which have much the same level of power.

The Reason version

After some trial and error, I came up with this:

let icons =
  fun
  | `arrowDown => {"label": "Down Arrow"}
  | `arrowLeft => {"label": "Left Arrow"};

let iconLabel = name => icons(name)##label;

let () = Js.log(iconLabel(`arrowLeft));
// "Left Arrow"

/* let () = Js.log(iconLabel(`bob));

   ERROR:

   This has type:
     [> `bob ]
   But somewhere wanted:
     [< `arrowDown | `arrowLeft ]
   The second variant type does not allow tag(s) `bob */

The biggest difference in the Reason version is that icons is not an object, but a function. This is because of the way polymorphic variant inference works. Only by using a function can we guarantee that the function will accept only valid values of the variant. In this way we emulate a union type.

A slightly smaller but still convenient difference: we don't need to annotate the iconLabel function type. Reason automatically infers from usage that its parameter must be the polymorphic variant type that the icons function takes as well, and that its return type must be a string because that's the type of an icon object's label prop. This is all completely type-safe for the same reasons the TypeScript version is, and offers the same maintenance and refactoring benefits.

Comments

[Yawar Amin]

Extensible variants are fun indeed 🙂 the technique I suggested with polyvariants will warn about typos though because of the way the function is defined with the polyvariant value being the function parameter. Its type is inferred as [< `arrowDown | `arrowLeft], so a typo like `arrowDonw will give the same kind of type error as I show in the post.

[Yawar Amin]

Hmm, I still don't see how that could happen though 🤔 at some point in the code we would call icons(something) where something is a polymorphic variant tag. At that point the typechecker would step in to point out if you called it with icons(`arrowDown) which is not handled by the icons function (assuming the typo in its definition). You wouldn't be calling the icons function with a string, it's not stringly typed.

[Yawar Amin]

Try out a typo in the icons definition in my code sample, you'll see the error at compile time 🙂 In fact you even hinted as to why: because I didn't use a catch-all case. That's exactly what causes the polymorphic variant type to be inferred as 'less than these cases', as I mentioned before. Definitely agree though that these are subtleties that need to be understood for proper usage. Real World OCaml is a good resource to learn about those, for sure.