Using elementFinder & elementFinderArray consistently across finders

[pvsundarram]

Just for the context, I am using protractor in my company (thanks to maintainers) for testing angular apps. Also I am quite new to protractor & I may not know a lot of things.

We are building complex page objects which have a clear parent child/relationship & hence the search scope is inherited from the parent page object.

It becomes difficult to expose elements(from finders in protractor) as properties because it can either be:
a. elementFinder (E.g. element(by.css('table'))
b. WebElement (E.g. element(by.css('table')).findElement(by.repeater('person in people'))
c. promise (E.g. element(by.css('table')).findElements(by.repeater('person in people'))

Right now it is not possible to call:

element(by.css('#main-content'))
    .element.all(by.css('tables.data-table'))
    .first()
    .element(by.css('buttons.user-actions'))
    .click()

Also right now all the locators used to find a element is not exposed.

If findElement & findElements is assumed to always talk to selenium(immediately), then it can be safe to assume that elementFinder(via element) & elementFinderArray(via element.all) exposes methods which return elementFinder(deferring talking to selenium) for chaining calls.

elementFinderArray can be made to return elementFinder all the time by modifying(get, first & last) along the lines:

elementArrayFinder.get = function(index) {
    return buildElementHelper(ptor, usingChain)({
        findElementsOverride: function(driver, using) {
            return using.findElements(locator)
            .then(function (items) { return [items[index]]; });
        }
    });
}

Adding a wrapFinderElement function & wrapping all elements from map & each functions will make it consistent. The similar wrapping functions can be used to wrap webelements/promises returned from other functions(findElement, findElements).

The API will be far simpler to use if all of the finder methods(atleast element & element.all.get/first/last) always return elementFinder & elementFinderArray.

I can work on a pull request if you think it will be useful/makes sense.

Please let me know, If I am missing anything or if there is a better way to do it.

Thanks

[juliemr]

Hi,

Thanks for looking into this, I agree that the situation as it stands can be confusing. I think you're right that get/first/last would make more sense if they return ElementFinders. I'm not sure about map and each - these imply "now I'm doing something with the elements", and I think it makes sense for them to be talking immediately to selenium. I'm also not quite sure what you mean by wrapping elements returned from findElement - once you've talked to Selenium, you can't go back.

[pvsundarram]

Sorry to be a little confusing on that.
By wrapping I meant to make the interface consistent i.e. any element(or set of elements) returned(regardless of whether it is deferred or returned from selenium) via protractor layer always provides elementsFinder(or elementsFinderArray) interface.

This wouldn't make sense if there needs to be a clear distinction from the finders that will defer the operations.

[hankduan]

addressed in #889

[hankduan]

Cleaned up the way elements are accessed (i.e. unified all element-related objects into ElementFinder/ElementArrayFinder). There will no longer be wrapped WebElements. Should be a easier interface to work in now. Take a look and let me know if you have other suggestions. (#896)

[pvsundarram]

Looks good!
Thanks.