fix(TS): waitForElementToBeRemoved: fix return type (#631)

1) Resolve to the type param T

Keeping references to removed elements is a probable source of bugs and
confusing tests. A reference should be easy enough to obtain with other
test utilities; I submit that there's no added value in providing it
here.

2) Resolve to boolean (or literal `true`)

Not a bad choice by any means, but not particularly meaningful (the
fulfillment of the promise is signal enough IMO)

3) Resolve to something empty
This is what I've gone with. We are _literally_ waiting for removal,
after all :)

Fixes #610

Author: tjefferson08

src/__tests__/wait-for-element-to-be-removed.js

@@ -77,6 +77,18 @@ test('requires an unempty array of elements to exist first (function form)', ()
   )
 })
 
+test('after successful removal, fullfills promise with empty value (undefined)', () => {
+  const {getByTestId} = renderIntoDocument(`
+  <div data-testid="div"></div>
+`)
+  const div = getByTestId('div')
+  const waitResult = waitForElementToBeRemoved(() => getByTestId('div'), {
+    timeout: 100,
+  })
+  div.parentElement.removeChild(div)
+  return expect(waitResult).resolves.toBeUndefined()
+})
+
 describe('timers', () => {
   const expectElementToBeRemoved = async () => {
     const importedWaitForElementToBeRemoved = importModule()

src/wait-for-element-to-be-removed.js

@@ -34,14 +34,14 @@ async function waitForElementToBeRemoved(callback, options) {
       result = callback()
     } catch (error) {
       if (error.name === 'TestingLibraryElementError') {
-        return true
+        return undefined
       }
       throw error
     }
     if (!isRemoved(result)) {
       throw timeoutError
     }
-    return true
+    return undefined
   }, options)
 }
 

types/wait-for-element-to-be-removed.d.ts

@@ -3,4 +3,4 @@ import { waitForOptions } from "./wait-for";
 export function waitForElementToBeRemoved<T>(
     callback: (() => T) | T,
     options?: waitForOptions,
-): Promise<T>;
+): Promise<void>;