-
Notifications
You must be signed in to change notification settings - Fork 470
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
getClosestBy* #327
Comments
There's been some discussion of this idea and its trade-offs in a few threads already: #204 (comment) Can you describe what this API would allow you do to that you can't do already? Is it testing attributes on the parent nodes? |
Understand that specifying tags/attributes in queries is testing implementation details, but there are some cases where this might be the most sane way inferring behaviour? As you say, testing attributes on parent nodes. E.g. Ensuring a button with nested span is
@kentcdodds had mentioned a hypothetical solution in #204, suggesting a |
This particular instance will be covered by #408. When this lands you'll be able to query the button with |
Yup, closing this in favor of #408. Thanks! |
Describe the feature you'd like:
I'd like to introduce
getClosestBy*
as a way to find an element that is the known element or some ancestor of it that matches one of theytesting-library
queries.For example, given the following markup, I'd like to be able to get the button by its text.
Suggested implementation:
Recursively walk up from the node and find the first node that matches.
Describe alternatives you've considered:
Use native
closest
:Walk the tree myself:
Get by a known index:
Abuse a TextMatcher:
Teachability, Documentation, Adoption, Migration Strategy:
getClosestBy*
would be togetBy*
asclosest
is toquerySelector
.The text was updated successfully, but these errors were encountered: