-
-
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
[Ember 2.9-beta2] Missing render revalidation in production build #14298
Comments
Thank you for the detailed error report! Would you mind creating a repo with a test that passes with |
Yes, here you go: https://github.com/kanongil/render-fail |
Awesome, thank you! |
[BUGFIX beta] Fixes #14298 rendering aliased paths
When dirtying an object, other objects with aliases that path through this object should dirty as well. (cherry picked from commit 1cb8975)
@rwjblue @kanongil I have a feeling that the removal/move of:
has caused some issues. Our bower upgraded automatically from a working v2.9.0-beta.2 to v2.9.0-beta.3,, and a src binding against an image tag stopped working. I'd love to create some re-create some steps here, but it's an enormous app and hard to dig out, but basically switching back to beta2 in bower solves the issue. Seen as this is largely the only change in the bower shim for beta3 (components/ember@1721af7), I think this may cause issues. I can't be of more help atm, but something to look out for, should others start reporting issues with bindings, specifically image src bindings. |
That said, this also may be that we're still on -beta2 in npm though too, so this may throw it. |
There is a separate issue open for img src issues (I don't think it's related to this change). |
@rwjblue Ok, can you point me to it? |
Perfect, thanks! |
When dirtying an object, other objects with aliases that path through this object should dirty as well.
I tried to update my app to v2.9.0-beta2 in which I encountered a rendering regression, where some of my UI failed to update after an initial render, deferring it until another part of the UI needed revalidation.
While I did expect some corner cases to have issues, I did not expect it to only appear when using the production builds, as this does!
I have spent some time to isolate the cause, and I ended up with this code on top of a brand new
ember init
project:app/templates/application.hbs
app/controllers/application.js
ok
.fail
.Notes:
{{object.value}}
instead, it renders correctly in both cases.this.get('value')
always gets the correct value.canary
build.The text was updated successfully, but these errors were encountered: