CollectionContition could accept `List<SelenideElement>` instead of `List<WebElement>`

The problem

It would be more convenient to use Predicate<SelenideElement> instead of Predicate<WebElement> in methods allMatch, anyMatch, noneMatch.

Details

Now folks need to implement allMatch like this:

trs.shouldBe(allMatch("all value same in column",
                    e -> e.findElements(By.tagName("td")).get(i).getText().equals(cellValue)));

it would be simpler if allMatch accepted Predicate<SelenideElement>:

trs.shouldBe(allMatch("all value same in column",
                    e -> e.findAll("td").get(i).has(text(cellValue));

Pros

The following things would be possible (which are not possible now):

• Navigation: search for inner elements using e.find("[class*='<class-part>']")
• Use execute methods from SelenideElement.
• Use pseudo-elements
• Use Conditions and other SelenideElement methods.

Note that current approach forces users to mix Selenium and Selenide syntax which is probably bad.

Cons:

I see a potential risk if folks use “waiting” methods of SelenideElement like shouldHave.
The point of $$.allMatch and other collection checks is that they can wait (if condition is not satisifed yet). If we give access to SelenideElement inside allMatch (and other CollectionCondition), folks can call methods like .shouldHave(…), and then we get “waiting inside waiting”. It may become an untrackable nightmare.

[asolntsev]

@sergiomartins8 Ok, I understand. I started thinking that probably we could add to Selenide this feature: When you execute command $$("#books .book:visible").shouldHave(size(1)), Selenide loads only the number of elements using JavaScript without fetching the whole WebElement instances from WebDriver. It would be a great optimisation.

I even think that all those checks like $$("#books .book:visible").shouldHave(texts("foo", "bar", "zoo")) could be done via JavaScript which would make them much more efficient.

I registered a separate issue for this idea: https://github.com/selenide/selenide/issues/1244.

[asolntsev]

Closing this feature request in favor of #1244.

I realized that it’s ok for Condition and CollectionCondition implementations to use Selenium API, not Selenide API. They are low-level “bricks” for Selenide, and typical users don’t need to implement them in most cases.