Non-cached mode about ember-decorators

[stefanpenner]

We don't plan to support this here, as the plan is for volatile to merely be a raw es5 getter

[blia]

@stefanpenner Ok. It's rightly. Thanks.

[blia]

Maybe some mode with memorize decorator?
What do you think of it? Discussed?

[stevesims]

@stefanpenner I just tried to use a raw es5 getter to make what's effectively a volatile CP within a component but found that when the getter code is run this is the raw JS object for the component definition, rather than the run-time instance of the component, thus this.get and this.getProperties are not defined.

The old style syntax of Ember.computed(function() {}).volatile() as per the example above works OK. Given the syntax of how a component is currently made (using Ember.Component.extend(...)) it makes sense that an es5 getter won't work, and an old style volatile CP will, but it feels a bit icky to have to use old-style computed syntax alongside decorators.

Feels like it would be nice to have a @volatile, at least in the short term

[rwjblue]

Kind of annoying, but you cannot use the ES6 shorthand for defining getters/setters at .extend time right now.

// does not work
export default Ember.Component.extend({
  get foo() {
    return 'hi';
  }
});

// Works, but definitely not as pretty:
const Thing = Ember.Component.extend({});

Object.defineProperty(Thing.prototype, 'foo', {
  get() {
    return 'hi';
  }
});

export default Thing;

Small demo: http://rwjblue.jsbin.com/bofijik/edit?html,js,output