[BUGFIX beta] Fix issues with revalidation during teardown.#14110
Merged
rwjblue merged 2 commits intoemberjs:masterfrom Aug 23, 2016
Merged
[BUGFIX beta] Fix issues with revalidation during teardown.#14110rwjblue merged 2 commits intoemberjs:masterfrom
rwjblue merged 2 commits intoemberjs:masterfrom
Conversation
Member
Author
|
I have uploaded the assets to make it a bit easier to test this in an ember-cli app. All you should need to do is change your "ember": "~2.8.0-beta.1",To: "ember": "rwjblue/ember#pr-14110", |
Member
Author
|
Since @krisselden worked on #13775, I'd love his review here... |
backspace
added a commit
to travis-ci/travis-web
that referenced
this pull request
Aug 22, 2016
Contributor
|
I confirm that this branch fixes the test suite for Ember Power Select: https://travis-ci.org/cibernox/ember-power-select/jobs/154144524#L332 |
2a64c3f to
3dd760c
Compare
When the toplevelView (aka `ownerView`) is being destroyed (during test
teardown generally) an error was ocurring under certain "special"
circumstances. Specifically, if removal of a sibling node triggered a
revalidation of one still attached.
Consider the following example:
```hbs
{{#x-select as |select|}}
{{#select.option value="1"}}{/select.option}}
{{#select.option value="2"}}{/select.option}}
{{/x-select}}
```
The components in question are using the registration pattern so that
the children notify/register with the parent upon `didInsertElement`
(and `willDestroyElement`).
When a new option is added or removed from the parent, it updates its
`value` property which is bound to each options `selected`
attribute (to toggle the selection state in the DOM).
The specific mechanism that causes the DOM to get updated when the
various computed properties change is that a Stream object calls
`ownerNode.emberView.scheduleRevalidate`. This tells the rest of the
system to start walking the tree to flush out any updates to the DOM.
When a view is being removed, we set the `emberView`
property of its `renderNode` to `null` before traversing the subtree of
children. This means, that as the children are removed (and therefore
cause the `value` of the parent to change) the `selected` attribute
binding attempts to call `ownerNode.emberView.scheduleRevalidation()`.
Unfortunately, when we are actually tearing down the
`ownerNode.emberView` itself that invocation results in an error (
cannot call `scheduleRevalidation` on `null`).
---
This change adds a simple guard to avoid calling `scheduleRevalidation`
when the `ownerNode.emberView` is being torn down.
3dd760c to
2fa4015
Compare
|
Thanks so much for this fix! |
Contributor
|
@rwjblue Could you port this commit to the beta branch so ember-try pulls the fix and addons got pretty green travis badges again 😄 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When the toplevelView (aka
ownerView) is being destroyed (during test teardown generally) an error was ocurring under certain "special" circumstances. Specifically, if removal of a sibling node triggered a revalidation of one still attached.Consider the following example:
The components in question are using the registration pattern so that the children notify/register with the parent upon
didInsertElement(andwillDestroyElement).When a new option is added or removed from the parent, it updates its
valueproperty which is bound to each optionsselectedattribute (to toggle the selection state in the DOM).The specific mechanism that causes the DOM to get updated when the various computed properties change is that a Stream object calls
ownerNode.emberView.scheduleRevalidate. This tells the rest of the system to start walking the tree to flush out any updates to the DOM.When a view is being removed, we set the
emberViewproperty of itsrenderNodetonullbefore traversing the subtree of children. This means, that as the children are removed (and therefore cause thevalueof the parent to change) theselectedattribute binding attempts to callownerNode.emberView.scheduleRevalidation().Unfortunately, when we are actually tearing down the
ownerNode.emberViewitself that invocation results in an error ( cannot callscheduleRevalidationonnull).This change adds a simple guard to avoid calling
scheduleRevalidationwhen theownerNode.emberViewis being torn down.Fixes #13846.
Fixes #13968.