[BUGFIX release] Ensure init is completed before didReceiveAttrs fires.

[rwjblue]

Given the following example:

export default Ember.Component.extend({
  init() {
    this._super(...arguments);

    this.wasInitWithSomeThing = !!this.attrs.someThing;
  },

  didReceiveAttrs() {
    this._super(...arguments);

    if (this.wasInitWithSomeThing) {
      // do custom logic based on being `init` with `someThing`
    }
  }
});

Currently, the didReceiveAttrs (and also didInitAttrs) is firing from within the this._super() call in init (because we trigger these hooks in Ember.View's init). Which means that didReceiveAttrs can not have access to things set in init.

This change allows us to avoid that circumstance, and ensure that init is fully completed before didReceiveAttrs is fired and also ensures taht didReceiveAttrs/didInitAttrs is still fired from within the constructor before observation is started.

[stefanpenner]

maybe just call it __postInit post initialization initialization is a bit redundant

[stefanpenner]

actually, can we make this a symbol ? That way no user can use it, and it wont collide with anything else.

[stefanpenner]

I'm slightly concerned that the property miss will not be as ideal as we would want, although I suspect today it is just in the noise.

[rwjblue]

Yes, I will:

• implement as a symbol (we can always tweak later)
• add to base object to avoid property lookup (then remove if)

[rwjblue]

Updated.

[stefanpenner]

I'm unclear how this will work in ES6 class land. Unless keep init around, then something like:

constructor() {
  this.init
  this.__postInit()
}

[rwjblue]

I'm unclear how this will work in ES6 class land.

This was something that @mixonic also mentioned, and is something we should definitely decide on before merging this. I was under the impression that the idea that constructor and init are separate things would not change in ES6, if that is not the case (meaning we will make init the actual constructor) then we will also need to figure out a different path forward.

For additional context there are a few things that currently happen after init that will also need to be figured out. Things like finishChains and sending the on('init') event are both done after init today, and have the same issue as what this PR proposes.

[stefanpenner]

@rwjblue ya i think we don't have a choice but to keep the two

[rwjblue]

Adding to the next core team meeting topics, but I'd like to get @mixonic and @wycats thoughts/review before so that we can discuss in detail.

[rwjblue]

We discussed this in the 2015-09-04 core team meeting. In general it seems that we had planned to have init be separate from constructor due to the other factors that I mentioned above. As such, this does not seem contentious.

I would still like to hear from @mixonic before landing.

[mixonic]

meh, I would probably leave out the _super as it is a hook ;-)