On TypeScript unions

Rubén Sospedra — Fri, 26 Feb 2021 08:52:14 +0000

Not a single day passes without finding a multi-type TypeScript entity that messes your code. Successful API responses can adopt multiple shapes. Collections may contain many types within them. Parsed user inputs can collapse to different scalars. It's expected. That's why TypeScript supports Unions.

const idk = string | number | Potato

Being able to define any entity with precision is great. But that's only half of the solution. Once we have a Union type in our hands we may want to conditionally act on it. Depending on what type matches the value at each moment. That's a fancy way to define a bunch of if-else. And, indeed, in most cases TypeScript is smart enough to infer the right type.

if (typeof idk === 'string') {
  // idk: String
} else {
  // idk: number | Potato
}

This process is call Discrimination. It's the other half of the solution. With simple entities such as the one below it's pretty straightforward. However, discriminating against objects can be tough.
The good thing is that TypeScript is smart enough to identify when there's a discrimination problem. More often than not I stumble upon it:

Property 'a' does not exist on type 'A', 'B'

Identifier keys

The recommended way to do it is by having a constant string-type field in the object. For TypeScript will infer the type using that field as an anchor. The same way it does with primitive types.

type VaporCoin = { type: 'vapor' }
type NeonCoin = { type: 'neon' }

const act = (coin: VaporCoin | NeonCoin) => {
  switch (coin.type) {
    case 'vapor': {
      // coin: VaporCoin
    }
    case 'neon': {
      // coin: NeonCoin
    }
  }
}

Morphic check

But, sometimes it's not possible to rely upon one specific field. Maybe it's not even up to us to decide the object shapes - working with a third-party API. In such cases, we can infer the type by running a morphic check. Meaning, looking for differences in their shape.

type VaporCoin = { vapor: string }
type NeonCoin = { neon: string }

const act = (coin: VaporCoin | NeonCoin) => {
  if ('vapor' in coin) {
    // coin: VaporCoin
  } else {
    // coin: NeonCoin
  }
}

TBD functions

Finally, when everything else failed. We can use a to-be-defined function. If the objects don't have an identifier field. If they are morphally equal. We can check their inner differences with a function. And let this TBD function to imperatively coerce the type.

type VaporCoin = { key: string }
type NeonCoin = { key: string }

const isVapor = (tbd: unknown): tbd is VaporCoin => {
  return tbd.key === 'vapor'
}

const act = (coin: VaporCoin | NeonCoin) => {
  if (isVapor(coin)) {
    // coin: VaporCoin
  } else {
    // coin: NeonCoin
  }
}

Conclusion

Unions and Intersections are part of TypeScript's backbone. These are powerful and we must embrace their usage as much as possible. Once we start working with them we must learn how to discriminate different types. For that I recommend that everyone follows this step-through:

By default, let TypeScript's inference do its magic.
Any normal if-else will suffice for simple types.
When discriminating objects use identifier fields.
If that's not possible, use morphic checks.
As a last resource, use TBD functions.

GitHub as a Service

Rubén Sospedra — Wed, 20 May 2020 14:22:17 +0000

This post was originally posted with code examples at sospedra.me/papers/gaas.

In the past years, GitHub became a technology mastodon. Since the acquisition by Microsoft, the company added a myriad of outstanding features. GitHub Actions, in-house CI/CD, a marketplace, the integration of npm, et al. In fact, GitHub is so powerful nowadays that it can be your all-in-all provider. You can use GitHub as a Service. GaaS, Gaas, Gaas!

What is GaaS?

GitHub's variety of products is extensive enough to power most of the web apps out there. Don't believe me? Let's go through my journey building Request For Maintainers (RFM).

This project is a community-driven platform to track any repository calling for support. From the product point of view, I want to help the community to have a clean record of the OSS status. On the tech side, this project is an experiment I got in my mind for so long. RFM runs 100% on GitHub services. And it's open-sourced so anyone is welcome to check the nuts and bolts.

If you want to build a web app that runs on GitHub you're gonna need some foundations. Basic things that are common to any web. But, before getting started, a disclaimer. I didn't read the terms and conditions and all the legal dullness. But I can sense this approach ~~maybe~~ exceeds the intended purposes.

Hosting: for what GitHub repositories excel. But wait, there's more! GitHub pages put your web under a CDN, with SSL certs, and all the other goodies you'll expect from your trusted provider.
Database: if you don't have anything to hide 🌝 then GitHub Issues is a wonderful database. For example, you can store a stringified JSON in the body. Or benefit from the Issue metadata.
Server: most of the heavy lifting will happen in the client. But sometimes you need some special functions to run on the cloud. Did anyone say serverless? 💊
Auth: Do you need to put some access restrictions? Well, GitHub has a top-notch OAuth service implemented.
Secrets: Another interesting side-effect is the env secrets management. Since GitHub repositories already have a secret values system. We can use that to run out GitHub Actions as serverless functions.

How does it work?

Read the same post with code snippets in the original post.

At this point, I guess you get the idea. But how we put together all the pieces? Let's see how I built RFM step by step. You'll see it's not that complex at all.

You need your web to be statically generated. There are tones of options: Jekyll, create-react-app, an old-fashion raw HTML. Whatever. The important bit is that to use GitHub pages it must be static.
You consume your fancy database with the public GitHub API. The public part is a no key-required standard CRUD. Your web app will use this API to get GitHub Issues. You can tweak your query with multiple params: the state, labels, content, assignation, etc.
When in need of server functions use GitHub Actions. These deliver an outstanding experience. They are so powerful. The basic idea is that a custom trigger will execute a custom function. There's a marketplace you can explore or you can build your own. It's free real state!
To integrate RFM with GitHub I use the GitHub Query Parameters. You know, remember to avoid Hooman Paws™️ as much as possible. There's a well-known library that can do the heavy parsing for us: new-github-issue-url.
Finally, tweak the limitations. You can either add some auth with the GitHub OAuth. Or play with the Issues metadata, Actions triggers, etc. In RFM the actions are executed only when the issue has a particular label. Only moderators can assign labels. That's the way I avoid RFM being a spammy tool.

Conclusion

Am I suggesting that y'all should use GaaS from now on? Well, absolutely no 🤷🏻‍♂️. But, there are some cases where this can be beneficial. I'm thinking of OSS projects, mostly. In fact, using GitHub Issues as blog post comments it's being a common practice for a long time. This is an evolution of the same concept. The actual point is: GitHub becomes an infra beast lately. We should keep an eye here and consider pushing the limits as much as possible.

DEV Community: Rubén Sospedra

On TypeScript unions

Identifier keys

Morphic check

TBD functions

Conclusion

GitHub as a Service

What is GaaS?

How does it work?

Conclusion