we may not need the initial check at the beginning of `waitForElementToBeRemoved` about dom-testing-library

[cmorten]

As solution to this specific use-case, is something like…

test('some executions after the message is removed works as expected', async () => {
  render(<SomeComponent />);
  const targetElement = getByText('some message');

  const isRemovedPromise = waitForElementToBeRemoved(targetElement);

  // an action to remove the message
  await user.click(getByRole('button', { name: 'remove message' }));

  // wait until the message is removed
  await isRemovedPromise;

  // It is explicit that the following code is executed after the "some message" is removed
  doSomething();
})

passable? (Some care needed to handle the dangling promise with a subtle change if being strict with resource cleanup and for if the click throws)

[AngusMacrae]

The problem with your suggestion would be that it would require everyone to make an additional manual assertion like you have at the start of the test, to ensure the element exists before proceeding.

Otherwise if changed as suggested, simply doing

waitForElementToBeRemoved(screen.queryBy...)

Would no longer fail if the element never existed in the first place.

So basically it would be making the API less flexible, just for the sake of avoiding one extra check.

[tnyo43]

@cmorten
Thank you for your suggestion! That works on my cases.

[tnyo43]

it would be making the API less flexible

I think my suggestion makes the API requiring more effort, but also MORE flexible 😉

---

So how can we ensure that the element exists at the start of the waitForElementToBeRemoved?
If we use await waitForElementToBeRemoved(screen.queryBy...) after any actions to remove a element, we must consider the possibility that the element have already removed at the start of it unless we know it takes much time to complete the removing actions.

We should consider more carefully about the timing of asynchronous processing.