Accessing property in union of object types fails for properties not defined on all union members

TypeScript Version: 2.1.1

Code

type A = { a: string; } 
type B = { b: string; }
type AorB = A | B;

declare const AorB: AorB;

if (AorB.a) {
    // use AorB.a
}

Expected behavior:
The code compiles without errors. Even though a doesn't (necessarily) exist on all the constituents of the union, the fact that it exists on some should allow me to check for .a and use it if it is present.

Actual behavior:
Typescript complains: "Property a does not exist on type AorB... Property a does not exist on type B."

The doc says :

To get the same code working, we’ll need to use a type assertion:

let pet = getSmallPet();

if ((<Fish>pet).swim) {
    (<Fish>pet).swim();
}
else {
    (<Bird>pet).fly();
}

http://www.typescriptlang.org/docs/handbook/advanced-types.html

Then in your sample:

if ((<A>AorB).a) {
    // use AorB.a
}

The issue here is that because B doesn't declare an a property, it might at run-time have an a property of any possible type (because you can assign an object with any set of properties to a B as long as it has a b property of type string). You can make it work explicitly declaring an a: undefined property in B (thus ensuring that B won't have some random a property):

type A = { a: string; } 
type B = { b: string; a: undefined }
type AorB = A | B;

declare const AorB: AorB;

if (AorB.a) {
    // Ok
}

Makes perfect sense. Brain fart.

If you define a: undefined on type B, you'll have to set it to undefined when you create/pass a variable.
To get around that, you can declare a as a?: undefined, and typescript will be happy if you omit it.

If I understand the comments correctly, this should work (but throws; tested on playground): Is this a bug or not? 🤔

type LinkProps = {
    to: string;
    onClick?: undefined;
    // Link specific props:
    target: string;
}

type ButtonProps = {
    to?: undefined;
    onClick: Function;
    // Button specific props:
    disabled: boolean;
}

type ActionProps = LinkProps | ButtonProps;

const Action = (props: ActionProps) =>
    props.to ?
        'Link with target: ' + props.target // Error not on ButtonProps
    :
        'Button with disabled: ' + props.disabled; // Error: not on LinkProps

Action({
  to: 'dssd',
  target: '_blank'
});

I don't understand this at all. Isn't if ((<A>AorB).a) the same as using if (A.a) because you're forcing it back to type A?

If you define a: undefined on type B, you'll have to set it to undefined when you create/pass a variable.
To get around that, you can declare a as a?: undefined, and typescript will be happy if you omit it.

might be better a?: never, now you can not assign undefined by mistake

What if you don't give a name to each of the members of the union? (can't make a type assertion as above without a name for the asserted type, can I?)

type u = "str" | {prop:"val"};
function f(arg:u){return arg.prop} // TypeScript: Property 'prop' does not exist on type 'u'

Any solution?

i find a solution on book :

interface A { x:  number;} 
interface B { y:  string;}
function doStuff ( q: A | B ) {
  if ( 'x'  in q) {
    //  if type A...
  }
  else {
    // if type B...
  }
}

Excerpt From: Basarat Ali Syed. “TypeScript Deep Dive.” Apple Books.

a property on an object and can be used as a type guard, and the TypeScript can know which type you used.

The issue here is that because B doesn't declare an a property, it might at run-time have an a property of any possible type (because you can assign an object with any set of properties to a B as long as it has a b property of type string). You can make it work explicitly declaring an a: undefined property in B (thus ensuring that B won't have some random a property):
type A = { a: string; } 
type B = { b: string; a: undefined }
type AorB = A | B;

declare const AorB: AorB;

if (AorB.a) {
    // Ok
}

Does not work for me 07.10.2020

And I think that this behavior of TS is not good because it does not help a developer much...

"The issue here is that because B doesn't declare an a property, it might at run-time have an a property of any possible type" (Accessing property in union of object types fails for properties not defined on all union members #12815 (comment))
At the same time, 'a' in AorB is supported as a type guard (Accessing property in union of object types fails for properties not defined on all union members #12815 (comment))
🤔🤔🤔

Georgii Dolzhykov (@thorn0)

Georgii Dolzhykov (@thorn0) yes, because if you write code like

if (a.foo) {

you might be thinking you're testing for the non-zeroness of foo in one branch of the union, but hitting a plain object through an aliased value in another branch. There's no ambiguity what you're trying to do with "foo" in a.

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) Thanks for the answer, but I'm having trouble understanding it. Could you put it another way please?

upd: Turns out there is an open issue for this: #1260. But I still don't understand your point about ambiguity. if ("foo" in a) is clearly as unsound as if (a.foo).

Navigation Menu

Repository navigation

Accessing property in union of object types fails for properties not defined on all union members #12815

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Accessing property in union of object types fails for properties not defined on all union members #12815

Description

Activity

akarzazi commented on Dec 10, 2016

ahejlsberg commented on Dec 10, 2016

ethanresnick commented on Dec 12, 2016

ocombe commented on Mar 14, 2018

donaldpipowitch commented on May 30, 2018

paddotk commented on Jul 30, 2018

artola commented on Jun 29, 2019

escKeyStroke commented on Aug 30, 2019

mookilyu commented on Dec 24, 2019

xxzhong21330 commented on Dec 26, 2019

cartok commented on Oct 7, 2020

thorn0 commented on Jan 14, 2021

RyanCavanaugh commented on Jan 14, 2021

thorn0 commented on Jan 14, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions