-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix multiplicative observation of controllers in views #12414
Conversation
A test would be ideal, that way if we find a regression or need to build on it, we have some confidence in our changes. Thank you for digging into this. |
@stefanpenner added a test and verified it failed before this fix. |
@trentmwillis very nice, thank you for taking the time. @wycats @ef4 @tomdale @krisselden I would love to double check this solution with one of you |
Looks good to me. |
Fix multiplicative observation of controllers in views
Oops. These should have been bugfix release.... @rwjblue paging you to fix my mistake :p |
@stefanpenner - release or release-1-13?
|
I would favor release-1-13, unless there is some hurdle that makes the backport nontrivial. |
|
@stefanpenner or @ef4 - was this put in a 1.13 release? I was looking through the changelog and didn't see this issue referenced anywhere. |
Yeah, I missed this (since it didn't have a commit prefix). |
Just pushed to release-1-13 branch. Assuming that the Travis build passes properly, the builds will be available from bower via |
Thanks for that @rwjblue. I'll make sure to pull that down and give it a look once the build goes through. |
@rwjblue - pulled down that release and all is working well. At least the issue I was having with these transitions are resolved 😄 |
@rwjblue any idea when this will be cut in a 1.13 release? Not sure if you were waiting on anything else before cutting a release. |
I don't see a bunch of value in tagging for just one change, when the builds (both S3 and bower) are available. I generally batch a few changes up before releasing... |
That's fair. I'll just continue with the |
I confirm that this fixed my problem with poor rendering performance of the component in the app I was working on. |
Addresses issue #12016.
Root cause: when the controller changed for a view, it would notify all of it's descendant views which would in turn notify all of their descendant views resulting in a multiplication of work, especially when many descendants are involved.
Solution: when the controller changes for a view, only notify it's immediate children.