buildComponentList() is super useful, and uses nth-child for creating really nice lists of components. However if a website is designed poorly, the nth-child index logic can pull the wrong elements.
I believe we can do an instant validation on the nth-child index that scaffold would choose to build the component list to filter out indices that would produce empty/null components.
What is the current behavior of scaffold?
In the following example:
With the way that things work as is, passing a list of elements with css selector .thing which produces a list of 2 elements via findElements(), scaffold will create the following selectors:
.thing:nth-child(1).thing:nth-child(2)
Due to how nth-child functions, this will actually select the first and second <div> that does not have that class .thing, breaking the css selector filtering process and giving unusable component results in the list.
What should we change?
Add in a quick validation right before choosing the index for nth-child that the index actually does map to the correct element. This can be achieved by doing one of the following:
Making an instant native selenium with the original selector, without any nth-child attached (and with no wait time) to get the correct list of elements to use as the list to verify against
Why?
If it were possible to get the list of all nth-child components the end-user could just filter out the ones that are actually invalid, however I think having scaffold do this for you and be aware of the issues of nth-child at the indexing level is super powerful.
This will also make the list builder more robust to bad website design.
What are the risks?
There will be 1 additional lookup call via selenium to verify the potential nth-child element is respecting the css selector locator, so with a large list of elements to build a component list from, there will be N extra selenium lookup calls. But with a 0 timeout this is negligible for the reliability benefits it brings to buildComponentList().
Are there any alternatives?
For using nth-child, not that I can think of. Use of another locator base for doing index based things such as xpath would work cleaner but, adding in an xpath-based buildComponentListBuilder() would not allow for the css selector combination logic that scaffold supports to function so, that's not really a way to solve this issue for css selector based lists of components.
A/C
buildComponentList() should do some validation that, for each nth-child component it intends to build, that it does not include siblings that do not match the passed in locator.
Some unit tests around this functionality, with a website that has this bad design would be nice, perhaps a local cached *.html page that has the exact situations we're trying to address.
Summary
buildComponentList()is super useful, and uses nth-child for creating really nice lists of components. However if a website is designed poorly, the nth-child index logic can pull the wrong elements.I believe we can do an instant validation on the nth-child index that scaffold would choose to build the component list to filter out indices that would produce empty/null components.
With the way that things work as is, passing a list of elements with css selector
.thingwhich produces a list of 2 elements via findElements(), scaffold will create the following selectors:.thing:nth-child(1).thing:nth-child(2)Due to how nth-child functions, this will actually select the first and second
<div>that does not have that class.thing, breaking the css selector filtering process and giving unusable component results in the list.What should we change? Add in a quick validation right before choosing the index for
nth-childthat the index actually does map to the correct element. This can be achieved by doing one of the following:Making an instant native selenium with the original selector, without any nth-child attached (and with no wait time) to get the correct list of elements to use as the list to verify against
Why? If it were possible to get the list of all nth-child components the end-user could just filter out the ones that are actually invalid, however I think having scaffold do this for you and be aware of the issues of
nth-childat the indexing level is super powerful.This will also make the list builder more robust to bad website design.
What are the risks? There will be 1 additional lookup call via selenium to verify the potential nth-child element is respecting the css selector locator, so with a large list of elements to build a component list from, there will be N extra selenium lookup calls. But with a 0 timeout this is negligible for the reliability benefits it brings to
buildComponentList().Are there any alternatives? For using nth-child, not that I can think of. Use of another locator base for doing index based things such as xpath would work cleaner but, adding in an xpath-based buildComponentListBuilder() would not allow for the css selector combination logic that scaffold supports to function so, that's not really a way to solve this issue for css selector based lists of components.
A/C
buildComponentList()should do some validation that, for eachnth-childcomponent it intends to build, that it does not include siblings that do not match the passed in locator.Some unit tests around this functionality, with a website that has this bad design would be nice, perhaps a local cached *.html page that has the exact situations we're trying to address.