What is preventing me from using property null checking to narrow down types?

Question

What is preventing me from using property null checking to narrow down types?

Why does TypeScript give an error when using property checking to narrow the type like this?

function test2(value:{a:number}|{b:number}){
    // `.a` underlined with: "Property a does not exist on type {b:number}"
    if(value.a != null){
        console.log('value of a:',value.a)
    }
}

test2({a:1})

test2({b:2})

The transpilation is successful, it functions correctly, and there are no runtime errors. The property check logically restricts the scope to {a:number}.

So what's the issue here? Is there a configuration I can modify in order to allow and use this method for type narrowing?

Someone might suggest using the in operator. However, I am aware that I could use the in operator, but I prefer not to. If I include a string in the union type as well, then I cannot use in with a string directly. I would need to first check that it's not a string with if(typeof value != 'string'). In regular JavaScript, I could simply rely on my property check and be confident that any value retrieved will have the property, ensuring everything works smoothly.

Therefore, why does TypeScript struggle with this scenario? Is it simply not intelligent enough to handle it?

(Changes: Originally, this question involved optional chaining to check for properties due to the type being unioned with null. To simplify, I've removed both the null and the optional chain operator from the if statement.)

typescript

Answer 1

Answer №1

What is the issue with TypeScript in this scenario?

It meticulously indicates that your code is attempting to access a property that has not been declared to exist on the object. If it were not a union type, you would naturally anticipate receiving this error message. Just because the code does not result in a runtime error does not mean that it is valid TypeScript. Reference link here.

If you are determined to access the property for discriminating the union, you must declare it on all type constituents - even if you specify it to have no value on the others:

function test2(value: { a: number; b?: never } | { b: number; a?: never }){
    if(value.a != null) {
        console.log('value of a:', value.a)
    }
}

test2({a:1})
test2({b:2})

Answer 2

What is the issue with TypeScript in this scenario?

It meticulously indicates that your code is attempting to access a property that has not been declared to exist on the object. If it were not a union type, you would naturally anticipate receiving this error message. Just because the code does not result in a runtime error does not mean that it is valid TypeScript. Reference link here.

If you are determined to access the property for discriminating the union, you must declare it on all type constituents - even if you specify it to have no value on the others:

function test2(value: { a: number; b?: never } | { b: number; a?: never }){
    if(value.a != null) {
        console.log('value of a:', value.a)
    }
}

test2({a:1})
test2({b:2})

Answer 3

Answer №2

If you're looking for a more detailed approach that avoids repeating properties for each type, consider using a type predicator. This function checks the object passed to it and determines if it fits the criteria for the desired type.

type A = {
  a: number;
};

type B = {
  b: number;
};

function isA(arg: unknown): arg is A {
  return !!arg && typeof arg === "object" && "a" in arg;
}

function isB(arg: unknown): arg is B {
  return !!arg && typeof arg === "object" && "b" in arg;
}

function test2(value: A | B) {
  if (isA(value)) {
    console.log("value of a:", value.a);
  }
  if (isB(value)) {
    console.log("Vale of b:", value.b);
  }
}

test2({ a: 1 });
test2({ b: 2 });

isA and isB are predicators that inform TypeScript about the type checks performed. While predicators are not foolproof and can be misleading by returning true when they shouldn't, they are useful for handling unique types with similar properties.

Check out this demo on Typescript playground: https://tsplay.dev/WJ0KZN. Also, read more about type predicates in the TypeScript documentation here: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates

Answer 4

If you're looking for a more detailed approach that avoids repeating properties for each type, consider using a type predicator. This function checks the object passed to it and determines if it fits the criteria for the desired type.

type A = {
  a: number;
};

type B = {
  b: number;
};

function isA(arg: unknown): arg is A {
  return !!arg && typeof arg === "object" && "a" in arg;
}

function isB(arg: unknown): arg is B {
  return !!arg && typeof arg === "object" && "b" in arg;
}

function test2(value: A | B) {
  if (isA(value)) {
    console.log("value of a:", value.a);
  }
  if (isB(value)) {
    console.log("Vale of b:", value.b);
  }
}

test2({ a: 1 });
test2({ b: 2 });

isA and isB are predicators that inform TypeScript about the type checks performed. While predicators are not foolproof and can be misleading by returning true when they shouldn't, they are useful for handling unique types with similar properties.

Check out this demo on Typescript playground: https://tsplay.dev/WJ0KZN. Also, read more about type predicates in the TypeScript documentation here: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates

Answer 5

Answer №3

The discriminated union pattern could have been beneficial in this scenario. By including a field with a unique value in each interface, it becomes possible to differentiate the correct type when used in a union context.

For instance:

type NetworkLoadingState = {
  state: "loading";
};
type NetworkFailedState = {
  state: "failed";
  code: number;
};
type NetworkSuccessState = {
  state: "success";
  response: {
    title: string;
    duration: number;
    summary: string;
  };
};

type NetworkState =
  | NetworkLoadingState
  | NetworkFailedState
  | NetworkSuccessState;

function onNetworkStateChanged(network: NetworkState) {
  switch (network.state) {
    case "loading":
      console.log("Loading state...")
      break;
    case "failed":
      console.log("Network failed to load. Error code:", network.code);
      break;
    case "success":
      console.log(`Network is connected! Time taken: ${network.response.duration / 1000} seconds`);
      break;
  }
}

Playground link

Answer 6

The discriminated union pattern could have been beneficial in this scenario. By including a field with a unique value in each interface, it becomes possible to differentiate the correct type when used in a union context.

For instance:

type NetworkLoadingState = {
  state: "loading";
};
type NetworkFailedState = {
  state: "failed";
  code: number;
};
type NetworkSuccessState = {
  state: "success";
  response: {
    title: string;
    duration: number;
    summary: string;
  };
};

type NetworkState =
  | NetworkLoadingState
  | NetworkFailedState
  | NetworkSuccessState;

function onNetworkStateChanged(network: NetworkState) {
  switch (network.state) {
    case "loading":
      console.log("Loading state...")
      break;
    case "failed":
      console.log("Network failed to load. Error code:", network.code);
      break;
    case "success":
      console.log(`Network is connected! Time taken: ${network.response.duration / 1000} seconds`);
      break;
  }
}

Playground link

What is preventing me from using property null checking to narrow down types?

Answer №1

Answer №2

Answer №3

Similar questions

Experiencing 429 Too Many Requests error on Angular 7 while attempting to perform multiple file uploads

Encountering a situation where the data retrieved from Firestore in Angular TypeScript is returning as

Leverage server-side data processing capabilities in NuxtJS

How can a TypeScript function be used to retrieve a string (or JSON object)?

Why is it that the Jasmine test is unsuccessful even though the 'expected' and 'toBe' strings appear to be identical?

Utilize the power of relative import by including the complete filename

Issue encountered: Unable to access the property 'loadChildren' as it is undefined, while attempting to configure the path

Enhance your MaterialUI Button with a higher order component that accepts a component

What could be the reason behind Typescript's unexpected behavior when handling the severity prop in Material UI Alerts?

Understanding the differences between paths and parameters of routes in express.js

Creating an object efficiently by defining a pattern

Having trouble compiling a Vue.js application with TypeScript project references?

Encountering an error message that says "ERROR TypeError: Cannot read property 'createComponent' of undefined" while trying to implement dynamic components in Angular 2

Utilizing TypeScript to reference keys from one interface within another interface

In TypeScript, both 'module' and 'define' are nowhere to be found

What is the syntax for using typeof with anonymous types in TypeScript?

TypeScript will show an error message if it attempts to return a value and instead throws an

Tips for minimizing disagreements while implementing optional generic kind in TypeScript?

Convert JSON data into an array of strings that are related to each other

Trigger a dispatched action within an NGRX selector