Implement wait_for_selector

[Mifrill]

closes#82

[ttilberg]

To be more consistent with the rest of the gem, would you mind changing this to use a JS heredoc? This is helpful because many editors support code highlighting in the language specified:

Original:

VS:

Subl:

Code:

I haven't tried the code out yet, but I'm looking forward to this feature!

[Mifrill]

it makes sense, will change, thanks!

[ttilberg]

I was feeling like this arguments list was a little crowded, and also noticed this function could be incorrectly called without raising an exception: one of css or xpath is required, but not handled. What do you think about something like this:

defwait_for_selector(css: nil,xpath: nil,timeout: 3000,interval: 100)raiseArgumentError.new("Provide :css or :xpath, but not both")ifcss && xpathraiseArgumentError.new("Provide :css or :xpath")unlesscss || xpathevaluate_func(<<~JS,css || xpath, !!xpath,timeout,interval,awaitPromise: true) function(selector, isXpath, timeout, interval) { var attempts = 0;

The guard clauses protect the arguments from being called incorrectly, and also simplify the resolution to isXpath, since it can now only be one or the other.

[Mifrill]

well, it looks like too much for one method to be responsible for selector/XPath and also for validations.
However, I see the confusing point here as well. In this case, I think we should use simple methods for more clear API, like those:

defwait_for_selector(css, **options)wait_for_element(css: css, **options)enddefwait_for_xpath(xpath, **options)wait_for_element(xpath: xpath, **options)end

The point to merge two ways of element-find logic was a follow a DRY principle for a common JS function, especially this part:

varelement=isXpath
? document.evaluate(selector,document,null,XPathResult.FIRST_ORDERED_NODE_TYPE,null).singleNodeValue
: document.querySelector(selector);

therefore, I think, we can find a way to refactor it with a private function by passing a js function, gimme see closer, will do an update soon.

[ttilberg]

Nice one, yes, I think this is a better direction. Consider wait_for_css rather than wait_for_selector as a selector could generically mean css or xpath. It makes the expected arg more clear.

[dsisnero]

Can this be merged? Do the linters need to be changed or do we want to follow the linter advice?

[Mifrill]

Hello @dsisnero this PR is on review, it can't be merged without approval.
The linter offenses are not related to this particular PR, we have dedicated PR to solve it:
#237 that also on review.

[route]

I'm sorry guys, with all this stuff happening I barely find time for open source now, hope it's going to calm down soon.

[Nakilon]

If anyone needs a simple substitute of assert_selector or Selenium::WebDriver::Wait.new.until &block and google leads him here, here is a simple ruby snippet to wait for arbitrary things to return true:

timeout_true=lambdado |timeout=1, &block|
Timeout.timeouttimeoutdoblock.yieldor(sleep0.1; redo)endend

[shreeve]

Any chance we could have a reviewer review and accept this? It would be very nice to have in the main Gem.

Thanks!

[shreeve]

Would this be simpler?

classFerrum::Browserdefwait_for(want,wait:1,step:0.1)meth=want.start_with?('/') ? :at_xpath : :at_cssuntilnode=send(meth,want)(wait -= step) > 0 ? sleep(step) : breakendnodeendend