// app/instance-initializers/foo.js
export default {
name: 'foo',
initialize(instance) {
let owner = Ember.getOwner(instance);
owner === instance; // this is false today
}
}
In the above example, it seems reasonable that owner === instance.
@dgeb - Any objections?
I believe that an _engine_ instance's owner might be better represented by its parent, but it seems reasonable that an _app_ instance's owner be itself.
What is the use case motivating this?
It should be undefined unless it was created by a lookup(...).
I ran into this issue today and I do feel like it is a bug but more from the viewpoint of expected API rather than programmatic correctness.
Everywhere else I can use Ember.getOwner(something) to get access to the owner, but when it doesn't work with the instance, I have to just know that the instance itself is the owner. I got confused at first and opted for instance.container, which then spit out a deprecation. Finally led me to this bug.
I feel like this behavior breaks the principle of least surprise.
I think an instance owning itself would be a bit nonsensical
@mixonic I agree, with the caveat of how would we educate devs that the appInstance IS the owner and that you don't need to use Ember.getOwner?
This also may be an artifact of the "owner" concept being new and relatively undocumented.
@bryanaka @dgeb @locks @mixonic @mmun @rwjblue @toddjordan is this still an issue, perhaps we should close; what do you think?
@pixelhandler this is still an issue I run into with newbies in initializers, test land, and legacy code bases, but I haven鈥檛 seen it come up in the new testing APIs and docs are clearer on initializers now.
I鈥檇 be fine closing personally - I agree with @mixonic that an appinstance owning itself is nonsensical and that it was an education problem. I think that鈥檚 mostly solved now.
Thank you for the update, I will be closing it!