Can I write a type guard that asserts multiple invariants?

Question

Can I write a type guard asserting something about one or multiple sub-objects of an argument? In pseudo-code, it might look like this:

class C {
    a: number?;
    b: string?;

    function assertInitialized() : (this.a is number) and (this.b is string) {
        return this.a !== null && this.b !== null;
    }
}

Background: I'd commonly use a single function to check invariants of my classes; for example, assume I have a class with some nullable fields, which get asynchronously initialized.

class DbClient {
    dbUrl: string;
    dbName: string;
    dbConnection: DBConnection?;
    …
}

This class goes through a complex asynchronous initialization process, after which dbConnection becomes non-null. Users of the class must not call certain methods until dbConnection is initialized, so I have a function assertReady:

assertReady() {
    if (this.dbConnection === null) {
        throw "Connection not yet established!";
    }
}

This function assertReady is called at the beginning of each function that requires the DbClient to be fully initialized, but I still have to write non-null assertions:

fetchRecord(k: string) {
    assertReady();
    return this.dbConnection!.makeRequest(/* some request based on k */);
}

Can I give assertReady a signature that makes the ! unnecessary? I don't want to pass this.dbConnection to assertReady, because that function is typically more complex.

The only trick I'm aware of is to create an interface with the same fields as the current class, but with non-nullable types (without the ?). Then I can make a type guard that says that this is InitializedDbClient. Unfortunately that requires duplicating a large part of the class definition. Is there a better way?

I'm sure it's probably too late by now, but a couple days ago I was running into the same thing. I ended up writing a proxied class that automatically waits for the connection to become ready. The one drawback is that all queries become asynchronous, but that's pretty common for databases anyway. https://gist.github.com/d99b5581ad672a8a362a161550ae23c6 I also wrote a synchronous JavaScript version that does your assertion in that gist, if you're interested. — dx_over_dt, Dec 13 '18 at 21:07

Aluan Haddad · Accepted Answer · 2022-06-25T10:21:06.487

Yes you can and you almost had it exactly right in pseudocode

interface A {
  a?: number;
  b?: string;

  hasAandB(): this is {a: number} & {b: string};
}

Notice how your pseudocode's and became an &. Very close indeed.

Of course, it's not necessary to use that operator, the type intersection operator, in this case because we can simplify it to

hasAandB(): this is {a: number, b: string};

But imagine we add a third property, say c, which isn't affected by the type guard and yet we don't want to lose its contribution to the result type all the same.

Your intuition of composable type guards brings us back full circle

hasAandB(): this is this & {a: number, b: string};

There are all sorts of really interesting, and highly useful, things you can do with these patterns.

For example, you can pass many property keys generically based on the type of an object and, depending on the actual keys that you pass, the result can be type guarded to the intersection of a bearer of each property.

function hasProperties<T, K1 extends keyof T, K2 extends keyof T>(
  x: Partial<T>,
  key1: K1,
  key2: K2
): x is Partial<T> & {[P in K1 | K2]: T[P]} {
  return key1 in x && key2 in x;
}


interface I {
  a: string;
  b: number;
  c: boolean;
}

declare let x: Partial<I>;

if (hasProperties(x, 'a', 'b')) {...}

And really, this just scratches the surface of what's possible.

Another really interesting application of this is to define arbitrarily generic and type safe builders and composable factories.

I'm trying to use this to assert some properties of a class are initialized and I'm seeing the type of `private assertInitialized(): this is this&{scene: Scene, canvas: HTMLCanvasElement}` resolve to `EmbeddingViz.assertInitialized(): this is never` — Grady S, Jun 24 '22 at 20:39
do you have a recommended resource to learn about this "define arbitrarily generic and type safe builders and composable factories" — Neil M, Dec 02 '22 at 03:40
@NeilM what I meant by that statement was that type system in TS can succinctly express highly useful and widely used design patterns, like the Builder and Factory patterns, without losing type checking and tooling. In JavaScript people use these patterns all the time, typescript just provides a way of describing them formally and statically which is highly useful. — Aluan Haddad, Dec 18 '22 at 11:09

score 1 · Answer 2 · answered Apr 06 '18 at 03:49

You can't change the type of a class property after you have declared it in Typescript. Your suggestion of using a type assertion function to locally re-qualify this may have some merit:

interface DefinitelyHasFoo
{
    foo: number;
}

class MaybeHasFoo
{

    public foo: number | null;

    constructor()
    {
        this.foo = null;
    }

    public hasFoo(): this is DefinitelyHasFoo
    {
        return !!(this.foo !== null);
    }

    public doThing()
    {
        if (this.hasFoo())
        {
            this.foo.toExponential();
        }
        else
        {
            throw new Error("No foo for you!");
        }

    }
}

// ...

const mhf = new MaybeHasFoo();

mhf.doThing();

You might also avoid the resource initialization problem by adapting your APIs to use Promises: https://jsfiddle.net/1b68eLdr/5144/ — Michael Zalla, Apr 06 '18 at 04:11

Can I write a type guard that asserts multiple invariants?

2 Answers2

Linked