Description
Describe the feature you'd like:
@alexkrolick has brought this up before and we ultimately decided to not go for it at the time, but I've been thinking about it more and I think it's time to revisit the decision.
There are some UI frameworks that are completely async. In my TestingJavaScript.com course when I show how to use dom-testing-library with these, I had to create a fire-event-async.js file to deal with those, but that wasn't enough for mithril's tests because mithril does not re-render on the next tick all the time (for who knows what reason 🤷♂️).
The findBy* and findAllBy* variants of the queries would return promises that resolve when the query is satisfied, or timeout after 3500ms or so.
Suggested implementation:
I'm thinking it'd be something like this:
const findByText = (...args) => waitForElement(() => getByText(...args))
const findAllByText = (...args) => waitForElement(() => getAllByText(...args))Describe alternatives you've considered:
So far the alternative is to have people write this themselves:
const successMessage = await waitForElement(() => getByText(/.*success.*/i))
expect(successMessage).toHaveTextContent('Welcome back Nancy')That's worked pretty well most of the time, but I think it would be nicer to write that like this:
const successMessage = await findByText(/.*success.*/i)
expect(successMessage).toHaveTextContent('Welcome back Nancy')Teachability, Documentation, Adoption, Migration Strategy:
We do have query explosion going on and I think the docs could be improved slightly around this to document first the types of queries (label text, text, placeholder, etc), and then the variants (getBy*, queryAllBy*, etc.).
This would be a new feature, so no breaking change/migration strategy necessary.