New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compatibility with ES6 class syntax #10341

Closed
fivetanley opened this Issue Feb 2, 2015 · 44 comments

Comments

Projects
None yet
@fivetanley
Copy link
Member

fivetanley commented Feb 2, 2015

This would be a great feature and usable by people using 6to5 in ember-cli. What kind of work would need to go in to make this possible?

  • align _super and super
  • es2016 decorators stability
  • loose mode proto for IE8 (for now) we don't support IE8 in 2.0
  • constructor vs init vs ..
    i suspect constructor will be the new form, with the new behaviour i would prefer, and init will fire after?...

@fivetanley fivetanley added the Feature label Feb 2, 2015

@topaxi

This comment has been minimized.

Copy link
Contributor

topaxi commented Feb 2, 2015

Kind of related rwjblue/ember-cli-esnext#7

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Feb 2, 2015

Won't be possible until js adds annotations. Also won't work in ie8.

That being said, I am sure we all want this.

@donaldpipowitch

This comment has been minimized.

Copy link

donaldpipowitch commented Mar 10, 2015

It looks like Angular and TypeScript teams working together with @wycats to get a proper annotations specification (see http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx). I hope this can be transpiled with Babel easily to get real ES6 class support.

@wycats

This comment has been minimized.

Copy link
Member

wycats commented Mar 10, 2015

The annotations proposal and a proposal for declarative properties are going to be brought to TC39 at the Paris meeting on March 24.

I anticipate support in Babel pretty quickly assuming all goes well. 😄

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Mar 10, 2015

@wycats we will also need jshint support, for annotations, can you apply pressure?

@wycats

This comment has been minimized.

Copy link
Member

wycats commented Mar 10, 2015

@stefanpenner once we have an advanced proposal, I'll try and get it done.

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Mar 10, 2015

@stefanpenner once we have an advanced proposal, I'll try and get it done.

👍 if we can get those tooling pieces tee'd up, we can roll this out much quicker.

@wycats we need to figure out this._super and super interop still.

@wycats

This comment has been minimized.

Copy link
Member

wycats commented Mar 10, 2015

@stefanpenner yeah. There's an ES7 super proposal coming up in Paris as well. I'll make sure to keep the Ember use case in mind.

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Mar 10, 2015

@stefanpenner yeah. There's an ES7 super proposal coming up in Paris as well. I'll make sure to keep the Ember use case in mind.

thanks, keep me in the loop. I'll gladly prototype something if i have the proposal.

@donaldpipowitch

This comment has been minimized.

Copy link

donaldpipowitch commented Mar 10, 2015

I'm not sure if this discussion overlaps, but the React team looks into how mixins could be expressed for ES6 classes (facebook/react#1380). It looks like this could be done solved with an annotation on a class, too...? Just to point to another use case outside of Ember.

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Mar 10, 2015

@donaldpipowitch awesome, good resource, will read it shortly.

I believe, as the thing to the right of extends is just an expression, and that super desugars to toMethod we may be in the clear.

@thehydroimpulse

This comment has been minimized.

Copy link

thehydroimpulse commented Mar 11, 2015

/cc me

@trek

This comment has been minimized.

Copy link
Member

trek commented Mar 12, 2015

@thehydroimpulse for future reference you can use the Notifications button on any issue to get notifications without sending everyone a message 🙌

@thehydroimpulse

This comment has been minimized.

Copy link

thehydroimpulse commented Mar 12, 2015

@trek Unfortunately, if you're watching a project, you're technically already subscribed to all issues, but you don't get email notifications. Commenting is unfortunately the only way around it.

@lolmaus

This comment has been minimized.

Copy link

lolmaus commented Mar 16, 2015

@thehydroimpulse, go here https://github.com/settings/notifications and enable email notifications for watched repos.

@Globegitter

This comment has been minimized.

Copy link

Globegitter commented Jun 6, 2015

Seems like Aurelia is making use of some of the features @wycats mentioned. They are using decorators for dependency injection. Also now that IE8 support is being dropped seems like there could be some movement happening in that direction.

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Jun 6, 2015

Also now that IE8 support is being dropped seems like there could be some movement happening in that direction.

Yes this is/was the largest barrier. The next largest is actually the copious amount of re-factoring, and the incompatibility between ES5 and ES6 classes (specifically the lack of desugaring for super).

@kottenator

This comment has been minimized.

Copy link

kottenator commented Jun 22, 2015

It would be great to use ES6 super-powered methods instead of magical this._super(...)
I guess it's not possible until Ember will switch to ES6 classes (for all the base classes).
As for IE8 support - as I understand, Ember 2.0 will drop it, so it's not a problem.

@rwjblue

This comment has been minimized.

Copy link
Member

rwjblue commented Jun 22, 2015

Much work has been done on this, there is a pending PR by @stefenpenner that makes the required changes (still needs a few changes/fixed IIRC).

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Jun 23, 2015

I guess it's not possible until Ember will switch to ES6 classes (for all the base classes).

For classes super works correctly, our superWrappering makes it "just work" today. Mostly we are just waiting on 3 things:

  1. decorator spec to be finalized – we can't start relying on on-finalized spec :(
  2. IE8 to be dropped
  3. extraction of the mixin helper

Without 1 + 2, 3 serves very little value in core. Although it may be provided as an add-on.

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Jun 23, 2015

i have updated the above checkboxes (and edited some of the words)

loose mode proto for IE8 (for now)

@fivetanley im not sure what this means, but I suspect this doesn't matter as ember 2.0 drops IE8?

@knownasilya

This comment has been minimized.

Copy link
Contributor

knownasilya commented Jul 28, 2015

Can't wait!!! Has there been any work on this since the last update?

@rosshadden

This comment has been minimized.

Copy link

rosshadden commented Sep 18, 2015

Is the decorators spec stable enough to do this now? rwjblue's project is a great step in the right direction, but having classes and decorators built-in to Ember would dramatically improve developer experiences (not to mention morale :-D).

@listepo

This comment has been minimized.

Copy link

listepo commented Oct 7, 2015

👍

@chadhietala

This comment has been minimized.

Copy link
Member

chadhietala commented Oct 7, 2015

@rosshadden Still at Stage 1, but many improvements have been made to the spec. wycats/javascript-decorators#36

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Oct 7, 2015

@rosshadden yes we agree, and this is why @wycats and myself are on tc39. To push aspects of the spec that benefit our day to day forward.

In-fact the decorator spec is largely championed by @wycats

@pixelhandler

This comment has been minimized.

Copy link
Contributor

pixelhandler commented Apr 22, 2016

Going foward should this "feature" issue be tracked in the emberjs/rfcs repo?

@locks

This comment has been minimized.

Copy link
Contributor

locks commented Apr 22, 2016

^ agreed

@locks locks closed this Apr 22, 2016

@rosshadden

This comment has been minimized.

Copy link

rosshadden commented Apr 22, 2016

Please link us to whatever the spiritual successor of this issue ends up being once it is created, so those of us that are interested may subscribe to it.

Thanks.

@mixonic

This comment has been minimized.

Copy link
Member

mixonic commented Apr 24, 2016

@rosshadden watching the https://github.com/emberjs/rfcs repo is the best bet for you to stay up to date on how this happens. I highly doubt whoever takes the next steps would remember to update this ticket directly, even if they knew it exists (the next person to move on it might be someone we don't know today)!

@lolmaus

This comment has been minimized.

Copy link

lolmaus commented Apr 24, 2016

Why have we closed this before an RFC was created?

Normally such action means a rejection.

@mmun

This comment has been minimized.

Copy link
Member

mmun commented Apr 24, 2016

This issue tracker is for bugs only. Features go in the RFCs repository. For more details read https://github.com/emberjs/ember.js/blob/master/CONTRIBUTING.md#requesting-a-feature.

@emberjs emberjs locked and limited conversation to collaborators Apr 24, 2016

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Apr 24, 2016

Normally such action means a rejection.

not here

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Apr 24, 2016

basically, the primary barrier is:

EcmaScript decorators stability

We are working on it from TC39 side of things.

@wycats

This comment has been minimized.

Copy link
Member

wycats commented Apr 24, 2016

Why have we closed this before an RFC was created?
Normally such action means a rejection.

I understand why you might have felt that way, and we probably should have been clearer: moving to standard JavaScript classes is a top-priority for us. It requires careful design and interoperability work, and as Stef said, any plausible transition will require JavaScript decorators.

I am working on decorators at TC39 and hope to advance them far enough in the next meeting (in Munich) that we can start seriously starting to plan a transition.

@emberjs emberjs unlocked this conversation Apr 24, 2016

@wycats

This comment has been minimized.

Copy link
Member

wycats commented Apr 24, 2016

I unlocked the conversation, but would suggest that any further discussion to lay the groundwork for this feature should happen in an issue on the RFC repository, and should probably either present or wait for a straw-man that uses JavaScript decorators.

@chadhietala

This comment has been minimized.

Copy link
Member

chadhietala commented Apr 25, 2016

Just a reminder we could very well be be doing static analysis and compiling to what decorators would compile to in Babel or TypeScript. While there are ergonomic things at steak from the consumer point of view, there are some performance benefits of doing this as well.

@stefanpenner

This comment has been minimized.

Copy link
Member

stefanpenner commented Apr 25, 2016

@chadhietala ya, if done right we can avoid the applyMixins costs we do today.

@karellm

This comment has been minimized.

Copy link

karellm commented Jan 9, 2017

Is there any update on this? Thanks!

@locks

This comment has been minimized.

Copy link
Contributor

locks commented Jan 9, 2017

@karellm not yet, still work to do and decorators are only stage 2!

@knownasilya

This comment has been minimized.

Copy link
Contributor

knownasilya commented Jan 9, 2017

stage 2 means ember needs to be on it.. 😄

@tatyahoo

This comment has been minimized.

Copy link

tatyahoo commented Mar 23, 2017

It looks like ES6 classes for Ember are already supported using ember-cli-babel...Is there some other "official" way to do it or is that still on hold?

@knownasilya

This comment has been minimized.

Copy link
Contributor

knownasilya commented Mar 23, 2017

@tatyahoo babel allows classes, but Ember has Ember.Object which is used throughout the framework for things like observing properties, unknown properties, etc., so moving to classes isn't so simple.

@tatyahoo

This comment has been minimized.

Copy link

tatyahoo commented Mar 23, 2017

@knownasilya So does that mean that even though the below code works, it's not functioning the same as the normal way and unsafe?

import Ember from 'ember';

const {
  Component
} = Ember;

export default class extends Component {
  
}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment