This would be particularly nice for waitForElementToBeRemoved (which would benefit from this being added to waitFor) because then people could easily see what the DOM looks like and maybe why the element has not been removed.
I was just looking for this functionality for the exact same reason. Perhaps adding onTimeout option that could be used for debugging purposes?
I was thinking about that but if we add a callback onTimeout I think that the most time the user will want to show DOM elements to understand why the elements is not removed, do you have a different use case?
@marcosvega91 that works for waitForElementToBeRemoved. However for waitFor, users might possibly want to log something else. I don't have any specific use case in mind as my issue was also with waitForElementToBeRemoved, so calling screen.debug is sufficient for me at this point.
Yes waitFor has a different goal so I share with you the idea to add onTimeout propr
Ah, I can think of some use cases where a flexible onTimeout option would be more useful, e.g. we can check what arguments some mock functions are last called with.
Maybe we can have an onTimeout option that defaults to call screen.debug() :)
Yes It seams a good solution ⛄
:tada: This issue has been resolved in version 7.18.0 :tada:
The release is available on:
npm package (@latest dist-tag)Your semantic-release bot :package::rocket:
Most helpful comment
Maybe we can have an
onTimeoutoption that defaults to callscreen.debug():)