Need way to express hybrid types that are indexable for a subset of properties

[aaronjensen]

Edit by @DanielRosenwasser: This might be thought of as a "rest index signature" or a catch-all index signature.

---

This is a feature request.

TypeScript Version: 2.4

Code

interface CSSProperties {
  marginLeft?: string | number
  [key: string]: CSSProperties
}

Based on the docs, this is not allowed:

While string index signatures are a powerful way to describe the “dictionary” pattern, they also enforce that all properties match their return type. This is because a string index declares that obj.property is also available as obj[“property”]. In the following example, name’s type does not match the string index’s type, and the type-checker gives an error:

Unfortunately, it seems to make this type (which is common amongst jss-in-css solutions) not expressible. Coming from flow, which handles index types by assuming they refer to the properties that are not explicitly typed, this is frustrating.

As it stands, you can workaround it with:

interface CSSProperties {
  marginLeft?: string | number
  [key: string]: CSSProperties | string | number
}

But this is not sound. It allows this:

const style: CSSProperties = {
  margarineLeft: 3
}

This could potentially be solved with subtraction types if they allowed subtracting from string (and you were allowed to specify key types in this way):

interface CSSProperties {
  marginLeft?: string | number
}

interface NestedCSSProperties extends CSSProperties {
  [key: string - keyof CSSProperties]: CSSProperties
}

I asked about this on stackoverflow to confirm that I wasn't missing something. It seems I'm not, so I guess I'd consider this a suggestion/discussion starter, since it's probably not a "bug". Thanks!

[ajafff]

It seems like you can actually do this by using intersection types.

interface I {
    [key: string]: string;
}

interface C {
    foo: boolean;
    bar: number;
}

type T = I & C;
declare let t: T;
t.foo; // boolean
t.bar; // number
t.baz; // string

http://www.typescriptlang.org/play/#src=interface%20I%20%7B%0D%0A%20%20%20%20%5Bkey%3A%20string%5D%3A%20string%3B%0D%0A%7D%0D%0A%0D%0Ainterface%20C%20%7B%0D%0A%20%20%20%20foo%3A%20boolean%3B%0D%0A%20%20%20%20bar%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Atype%20T%20%3D%20I%20%26%20C%3B%0D%0Adeclare%20let%20t%3A%20T%3B%0D%0At.foo%3B%0D%0At.bar%3B%0D%0At.baz%3B

[aaronjensen]

@ajafff No, that doesn't work if you actually want to assign to a variable of that type.

interface I {
    [key: string]: string;
}

interface C {
    foo: boolean;
    bar: number;
}

type T = I & C;
let t: T = {
    asdf: 'foo',
    foo: true,
    bar: 3,
}; 

http://www.typescriptlang.org/play/#src=interface%20I%20%7B%0D%0A%20%20%20%20%5Bkey%3A%20string%5D%3A%20string%3B%0D%0A%7D%0D%0A%0D%0Ainterface%20C%20%7B%0D%0A%20%20%20%20foo%3A%20boolean%3B%0D%0A%20%20%20%20bar%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Atype%20T%20%3D%20I%20%26%20C%3B%0D%0Adeclare%20let%20t%3A%20T%3B%0D%0At.foo%3B%0D%0At.bar%3B%0D%0At.baz%3B#src=interface%20I%20%7B%0D%0A%20%20%20%20%5Bkey%3A%20string%5D%3A%20string%3B%0D%0A%7D%0D%0A%0D%0Ainterface%20C%20%7B%0D%0A%20%20%20%20foo%3A%20boolean%3B%0D%0A%20%20%20%20bar%3A%20number%3B%0D%0A%7D%0D%0A%0D%0Atype%20T%20%3D%20I%20%26%20C%3B%0D%0Alet%20t%3A%20T%20%3D%20%7B%0D%0A%20%20%20%20asdf%3A%20'foo'%2C%0D%0A%20%20%20%20foo%3A%20true%2C%0D%0A%20%20%20%20bar%3A%203%2C%0D%0A%7D%3B%20%0D%0A

[RyanCavanaugh]

I will admit that I still don't fully understand the intent here. Flow advocates are always trumpeting soundness and then this happens

var x = 'hello' + 'world';
type Thing = {
  [index: string]: number;
  helloworld?: string;
};

var j: Thing = {
  [x]: 32
};
if (j.helloworld) {
  // crash, no error
  j.helloworld.substr(3);
}

Is the justification that objects initializing these types should never be constructed with dynamic keys? Is that a requirement that should be enforced? What should j[some_arbitrary_string]'s type be?

[aaronjensen]

@RyanCavanaugh Sorry, I'm not trying to make this a flow vs typescript soundness debate. I'm trying to type a very specific thing referenced in the OP:

interface CSSProperties {
  marginLeft?: string | number
  [key: string]: CSSProperties
}

Arbitrary keys are allowed, but they must be of type CSSProperties. This is not possible in Typescript afaict. This is not about soundness, it's about a type being not expressible in Typescript.

Soundness comes in if I attempt to work around Typescript's limitation:

interface CSSProperties {
  marginLeft?: string | number
  [key: string]: CSSProperties | string | number
}

In this case, I can do this:

const style: CSSProperties = {
  margarineLeft: 3
}

Which is wrong, but typechecks. In other words, I can typo the property names, which is one of the things I'm trying to protect against with types. For completeness sake, this would not be an error:

const style: CSSProperties = {
  margarineLeft: {
    marginLeft: 3
  }
}

[RyanCavanaugh]

Sorry for the tangent. I just mean, the index declaration means "If you index by a string, here's what you get", so it's contradictory to allow you to write property declarations for which that statement isn't true.

We can have some other syntax that means "If a property exists and isn't one of the following known properties, then it must have this type", but then we have to decide what it means when you're indexing (for read or write) by a computed property name which we can't immediately resolve to determine if it should have the index type or a declared property's type.

What would you want to happen here?

var s = "qqqmarginLeft".substr(Math.random() * 7);
style[s] = 32;

[aaronjensen]

Ah, yes, I understand the concern. AFAICT flow does what you describe as "If a property exists and isn't one of the following known properties, then it must have this type", but likely falters in the case that you describe.

I'd be fine with a separate syntax.

In your example, I would want that to be a type error. In that case, style[s] should be treated as type (string | number) & CSSProperties which is impossible.

I would expect something like this to work, however:

interface CSSProperties {
  marginLeft?: string | number
  marginRight?: string | number
  [key: string]: CSSProperties
}

var s: 'marginLeft'|'marginRight' = left ? 'marginLeft' : 'marginRight'
style[s] = 32

[aaronjensen]

Oh, and I'd only expect style[s] to be treated that way on writes, it should be a union on reads.

[masaeedu]

Perhaps we could use subtraction types to express this. { [P in string - "marginLeft"]: CSSProperties }?