ES6 classes broken in various ways about ember-decorators HOT 10 CLOSED

Just noting this down for fellow sufferers. There are a few class attributes like tagName or classNameBindings that need to be specified before the base class's init() method is called.

There are two ways that I know of. I currently prefer the first one because of the slightly less verbose syntax:

export default class extends Component.extend({
  styles,
  tagName: 'span',
  localClassNameBindings: ['iconTrueColored', 'iconFalseColored']
}) {
 layout = layout;

 // ...
}

export default class extends Component {
  layout = layout;

  init() {
    // set class attributes first
    this.tagName = 'span';
    this.styles = styles;
    this.localClassNameBindings = ['iconTrueColored', 'iconFalseColored'];

    // then call base class's init
    super.init(...arguments);

    // other init stuff goes here
  }

  // ...
}

from ember-decorators.

@pzuraq isn't it a hard error to access this in a constructor before calling super()?

from ember-decorators.

The first problem is explained by the fact that constructor is called after init and didReceiveAttrs.

from ember-decorators.

Correction: constructor is called before init, however the constructor of Ember.CoreObject instantly calls init etc, before returning to the derived constructor.

export default class extends Component {
  foo = 'bar';

  constructor() {
    console.log('constructor (pre super)');
    super();
    console.log('constructor (post super)', this.foo);
  }

  init() {
    super.init(...arguments);
    console.log('init', this.foo);
  }

  didReceiveAttrs()  {
    this._super(...arguments);
    console.log('didReceiveAttrs', this.foo);
  }
}

constructor (pre super)
init qux
didReceiveAttrs qux
constructor (post super) bar

The transformed Babel output makes clear why foo has a different value:

    function _default() {
      _classCallCheck(this, _default);

      // code before `super();`
      console.log('constructor (pre super)');

      // base constructor gets called here
      var _this = _possibleConstructorReturn(this, (_default.__proto__ || Object.getPrototypeOf(_default)).call(this));

      // default values are set
      _this.foo = 'bar';

      // code after `super();`
      console.log('constructor (post super)', _this.foo);
      return _this;
    }

So that's an explanation for the first problem. Second problem still unsolved.

Maybe this issue should be moved to Ember.js itself?

from ember-decorators.

We've been discussing and putting together an RFC for the behavior of Ember.Object's constructor, which was not public API up until this point. So far it looks like it does need to be refactored, but class properties still won't be overwritten by values passed into create. Instead, you'll have to intercept them in the constructor:

export default class extends Component {
  constructor(props) {
    props.foo = props.foo === undefined ? 'bar' : foo;

    super(props);
  }
}

This is a little inconvenient and counterintuitive compared to today's behavior, but it makes much more sense if/when components start behaving more like Glimmer components where all args are passed in to the component on args:

export default class extends Component {
  foo = 'bar'

  constructor(props) {
    super(props);

    console.log(this.foo); // 'bar';
    console.log(this.args.foo); // 'qux';
  }
}

This is what sold me on keeping the behavior this way, it actually gets rid of the merge behavior of old components and creates a clear separation between args that are passed in and properties that are defined on the class, one that cannot be overwritten. However, I do think the new behavior will be unintuitive to current Ember users.

from ember-decorators.

@dfreeman yup, but these two lines can be swapped, I think

from ember-decorators.

That's a typo, will update in a sec. The idea is that you modify the properties as the come in, before they're set on the object.

from ember-decorators.

👍 Gotcha, just making sure I understood correctly

from ember-decorators.

We should add some decorators specifically for handling those special component API's (tagName, classNames, classNameBindings, are there others?). Can you open a separate issue for that?

from ember-decorators.

Most of these issue have been addressed in the ES Classes RFC, going to close this in favor of discussion there and fixes upstream in CoreObject

from ember-decorators.