TypeScript Version: 3.6.3, 3.7.0-beta
Search Terms: inference, wrong, type parameter
Code
interface Instance {
test: string
}
type DataDef<Data, Props> = Data | ((this: Readonly<Props> & Instance) => Data)
export type ThisTypedComponentOptionsWithArrayProps<Data, PropNames extends string> =
object &
ComponentOptions<DataDef<Data, Record<PropNames, any>>, PropNames[]> &
ThisType<Instance & Data & Readonly<Record<PropNames, any>>>;
type DefaultData<V> = object | ((this: V) => object);
type DefaultProps = Record<string, any>;
export interface ComponentOptions<Data = DefaultData<Instance>, PropsDef = PropsDefinition<DefaultProps>> {
props?: PropsDef;
data?: Data;
watch?: Record<string, WatchHandler<any>>;
}
export type ArrayPropsDefinition<T> = (keyof T)[];
export type PropsDefinition<T> = ArrayPropsDefinition<T>;
export type WatchHandler<T> = (val: T, oldVal: T) => void;
declare function test<Data, PropNames extends string = never>(options?: ThisTypedComponentOptionsWithArrayProps<Data, PropNames>): void;
declare function test(options?: never): void
test({
data () {
return {
foo: true
}
},
watch: {
testWatch (value: boolean) {
this.test // any
}
}
})
Expected behavior:
this.test in testWatch is of type string.
Actual behavior:
this.test in testWatch is of type any.
Looks like Instance keys are used as PropNames and they override actual instance type.
Note that if I do either following things, it behaves as expected:
- Remove
value´s type annotation.
- Do not annotate
this type of DataDef callback.
- Do not use overload for
test function.
Playground Link:
http://www.typescriptlang.org/play/#code/JYOwLgpgTgZghgYwgAgJIgM5jiJyDeAUMspFgFzJZSgDmhAvoYWAJ4AOKAInNlxDAA8PbABpkABSgB7dhgB8yALzIRcZAB9kACm1gAFsAyUAShDgATaSAA2rQVNkLkAMjSZsuCAEplitd7MEAAe7NJQYKQcKAAqhhgx0RYAwtIAtmEgEOAA8uxgwNYYAOrABgCCUFBwrI5ywrxw4nUAcnBpEBjIIZAgFl3UdIpKxMjSAEYAVhAIkS6jqRnW2WB5BUUNfAKbTchmCOEWDjLsbR0Y4jis8vLNJ2edANoAuorzJHFGiZyC6Fg4eDcalce3MVls9n2h2OsgeF2QVxu8gA3Mw2JxVAI4ABXGxgNSCABqwxIE2ms00Oj08UohN8SkUZJmYG8qPR3CxuLAdS6KihUCOgxAtEuIGuqJCYQiyFAkFgiBQi0yKzWhUwO2UmPgXIJf08SFukhOGH4ME1PNNoDKauEnLxPJuBFG7GNAH5KBaBKiSBZGu7VI1vcgAO68BD6f38wVgGjC8TFMP6AASOAsNmggkRKMYQVC4Ui7OQlWqtWNlpA1usghiJO0AGsIKxpGaYt4XhK89LC56YFb1iBqyTizUe32bTXUYRJfmohiE2Bwym+umoIPNdoAG5wGyUGLiaQ2CyE7e7+mKDfSYAWScWGY2OBQFAwbG4fukTpgHZ3WHtTrdYK9P0VAxnQmpZBu0DyNosj9hg-qfAkSRKssuT5GqJRlPow6lk4X5Gj+5zyN4lAXleqK3gg96Psgz6vmq75YNBaFFP64HQMRyCkRYaIftoRA+o0Oi+PxJDII+YDYlAIBOqJokwNI0iUDG2IQKMJBMOpoijKGC76JQIkkGQYDzuGOhbjYKmUOMCnpjgwlqaJBhGAAdEZyAAPTuQiYoORpyBMAwgTMEAA
Related Issues:
This is quite similar issue with #33164 but different as it can reproduce on v3.6.3 which the issue is already fixed.
TypeScript Version: 3.6.3, 3.7.0-beta
Search Terms: inference, wrong, type parameter
Code
Expected behavior:
this.testintestWatchis of typestring.Actual behavior:
this.testintestWatchis of typeany.Looks like
Instancekeys are used asPropNamesand they override actual instance type.Note that if I do either following things, it behaves as expected:
value´s type annotation.thistype ofDataDefcallback.testfunction.Playground Link:
http://www.typescriptlang.org/play/#code/JYOwLgpgTgZghgYwgAgJIgM5jiJyDeAUMspFgFzJZSgDmhAvoYWAJ4AOKAInNlxDAA8PbABpkABSgB7dhgB8yALzIRcZAB9kACm1gAFsAyUAShDgATaSAA2rQVNkLkAMjSZsuCAEplitd7MEAAe7NJQYKQcKAAqhhgx0RYAwtIAtmEgEOAA8uxgwNYYAOrABgCCUFBwrI5ywrxw4nUAcnBpEBjIIZAgFl3UdIpKxMjSAEYAVhAIkS6jqRnW2WB5BUUNfAKbTchmCOEWDjLsbR0Y4jis8vLNJ2edANoAuorzJHFGiZyC6Fg4eDcalce3MVls9n2h2OsgeF2QVxu8gA3Mw2JxVAI4ABXGxgNSCABqwxIE2ms00Oj08UohN8SkUZJmYG8qPR3CxuLAdS6KihUCOgxAtEuIGuqJCYQiyFAkFgiBQi0yKzWhUwO2UmPgXIJf08SFukhOGH4ME1PNNoDKauEnLxPJuBFG7GNAH5KBaBKiSBZGu7VI1vcgAO68BD6f38wVgGjC8TFMP6AASOAsNmggkRKMYQVC4Ui7OQlWqtWNlpA1usghiJO0AGsIKxpGaYt4XhK89LC56YFb1iBqyTizUe32bTXUYRJfmohiE2Bwym+umoIPNdoAG5wGyUGLiaQ2CyE7e7+mKDfSYAWScWGY2OBQFAwbG4fukTpgHZ3WHtTrdYK9P0VAxnQmpZBu0DyNosj9hg-qfAkSRKssuT5GqJRlPow6lk4X5Gj+5zyN4lAXleqK3gg96Psgz6vmq75YNBaFFP64HQMRyCkRYaIftoRA+o0Oi+PxJDII+YDYlAIBOqJokwNI0iUDG2IQKMJBMOpoijKGC76JQIkkGQYDzuGOhbjYKmUOMCnpjgwlqaJBhGAAdEZyAAPTuQiYoORpyBMAwgTMEAA
Related Issues:
This is quite similar issue with #33164 but different as it can reproduce on v3.6.3 which the issue is already fixed.