[BUG] arrow functions with Ember.computed have this as undefined about ember-cli-babel

[gordonkristan]

@bartocc Yes, you must use the old-style anonymous function, not the arrow functions. Arrow functions, by definition, are bound to their lexical scope and the scope cannot be changed. If you need to access this in your property, an arrow function simply won't work.

[rwjblue]

I believe that the transpilation is correct. At the time that the Ember.computed(()=>{}) bit is processed this is the module scope (which is undefined due to being in "use strict" mode). Ember ensures that the computed is called with the correct this context, no () => { } is needed here.

[sivakumar-kailasam]

@rwjblue My bad. Played around the interactive babel editor and understood how the transpilation works in this and few more cases 😄

[stefanpenner]

as soon as the spec settles, we will get/enable annotations, which will likely unlock the following syntax

class Foo extends Ember.Object {
  @dependsOn('firstName', 'lastName')
  get fullName() {
    ...
  }
}

this gives us the nice concise syntax we crave

[sivakumar-kailasam]

yeah can't wait for that to be out 😄 feels more natural.

[stefanpenner]

ya, we are working to nail down some of the other semantics, but hopefully soon :)

[bartocc]

@rwjblue when you say "no () => { } is needed here", do you mean we MUST use "function() {}" instead or is there another way ?

[bartocc]

@sivakumar-kailasam I'd be interested to know if you managed to have computed properties work with fat arrow functions in the end

[sivakumar-kailasam]

@bartocc I didn't. I'm planning to use @rwjblue's ember-computed-decorators which is a step towards what @stefanpenner had mentioned

[bartocc]

Thx guys. things are clear now ;-)

[SathishkumarThangavel]

does this problem solved now?