Why does TypeScript not complain about properties not included in the state when casting?

Question

Why does TypeScript behave the way it does in my case?

If I directly type an object, it complains about properties which are not defined in the interface. But if I cast the object it allows do add any random properties not defined in the interface.

Best explained with an example:

interface House {
  windows: number;
  garden: boolean;
}

const house1: House = {
  windows: 5,
  garden: true,
  garage: true // not allowed
};

const whatever = {
  house2: <House> {
    windows: 3,
    garden: true,
    garage: true // why is it here allowed?
  }
};

Related: https://stackoverflow.com/questions/32167593/how-to-do-runtime-type-casting-in-typescript — k0pernikus, Jun 27 '19 at 15:25

Murat Karagöz · Accepted Answer · 2019-06-27T12:47:29.700

3

It works because it is a Type Assertion. Basically telling the compiler what type it is but not guarding it e.g.

const house1 = <House> {
  windows: 5,
  garden: true,
  garage: true // allowed
};

Basically you tell the ts-compiler to not perform special checking or restructuring of data.

You would type guard it with the appropriate type for the properties e.g.

const whatever: { house2: House } = {
    house2: {
        windows: 3,
        garden: true,
        garage: true // not allowed
    }
};

edited Jun 27 '19 at 12:47

answered Jun 27 '19 at 12:26

Murat Karagöz

35,401
16
78
107

Could you please make the distinction between "type casting" and "type assertions" more clear? – k0pernikus Jun 27 '19 at 12:34
@k0pernikus There is no "type casting", there is not much difference between both terms. Typescript called it "type assertion" since it sounds more like the language framework. Other than that, "casting" implies that there might be a run time support in other languages, but in Typescript it is purely at compile time. – Murat Karagöz Jun 27 '19 at 12:39
Ok, and is there a way to cast it, that it’s not only telling the compiler what type it is, but also guards it? – mnewmedia Jun 27 '19 at 12:42
@mnewmedia Added. – Murat Karagöz Jun 27 '19 at 12:47
Ok, got it. But since in real-life app the house2 is wrapped by an object(whatever) which is in an array. And sometimes it’s a different type than a House. So the way it behaves makes it now, much more complicated than it could be. – mnewmedia Jun 27 '19 at 12:57
@mnewmedia Yes, it is more time consuming to have type safety, but it is still better than none. – Murat Karagöz Jun 27 '19 at 13:03
@MuratKaragöz I know. And you know. I am saying your answer would benefit from making that fact abundantly clear, so it becomes clear to newbies to TypeScript as well. You could quote your link where it states: "A type assertion is like a type cast in other languages, but performs no special checking or restructuring of data. It has no runtime impact, and is used purely by the compiler. TypeScript assumes that you, the programmer, have performed any special checks that you need." – k0pernikus Jun 27 '19 at 15:19
@k0pernikus It is actually already hyper linked in the answer. – Murat Karagöz Jun 27 '19 at 15:28
As stated in the [how to answer help](https://stackoverflow.com/help/how-to-answer): "Always quote the most relevant part of an important link, in case the target site is unreachable or goes permanently offline." – k0pernikus Jun 27 '19 at 15:37

Why does TypeScript not complain about properties not included in the state when casting?

1 Answers1