DEV Community: John R Murray

Type Safe GroupBy In TypeScript

John R Murray — Fri, 27 May 2022 20:09:59 +0000

Feel free to read this on my blog!

Lodash's groupBy

I would bet if you have a sizeable Javascript/Typescript codebase you most likely are using lodash somewhere in there.
While Javascript has gotten more "batteries included" over the last few years, lodash still has many nice functions for manipulating arrays/objects.
One such function is groupBy. It groups a list by some predicate, in the simplest case it can just be a key in the objects of the array.

import _ from 'lodash';

interface Foo {
  num: number;
  someLiteral: 'a' | 'b' | 'c';
  object: Record<string, any>;
}

const vals: Foo[] = [
  { num: 1, someLiteral: 'a', object: { key: 'value' } },
  { num: 2, someLiteral: 'a', object: { key: 'diffValue' } },
  { num: 1, someLiteral: 'b', object: {} },
];

console.dir(_.groupBy(vals, 'num'));
/*
{
  '1': [ { num: 1, someLiteral: 'a' }, { num: 1, someLiteral: 'b' } ],
  '2': [ { num: 2, someLiteral: 'a' } ]
}
*/
console.dir(_.groupBy(vals, 'someLiteral'));
/*
{
  a:[
      { num: 1, someLiteral: 'a', object: [Object] },
      { num: 2, someLiteral: 'a', object: [Object] }
  ],
  b: [ { num: 1, someLiteral: 'b', object: {} } ]
}
*/

This all seems to make sense, you can set what key you want to group on, and you get back an object whose keys are the values for found in the input array of objects.

Now if you're in a TypeScript code base I hope you are using the definitely typed lodash types to add some types to the lodash functions.
In this case the _.groupBy type looks roughly like (simplified from the actual code)

declare function groupBy<T>(collection: List<T>, key: string): Dictionary<T[]>;

interface Dictionary<T> {
  [index: string]: T;
}

So a few things stick out here. First, the key type is just string, so there's nothing stopping me from doing _.groupBy(vals, "someKeyThatDoesNotExist").
Second, we have no restrictions at the type level of me grouping on a key whose value is not a valid object key (the value must be a subset of string | number | symbol). For example in Foo the object key's value was a record. Here's what happens when you try to group on that key.

console.dir(_.groupBy(vals, 'object'));
/*
{
  '[object Object]': [
    { num: 1, someLiteral: 'a', object: [Object] },
    { num: 2, someLiteral: 'a', object: [Object] },
    { num: 1, someLiteral: 'b', object: {} }
  ]
}
*/

In this case the objects where coerced to string values so all elements of vals where grouped under the same weird [object Object] key. While this does not throw an error there is almost 0 chance you want this to happen in your code.

Finally, the return type of this function is Dictionary, while its "right" it could be "more right" by encoding that the returning object's keys would be the values of the grouping key in the input object.

Making our own groupBy

insert Bender joke here

To start making our own type safe groupBy, we first need some code that actually does the grouping logic. Let's start with that and some basic types.

// Note: PropertyKey is a builtIn type alias of
// type PropertyKey = string | number | symbol
// This lets us use "Record<PropertyKey, any>" to represent any object
// but is slightly nicer to use than the "object" type
function simpleGroupBy<T extends Record<PropertyKey, any>>(arr: T[], key: keyof T): any {
  return arr.reduce((accumulator, val) => {
    const groupedKey = val[key];
    if (!accumulator[groupedKey]) {
      accumulator[groupedKey] = [];
    }
    accumulator[groupedKey].push(val);
    return accumulator;
  }, {} as any);
}

console.dir(simpleGroupBy(vals, 'num'));
/*
{
  '1': [
    { num: 1, someLiteral: 'a', object: [Object] },
    { num: 1, someLiteral: 'b', object: {} }
  ],
  '2': [ { num: 2, someLiteral: 'a', object: [Object] } ]
}
*/

Cool the logic here seems to work, but obviously the types could use some love.

Let's start by adding a few more generics, so we can type the output correctly.
Your first change might be to make the return type Record<string, T[]> since the keys will be coerced to strings by JavaScript and the values will be the same values in the array.
This will unfortunately make typescript sad.

function sadAttempt<T extends object>(arr: T[], key: keyof T): Record<string, T[]> {
  return arr.reduce((accumulator, val) => {
    const groupedKey = val[key];
    if (!accumulator[groupedKey]) {
      accumulator[groupedKey] = [];
    }
    accumulator[groupedKey].push(val);
    return accumulator;
  }, {} as Record<string, T[]>);
}

The lines with accumulator[groupedKey] will error with Type 'T[keyof T]' cannot be used to index type 'Record<string, T>'. Here the keyof T could be any key in T so since not every key's value in T is a string typescript will not let you treat groupedKey as a string.

We can almost fix this by adding some more information on the input key by binding it to a new generic parameter, though there will still be some issues.

function betterSadAttempt<T extends Record<PropertyKey, any>, Key extends keyof T>(
  arr: T[],
  key: Key
): Record<T[Key], T[]> {
  return arr.reduce((accumulator, val) => {
    const groupedKey = val[key];
    if (!accumulator[groupedKey]) {
      accumulator[groupedKey] = [];
    }
    accumulator[groupedKey].push(val);
    return accumulator;
  }, {} as Record<T[Key], T[]>);
}

Here we added a new generic Key extends keyof T so when we supply a specific key to the function, the Key generic will be narrowed to that value. For example if we did betterSadAttempt(vals, 'someLiteral'), Key would exactly be 'someLiteral' instead of keyof Foo = 'someLiteral' | 'num' | 'object'

However, typescript is still sad on the Record<T[Key], T[]> lines with Type 'T[Key]' does not satisfy the constraint 'string | number | symbol'.
This error is similar to the error before, basically T[Key] can not be a key for the Record since it could be some weird value.

To accomplish this we need to make a helper type that filters down the allowed keys to only keys whose values are string | number | symbol.
We can use a mapped type to do just that

type MapValuesToKeysIfAllowed<T> = {
  [K in keyof T]: T[K] extends PropertyKey ? K : never;
};
type Filter<T> = MapValuesToKeysIfAllowed<T>[keyof T];

This type helper does a few things. First it maps over all the values in T ([K in keyof T]) and makes the value the key if it is a subset of string | number | symbol (T[K] extends PropertyKey ? K), if it's not a subset its value will bethe never type. Finally, we use an index access type to get all values of the transformed object as a union. This step will drop all the never values automatically for us since adding never to a union is like saying or false its basically is a no op.

That was a mouthful so let's see an example

// from above
interface Foo {
  num: number;
  someLiteral: 'a' | 'b' | 'c';
  object: Record<string, any>;
}

type MappedFoo = MapValuesToKeysIfAllowed<Foo>;
/*
{
  num: "num";
  someLiteral: "someLiteral";
  object: never;
}
*/
// we replace the values of this object with just the key as a string literal or never

type FooKeys = Filter<Foo>;
// => "num" | "someLiteral"
// notice the never does not show up in the union

interface AllObjects {
  object: Record<string, any>;
  diffObject: Record<number, any>;
}

type MappedAllObjects = MapValuesToKeysIfAllowed<AllObjects>;
/*
{ 
  object: never;
  diffObject: never;
}
*/

type AllObjectsKeys = Filter<AllObjects>;
// => never
// the output is only never. Think of this like saying "false or false", the output will just be false

With this filter type helper function we can now properly limit the Key generic by replacing Key extends keyof T with Key extends Filter<T>.

Putting it all together

type MapValuesToKeysIfAllowed<T> = {
  [K in keyof T]: T[K] extends PropertyKey ? K : never;
};
type Filter<T> = MapValuesToKeysIfAllowed<T>[keyof T];

function groupBy<T extends Record<PropertyKey, any>, Key extends Filter<T>>(
  arr: T[],
  key: Key
): Record<T[Key], T[]> {
  return arr.reduce((accumulator, val) => {
    const groupedKey = val[key];
    if (!accumulator[groupedKey]) {
      accumulator[groupedKey] = [];
    }
    accumulator[groupedKey].push(val);
    return accumulator;
  }, {} as Record<T[Key], T[]>);
}

const nums = groupBy(vals, 'num');
// nums = Record<number, Foo[]>

const literals = groupBy(vals, 'someLiteral');
// literals = Record<"a" | "b" | "c", Foo[]>

const sad = groupBy(vals, 'object');
// error: Argument of type '"object"' is not assignable to parameter of type 'Filter<Foo>'

Now this works great, we can only pass in keys that have valid values, and we even get autocomplete on it! However, one thing that bothers me is the error message in the last case.
While it's correct, saying not assignable to parameter of type 'Filter<Foo>' is not very useful to a user. This pops up sometimes with typescript where it won't show the underlying type and instead just show the higher level type helper instead.

To make the error message show the valid keys we can use a modified version of this "hack". Here instead of creating the Expand type in the post, we can make our own ValuesOf to replace the [keyof T] at the end of Filter

type ValuesOf<A> = A extends infer O ? A[keyof A] : never;

type Filter<T> = ValuesOf<MapValuesToKeysIfAllowed<T>>;
// was Filter<T> = MapValuesToKeysIfAllowed<T>[keyof T]

const sad = groupBy(vals, 'object');
// error: Argument of type '"object"' is not assignable to parameter of type '"num" | "someLiteral"'

Now we have type safety and good error messages!

Possible improvements

One thing this groupBy function lacks that the lodash groupBy gives is we do not allow you to pass a function instead of a key to group on.
The example in the lodash docs is

_.groupBy([6.1, 4.2, 6.3], Math.floor);
// { '4': [4.2], '6': [6.1, 6.3] }

While this is not perfect this mostly works

function groupByFunc<
  RetType extends PropertyKey,
  T, // no longer need any requirements on T since the grouper can do w/e it wants
  Func extends (arg: T) => RetType
>(arr: T[], mapper: Func): Record<RetType, T[]> {
  return arr.reduce((accumulator, val) => {
    const groupedKey = mapper(val);
    if (!accumulator[groupedKey]) {
      accumulator[groupedKey] = [];
    }
    accumulator[groupedKey].push(val);
    return accumulator;
  }, {} as Record<RetType, T[]>);
}

const test = groupByFunc([6.1, 4.2, 6.3], Math.floor);
// test = Record<PropertyKey, Foo[]>

This works by only letting you pass in functions that return PropertyKey, but typescript does not seem to narrow the types. In this case test should be Record<number, Foo[]> since TS should infer the return type of the grouping function. If you know how to improve this function to make the return type narrow properly feel free to leave an issue/pr on my blog's GitHub!/JRMurr.github.io)!

Rust Environment and Docker Build with Nix Flakes

John R Murray — Thu, 19 May 2022 00:00:00 +0000

Feel free to read this on my blog!

Why Nix

Getting a dev environment setup with rust is usually pretty simple, just use rustup then you're good to go.
Using a build tool like Nix can buy you much more for not much extra work. Nix lets you

Specify non rust project dependencies in code
Automatically add all your projects tools/dependencies to your path with direnv
Easily build slim docker containers

Once you start working in a repo with nix you never want to go back.
No more READMEs with a list of Homebrew, apt, pacman, etc. commands you need to run.
Building slim docker containers is a breeze without needing to manually handle multiple layers to copy build artifacts from.

This post will mostly be a quick and dirty guide to getting started with nix, so I won't go into too much detail on what nix is doing under the hood/nix syntax.
For a quick and dirty nix syntax reference I recommend learn X in Y's post,
if you have some functional programming experience most of the basics will be quick to pick up.

The Dev Environment

We will use nix flakes to set up nix for our project.
Flakes are nix's newish way to make nix builds more reproducible by adding a lock file concept to the project.
Each flake can have inputs which are other flakes/nix files and many outputs.
One thing to note, all files referenced in your flake (including itself) must be added to git.
If you run into any file not found errors make sure you git add everything you need.

To get started in the root of your project run

nix flake init

This will give you a flake.nix file that looks like

{
  description = "A very basic flake";

  outputs = { self, nixpkgs }: {

    packages.x86_64-linux.hello = nixpkgs.legacyPackages.x86_64-linux.hello;

    defaultPackage.x86_64-linux = self.packages.x86_64-linux.hello;

  };
}

This starter flake will build a hello world binary with nix build .#hello which calls the first line or with just nix build to call the defaultPackage line.
The downside is this only builds the package on x86/64 Linux, let's add some inputs to generalize this to more systems.

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
  };

  outputs = { self, nixpkgs, flake-utils, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let pkgs = import nixpkgs { inherit system; };
      in {
        packages.hello = pkgs.hello;
        defaultPackage = pkgs.hello;
      });
}

We added two inputs, the first is nixpkgs which lets us specify which version of nixpkgs we should use.
There are many thousands of packages in the nixpkg repository, and they are updated often so here will use the unstable branch.
We also added flake-utils which helps us generalize the flake to support multiple systems, not just Linux.

Now on Linux and mac the hello package will build. When you run nix build, you should see a result folder which contains the hello package,
you can run it with ./result/bin/hello. The result folder is a symlink to the output of build in the nix store (where nix keeps all outputs).
It will not always be a folder, it will just depend on the build.

Rust in Nix

To move on from "hello world" to rust lets add another input

inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixos-unstable";
    flake-utils.url = "github:numtide/flake-utils";
    rust-overlay.url = "github:oxalica/rust-overlay";
  };

  outputs = { self, nixpkgs, flake-utils, rust-overlay, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) ];
        pkgs = import nixpkgs { inherit system overlays; };
        rustVersion = pkgs.rust-bin.stable.latest.default;
      in {
        devShell = pkgs.mkShell {
          buildInputs =
            [ (rustVersion.override { extensions = [ "rust-src" ]; }) ];
        };
      });
}

We added rust-overlay, so we can easily specify different rust versions
without relying on nixpkgs to give us what ever rust version in there.

We also switched the outputs to only have devShell, that output is tied to nix develop, when run you will get a new sandboxed shell with the stable rust version.

If you want to use a specific version/nightly build you can use
rustVersion = (pkgs.rust-bin.fromRustupToolchainFile ./rust-toolchain.toml); to read a rust toolchain file and use the version specified in there.

You may also have noticed we added .override { extensions = [ "rust-src" ]; }). This is needed for rust analyzer to get rust source code.

Automatically Load the Nix Environment

Now that we have the rust version we want let's make the nix develop step automatic.

Install direnv and nix-direnv.
The second is optional but helps with caching, so I recommend it.

Direnv will add hooks to your shell so when you cd into your project it will autoload the nix environment for you without needing to run nix develop.

In the root of your project run

echo "use flake" >> .envrc
direnv allow

The .envrc file will be loaded by direnv, and it will use the flake's devShell output to set up your environment.
On changes to your flake direnv will reload only what has changed.

If you are using VS Code, use nix env selector, so VS Code is aware of the flake. It is not always necessary if you open VS Code from your terminal, but It's simple to set up.

Build Rust Project

Now that we have rust in our dev environment we can make a new rust app with

cargo init

Then we can run/build the project like you normally would with cargo run/cargo build.
That works well while developing but let's use nix to build the project, this will help us later on when we make the docker image.

Let's update the outputs too

outputs = { self, nixpkgs, flake-utils, rust-overlay, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) ];
        pkgs = import nixpkgs { inherit system overlays; };
        rustVersion = pkgs.rust-bin.stable.latest.default;

        rustPlatform = pkgs.makeRustPlatform {
          cargo = rustVersion;
          rustc = rustVersion;
        };

        myRustBuild = rustPlatform.buildRustPackage {
          pname =
            "rust_nix_blog"; # make this what ever your cargo.toml package.name is
          version = "0.1.0";
          src = ./.; # the folder with the cargo.toml

          cargoLock.lockFile = ./Cargo.lock;
        };

      in {
        defaultPackage = myRustBuild;
        devShell = pkgs.mkShell {
          buildInputs =
            [ (rustVersion.override { extensions = [ "rust-src" ]; }) ];
        };
      });

First we have to make a rustPlatform with our rust version.
The platform will let us build our rust package with rustPlatform.buildRustPackage. This is the nix equivalent of cargo build.
We need cargoLock.lockFile so nix can cache all of your project's dependencies based on your existing lock file.

Now we can run nix build, then your project will be in the result folder again. In my case I can run ./result/bin/rust_nix_blog.

Make a Docker Image

Now that we have nix building the rust project making the docker container is quite easy.

outputs = { self, nixpkgs, flake-utils, rust-overlay, ... }:
    flake-utils.lib.eachDefaultSystem (system:
      let
        overlays = [ (import rust-overlay) ];
        pkgs = import nixpkgs { inherit system overlays; };
        rustVersion = pkgs.rust-bin.stable.latest.default;

        rustPlatform = pkgs.makeRustPlatform {
          cargo = rustVersion;
          rustc = rustVersion;
        };

        myRustBuild = rustPlatform.buildRustPackage {
          pname =
            "rust_nix_blog"; # make this what ever your cargo.toml package.name is
          version = "0.1.0";
          src = ./.; # the folder with the cargo.toml

          cargoLock.lockFile = ./Cargo.lock;
        };

        dockerImage = pkgs.dockerTools.buildImage {
          name = "rust-nix-blog";
          config = { Cmd = [ "${myRustBuild}/bin/rust_nix_blog" ]; };
        };

      in {
        packages = {
          rustPackage = myRustBuild;
          docker = dockerImage;
        };
        defaultPackage = dockerImage;
        devShell = pkgs.mkShell {
          buildInputs =
            [ (rustVersion.override { extensions = [ "rust-src" ]; }) ];
        };
      });

Now nix build or nix build .#docker will build the docker image. After building result is just a sym link to the image tar file of a folder like before.
Since nix is declarative it does not load it directly into docker for you. You can load it with

docker load < result

You should see an output like rust-nix-blog:yyc9gd4nkydrikzpsvlp3gmwnpxhh1ik which is the image and tag loaded in.

Now run the image with

docker run rust-nix-blog:yyc9gd4nkydrikzpsvlp3gmwnpxhh1ik

We can automate this a bit with a script like. (Slightly modified example from here)

#!/usr/bin/env bash
set -e; set -o pipefail;

nix build '.#docker'
image=$((docker load < result) | sed -n '$s/^Loaded image: //p')
docker image tag "$image" rust-nix-blog:latest

Let's use dive to look at the image. You can use it temporarily with nix shell nixpkgs#dive.

Looking at the output you can see it's a single layer image with just they need nix store package to run the binary (in case just libc and the rust code).

Common troubleshooting issues

Non Rust Build Dependencies

Building with nix is great once its working, it will stay working forever.
Getting to a working state can be a bit of pain sometimes.
If your rust code relies on system packages (like OpenSSL) make sure you include them in buildInputs, for example

rustPlatform.buildRustPackage {
  pname =
    "rust_nix_blog"; # make this what ever your cargo.toml package.name is
  version = "0.1.0";
  src = ./.; # the folder with the cargo.toml
  nativeBuildInputs = [pkgs.pkg-config ]; # just for the host building the package
  buildInputs = [pkgs.openssl]; # packages needed by the consumer
  cargoLock.lockFile = ./Cargo.lock;
};

For OpenSSL specifically I would recommend using rustls when possible. It's easier to build and in rust.

Nix Docs

Nix documentation is not the best. While the wiki and manual have some info, I've found the best resources have been the many nix bloggers out there. Here are some good references

Xe most of her blogs relate to nixos, the Linux distro based on nix, but it helps to learn the language and common patterns
Ian Henry's how to learn nix Ian has a blog series of him learning nix. It's not really documentation but more curated notes of his process of using nix.
Intro to nix flakes Great 3 part series on what flakes are and how to use them
Building docker containers with nix Linked this earlier, but it's a good reference for more options on building containers

I also highly recommend on diving headfirst into nix by using Nixos as your Linux distro. It will help make you more comfortable with the language and its great to use once it clicks.

Intermediate Typescript Part 1

John R Murray — Wed, 26 Jan 2022 22:01:43 +0000

Feel free to read this on my blog!

At my job we have spent a lot of time converting a node backend and angular frontend to Typescript.
Before Typescript when working in our codebase I found myself having to read a lot of code, api schemas, and tests just to see what fields actually existed.
So during the transition I tried my hardest to make the types I made as descriptive as they could be.
Converting to Typescript and making big interfaces/types with many optional fields does not buy you much other than typo prevention and basic autocomplete.

This post assumes you have a basic understanding of javascript/typescript.

Literal types

You are most likely familiar with the basic types like

let num: number = 1; // can be any number
let str: string = 'hi'; // can be any string
let bool: boolean = true; // can be true or false
let arr: number[] = [10]; // can be an array of any length with numbers
let obj: { key: string } = { key: 'value' }; // the key field can be any string

These types are fine for many cases and I still default most types to be these until I understand the code more.

Literal Types on the other hand are a much stronger restricion on what the allowed values are

const numLiteral = 1 as const; // this can only be the number 1, no other number
const strLiteral = 'literal' as const; // can only be the string 'literal'
const boolLiteral = true as const; // can only be true
const arrLiteral = [10] as const; // can only be an array with a single element of 10
const objLiteral = { key: 'value' } as const; // can only be this specific object mapping

These types on there own are not that useful but when combined with unions and conditional types they can make your types very powerful.

Unions

Union Types allow you to say a type is either
foo or bar or number or string...

function printId(id: number | string) {
  console.log('Your ID is: ' + id);
}

This function will allow you to pass in a string or number, this is fine since both can be added to a string for display.

When combined with literals you can make types very strongly defined.

type MethodType = "GET" | "PUT" | "POST" | "DELETE"

function makeHttpCall(url: string, method: MethodType) {...}
const url = "johns.codes"
makeHttpCall(url, "GET") // allowed
makeHttpCall(url, "GeT") // not allowed
makeHttpCall(url, "POG") // not allowed

This helps greatly for new users of this function to see what the valid method fields are without having to look at external documentaion,
your editor will provide autocomplete on the method field, and you get a compile error if you try to use an arbitrary string as the method param.

Restricting Unions

Literals allow for strongly typed apis but how do you properly narrow a general type to a more specific type? Typescript allows this in a few ways

function handleAny(url: string, method: unknown) {
  if (typeof method === "string") {
    // in this block method is now a string type
    if (method == "GET") {
        // method is now the literal "GET"
        makeHttpCall(url, method);
    }
    if (method == "PUT")
    ...
  }
}

This manual checking is fine but if you have a more complex type or a union with many possible values this gets unwieldy quite fast.
The next best approach is a type predicate

// First define valid methods as a const array
const ValidMethods = ['GET', 'PUT', 'POST', 'DELETE'] as const;
type MethodType = typeof ValidMethods[number]; // resulting type is the same as before

function isValidMethod(method: unknown): method is MethodType {
  // need the `as any` since valid methods is more strongly typed
  return typeof method === 'string' && ValidMethods.includes(method as any);
}

function handleAny(url: string, method: unknown) {
  if (isValidMethod(method)) {
    // method is now a MethodType
    makeHttpCall(url, method);
  }
}

The type predicate isValidMethod is just a function that returns a bool,
when true Typescript knows the input param method is a MethodType and can be used as such.
Type predicates are a good simple way to to encode any runtime checks into the type system.

Discrimnated unions

Now unions of basic literals are quite powerful but unions can be even more powerful when you make unions of objects.
Say in your app you track different events. The events could look like the following

interface LoginEvent {
  // the user's email
  user: string;
  wasSuccessful: bool;
}

interface PostCreatedEvent {
  name: string;
  body: string;
  createdAt: date;
}
// and many others

Once you have typed out all the different events and you want them group them together to a single event type
you might think a simple union like type ApiEvent = LoginEvent | PostCreatedEvent | ... would be good but
when you want to narrow this type down you would have to end up with a lot of if ('user' in event) {..} checks or many custom type predicate functions.

To avoid that issue you can define the event types as a Discriminated union.
All this is a union type where all types in the union have a field whos value is unique in all the union's types. We can redefine the above types as follows

interface LoginEvent {
  type: 'login';
  user: string;
  wasSuccessful: ApiEvent;
}

interface PostCreatedEvent {
  type: 'postCreated';
  name: string;
  body: string;
  createdAt: Date;
}

type ApiEvent = LoginEvent | PostCreatedEvent;
type EventTypes = ApiEvent['type']; // this resolves to 'login' | 'postCreated'

In this example you could name the key type whatever you want, as long as every type has that field the union type will allow you to access the key.
Now to narrow this type down you could do the following

function logEvent(event: ApiEvent) {
  if (event.type === 'login') {
    console.log(`user: ${event.user}, wasSuccessful: ${event.wasSuccessful}`);
  } else if (event.type === 'postCreated') {
    console.log(`post ${event.name} was created at ${event.createdAt}`);
  }
}

This style of checking the discriminating field in if statments is fine but is a little verbose to me.
I find that a switch statment makes it more readble and less verbose.

function logEvent(event: ApiEvent) {
  switch (event.type) {
    case 'login':
      console.log(`user: ${event.user}, wasSuccessful: ${event.wasSuccessful}`)
      break;
    case: 'postCreated':
      console.log(`post ${event.name} was created at ${event.createdAt}`)
      break;
    default:
      throw new Error(`invalid event type: ${event.type}`)
  }
}

There is one issue with this approach however. In the future when we add a new event type it would fall through to default case and we wouldn't know about it until runtime.
However using Typescript's never type we can force a compile error when we don't handle all cases

function assertUnreachable(type: never): never {
    throw new Error(`Invalid event type: ${type}`);
}

function logEvent(event: ApiEvent) {
  const type = event.type;
  switch (type) {
    case 'login':
      console.log(`user: ${event.user}, wasSuccessful: ${event.wasSuccessful}`)
      break;
    case: 'postCreated':
      console.log(`post ${event.name} was created at ${event.createdAt}`)
      break;
    default:
      // event.type is `never` here since this default case would never be hit since all possible cases are handled
      assertUnreachable(type)
  }
}

Now in the future if we added an event with a type field of NewEvent it would fall through to the default case,
since its type is not never (it would be NewEvent) we would get a compile error on the call to assertUnreachable.

Wrap up

While these features I covered can help you alot (these are almost all I used during the inital typescript migration),
there are many other really cool typescript features, like generics, mapped types and conditonal types.
I hope to cover them all in a Part 2 so check back soon!