[on hold] WIP: Support decorators stage 2 proposal, implements #1352

[mweststrate]

• Use Babel7 #1731 should be merged first
• make all tests pass
• make sure decorate / extend observable prefer stage2 decorator implementation
• add additional assertions to the stage2 decorators
• document change in behavior: computed properties now become visible as own property
• document change in behavior: some non-observable fields will unexpectedly non-enumerable, see babel bug
• document bug: isObservable / isObservableProp etc will yield incorrect results for members that were never visited (or create workaround via finisher?) Found workaround
• make sure that tests also succeed in legacy mode (swap out .babelrc or different .babelrc in sub dir?)
• backport to MobX 4
• follow up on late initialization issues: Public prototype accessor does not support initializer tc39/proposal-decorators#153
• Investigate using ["@babel/plugin-proposal-class-properties", { "loose": false }], or document that true should be used! as loose: false will wipe the properties and redefine them (when using decorate
  instead of decorators)
• await fix for non-decorated field enumerability, see: Using a decorator breaks the enumerability of non-decorated fields babel/babel#8760 Fixed, released with next babel release
• Document that class-properties proposal should be used in loose mode if the decorate utility is used
• update gh-pages with syntax settings
• verify against mobx-state-tree
• check performance impact. Before -> After: (babel create update / TS create update) 200 / 6300 / 3700 / 5700 => 1800 / 5000 / 3800 / 6100
• Implement flow and flow.bound as decorator: Flow functions are not type checked by FlowType #1769 / Bound Flow functions #1767
• Follow up on
  • [Mobx >= 4] Object.hasOwnProperty fails #1526
  • Support the new Babel 7 decorator implementation #1352
  • Can't make @observable parameter properties #1273
• create follow-up issue, in MobX 6 legacy decorators will not be supported (4 will stay as is supporting both). But not before TS followed suit
• wait until key-less initializers are implemented in babel: Normative: Add initializer callback for side effects tc39/proposal-decorators#165, waiting for: @babel/plugin-proposal-decorators doesn't support kind: "initializer" babel/babel#9260 /
• wait until initializers have been renamed to hooks: https://github.com/babel/babel/pull/9360/files (see Normative: Renamings in decorator descriptors tc39/proposal-decorators#199 for the naming changes)

[coveralls]

Coverage decreased (-0.2%) to 93.756% when pulling 88c8c3a on decorators-stage-2 into d6f2b54 on master.

[nicolo-ribaudo]

Maybe instead of recommending decoratorsBeforeExport: true you could just say that it is similar to the old behavior but that it could change? Since TC39 hasn't decided yet it would be better not to recommend neither true not false.

[nicolo-ribaudo]

I think that it would be more future-proof to also check if args[0].kind === "class", just in case someone tries to use this helper with a class decorator.

[mweststrate]

Current main blocker: wait until tc39/proposal-decorators#165 is implemented in babel.

[nicolo-ribaudo]

I will implement it as soon as that PR is merged in the proposal repo.

[mweststrate]

@nicolo-ribaudo awesome, thanks!

[IngwiePhoenix]

Is the decorator-plugin so much in WIP that you can not use it without legacy being turned on? I am asking because I am - sort of desparately? - trying to get class-level decorators to work, but have had little to no luck. I managed to get method decorators to work, but that's it. I can not seem to be able to attach a field to a class through a decorator.

"legacy" sounds like "old", or rather "do not use for long-term support". I would like to get started on decorators with sort of an LTS in sight, so that I can stay on that implementation for at least a while.

This is the test-file I am trying to compile:

function classDecorator(value) {
  //console.log("class", value, arguments.length, arguments)
  return function decorator(target) {
    let obj = {
      kind: "field",
      key: "isDecorated",
      placement: "static",
      descriptor: {
        configurable: false,
        enumerable: false,
        writeable: false,
      },
      method: () => {console.log("class rt mtd"); return true},
      value: true
    }
    target.elements.push(obj)
    console.log(target)
    return target
  }
}

function methodDecorator(value) {
  //console.log("method", value, arguments.length, arguments)
  return (target) => {
    //console.log("method rt", arguments)
    target.descriptor.value.isDecorated = true
    return target
  }
}

@classDecorator("class val")
class Bar {
  @methodDecorator("mtd val")
  baz() {
    console.log("foo")
  }
}

console.log(Bar, Bar.isDecorated, Bar.prototype.isDecorated)
// Expected to see the class and "true".

And this is the .babelrc:

{
  "presets": [
    ["@babel/preset-env", {
      "targets": { "node": "current" }
    }]
  ],
  "plugins": [
    ["@babel/plugin-proposal-decorators", {
      "decoratorsBeforeExport": true
    }]
  ]
}

[mweststrate]

Eh one step back, what is the relation with MobX? Op ma 21 jan. 2019 18:53 schreef Ingwie Phoenix <notifications@github.com>:

…

Is the decorator-plugin so much in WIP that you can not use it without legacy being turned on? I am asking because I am - sort of desparately? - trying to get class-level decorators to work, but have had little to no luck. I managed to get method decorators to work, but that's it. I can not seem to be able to attach a field to a class through a decorator. "legacy" sounds like "old", or rather "do not use for long-term support". I would like to get started on decorators with sort of an LTS in sight, so that I can stay on that implementation for at least a while. This is the test-file I am trying to compile: function classDecorator(value) { //console.log("class", value, arguments.length, arguments) return function decorator(target) { let obj = { kind: "field", key: "isDecorated", placement: "static", descriptor: { configurable: false, enumerable: false, writeable: false, }, method: () => {console.log("class rt mtd"); return true}, value: true } target.elements.push(obj) console.log(target) return target } } function methodDecorator(value) { //console.log("method", value, arguments.length, arguments) return (target) => { //console.log("method rt", arguments) target.descriptor.value.isDecorated = true return target } } @classDecorator("class val")class Bar { @methodDecorator("mtd val") baz() { console.log("foo") } } console.log(Bar, Bar.isDecorated, Bar.prototype.isDecorated)// Expected to see the class and "true". And this is the .babelrc: { "presets": [ ***@***.***/preset-env", { "targets": { "node": "current" } }] ], "plugins": [ ***@***.***/plugin-proposal-decorators", { "decoratorsBeforeExport": true }] ] } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1732 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhMFXHbfdX6kbd9l9XuPqjvX8b4MGks5vFf6EgaJpZM4WyiA1> .

[mweststrate]

Latest status: initializers haven't landed yet in babel, since the proposal was slightly changed. Waiting for https://github.com/babel/babel/pull/9360/files to land.

[mweststrate]

Update: the proposal is undergoing significant changes again. Waiting on that: tc39/proposal-decorators#250

[mweststrate]

Closing for now, will be reopened once #1928 happens.