Reactivity only works for non-bracket-notation string properties

[nolanlawson]

const symbol = Symbol("haha")
export default class extends LightningElement {
  reg = 'regular!';
  ["with spaces"] = 'spaces!';
  [1337] = 'number!';
  [symbol] = 'symbol!';
}

In the above example, only reg is a reactive property. The other properties are non-reactive, because @lwc/babel-plugin-component does not recognize them as reactive properties and doesn't register them as such:

registerDecorators(App, {
  fields: ["reg"]
});

Repro showing reactivity not working correctly

This is definitely an edge case of an edge case, but maybe it's something we should support? If not, it's at least worth documenting in this GitHub issue.

Full repro for posterity

```html ``` ```js import { LightningElement } from 'lwc'; const symbol = Symbol("haha") let count = 0 export default class App extends LightningElement { reg = 'regular!'; ["with spaces"] = 'spaces!'; [1337] = 'number!'; [symbol] = 'symbol!'; get regular() { return this.reg } get spaces() { return this['with spaces'] } get number() { return this[1337] } get symbol () { return this[symbol] } renderedCallback() { if (++count) { setTimeout(() => { this.reg = 'regular 2!' setTimeout(() => { this['with spaces'] = 'spaces 2!' this[1337] = 'number 2!' this[symbol] = 'symbol 2!' }) }) } } } ```

[wjhsf]

To be more specific, it seems that reactivity only works when the prop is a valid identifier -- quoted "reg" is a string literal, and does not work. Similarly, 1337 is not a computed prop, but still does not work because it is a numeric literal.

[cardoso]

To be more specific, it seems that reactivity only works when the prop is a valid identifier -- quoted "reg" is a string literal, and does not work. Similarly, 1337 is not a computed prop, but still does not work because it is a numeric literal.

@wjhsf I included tests for those cases in my PR

[cardoso]

@nolanlawson could you update this issue with your latest thoughts? Thanks!

[nolanlawson]

My current thinking:

It occurred to me that we still don't support decorators (@api, @track, @wire) on these computed properties. So it's not really a full solution.

I feel like it might make more sense to just document this as a limitation of the framework, and then focus on fixing it once browsers have native support for decorators. At that point, it would be easy to support these decorators at the syntax level (since we wouldn't need our own Babel plugin), and we could potentially get rid of registerDecorators altogether which would resolve the reactivity issue.