René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Field declarations overwrite properties on the prototype","articleBody":"I think this issue has been raised a few times already in several of the open issues, like #100, but I thought it would probably be good to report a very specific, real life use case. \r\n\r\nThe following snippet is the official way to enhance a class with observable capabalities in [MobX](https://github.com/mobxjs/mobx), when decorator syntax is not used. (See [`decorate` docs](https://mobx.js.org/refguide/api.html#-decorate))\r\n\r\n```javascript\r\nclass Counter {\r\n  counter = 0\r\n}\r\n\r\ndecorate(Counter, { counter: observable })\r\n```\r\n\r\nWhich is currently semantically equivalent to:\r\n\r\n```javascript\r\nclass Counter {\r\n  @observable counter = 0\r\n}\r\n```\r\n\r\nThis first example works fine with TypeScript and [babel-plugin-proposal-class-properties](https://babeljs.io/docs/en/next/babel-plugin-proposal-class-properties.html), but only if `loose` mode is used (that translates the initializes to an assignment in the constructor). In standards mode, this mechanism no longer works. \r\n\r\nThe simple reason is, the `decorate` call introduces the `count` property on the `Counter` property, and gives it a getter and setter. If just an assignment is made in the constructor, this works fine. However, if a new property is introduces, the property on the prototype is completely ignored and a new one is introduced on the instance. \r\n\r\nIn pseudo code `decorate` does something along these lines: \r\n\r\n```javascript\r\nclass Counter {\r\n    counter = 3\r\n}\r\n\r\nObject.defineProperty(Counter.prototype, \"counter\", {\r\n  set(counter) {\r\n    this._counter = counter * 2 \r\n  },\r\n  get() {\r\n    return this._counter * 2 \r\n  }\r\n})\r\n\r\nconst counter = new Counter()\r\n\r\nconsole.log(counter.counter)\r\n```\r\n\r\nPrinting the `counter` will yield `12` in loose mode, but `3` in standards mode, as in standards mode the field would be re-introduced in a non-interceptable way.\r\n\r\n---\r\n\r\nI search this repo for it, but couldn't really find it, what was the motivation to change the spec in this regards? (or if it never changed; what is the motivation to deviate from what existing transpilers are doing?).\r\n\r\nAnd more specific: how could I express \"decorating\" my class fields in the future with the above API? After all, changing a prototype after the initial class declaration is not that uncommon in JavaScript. \r\n\r\n---\r\n\r\nA potentially future risk of this approach is that it will render MobX completely incompatible with create-react-app, if this proposal is finalized before the decorators standard, as the `decorate` utility is currently the only way in which CRA users can obtain decorator-like behavior without the syntax. For some background: https://mobx.js.org/best/decorators.html\r\n\r\nN.B. note that this problem also happens when the field is declared, but never initialized.\r\n\r\n---\r\n\r\n_Edit: for clarification to other readers of this issue, the difference in compilation between loose and standards mode is:_\r\n\r\n```javascript\r\n// Loose:\r\nvar Counter = function Counter() {\r\n   this.x = 3 // assignment being picked up by property on the prototype\r\n}\r\n\r\n// Standard:\r\nvar Counter = function Counter() {\r\n   Object.defineProperty(obj, \"counter\", { // Property definition hides prototype property\r\n      value: 3,\r\n      enumerable: true,\r\n      configurable: true,\r\n      writable: true\r\n    });\r\n};\r\n```\r\n","author":{"url":"https://github.com/mweststrate","@type":"Person","name":"mweststrate"},"datePublished":"2018-10-17T19:31:16Z","url":"https://github.com/tc39/proposal-class-fields/issues/151"}