Option in Typescript
Implementing an Option type in Typescript
After working regularly with some of the features in Scala, it becomes difficult to go without them. Front end code is one of the places where this pain feels the worst. Options are one of those features that you really do miss when you're forced to be without them. As a sort of follow up to the last post, I decided to shoehorn Options into the web with Typescript.
I'd been using React with Flow for a couple of years and really liked it. Having any level of type-saftey over vanilla JS was a big improvement.
Recently, I finally decided to bite the bullet and give Typescript a shot after hearing so many good things about it. I have no doubt anymore that Typescript is superior to es6 + flow. It catches way more issues that flow doesn't and there's an overall higher level of confidence I have with Typescript that just isn't there with flow. Plus, the community seems more engaged and growing by the day.
Options for the Front End
I decided I had enough of dealing with null
and undefined
in front end code. I wrote a small library to implement an Option
type in Typescript. It's based on the Scala code for Option
--the simlarities should be clear on a visual inspection. You can find that library here:
https://github.com/alanqthomas/option
It's published to npm as well with the package name @alanqthomas/option
.
The Syntax Struggle
The most difficult part of making this library was trying to get the usage mechanisms as close to Scala as possible. A major point of emphasis for me was trying to get rid of the tedious new
operator. I scoured the internet in search of answers and I came out with the best hack I could find that still played nice with type parameters.
The actual classes are suffixed with an underscore, there's a type alias to the class without the underscore, and then a factory function that spits out new instances, also without the underscore.
Type annotations in the IDE (VSCode) now show the types as Some_
instead of just Some
. It's a tradeoff I'm willing to make to have Some(42)
instead of new Some(42)
.
I also implemented a pseudo-match statement that looks something like this:
It uses an object with some
and none
keys as a parameter to mimic the syntax of a match
in Scala.
If anyone knows a better way to do this, please let me know.
Type Safety For Everyone
All in all, I'm pretty satisfied with how this small library turned out and I'm going to try more to put it through the ringer of real life code-writing to see if it stands up as well as I hope.
I also have a mostly complete version of Scala's Either
type in the works, but that'll have to wait for another post.
Last updated