Skip to content
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

Use "real" rootElement for DOM interaction helpers. #295

Merged
merged 7 commits into from
Dec 31, 2017

Conversation

rwjblue
Copy link
Member

@rwjblue rwjblue commented Dec 30, 2017

Extracts a getRootElement utility function (used by getElement and waitFor). The utility is private for now, but may be made public in the future (needs more docs at the least).

The basic gist is that getRootElement should search relative to the rootElement of the application (when setApplication was used), and not scoped to the first .ember-view inside that element. This ensures that elements added to the rootElement (e.g. via ember-wormhole / liquid-wormhole) can also be interacted with.

Also updates setupRenderingContext to use the applications designated rootElement (as opposed to always using #ember-testing). This brings setupRenderingContext in line with setupApplicationContext, and now properly uses the specified rootElement.

Prior to this, when using setApplication(...) with a different rootElement set than #ember-testing the event dispatcher would be setup to listen on a different element than the one that is actually being rendered into...

rootElement = '#ember-testing';
} else {
rootElement = owner.rootElement;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this not using the extracted helper function?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, I'll double check that all supported ember versions support calling appendTo with an actual element (as opposed to a selector string, which is being used here), but I totally agree that it makes sense to avoid double encoding this concept (and is why I removed the complete hard coding to begin with).

This brings setupRenderingContext in line with setupApplicationContext,
and now properly uses the specified `rootElement`.

Prior to this, when using `setApplication(...)` with a different
`rootElement` set than `#ember-testing` the event dispatcher would be
setup to listen on a different element than the one that is actually
being rendered into...
Using `Node.prototype.nodeType` is a better way to detect this...
The utility is private for now, but may be made public in the future
(needs more docs at the least).

The basic gist is that `getRootElement` should search relative to the
`rootElement` of the application (when `setApplication` was used), and
_not_ scoped to the first `.ember-view` _inside_ that element. This
ensures that elements added to the `rootElement` (e.g. via
`ember-wormhole` / `liquid-wormhole`) can also be interacted with.
The tests previosly avoided using `setupContext` /
`setupRenderingContext` / `setupApplicationContext` and instead relied
on internal private API details around _how_ the selectors are found.

This refactors the DOM interaction helper tests to use
`setupContext`, which is much closer to "reality"...
The tests use `setupContext` / `setupRenderingContext` which do not work
in Ember 2.0.0.
@rwjblue rwjblue merged commit c27850b into emberjs:master Dec 31, 2017
@rwjblue rwjblue deleted the root-element-tweaks branch December 31, 2017 01:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants