in operator as type guard / narrowing for partial records and similar objects

[mfulton26]

🔍 Search Terms

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/in

✅ 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

I'd like to be able to check if a property is in an object and then access that property without needing a type cast.

📃 Motivating Example

given something like:

declare const props: Partial<Record<string, string>>;

I want to be able to access properties in it using in as a type guard:

const answer: string = "answer" in props ? props.answer : "42";

my current workaround is to cast:

const answer: string = "answer" in props ? props.answer as string : "42";

💻 Use Cases

1. What do you want to use this for? type guards/narrowing
2. What shortcomings exist with current approaches? I have to cast even though I think TypeScript should already be able to detect that the cast is unnecessary
3. What workarounds are you using in the meantime? manually cast

[snarbles2]

Looks like Partial is producing a type that is effectively {[key: string]: string | undefined}. I wasn't aware that Partial did that with index types, but I don't think I've ever combined the two.

Given that index signature, I don't think this is a type guard issue. As far as TS is concerned, the property exists, and its type is string | undefined. Typescript doesn't seem to support the encoding {[key: string]?: string} (not sure why), but that's probably what would be needed for the expected behavior with a type guard.

A workaround that involves less typing would be using a non-null assertion (!):

const answer: string = "answer" in props ? props.answer! : "42";

Non-null assertion is generally met with a negative reaction, but this is what it is for (for lack of a better solution at present).

[MartinJohns]

This is working as intended because this is legal:

const props: Partial<Record<string, string>> = { answer: undefined };

[jcalz]

This is effectively #46969; you would need to turn on --exactOptionalPropertyTypes for k in obj to rule out undefined for an optional property... but TS doesn't quite do the expected thing here.

[mfulton26]

So this works as I expected and yields no errors:

declare const props: { answer?: string };
const answer: string = "answer" in props ? props.answer : "42";

I had thought that Partial<> would work the same but it makes sense now that it does not and why.

Maybe I should close this issue then and open a new one requesting a way to specify an optional index signature. i.e. This is what I want to be able to write but isn't currently supported by TypeScript as @snarbles2 mentions:

declare const props: { [key: string]?: string };
const answer: string = "answer" in props ? props.answer : "42";

[snarbles2]

I think jcalz hit it on the head. --exactOptionalPropertyTypes seems to help, at least in the case of the example code.

declare const props: Partial<Record<string, string>>;
const answer = "answer" in props ? props.answer : "42";
// answer is inferred as `string`

[mfulton26]

Oh, that does work. I overlooked that but I just tried it and I can confirm. Thank you.

[mfulton26]

Hmmm… what I don't like about --exactOptionalPropertyTypes though is that it applies it to all interfaces and types whereas I want to do this in only a handful types. Is there a way to opt in for only specific cases rather than globally?

[MartinJohns]

Is there a way to opt in for only specific cases rather than globally?

No.

[RyanCavanaugh]

Agreed with jcalz, #46969 is the relevant issue here

[mfulton26]

closing this one in favor of #46969