Typings: Improve $slots and $scopedSlots type to prevent unchecked access to undefined

[thenickname]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

• It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
• All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
• New/updated tests are included

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

When working directly with render functions in TypeScript / tsx, currently the following code is unsafe and unchecked by the ts compiler:

this.$sopedSlots.default() // default can be undefined

The change in this PR makes TypeScript complain about the unsafe access accordingly and the code has to be expressed in a way that prevents calling an undefined function, e.g.:

( this.$scopedSlots.default || ( () => 'default value' ) )( props )

[ktsn]

Thank you for making this PR. However including undefined in the scoped slots value is actually inaccurate.

In the TypeScript, index signature is not guarantees whether the referenced key is exists. This is similar that an array type can be return undefined if accessing index of out of length.

const obj: Record<string, number> = { foo: 1, bar: 2 }
obj.baz // -> undefined

const arr: number[] = [1, 2, 3]
arr[5] // -> undefined

Some case that Including undefined is appropriate would be the case that key is exists but the value is undefined such as:

const obj: Record<string, number | undefined> = { foo: 1, bar: undefined }

Object.values() type would help you to understand these differences:

const a: Record<string, number | undefined> = { a: 1 }

// will be `(number | undefined)[]` even though `undefined` will be never appeared
const b = Object.values(a) 

[thenickname]

Hey, thank you for the quick reaction.

In the TypeScript, index signature is not guarantees whether the referenced key is exists.

Actually, I believe that it effectively does guarantee the following: It tells the TypeScript compiler that every possible key is permitted and (thats the important part) that all the values of the given object are guaranteed to have actual content of the type ScopedSlot.

Let me give you an example to hopefully better illustrate what is happening with the current type definition:

Let's first look at the current type definition for $scopedSlots:

interface Vue {
    readonly $scopedSlots: { [key: string]: ScopedSlot };
}

Now, in a vue component we try to call the default slot function:

this.$scopedSlots.default( props );

TypeScript won't complain about this code. But at runtime, default slot could be empty. The code above in that case will lead to a runtime error, because default is not a function and hence not callable.

Now if we tweak the type definition like that:

interface Vue {
    readonly $scopedSlots: { [key: string]: ScopedSlot | undefined };
}

This is what happens:

It says cannot invoke an object which is possibly undefined. And that is a good thing. It forces you to do a safety check before calling the function. For example like that:

<div>
    {this.$scopedSlots.default ?
        this.$scopedSlots.default( props ) :
        'Fallback content'
    }
</div>

So, to sum it up:

Right now the TypeScript compiler won't complain about slot access because of the current type defintition for $scopedSlots. Because the content that is referenced by the key is defined to always be a ScopedSlot, TypeScript will happily allow a function call even if no slot function is present. It does not account for the fact that at runtime a slot is not necessarily defined.

I hope this explanation better illustrates why I believe this PR is an improvement of the current typing.

[KaelWD]

Non-scoped slots can be undefined too.

[thenickname]

thanks for pointing that out! Will add that to this PR..

[ktsn]

I see your point. As scoped slot and slot optional, it may be better to have undefined value 🙂

I was thinking scoped slot and slot always there if the object key is exists but it was incorrect as they can be blank. Not sure how actual implementation is but it sounds good to have undefined in that case.

[KaelWD]

You missed the one in VNodeData, I've fixed it with #9131

[thenickname]

@KaelWD thanks