Repository navigation
Primitive literals in computed property names #4653
Description
Looking at #4648 brought this up -
declare module JSX {
interface IntrinsicElements {
["my-custom-element"]: MyCustomElementClass
}
}We should allow string literals in computed property names in interfaces. Right now we only allow well-know symbols, but allowing all primitive literals (of valid indexer types, I suppose) should be supported.
This is a spec change - section 2.2.3 would need to be updated to reflect this, but, IMO, is fairly important and worth the change. We can't strongly type, say, tslint.json result structures right now, as we lack this.
Activity
danquirk commentedon Sep 4, 2015
See #1082 for some previous discussion on computed property names in interfaces.
vladima commentedon Sep 4, 2015
will this work in your case?
weswigham commentedon Sep 4, 2015
Huh. Why does our syntax for defining non-identifier string object properties in interfaces not overlap with the computed property syntax?
That's weird and unexpected.
It's quick info is also really weird:
That's... not valid JS in that quick info. It should certainly use square brackets, reflecting it's correct usage.
Yeah, still feels wrong:
Also, we don't get completions for this:
vladima commentedon Sep 4, 2015
I guess that it reflects syntax for defining object literals. Also string\numeric literals as names in properties were allowed in TypeScript long before ES6 support was added
weswigham commentedon Sep 4, 2015
Weird - VSCode's syntax highlighter doesn't even think it's valid:
Like, I feel like the square brackets (computed property) should certainly be correct syntax in TS, even if the old interface syntax is still valid - just because it works for symbols, so it feels like it aught to work for other primitives.
weswigham commentedon Sep 4, 2015
I also don't think many people would argue with me that
is better written as
The top is feels almost nonsensical (I did not even realize that was valid TS until I tried it), the bottom is ES6 classes (and yet invalid in TS).
danquirk commentedon Sep 4, 2015
Both of those forms are valid in classes (where someone would actually migrate JS to TS). Would be reasonable to support both in interfaces for consistency sake.
jbondc commentedon Sep 24, 2015
Also was confused by this recently. Consider #2225
Don't really know if string literals should be in computed property names but you should be able to see those strings somewhere.
DanielRosenwasser commentedon Sep 25, 2015
Jon (@jbondc) I'm not really sure how #2225 ties in, but #606 is relevant.
weswigham commentedon Sep 25, 2015
Daniel Rosenwasser (@DanielRosenwasser) in the chrome devtools, one can write
get completions at the marker, and recieve the list of properties
select
thing-explainer, and have it completed asI think this is the behavior we want to be able to replicate. (as far as completions go)
vladima commentedon Nov 10, 2015
should be addressed in #5535