Resolve type structure with optional properties

[fudom]

🔍 Search Terms

Resolve type structure with optional properties. Allow optional properties for inferred types. I can't find a better title right now. Sorry if this is a dup.

✅ 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 wonder why only intersections are available in type when TypeScript resolves types automatically. Means, only the properties which exists in ALL objects are available. Optional properties not. I would expect that properties which only exist in some objects are also available as optional property, but well typed. Like {all: number, opt?: number}.

Code is worth 1000 words:

interface ValueType {
    a: number;
    b?: number;
    c?: number;
}

const myObject = {
    one: { a: 10 },
    two: { a: 10, b: 20 },
    three: { a: 10, c: 30 },
} satisfies Record<string, ValueType>;

for (const value of Object.values(myObject)) {
    // Problem here: Only 'a' is in suggestions.
    if (value.a) {} // works
    if (value.b) {} // error
    if (value.c) {} // error
    // Workaround would be `if ('c' in value)` but this is not the point.
    // Another workaround is to give the generic type an interface type.
}

// I wonder why, are the optional types not available? It makes no sense because TypeScript can handle optional type.
// I want to use all possible properties. Optional nullish values can be catched by type-guards like if-condition.
// I would expect that TypeScript resolves the values similar like my custom type `ValueType`.

📃 Motivating Example

Make code life easier...

Playground

💻 Use Cases

Background: I could create the interface. But I don't write the key names again and again. Just create my object with defined value types. I could use Record<string, ...> but this would blur the key structure. I want the type as the object is created. This is the my path to the issue. But maybe only one case.

Note: The interface ValueType and satisfies or any other is not required and only one case. This is not the point of this issue. The core is: Why are the optional keys not in the inferred type? I see no reason why not, since optional properties are a legit part of a type.

Or is this a bug? I doubt. But if it's intentional, I don't understand why.

[Renegade334]

The satisfies clause in your example has no effect on the inferred type of myObject, it just validates that the left-hand side is assignable to the right-hand side.

Your example is equivalent to:

const myObject = {
    one: { a: 10 },
    two: { a: 10, b: 20 },
    three: { a: 10, c: 30 },
};

for (const value of Object.values(myObject)) {
    if (value.a) {}
    if (value.b) {} // error
    if (value.c) {} // error
}

which is the behaviour that you'd expect. Your example seems to assume that satisfies would change the inference of myObject's type to something like

{
  a: number;
  b?: number;
  c?: number;
} | {
  a: number;
  b: number;
  c?: number;
} | {
  a: number;
  b?: number;
  c: number;
}

but that just isn't the way that satisfies works.

[snarbles2]

I took the suggestion to mean a type such as {a: number} | {a: number, b: number} should be treated as equivalent to, or at least treated more similarly to, {a: number, b? number}

[MartinJohns]

a type such as {a: number} | {a: number, b: number} should be treated as equivalent to, or at least treated more similarly to, {a: number, b? number}

This has been rejected over and over again for good reasons. Types are not sealed. The value behind the type { a: number } may have a property b.

[snarbles2]

The value behind the type { a: number } may have a property b.

And it might not even be a number

Probably a duplicate of #49933. An example of where this is unsound is found at #49933 (comment).

[fudom]

It's not about satisfies. I know how it works. This is just in my example to demonstrate a use case. Sorry for confusion. Btw. english is not my main language.

I also have the feeling that this issue has probably been discussed before. But I couldn't find anything and wanted to present my case.

To break it down, I expected this:

const myObject = {
  one: { a: 10 },
  two: { a: 10, b: 20 },
  three: { a: 10, c: 30 },
}

to be resolved as type:

interface ValueType {
    a: number;
    b?: number;
    c?: number;
}

Because a exist in all entries, and b and c not in all.

But as I wanted to iterate though the values ...

for (const value of Object.values(myObject)) {
    if (value.a) {} // works
    if (value.b) {} // error
    if (value.c) {} // error
}

... it seems to be the type:

interface ValueType {
    a: number;
}

That's all. I don't get why. Maybe there is a strong reason for. But it feels like a bug or missed coverage.

Playground

Or actually the type is:

const value: {
    a: number;
} | {
    a: number;
    b: number;
} | {
    a: number;
    c: number;
}

But why do I get only the a? It's not true. I seems that only the first entry is used. Not sure if this can be safety chanced. At the moment, this doesn't make sense to me.

Even if the a would have different types, I would expact a union. E.g.

const myObject = {
  one: { a: 10 },
  two: { a: 'lol', b: 20 },
  three: { a: 10, c: 30 },
}

interface ValueType {
    a: number | string;
    b?: number;
    c?: number;
}

[Renegade334]

Sorry for not being on the same wavelength. I believe #42775 was asking pretty much the same question, so the explanations there should apply?

[fudom]

Okay, if you think the current behavior is correct and exactly what's desired, and won't provide any benefit, I'll accept that. Even if I don't fully understand the reason yet. 🤔

Maybe someone can explain it to me using colorful hand puppets 👻 if you want? JK, but I'm really confused at this moment. 🤯 Why do you think, that this is not good? Is it just a belief or does it have a technical and logical reason?

Perhaps this can be achieved with a utility type (own or official)? But anyway, workaround is using 'key' in obj (in if-conditions, but which is less safe as optional type) or type cast like this:

interface ValueType {
  a: number | string;
  b?: number;
  c?: number;
}

const myObject = {
  one: { a: 10 },
  two: { a: ':)', b: 20 },
  three: { a: 10, c: 30 },
} satisfies Record<string, ValueType>;

for (const value of Object.values(myObject) as ValueType[]) {
  if (value.a) {} // ok (optional check for type too)
  if (value.b) {} // ok
  if (value.c) {} // ok
}

Playground

Just if someone wondering why I don't set the type Record<string, ValueType> at Definition: It's because string makes the key structure generic (blurry). That means no autocomplete suggestions and a bit unsafe as runtime. The best way would be to define a well interface with all key names you have. But then you have to write anything twice, which is sometimes overkill and making you very very 🥱 ... I think this idea comes from the approach of reducing type declaration and letting TypeScript do the work instead. At least for some cases like creating map objects quickly, etc.

For me it's fine if you close this issue if you think the current behavior is what you want.

[snarbles2]

Is it just a belief or does it have a technical and logical reason?

Going back to your original code, the type of value in the for loop is:

{
    a: number
} | {
    a: number,
    b: number
} | {
    a: number,
    c: number
}

See if this logic makes sense to you.

• {a: 10, b: "ten"} satisfies {a: number}
• {a: number} satisfies {a: number} | {a: number, b: number} | {a: number, c: number}
• So... {a: 10, b: "ten"} satisfies {a: number} | {a: number, b: number} | {a: number, c: number}
• Therefore, we can't conclude that b, if it exists, is a number

If you wanted to collapse the union, it would more properly reduce to:

{
    a: number;
    b?: unknown;
    c?: unknown;
}

[fudom]

Thanks for that example. But I don't think that's the case. At first I thought this made sense because I was ignoring the case where other objects might be checked for these union types. But will this really happen? And your list of satisfies are not correct.

Your assumption that the following will is satisfies is wrong:

{ a: 10, b: 'ten' } satisfies { a: number } | { a: number, b: number } | { a: number, c: number } ▶ Test

Error: Type 'string' is not assignable to type 'number'.(2322)

If I would create that object in my definition, the untion type would have a string as type.

const myObject = {
  one: { a: 10 },
  two: { a: 10, b: 'ten', c: 'another' },
  three: { a: 10, c: 30 },
}

// Results to type:
{
    a: number;
} | {
    a: number;
    b: string;
    c: string;
} | {
    a: number;
    c: number;
}

Logically, my expected type would result:

{
  a: number; // Exists in all variants as number.
  b?: string; // Exists in some variants as string.
  c?: string | number; // Exists in some variants as string or number.
}

In both type cases (actual and mine), the property b can never be a number, when only string was defined. And other objects that where not infered from this definition type, will not work unless, you cast to it or satisfies the type. But I hope I made a (thinking) mistake. 🤯 I would also happy if you correct me. Maybe that was a misunderstanding? It might be better to verify this in the Playground first.

▶ Play with this demo

// Actual TypeScript behavior compared to my expected behavior.

type ValueTypeTypeScript = (typeof myObject)[keyof typeof myObject];
type ValueTypeMine = {
  a: number; 
  b?: string;
  c?: string | number; 
}

// TypeScript actual behavior
for (const value of Object.values(testObject1) as ValueTypeTypeScript[]) {
  if (value.a) { } // ok
  if (value.b) { } // error
  if (value.c) { } // error
}

// My expected behavior
for (const value of Object.values(testObject2) as ValueTypeMine[]) {
  if (value.a) { } // ok
  if (value.b) { } // ok
  if (value.c) { } // ok
}

If there is no mistake, please let me know what might be wrong with this expectation. I mean, a decision is a decision. And I tolerate it. But I wonder if my expectation would cause ts to break.

[snarbles2]

Your assumption that the following will is satisfies is wrong

Simple code samples like your OP make it seem like "b can obviously only be number", but in real code things are often affected by something one step or more removed.

const exampleA = {a: 10, b: "ten"};
const exampleB = exampleA satisfies {a: number};
const exampleC = exampleB satisfies 
    {
        a: number
    } | {
        a: number,
        b: number
    } | {
        a: number,
        c: number
    };

Or, alternatively:

type Example = {
    a: number
} | {
    a: number,
    b: number
} | {
    a: number,
    c: number
}

function chaos(value: {a: number, b?: string}) {
    value.b = "oops";
}

function whatIsB(value: Example) {
    // logs "oops", which is certainly not a number
    console.log((value as any).b); 
}

const stringB = {a: 0};
chaos(stringB);
whatIsB(stringB);

The bottom line is in typescript types don't tell you anything about what isn't there. In your union, you have two constituents that don't mention .b.

type Example = 
  { a: number }           // b could be nothing or anything  
| { a: number, b: number} // b is a number
| { a: number, c: number} // b could be nothing or anything  

[typescript-bot]

This issue has been marked as "Question" and has seen no recent activity. It has been automatically closed for house-keeping purposes.