| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Something is amiss with this, or it's not been released yet. Still receiving the 'ol error TS1337: An index signature parameter type cannot be a union type. Consider using a mapped object type instead. errors. Ryan Cavanaugh (@RyanCavanaugh) can you confirm it's been released as of 4.3.5? |
Sorry, something went wrong.
It's currently in the 4.4 release which is in beta scheduled to be released by the end of August. |
Sorry, something went wrong.
|
Anders Hejlsberg (@ahejlsberg) Could you please clarify why those cases work differently in terms of assignability (playground)? AFAIU for a type alias and anonymous type it uses an empty literal type from getTypeFromTypeLiteralOrFunctionOrConstructorTypeNode without resolving its members, but is it the expected behavior? const sym = Symbol();
function gg3(x: { [key: string]: string }, z: { [sym]: number }) {
x = z; // Ok
}
interface GG4 {
[sym]: number;
}
function gg4(x: { [key: string]: string }, z: GG4) {
x = z; // Error
}
type GG5 = {
[sym]: number;
}
function gg5(x: { [key: string]: string }, z: GG5) {
x = z; // Ok ?!
}
|
Sorry, something went wrong.
|
Is this in and working? I'm sitting on v4.4.2 and still receiving:
type Test = 'one' | 'two';
export interface Foo {
[key: Test]: any;
} |
Sorry, something went wrong.
|
Douglas Gaskell (@douglasg14b) You can do it using type and in (although not with interface). type Test = 'one' | 'two';
type Foo= {
[key in Test]: any;
}
//type Foo = {
// one: any;
// two: any;
//}
type Foo2= {
[key in `${Test}${Test}`]: any;
}
//type Foo2 = {
// oneone: any;
// onetwo: any;
// twoone: any;
// twotwo: any;
//}I believe that because there is no "free" string or number template, this is old hat, and not related to this new feature. |
Sorry, something went wrong.
|
Anders Hejlsberg (@ahejlsberg) - This is really a great feature, thanks! I noticed that spaces seem to count as digits with the number type. How about not allowing that? type TP4 = {[k:`${number}`]:null}
const tp4_1:TP4 = {'1':null}
const tp4_2:TP4 = {' ':null} // even though there is no number present, it passes
const tp4_3:TP4 = {' 1':null}
const tp4_4:TP4 = {'1 ':null}
const tp4_5:TP4 = {' 1 ':null}
|
Sorry, something went wrong.
|
Index signatures for template literal string with generic? type Props<T extends string> = {
renders: {[key in T]: any};
[key: `render${Capitalize<T>}`]: any;
};TS 4.5.2 says:
|
Sorry, something went wrong.
type Test = 'one' | 'two';
type Foo= {
stringKey: string; // A mapped type may not declare properties or methods.
numberKey: number;
[key in Test]: any;
}
enum Test {
ONE = 'one',
TWO = 'two'
}
interface Foo {
[key: Test]: any; // An index signature parameter type cannot be a literal type or generic type. Consider using a mapped object type instead.
}
|
Sorry, something went wrong.
|
Sorry, something went wrong.
4.4.2 was the 1st npm release to allow template string pattern index signatures, used in this PR. see microsoft/TypeScript#44512
| Back | FazBrowse Home | New Git URL |
With this PR we implement support for symbol and template literal string index signatures. We furthermore permit index signature declarations to specify union key types, provided all constituents are either string, number, symbol, or template literal types with non-generic placeholders. Some examples:
An index signature declaration that specifies a union key type is exactly equivalent to a set of distinct index signatures for each constituent key. For example, the PropertyMap declaration above is exactly equivalent to:
Index signature declarations are not permitted to specify literal key types or generic key types. Those kinds of types can only be used with mapped types, which map literals key types to distinct properties and defer resolution of generic key types until they're instantiated with non-generic types. For example:
This PR supercedes #26797 which was more ambitious but had overlap between regular properties and index signatures with literal key types that is difficult to reconcile, as well as generic index signatures for which type relationships become exceedingly complex to reason about.
Fixes #1863.
Fixes #26470.
Fixes #42192.
Fixes #44675.