App.MyController = Ember.Controller.extend({
activity: false,
activate: function() {
if (!(this.get('activity'))) { // if 'activity' is false, make it true
this.toggleProperty('activity')
}
}
});
App.MyView = Ember.view.extend
classNameBindings: ['isShown:active:'],
isShown: false,
show: function() { // toggle 'isShown' when 'controller.activity' changes
this.toggleProperty('isShown')
}.observes('controller.activity'),
hide: function() { // when 'isShown' is true, we can turn off 'controller.activity'
if (this.get('isShown')) {
this.toggleProperty('controller.activity')
}
}
This works in RC-5 very well, controller.activity and view.isShown are false when application initialized, but when I upgrade to RC-6, view.isShown will automatically turns to true when application initialized, then it breaks everything related.
Anyone can explain me why view.isShown will be true by default? It doesn’t make sense to me. I’m sure nothing trigger the activate method when app is initializing, and I double checked these two properties:
I can make a little tweak to make it work as I wish, but still don’t understand why it is different between RC-5 and RC-6, is it a BUG or some internal changes?
BTW, I’ve checked the CHANGELOG, but no luck with this issue.
It seems that as of RC.6 a view’s controller property will change after instantiation. Anything that observes 'controller' or 'controller.property' will be triggered immediately (and somewhat unexpectedly for those of us that were used to the previous behaviour). Best guess — this is something to do with the new view re-use strategy, but don’t hold me to that.
Reading through the docs for views, I gather that because controller is the default context of the view, you shouldn’t ever need to use 'controller.property' explicitly — just 'property' will do the trick. Taking this approach should protect you from observers firing at unexpected times.
Just double-checked, and I was wrong in my assumption that you can observe just 'property' from within the view — that doesn’t work. You have to observe 'controller.someProperty' and so it’s definitely a problem that the observer fires immediately.
@jgwhite If it is indeed a new change while not a bug in RC.6, well I think it’s not good enough because of the incautious side-effect, it forces me to write anti-logic codes which makes me feel very unnatural.
So, you’re right, it is definitely a problem. How should we help to fix it?
I just checked this against RC.4 and RC.5 and the behaviour is the same — observers of 'controller' defined on views fire by the time they’re inserted into the DOM. I’m not sure Ember has ever made any guarantees about a view’s 'controller' property not changing post-instantiation.
But the same code works totally different in RC.5… how to explain that? No matter Ember guaranty this behavior or not, at least it should be stay the same in every version. If it has to be changed, developers should also be noticed about it, am I right?
Anyway, thanks for your patience. I’m not complaining, I just don’t feel comfortable about this.
@nightire Since it seems like a bug, could you please close this discussion topic and file an issue in GH ? If you could provide a jsbin/jsfiddle reproducing the two different behaviors, it would be great
That beeing said, perhaps something has changed during the view/controller wiring, so that instead of the view is instantiated with the controller, perhaps now the controller is beeing set later, so the observer fire… just a guess though, not sure at all…
Yeah, a JSFiddle would be awesome. There are a few toggleProperty calls in your example above which make it a little difficult to isolate the issue.
I’m less convinced this is strictly a bug though, more a gotcha that could be documented, i.e.:
The controller property will change during a view’s lifecycle, so be careful when defining observers within views to 'controller.someProperty' as the may fire earlier than you expect.