Interaction helpers also accept HTMLElements as first argument

[cibernox]

Closes #27

[rwjblue]

Hmm. Since all of the other helpers go through find, findAll, and findWithAssert to convert a selector to an element, I was thinking that those would be the only methods that needed modification...

[rwjblue]

Just thinking that would remove a bunch of extra conditionals (and reduce overall complexity for individual helpers), not sure if I've missed something though.

[cibernox]

I find semantically weird to call find with the element I already want it to find.

find(button); // button

Feels weird.

[rwjblue]

Ya, I agree that it's odd for users to do this, however it is quite a bit nicer to funnel the concept of "convert selector or element to an element" through a single path (versus forcing every helper to have these kinds of conditionals).

One way we could remove the user calling find(button) case is by moving the core logic of find into a private helper called _ensureElement. Then you could use that helper throughout the other helpers, and still have an assertion if end users call find without a string.

[cibernox]

I think that I'd rather do that, since allowing find(HTMLElement) in the public API is rather useless and not something real users would do. Changing it.

[cibernox]

Done. There is two private helpers. Technically find(HTMLElement) will still return the HTMLElement, but it's not documented in the public API. When we transform this to Typescript it will be enforced, not it's just part of the JSdocs.