-
Notifications
You must be signed in to change notification settings - Fork 399
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
fix: treat shadow DOM elements as in the document #298
fix: treat shadow DOM elements as in the document #298
Conversation
Codecov Report
@@ Coverage Diff @@
## master #298 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 23 23
Lines 315 315
Branches 72 72
=========================================
Hits 315 315
Continue to review full report at Codecov.
|
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.
@geoffrich nice idea!
It looks good, and looks safe to me.
Ready to merge? |
yup, I forgot about it. One thing: I'm not 100% this is a patch release (a fix). Isn't this potentially breaking tests to others that may have had stuff under shadow DOM that were not found? (apologies if this makes little sense, I'm not 100% familiar with shadow dom) |
That depends on whether we consider not discovering shadow DOM elements as a bug from the previous version. |
It's possible that someone has a test depending on this behavior, but I think it's unlikely. Testing Library queries do not currently return any elements in the shadow DOM -- they use Here's an example with the custom element I defined in the tests: const customElement = document.querySelector('custom-element');
const shadowDiv = customElement.shadowRoot.querySelector('div');
expect(shadowDiv).not.toBeInTheDocument(); // passed before my commit, and will now fail So it's potentially a breaking change for that kind of test, but that test seems contrived -- what's the point of expecting the shadowDiv to not be in the document? It was a brittle test, because it would have also passed if querySelector returned nothing. If they were doing something like this, it's more likely that they would expect shadowDiv to be in the document (as I did) and be confused when it didn't work. That was my rationale for treating this as a bug and not a new feature. However, I don't care too much one way or another, so I can reword the commit if you like. |
It is a fairly specific example and I agree it's contrived, so it sounds like a bug to me, and therefore not a breaking change. I'm interested in what other maintainers think about it though. |
@all-contributors please add @geoffrich for code, test, idea, bug |
I've put up a pull request to add @geoffrich! 🎉 |
🎉 This PR is included in version 5.11.5 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
What:
expect(element).toBeInTheDocument()
would return false whenelement
was in a shadow root. It now returns true.Why:
I want
toBeInTheDocument
to treat elements in a shadow root as in the document. I am experimenting with using Testing Library on apps that use custom elements.How:
toBeInTheDocument
originally checked thatelement.ownerDocument.contains(element)
was true. However, this returns false if the element being checked is within a shadow root.I changed the function to use getRootNode instead.
getRootNode
will return the element's root (usually either the document or the element's shadow root). Passing{composed: true}
will return the document instead of any shadow roots, so we can compare this toelement.ownerDocument
to see if the element is in the document.All existing tests pass with these changes, but let me know if you can think of any edge cases I missed.
Checklist:
I am not sure what the browser support requirements are for this library, but
getRootNode
does not work in IE11 and non-Chromium Edge. If that's a problem I can work on an alternate approach.