-
-
Notifications
You must be signed in to change notification settings - Fork 257
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
Conversation
rootElement = '#ember-testing'; | ||
} else { | ||
rootElement = owner.rootElement; | ||
} |
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.
Why is this not using the extracted helper function?
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.
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).
b5e4d2b
to
5b2d7db
Compare
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.
c926272
to
0dbcb31
Compare
Extracts a
getRootElement
utility function (used bygetElement
andwaitFor
). 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 therootElement
of the application (whensetApplication
was used), and not scoped to the first.ember-view
inside that element. This ensures that elements added to therootElement
(e.g. viaember-wormhole
/liquid-wormhole
) can also be interacted with.Also updates
setupRenderingContext
to use the applications designatedrootElement
(as opposed to always using#ember-testing
). This bringssetupRenderingContext
in line withsetupApplicationContext
, and now properly uses the specifiedrootElement
.Prior to this, when using
setApplication(...)
with a differentrootElement
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...