TypeScript Version: 2.2.1 / nightly (2.2.0-dev.201xxxxx)
Code
class Foo {
constructor(public value: { [prop: string]: boolean }) {}
}
const foo = new Foo({ a: true });
Expected behavior:
The compiler should generate an object with string properties (notice how a is in quotes below). This behavior allows for proper minification of the generated code since minifiers such as the closure compiler will not rename strings.
var Foo = (function () {
function Foo(value) {
this.value = value;
}
return Foo;
}());
var foo = new Foo({ 'a': true });
Actual behavior:
Unfortunately, even thought the type of the object specified that all boject properties are strings, the generated code does not wrap the property name in quotes.
var Foo = (function () {
function Foo(value) {
this.value = value;
}
return Foo;
}());
var foo = new Foo({ a: true });
What problem is this causing? Traditionally strings as keys of object literals are only quoted when the string contains something that would not be a valid variable name in JavaScript (e.g. 'a key like this').
The problem is that without using actual strings minifiers are prone to rename the symbol. This becomes a problem when receiving json's via http for example where the server constructs a message with the non renamed symbol
Most minifiers do not mangle object literal keys unless they are instructed it is safe to do so because of exactly the problem you mention.
The developer has every right to specify object literals as strings or not, if that meets their particular use case. Having TypeScript universally enforce one way or the other would likely not be a good idea.
I would agree with that. Okay let's take a step back and imagine a more
specific developer scenario. Imagine a team trying to enforce that a
specific object only has its properties accessed using bracket notation.
Prior to typescript 2.2 this was possible. Now it is not. So typescript 2.2
has introduced a regression of language features for developers in this
category. Perhaps this regression warrants a flag of some sort?
On Sun, Apr 16, 2017, 1:04 AM Kitson Kelly notifications@github.com wrote:
Most minifiers do not mangle object literal keys unless they are
instructed it is safe to do so because of exactly the problem you mention.The developer has every right to specify object literals as strings or
not, if that meets their particular use case. Having TypeScript universally
enforce one way or the other would likely not be a good idea.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/TypeScript/issues/15206#issuecomment-294337334,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHteO2r2aXGR23nToVo13Vnm6J1Iu3tDks5rwb1ngaJpZM4M-aTr
.
Imagine a team trying to enforce that a specific object only has its properties accessed using bracket notation.
Again, what problem would this be causing? If anything, it would appear to be a stylistic choice then, which is the domain of a linter.
I'm using Angular 2 with the closure compiler. Angular's form's has an implicit requirement that FormGroups values be access with string indicies so that the closure compiler does not minify them.
By the way, AFAIU this is not limited to Closure compiler, you'll have the same problem when using Uglify in advanced mode.
See also https://github.com/Microsoft/TypeScript/issues/14267 files by @alexeagle
For any code that is "normal" JS, we're going to emit the same code as what you wrote. The onus is on the developer to have the right rules / process around whether or not the code they're writing is correct for downstream heuristic-based tools.
Ryan: previously, we were able to use TypeScript to express the
process/rules around quoting for optimization – you'd simply get errors in
your IDE if you get the ['quoting'] vs .dotting wrong due to index
accessor/no index accessor.
We can no longer express this in TypeScript, which means people run into
errors, which means we'll apparently have to build our own toolchain to do
this (which is effort, and likely won't be as nicely integrated into e.g.
the IDE experience).
That's quite a loss in usability of TS for us.
One person's improvement is another's regression.
It appears that people were depending on a side-effect versus a feature.
It should be very simple to write a TSLint rule to detect "used dotting to access string index signature" (or vice versa) mismatches, assuming one doesn't exist already.
This issue seems to have been already addressed or is unactionable at the moment. I am auto-closing it for now.
Most helpful comment
It should be very simple to write a TSLint rule to detect "used dotting to access string index signature" (or vice versa) mismatches, assuming one doesn't exist already.