What could be the rationale behind the optional chaining operator not being fully compatible with a union of classes in TypeScript?

Question

What could be the rationale behind the optional chaining operator not being fully compatible with a union of classes in TypeScript?

Imagine I have a combination of classes:

type X = ClassA | ClassB | ClassC;

Both ClassA and ClassC have a shared method called methodY.

Why is it that I can't simply use the optional chaining operator to call for methodY?

class ClassA {
    methodY() {
        return 'a';
    }
}
class ClassB {}
class ClassC {
    methodY() {
        return 'c';
    }
}
type X = ClassA | ClassB | ClassC;

function getMethodY(x: X) {
    return x.methodY?.(); // Error: Property 'methodY' does not exist on type 'ClassB'.
}

Instead, I find myself having to use these patterns:

methodY in doc && doc.methodY()

or

if (methodY in doc) doc.methodY()

, which seem very similar to the optional chaining operator. Why is there a difference between checking for methodY in doc versus using the operator directly?

What design reasons justify why the check for methodY in doc should be treated differently than using the operator itself?

typescript

Answer 1

Answer №1

There are numerous discussions surrounding this topic, including related issues:

Debating whether properties in any members of Union should be Optional (or | undefined) · Issue #42775 · microsoft/TypeScript
Exploring how property in subset of branches of a union type should be accessible for checking against undefined and narrowing object types · Issue #49933 · microsoft/TypeScript.

Illustrating an example:

type Message =
  { kind: "close" } |
  { kind: "data", payload: object }

function handle(m: Message) {
  switch (m.kind) {
    case "close":
      console.log("closing!");
      // mistakenly omitted 'break;' here
    case "data":
      updateBankAccount(m.payload);
  }
}

This scenario showcases how using "type does not exist" can assist in identifying inadvertently used properties. If accepting undefined values at the point of use, simply treating it as undefined may fail to detect the error.

Additionally, there could be instances where one might unintentionally employ if (a.length) instead of verifying with if ('length' in a).

To sum up, while both the current in operator narrowing and the yet-to-be-implemented undefined check narrowing may exhibit unsound behavior in certain cases, the former is more explicit and likely to result in fewer errors in other contexts.

Answer 2

There are numerous discussions surrounding this topic, including related issues:

Debating whether properties in any members of Union should be Optional (or | undefined) · Issue #42775 · microsoft/TypeScript
Exploring how property in subset of branches of a union type should be accessible for checking against undefined and narrowing object types · Issue #49933 · microsoft/TypeScript.

Illustrating an example:

type Message =
  { kind: "close" } |
  { kind: "data", payload: object }

function handle(m: Message) {
  switch (m.kind) {
    case "close":
      console.log("closing!");
      // mistakenly omitted 'break;' here
    case "data":
      updateBankAccount(m.payload);
  }
}

This scenario showcases how using "type does not exist" can assist in identifying inadvertently used properties. If accepting undefined values at the point of use, simply treating it as undefined may fail to detect the error.

Additionally, there could be instances where one might unintentionally employ if (a.length) instead of verifying with if ('length' in a).

To sum up, while both the current in operator narrowing and the yet-to-be-implemented undefined check narrowing may exhibit unsound behavior in certain cases, the former is more explicit and likely to result in fewer errors in other contexts.

Answer 3

Answer №2

Unfortunately, I don't have insights into the design rationale. However, a possible solution to eliminate the error without adding guards around the method in the function is to create an abstract class that defines the method.

abstract class ClassP{
    methodY?():void
}

class ClassA extends ClassP{
    methodY() {
        return 'a';
    }
}
class ClassB extends ClassP {}
class ClassC extends ClassP {
    methodY() {
        return 'c';
    }
}
type X = ClassA | ClassB | ClassC;

function getMethodY(x: X) {
    return x.methodY?.();
}

For more details, you can check out the provided link.

It would certainly be convenient if the optional chaining operator could handle this scenario automatically.

Answer 4

Unfortunately, I don't have insights into the design rationale. However, a possible solution to eliminate the error without adding guards around the method in the function is to create an abstract class that defines the method.

abstract class ClassP{
    methodY?():void
}

class ClassA extends ClassP{
    methodY() {
        return 'a';
    }
}
class ClassB extends ClassP {}
class ClassC extends ClassP {
    methodY() {
        return 'c';
    }
}
type X = ClassA | ClassB | ClassC;

function getMethodY(x: X) {
    return x.methodY?.();
}

For more details, you can check out the provided link.

It would certainly be convenient if the optional chaining operator could handle this scenario automatically.

What could be the rationale behind the optional chaining operator not being fully compatible with a union of classes in TypeScript?

Answer №1

Answer №2

Similar questions

Utilizing the `in` operator for type narrowing is yielding unexpected results

Utilizing React and TypeScript: Passing Arguments to MouseEventHandler Type Event Handlers

What is the best way to obtain a reference to an instance of my Angular 2 directive?

Sign up for notifications about updates to a variable within an Angular service

execution of synchronized task does not finish

Exploring the concept of recursive method calls in TypeScript

Custom typings for Next-Auth profile

What is the reason behind having to press the Tab button twice for it to work?

Tips for successfully transferring a JsonifyObject<T> from Remix's useLoaderData<typeof loader> to a function

Is it possible to exclude a certain prop from a styled component that has emotions?

Connect the child content to the form

Incorporating numerous query parameters in Angular version 14

Issue with retrieving the positions of two numbers in an array

Strategies for evaluating a Promise-returning imported function in Jest

Angular 5 - Issue with Conditional Validator Functionality Being Ineffective

TypeScript compilation error caused by typing issues

Is there an easier method to utilize ES6's property shorthand when passing an object in TypeScript, without needing to prefix arguments with interface names?

Converting lengthy timestamp for year extraction in TypeScript

Get the file without specifying type in request - Angular

Ways to simulate objects in jest