Using const string enum as object key produces an indexed type

[Jessidhia]

TypeScript Version: nightly (2.5.0-dev.20170621)

Code

const enum Test {
  A = 'a',
  B = 'b'
}

type TestMap = {[key in Test]: string}

// Type '{ [x: string]: string; }' is not assignable to type 'TestMap'.
// Property 'a' is missing in type '{ [x: string]: string; }'.'
const x: TestMap = {
  [Test.A]: 'string',
  [Test.B]: 'another string'
}

Expected behavior:

Keys from a string enum to be usable as static key names, similar to how constant strings are usable in computed key position. This probably should work even with non-const enums.

const x: TestMap = { // currently works
  ['a']: 'string',
  ['b']: 'another string'
}

Actual behavior:

Not usable without a (potentially incorrect?) type assertion.

[SLaks]

This should also work for numeric enums.

[simonbuchan]

Is this the same error?

function make<Name extends string, Value>(name: Name, value: Value): Record<Name, Value> {
    return {
        [name]: value,
    };
}

Gives:

[ts] Type '{ [x: string]: Value; }' is not assignable to type 'Record<Name, Value>'.
[ts] A computed property name must be of type 'string', 'number', 'symbol', or 'any'.

[sandersn]

@simonbuchan Not really. @Kovensky wants the keys of strings enums to be statically known for use in computed properties.

You want one unknown member of an unknown set of keys to be create a type with computed name in it. Something like { [Name]: Value }, with [Name] to be assignable to other uses of T[Name] or something like that. (I'm haven't worked out in detail how it would have to work.)

Unfortunately, Typescript doesn't have a type like this, though, so instead the type inferred for the object literal has a string indexer, which is not assignable to a mapped type, even though both have an unknown set of allowed properties. You'll have to read the PRs for mapped types, but I think the reason is that a string indexer will always have an unknown set of properties, but the mapped type, when instantiated, will have a particular set of properties. For example:

make('hi', 'there'): Record<'hi', string>

And { [x: string]: Value } should not be assignable to that since it might not have the property 'hi'.

[simonbuchan]

@sandersn I think I get it reflecting on this a bit: Record<Key, Value> is { [key in Key]: Value }, not { [key: Key]: Value }, because the latter doesn't make sense when Key is not string (or any or never) or a string literal type (and this issue is that string enums should be considered the latter?). Is it correct that the only other type Key could be for Key extends string is a union of the previous? Would it make sense if TS had something like literal string as a type?

function make<Name extends literal string, Value>(name: Name, value: Value): { [name: Name]: Value };
make("foo", "bar"); // { foo: string } - though I would like { foo: "bar" }, that's another issue
["foo", "bar"].map(name => make(name, name)); // either error on make "'string' is not assignable to 'literal string' or Array<{ [name: string]: string }> as before?

function zipMake<Names extends string, Values>(names: Names[], values, Values[]) {
  return names.map((name, i) => make(name, values[i])); // "'Names' is not assignable to 'literal string'"
}
function zipMake<Names extends literal string, Values>(names: Names[], values, Values[]); // Either error or can only be called with 0 or 1-length literal array of `names` (or matching constrained type)?

This arose when I was playing around with a toy version of recompose, the use case is essentially that withState("counter", "setCounter", 0) should return a function that takes wraps a react component and adds the counter and setCounter props`: when simplified, something like:

type WithCounterEnhancer = <ExternalProps>(
  wrappedComponent: React.ComponentType<ExternalProps & { counter: number, setCounter(value: number }>,
): React.ComponentType<ExternalProps>;

I could get it to typecheck pretty well externally with ExternalProps & Record<Name, Value> & Record<UpdaterName, (value: Value) => void>, but I see now it would break in weird ways with type unions.

[sandersn]

@simonbuchan Do you mind creating a separate issue for this with your example code and discussion? This feels like it is generating discussion distinct from that based on the original example. I'll see if I can answer your questions there.

[simonbuchan]

@sandersn Seems like it's #2049 in this specific case. I've been thinking about the general case and working on a proper proposal - turns out languages are hard :). Further discussion would be in #2049 or a proposal.

[mhegazy]

another interesting use case described in #17784

class Component<S> {
    state: S;
    setState(partialState: Partial<S>) { }
    onFiledChanged = (filedName: keyof S) => (value) => {
        this.setState({ [filedName]: value });
    }
    render() {
        return <form>
                <input onChange={ this.onFiledChanged('foo') } />
                <input onChange={ this.onFiledChanged('bar') } />
            </form>
    }
}

[sandersn]

#15473 should be to fix this.