-
Notifications
You must be signed in to change notification settings - Fork 12.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent property type inference #49463
Comments
Simpler version: type Template = {
prop: number;
}
type SomeType<T> = {
[Property in keyof T]?: boolean;
} & { [s: string]: string };
// section A: no TS error
let something: SomeType<Template> = {};
something.prop = true;
something.anotherProp = 'value';
// section B: TS error
// Type '{ prop: true; anotherProp: string; }' is not assignable to type 'SomeType<Template>'.
// Property 'prop' is incompatible with index signature.
// Type 'boolean' is not assignable to type 'string'
something = {
prop: true,
anotherProp: 'value',
}; It seems like you're trying to emulate rest index signatures, which aren't really supported. See #7765. |
That's very, very sad because this sounds like a very useful feature when working with types. (at least in my use cases ^.-) So basically, in order to achieve this, I have to generate a separate file with type definitions from runtime information as relay does. Thank you very much though. |
The problem with “rest” properties is, given you have Note that you have to be very careful when using this pattern at runtime for the same reason - if your keys are dynamic (provided by the user, e.g.), you have to make sure they don’t overlap with the named ones. |
I am not saying
then there would be no problem to determine the type for property Edit: I wanted to make use of the (non-existing, because I didn't know it better) rest feature with recursion but recursion doesn't seem to work even if rest properties were supported. |
Well, |
Yep, I agree - but you'd be surprised how many people still want that exact type to work, and will argue vehemently with you when you try to tell them it's unsafe. It's refreshing to see someone who recognizes that. 😄 |
Section A causes no TS error in the source code below.
Section B causes a TS error in the source code below.
Both sections do the same thing and section B shouldn't yield any errors. (?)
The message "Type 'boolean' is not assignable to type 'string'" also makes no sense because
prop
is clearly aboolean
now. (?)(?) means: I am pretty sure, but not entirely sure, as I am new to Typescript. ^^
Here is the playground.
The text was updated successfully, but these errors were encountered: