Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
fix: treat shadow DOM elements as in the document #298
I changed the function to use getRootNode instead.
All existing tests pass with these changes, but let me know if you can think of any edge cases I missed.
I am not sure what the browser support requirements are for this library, but
@@ Coverage Diff @@ ## master #298 +/- ## ========================================= Coverage 100.00% 100.00% ========================================= Files 23 23 Lines 315 315 Branches 72 72 ========================================= Hits 315 315
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)
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.