Allow classes to implement unions of object types

[justinfagnani]

🔍 Search Terms

class extends union type

✅ Viability Checklist

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

Allow classes to extend unions of object types when the types in the union have the same set of properties.

The goal is to allow type-narrowing on class instances by checking a discriminant field.

📃 Motivating Example

I often have classes that represent data that can be in one of several states, and whose fields depend on that state.

An example is an object that is imported into a database with a long task. The app will write a record to the database to indication that it's currently being imported, and locking it from other writers.

We might model that with two interfaces: ImportingFoo, and ImportedFoo, discriminated by a status field:

type FooStates = ImportingFoo | ImportedFoo;

interface ImportingFoo {
  status: 'importing';
  value: undefined;
}

interface ImportedFoo  {
  status: 'imported';
  value: string;
}

We want our class to implement this type to indicate what type value can be depending on the type of status:

class Foo implements FooStates {
  status: 'importing' | 'imported' = 'importing';
  value: undefined | string;
}

This currently gives a "A class can only implement an object type or intersection of object types with statically known members.(2422)" error.

If we could do that, we could use narrowing for the instance:

const getValue = (foo: Foo): string => {
  if (foo.status === 'imported') {
    return foo.value; // OK, because foo narrowed to a ImportedFoo
  }
  throw new Error('Invalid state');
}

💻 Use Cases

1. What do you want to use this for?

• Classes that act as discriminated unions

2. What shortcomings exist with current approaches?

• The class can't explicitly implement the union, narrowing doesn't automatically work

3. What workarounds are you using in the meantime?

• Cast the instance to an intersection of the class and interface: foo as Foo & ImportedFoo, but this is error prone as the cast will succeed in cases where it shouldn't.

[MartinJohns]

I'm not sure what you expect to happen. The class can't implement both ImportingFoo and ImportedFoo, because those types are incompatible with each other. Having the properties be unions doesn't make sense, because ImportingFoo clearly states the property status must be typed "importing", whereas ImportedFoo states the property status must be typed "imported" - neither type accepts a union.

[RyanCavanaugh]

I don't understand this either. It seems like it would make sense to say that

class Foo implements Bar { }

should be treated exactly the same as

class Foo { }
const m: Bar = new Foo(); // check assignability

But the proposed class doesn't fit that; as-is the class obviously allows illegal combinations.

Is the intention here that TS would somehow track mutations inside the class to ensure it's always in one union or the other? I mean even that isn't really workable, since between the first and second mutation that's not true either.

[jcalz]

Before it could be even considered to allow classes/interfaces to be unions (which seems like a huge change), you'd have to figure out how TypeScript could allow mutating an existing object from one union member to another. Like, if you have const o: {a: 0, b: 0} | {a: 1, b: 1} = {a: 0, b: 0} you're stuck with o being the 0 member forever. TypeScript will complain about o.a = 1; o.b = 1; because it's narrowed, and even if it weren't, the time period between o.a=1 and o.b=1 violates the invariant, so TypeScript would need some kind of "please only check this after I'm done mucking with it" which it doesn't have (I've seen requests this before for things like const o: Person = {}; o.name = "Fred"; o.age = 35;). Some kind of "eventual" type checking.

I'm thinking all of this is really neat but would require huge changes to the language, and... for what? To allow a class instance to be a mutable discriminated union itself instead of just refactoring so that the object has the data instead of is the data? I mean, I'd think the most reasonable workaround is just to push the union down into a property:

type FooStates = ImportingFoo | ImportedFoo;

interface ImportingFoo {
  status: 'importing';
  value: undefined;
}

interface ImportedFoo {
  status: 'imported';
  value: string;
}

class Foo {
  fooData: FooStates = { status: 'importing', value: undefined }
}

const getValue = (foo: Foo): string => {
  if (foo.fooData.status === 'imported') {
    return foo.fooData.value;
  }
  throw new Error('Invalid state');
}

Playground link to code

[justinfagnani]

I have a bit more to say to the questions above, but very quickly: isn't the mutation question already an issue with discriminated unions today? I didn't address it in the issue because it is hairy, but also because IMO, this wouldn't be introducing any new problems around mutation.

Consider the same code without classes:

type Foo = ImportingFoo | ImportedFoo;

interface ImportingFoo {
  status: 'importing';
  value: undefined;
}

interface ImportedFoo  {
  status: 'imported';
  value: string;
}

const updateFoo = (foo: Foo) => {
  // This is bad! We didn't check foo's status, or also update .value to be a string
  foo.status = 'imported';
}

There would indeed need to be a new language feature to try to ensure that a variable satisfies a type by some check point. I think the only thing close to this is constructors that make sure fields are initialized. But again, I don't think classes implementing unions would be the first thing to reveal this problem.

[RyanCavanaugh]

If it doesn't mutate then you could have written this instead:

type OfStatus<K extends FooStates['status']> = FooStates & { status: K };
class Foo implements OfStatus<'importing'> {
  status: 'importing' = 'importing';
  value: undefined;
}

so I assume you actually are mutating

[justinfagnani]

Yes, I'm often mutating in these cases, but like with objects and union types currently, the correctness of the mutations is left as an responsibility for the author. I don't know that TypeScript offers any help here outside of custom type assertions.

But there are also non-mutating use cases, like one I have with a database. A class is mapped to a table, and must satisfy one of several discriminated types, but instances aren't mutated over their lifetime in the VM - they're mutated by writing to the DB.

[jcalz]

Non-mutating cases map more cleanly onto subclasses like

type FooStates = ImportingFoo | ImportedFoo;

class Foo {
  generalFooStuff = 123;
}

class ImportingFoo extends Foo {
  readonly status = 'importing';
  value: undefined;
}

class ImportedFoo extends Foo {
  readonly status = 'imported';
  constructor(public value: string) { super() }
}


const getValue = (foo: FooStates): string => {
  if (foo.status === 'imported') {
    return foo.value;
  }
  throw new Error('Invalid state');
}

Playground link to code

[justinfagnani]

It isn't always an option to refactor a single class into multiple classes.

[jcalz]

Sure, but pragmatically speaking you are going to look for workarounds instead of a waiting for a fairly hefty language change. You could do it this way with one class:

interface FooValue {
  importing: undefined;
  imported: string;
}

class Foo<K extends keyof FooValue> {
  constructor(public status: K, public value: FooValue[K]) { }
}

type FooStates<K extends keyof FooValue = keyof FooValue> = { [P in K]: Foo<P> }[K]

const getValue = (foo: FooStates): string => {
  if (foo.status === 'imported') {
    return foo.value;
  }
  throw new Error('Invalid state');
}

Playground link to code

And yes, of course, there are use cases where that won't work. But again, until and unless this feature (or set of features) is implemented, there's not much else to do but work around it.

[justinfagnani]

I guess I'm arguing that this wouldn't be a hefty language change. It's two things:

1. Checking that the class declaration is compatible with the union type, similar to how function overloads are already checked.
2. Allowing type narrowing to be applied to class instances without casting to the union type first.

The mutation problem does exist, but it already exists, so I'd argue for deferring it and solving it (or not!) for existing discriminated unions as well.

[justinfagnani]

Adding some more detail for the questions above...

First, I would propose that this feature only does the two things I mentioned.

1. Check that the class declaration is compatible with the union type

   type FooStates = ImportingFoo | ImportedFoo;
   
   interface ImportingFoo {
     status: 'importing';
     value: undefined;
   }
   
   interface ImportedFoo  {
     status: 'imported';
     value: string;
   }
   
   class Foo implements FooStates {
     status: 'importing' | 'imported' = 'importing';
     value: undefined;
     //         ^ Error: This property is not compatible with the type FooStates (missing type undefined)
   }

   This is similar in spirit to the check performed on function overloads. If the function implementation does not allow for an overload signature, then there's an error. The function check is in a different direction though - I'm not sure if that's a problem here.

2. Enable type narrowing for class instances

   My previous example:

   const getValue = (foo: FooStates): string => {
     if (foo.status === 'imported') {
       return foo.value;
     }
     throw new Error('Invalid state');
   }

I think these two things would bring a lot of value to existing code where a class instance should only be in a valid state that's already describable with discriminated unions.

---

I don't understand this either. It seems like it would make sense to say that

class Foo implements Bar { }

should be treated exactly the same as

class Foo { }
const m: Bar = new Foo(); // check assignability

But the proposed class doesn't fit that; as-is the class obviously allows illegal combinations.

Assuming that the constructor is well behaved, my proposal would indeed imply what you wrote. Foo would be assignable to Bar.

This is the same for objects without classes. ie, replace the constructor with a factory function that returns an object of a type:

declare createBar(): Bar;
const m: Bar = createBar();

In the class case, new Foo() is a factory for a type that's assignable to Bar.

Construction

I think the difference here is the assumptions we make around object construction. With objects and unions the simple, happy path is using object literals that conform to the union from inception, while constructors are inherently imperative and mutating. So it might seem like you can't verify that class instances ever get into a valid state, while you can with objects. But I think this is maybe over-simplifying: I often see cases where objects need to be constructed imperatively and are cast to the correct type afterwards.

I can see the desire to not just have to trust the constructor, but this is another problem that also exists today, with function overloads.

Consider this overloaded function:

function foo(status: 'importing', value: undefined): undefined;
function foo(status: 'imported', value: string): string;
function foo(status: 'importing' | 'imported', value: string | undefined): string | undefined {
  return 'foo';
}

The implementation is wrong. If value is undefined, the return value should be undefined, but the checker doesn't check that.

It would be very useful to be able to check the constructor though. This would make the feature bigger. I can naively imagine expanding on the initialization checks for constructors to try to allow this:

class Foo implements FooStates {
  status: 'importing' | 'imported' = 'importing';
  value: undefined | string;

  constructor(status: 'importing', value: undefined);
  constructor(status: 'imported', value: string);
  constructor(status: 'importing' | 'imported', value: string | undefined) {
    this.status = status;
    this.value = value;
  }
}

And error for this:

  constructor(status: 'importing', value: undefined);
  constructor(status: 'imported', value: string);
  constructor(status: 'importing' | 'imported', value: string | undefined) {
    this.status = status;
    this.value = value ?? ''; // Error
  }

I don't know, that admittedly might be too big of a lift. You'd have to track not just that a field was initialized, but the type it was initialized to. But at least you have a block in which to do that check, and precedence that certain conditional logic or delegating to functions doesn't contribute to the analysis.

And a maybe crazy idea is if constructors could be checked this way, maybe that opens the door to check other blocks this way and that could solve for mutating objects that must conform to a union type. Like some annotation that says at the end of a block a variable must satisfy a type.