[QUEST] Native Classes

[pzuraq]

Background

This issue is for tracking the progress on Native Classes in Ember! The task list below is actively used by the strike team to keep track of all of the major tasks left before we can officially ship. Feel free to ask questions or help out!

Original RFC here.

Tasks

• Decide Native Class Constructor Update RFC #337

  This ultimately decides what the behavior of native classes, and the way we write them, looks like until EmberObject is deprecated and removed from the framework. We need to get a final decision on this RFC before we can move forward.

  • feature [core-object] Delay init until after construction #16795

• Bugfixes

  We have some open issues that could cause compatibility issues when converting to native classes. We need to get these merged.

  • ES6 classes on/removeListener and observes/removeObserver interop v2 [BUGFIX beta] ES6 classes on/removeListener and observes/removeObserver interop v2 #16923
  • [BUGFIX] Adds default implementations of Component lifecycle hooks [BUGFIX] Adds default implementations of Component lifecycle hooks #17169

• Polyfills

  Currently we're going to polyfill back to 3.4 (the last LTS). Polyfills for earlier versions are definitely welcome and we will be working on them as we have time, but help would be appreciated!

  • 2.16 [Backport 2.16] CoreObject native class compatibility #16806
  • 2.18 [Backport 2.18] CoreObject native class compatibility #16805
  • 3.4 [DO NOT MERGE] Ember native class polyfill 3.4 #17167
  • 3.5 [DO NOT MERGE] Ember native class polyfill 3.5 #17168

• Write ReadOnly/Volatile Deprecation RFC

  Clobberability is an anti-pattern, and volatile is generally not needed. This is not something that is 100% necessary to move forward, but it resolves differences between native getters/setters and computeds so ideally we can address it quickly.

  readOnly RFC
  volatile RFC

• Write Decorators RFC (once decorators reach stage 3)

  We can move forward with the codemod with decorators being an addon, but we should fold them into Ember as soon as we can. Stage 2 is potentially viable, but ideally we would wait until stage 3.

• Address open issues on ember-decorators

  • Add @computed.readOnly and @computed.volatile

    We need a way to access these APIs for the codemod.

  • ES6 blueprints not being used

    General bug, this is important for shipping though since users will want to use these generators, and they can probably be ported into Ember.

  • route queryParams support

    I think this may need to be a class decorator, given the prototype placement of an object. Only one instance of said object will ever be created though, so maybe not an issue.

  • Filter array based on another property?

    Need a way to access .property() and add properties to computeds, for the codemod. This was ultimately unneeded

• Update decorators

  • Update to Babel 7

  • Update decorators to use stage 2 transforms

    Upon further discussion it seems like we'll be stuck on stage 1 transforms until Typescript updates, which will likely be stage 3

• Finish up codemod

  • Stage 2/3
  • Folder globbing, types

• Update guides - Blocked on Decorators RFC

[ghost]

@pzuraq nitpick: "volatile RFC" deprecation link should be emberjs/rfcs#370

[locks]

Thanks for the help! Closing as finished.