Computed object keys produce very odd output

[alextreppass]

Hi, I'm seeing some strange-looking output when using square brackets to quote object keys.

const a = { ['foo']: 1};
const b = { ['bar']: 2};
console.log(a, b);

becomes:

var a={},b=(a.foo=1,a),c={},d=(c.bar=2,c);console.log(b,d);

Appspot link here. It gets worse: more intermediary objects are created as you add more keys.

I'd expect the result to be closer to the setup without [], i.e.:

console.log({foo:1},{bar:2});

---

Further context: this came about as we're looking to use Prettier to format code in our project, but can't easily do so as it unquotes keys that don't strictly need to be quoted. This breaks instances where we need quoted keys not to be mangled by Closure Compiler.

One of the workaround people are using is { ['foo']: bar } syntax, which Prettier won't unquote, but that produces bad output when fed into CC.

[lauraharker]

The compiler could probably transpile computed properties that are just strings (or numbers) differently. e.g. convert const a = { ['foo']: 1};

into

const a = { 'foo': 1};

during transpilation.

This should be easy to implement, and the compiler can actually optimize it. (appspot link)

[alextreppass]

Hi @lauraharker that sounds great - what would be required to get it into an upcoming project milestone?

[lauraharker]

@alextreppass assigning myself to work on this when I have time.

Are you able to give numbers for how much this affects your code size? (e.g. your gzipped output grew 1% after switching to this syntax). That would help me prioritize this change.

[lauraharker]

Sent out a fix for internal review. I'd estimate it will be in the May release.

[alextreppass]

Hi @lauraharker after some internal testing, using computed object keys with our CC advanced mode compilation adds ~5kb to our bundle size (out of ~2.1MB) and ~10ms to our performance user timings.

We're considering finding some exclusions to keys that don't need to be computed (namely, autogenerated code that is already formatted), and/or pre-processing the input prior to CC to un-compute the keys, but if this fix were to land we could sidestep that.

How is the fix review going?

Thanks again

[lauraharker]

Sorry I haven't updated this in a while. Thanks for the numbers. After some internal review, we do still want to fix this, but in a way slightly more complicated than my initial proposal to deal with the restriction on duplicate object literal keys in ES5 strict mode.

Filed Google internal bug b/120031769.

[monfera]

Is there any progress on this perhaps?

[brad4d]

@monfera I've just been looking through @lauraharker 's notes on the internal issue as well as here.

I believe the problem is that if we just convert computed properties to string keys we could introduce a duplicate string key, which would then become a syntax error in ES5 strict mode. Working around that is tricky, and there are other issues higher on our priority list than this one.

I don't think any work is being done on this right now. Sorry.

[lauraharker]

Unassigning myself, I've forgotten what the state of this issue was but probably don't have time to prioritize it