Repository navigation
General indexer type #2049
Description
Activity
So for your example, I think what you're looking for is really the ability to index with a union type:
interface Map<T> { [key: string | number]: T; }
Which wasn't allowed when we first introduced union types, but for 1.5 you should have it through #1765.
This wasn't a change we made, so re-opening this although it's not clear how useful it is.
+1, am wanting to do this now to write a type definition for Lodash's
_.mapKeysThis needs more fleshing out. Currently number and string indexers have very different behavior; it's not at all obvious what the behavior of the "combined" key type would be. At a minimum we need to see what the desired behavior of this would be other than simply allowing its declaration to exist.
At least it would be very useful to have the ability to use string literal union type as an indexer. As people have already pointed out in #5185 (comment)
It is more limited than initial proposal, but added value will be tremendous.
Reacted by Mathieu Masy, Marcel Šebek, Nathan Liebrecht and Tomáš HübelbauerAnd now number literal union type as indexer!
I also would like to have indexer with generics support:
interface IPerson<TPersonId extends string> { readonly id: TPersonId; fullName: string; } interface IPersons { <TKey extends string>[key: TKey]: IPerson<TKey>; // Made-up syntax }to represent:
const persons: IPersons = { "a14578": { id: "a14578", fullName: "Jo Van den Berghe" } }The examples in this thread can be represented, today, with mapped types.
type KeyValue<Key extends string, Value> = {[K in Key]: Value}; interface IPerson<TPersonId extends string> { readonly id: TPersonId; fullName: string; } type IPersons<TKey extends string> = {[K in TKey]: IPerson<K>};
Is there still a feature request here?
The problem with mapped types is that once you converted anything to type, you cannot use it as an interface, e.g.: no more
implementsfor classes, and that's quite a bit trade-off.I wonder if there are any ideological objections to allowing simple mapping syntax inside of interfaces.
type AllWorks<T> = { [K in keyof T]: T[K]; // ok } interface DoesNotWork<T> { [K in keyof T]: T[K]; // would be great for this syntax to work inside of interfaces }
While first one works as expected, second one gives the TS error:
[ts] A computed property name must be of type 'string', 'number', 'symbol', or 'any'.
[ts] Member '[K in keyof' implicitly has an 'any' type.
[ts] Cannot find name 'keyof'.Reacted by John Maillet, Kevin Upton and Robin BaumI think what would be ideal is having generic types, but having the compiler validate the type when it is used. (for the key validation).
An example where a function returns:
{ [key : T[K]] : T }
Tbeing an object, andKbeingkeyof TExample Code:
A function which takes an array of objects, and returns an object map, with the each object mapped to the input key.
interface Type { [key: string]: any; } /** * Function which maps an array to an object. * This will convert [{id, test}...] => {id: {id, test}...} * Useful for creating cache maps. * * @param {K} key * @param {T[]} objects * @returns {{[p: string]: T}} */ export function mapArrayToObject<T extends Type, K extends keyof T>(key: K, objects: T[]): { [key: T[K]]: T; // it should recognise that this is a variable type which depends on the input, and validate it on use. } { return Object.assign( {}, ...objects.map(object => ({ [object[key]]: object })) ); }
Then when they use the method:
This should work
interface Test { id: string; value: any; } const testArray: Test[] = []; mapArrayToObject('id', testArray); // this should work because id is a string type and key accepts string.
This should fail
interface Test2 { id: object; value: any; } const test2Array: Test2[] = []; mapArrayToObject('id', test2Array); // this should fail because it recognises that `id` is an object. And you cannot have an `object` as a key.
Mohamed Hegazy (@mhegazy) Is there an issue tracking the
iscontraint suggestion in the OP? I am trying to write apropertyIsDefinedfunction like this to help with #10976 (comment):export const isDefined = <T>(val: T): val is NonNullable<T> => val !== undefined && val !== null export const propertyIsDefined = <T extends object, K extends keyof T>(key: K) => (val: T): val is T & { [k in K]: NonNullable<T[k]> } => isDefined(val[key])
which works, but it is only type safe if
Kis a single string literal. IfKis a union, this function is not type safe anymore, as it would mark all properties inKas non-null, instead of one of the properties inK. I would like to forbid passing in a union,Kshould be an exact element ofkeyof T, butextendsallows to pass any subtype ofkeyof T.Felix Becker (@felixbecker) you just wanna decompose any input unions before you map, eg
export const propertyIsDefined = <T extends object, K extends keyof T>(key: K) => (val: T): val is (K extends any ? T & { [k in K]: NonNullable<T[k]> } : never) => isDefined(val[key])
which should handle the input as union case like you'd like.
Reacted by SlurpTheoWesley Wigham (@weswigham) wow, works like a charm! I would have never thought about that. How does it work? Shouldn't
K extends anyalways be true?Discussion here has wandered quite a bit but the OP use case works now.
It is impossible to write generic type that represents key-value dictionary:
Key must be string or number, but generic constraints doesn't allow this.
There is 'extends' but there is no 'is' to match exact type.
Something like "Key is string|number" or "Key: string|number" .