Document confusing behavior with waitForElementToBeRemoved

[kentcdodds]

So, I added this feature:

- await waitForElementToBeRemoved(() => screen.getByText('foo'))

+ const element = screen.getByText('foo')
+ await waitForElementToBeRemoved(element)

Both work, but the first I think is easier most of the time.

But I just learned that in React applications (and likely other frameworks) the DOM nodes aren't always removed, rather they're updated. So, that cool new feature won't always work as you might expect. I think we should probably document this somewhere.

[eps1lon]

the DOM nodes aren't always removed, rather they're updated.

Do you have an example for that?

[alexkrolick]

yeah, wrangling references to nodes like that is how you end up with wrapper.update() in Enzyme

[kentcdodds]

Do you have an example for that?

I ran into this during my livestream. It was a DOM node where I was rendering <h1>Loading title</h1> and when the title loads I change it to <h1>The Title</h1>

[eps1lon]

Hmm I guess the problem is that removal is actual an implementation detail? What we're actually asking is: "Wait until this selector no longer matches an element". In which case await waitForElementToBeRemoved(() => screen.getByText('foo')) is easier to implement. We have to find a smart observer that observes any change that the might affect the element matched. I think the easiest way is to listen to subtree changes of the element that is returned first.

[kentcdodds]

Yeah, I'm thinking that the recommended (and primary documented) approach is the callback approach and people can pass a DOM node if that works for them. 🤷‍♂️

[shermanhui]

Hey all, I opened up a draft PR to add the documentation. I've summarized the thread and added that to waitForElementToBeRemoved's documentation in api-async.md.

If anyone has some time to provide some assistance, I'm having some trouble with adding examples to help illustrate the points discussed in this thread. I've linked the two sandboxes in my PR - it'd be great to get more context onto what the exact issue was so that we could add an example of what didn't work.

Thanks!

[nikkhielseath]

I noticed that this issue is still open. Let me know if I can assist in resolving it or perhaps re-create an MR based on the changes from the linked MR. (with proper citations to the original MR author :) )

[MatanBobi]

I noticed that this issue is still open. Let me know if I can assist in resolving it or perhaps re-create an MR based on the changes from the linked MR. (with proper citations to the original MR author :) )

@nikkhielseath Feel free to take it, as you said this is still open :)

[nikkhielseath]

Sure, I am picking it up. Thank you. :)

…

On Sun, 14 Apr 2024 at 11:50 am, Matan Borenkraout ***@***.***> wrote: I noticed that this issue is still open. Let me know if I can assist in resolving it or perhaps re-create an MR based on the changes from the linked MR. (with proper citations to the original MR author :) ) @nikkhielseath <https://github.com/nikkhielseath> Feel free to take it, as you said this is still open :) — Reply to this email directly, view it on GitHub <#409 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AMIIUQCZO53TRVWWRLRYV6TY5INZDAVCNFSM4LQSKP2KU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVGM4TEOBQGMZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>