-
-
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
[BUGFIX lts] Ensure setter CP's with dependent keys on curly components can be two way bound #19028
[BUGFIX lts] Ensure setter CP's with dependent keys on curly components can be two way bound #19028
Conversation
Co-authored-by: Robert Jackson <me@rwjblue.com>
6f70130
to
acc8100
Compare
953406e
to
7e6a91b
Compare
7e6a91b
to
ae0c5d8
Compare
packages/@ember/-internals/glimmer/tests/integration/components/curly-components-test.js
Outdated
Show resolved
Hide resolved
packages/@ember/-internals/glimmer/lib/component-managers/curly.ts
Outdated
Show resolved
Hide resolved
472e373
to
5a7e166
Compare
Added a few reviewers... |
@rwjblue - we have some scenarios where this appears to not completely fix the issue. We're working on further small-scale reproduction, as we can't quite extract it from our application code, but we do have several other instances of computed properties still not successfully updating up to their two-way bound parents. I'll let you know if we're able to successfully provide smaller-scale reproductions. |
Gut instinct right now tells me it has something to do with two-way binding to properties inside an object ( |
does the observer have to be a sync observer? Can it be async? |
Ya probably, I'll test. |
After discussing with @pzuraq (offline) I think I'm also going to see if it is possible to do from the CP side (instead of the curly component manager side). Specifically, the thought process is that we instantiate many more |
01f7224
to
1f35753
Compare
1f35753
to
f2e8c2d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
* Change guard for setting observer up to use `this` instead of `descriptorForProperty` * Check for `obj[PROPERTY_DID_CHANGE]` and `obj.isComponent` instead of `instanceof Ember.Component` * Move observer setup outside of `try`/`finally` * Use arrow function for observer (instead of `Function.prototype.bind`)
d6f61f5
to
dbebd35
Compare
Chatted a bit with @krisselden about the updated fix here, we need to do a (hopefully) quick performance test to confirm this does not introduce a regression for existing apps. I believe that @pzuraq mentioned that he would run the comparison. |
Benchmarked, and this doesn't appear to have a significant impact. We're good to merge! Thanks a ton @richgt! |
No description provided.