add init flag to observers

[krisselden]

Add a flag to indicate an observer function should be called on init.

Ember.Object.extend({
    selectionDidChange: function() {

    }.observes('selection').init() // auto call function on init
});

[workmanw]

+1 . 90% of the time I implement init: function() {} it looks like this.

Ember.Object.extend({
  init: function() {
    this._super();
    this._somethingDidChange();
    this._somethingElseDidChange();
  }
});

[lukemelia]

+1 same as @workmanw

[ebryn]

👍

[sly7-7]

I think this would answer to http://stackoverflow.com/questions/11412550/observer-are-not-called-on-create/11526098#11526098

[pangratz]

🙌

[lcoq]

@sly7-7 it does! 👍

[wagenet]

👎 I know this was discussed some with @tomhuda, though I'm not sure what the conclusion was. For my part, it's not at all obvious what this function would do. I don't see any major burden in putting things in the init method, which seems like a more correct approach anyway.

[lukemelia]

I agree the naming is confusing. Perhaps runOnInit() is better. But it feels like a simple feature that eliminates boilerplate that a lot of people encounter (as evidenced by the +1s). That seems very much in keeping the Ember philosophy.

[wagenet]

If we do anything with this, it should be after we decide on whether we alter the behavior of create.

[krisselden]

I do think it would be simpler if the super() call weren't there, if there was a postInit() hook or the current init() becomes _init() so init() doesn't need super called.

I still think people forget to think about init when creating observers.

[workmanw]

I'm not sure what the proposed alteration to create is, but with the way things work now I find value in this. I don't think there is much of a burden with putting things in the init, but the same could really be said for observers and bindings too. I just see it as an extra convenience, just saves me a little bit of time and makes my code a little more readable.

Ember.Object.extend({
  init: function() {
    this._super();
    this._somethingDidChange();
  }
  /** VS **/
  _somethingDidChange: function() {

  }.observes('something').onInit()
});

I think onInit() might be a good name, short and descriptive.

[wagenet]

@workmanw The proposed change to create is to have it behave more like setProperties. I suspect that if we made that change, initial observers would be fired so this would become a non-issue.

[krisselden]

@wagenet that proposal was made also with the suggestion the object not fire observers on init. If setProperties from create() caused observers you would still need to manually init for extend, undefined -> defined would still not be consistently a change.

onInit isn't that much clearer, autoInit maybe the most clear and terse.

create brings you to state 0, and then observers handle it after that.

[wagenet]

@kselden, are your thoughts on this still the same?

[stefanpenner]

if @kselden's thoughts are the same, we should make sure our use of `autoinit is consistent.

Then the recent change: autoInit -> autoinit should be reflected here as observes('..').autoinit()

[lukemelia]

If this is desired functionality, please assign me and I will implement. Otherwise, let's close this since it has been hanging out for 9 months.

I like this feature and would like to see it added.

[stefanpenner]

oh the world of open source, being able to assign tasks to your CTO. 👍 Luke you have been assigned!

[wagenet]

@lukemelia Are you going to do this?

[knownasilya]

👍

[guilhermeaiolfi]

Well, I thought that observers already did that: being fired after creation. I've found this issue after creating a complex component and observing its value property for doing other stuff. Every time ember transition to a view that shown that component, its value changes, but the observer is never called b/c its value is set on creation.

So +1 from me. Except that I don't think we need the flag, it should be the default behavior.

[lukemelia]

This functionality is provided for in PR #3155, in a more general way. If that PR is merged, you can do:

Ember.Object.extend({
    selectionDidChange: function() {
      // this method will be called when the object is created, as well as when selections changes
    }.observes('selection').on('didInit')
});

We can easily sugar that to .autoinit() or something similar, but let's wait and see if it's necessary.

[wagenet]

@guilhermeaiolfi, observers are NOT fired after creation. If you want to ensure that they are, you need to call them from the init hook.

[guilhermeaiolfi]

@wagenet I know that now. I was saying exactly that I think it SHOULD be fired after creation. I mean, only if the creation of that object sets the observed property (directly or by bindings).

[abrahamgreyson]

🙌