Type inconsistency in waitFor, waitForElement, & waitForElements

[Michael Bull]

I'm submitting a bug report

• Library Version:
  1.0.0-beta.3.0.1

Please tell us about your environment:

• Operating System:
  Linux (Fedora 25)

• Node Version:
  6.11.0

• NPM Version:
  3.10.10

• JSPM OR Webpack AND Version
  webpack 3.3.0

• Browser:
  all
• Language:
  all

Current behavior:
The type definition for waitForElement, waitForElements and waitFor define the second options argument as required (options: any). The ComponentTester's unit test suggests that the second argument is optional as it omits it entirely.

This inconsistent definition forces TypeScript users to unnecessarily pass in an empty object to satisfy the type definition, therefore I think the definition should be changed to options?: any.

This is reinforced by the official docs which state the first argument, selector, as mandatory, but pose no such restriction on the options argument.

Expected/desired behavior:

• What is the expected behavior?

  • The type definition of the second argument (options) for the waitForElement, waitForElements, and the waitFor functions should be updated to make the options argument optional (i.e. options?: any).

• What is the motivation / use case for changing the behavior?

  • Consistent type definitions with example usage and existing technical documentation.
  • Avoid forcing TypeScript users to unnecessarily pass in an empty object as the argument.

[Michael Bull]

Looks like this was fixed with #76