Make it possible to customize selector resolver

[dolfje]

Description

I saw a lot off comments about changing the selector. Using not class based selector, but something other. As all programmers and projects have their own requirements. I have made the resolver programmable. So that the user can set their own resolver in the settings. With that settings, it still uses the same method as before.

I for example use the following resolver in the settings. It is based on text instead of classnames. This is just so that other persons have an example of how the resolver could look like with the new setting.

const filter = function(element) {
  return Array.from(element.childNodes).filter((node) =>node.textContent.replaceAll(" ", "").trim() != "");
}

while(filter(element).length == 1) {
  let newElement = filter(element)[0]
  if(newElement.nodeName == "#text")
    break;
  element = newElement;
}

var text = element.textContent.trim();
if(text.indexOf('\n') == -1 && text.indexOf('"') == -1 && text.indexOf("'") == -1) {
  var found = document.evaluate("//*[text()='"+text+"']", document, null, XPathResult.UNORDERED_NODE_ITERATOR_TYPE).iterateNext()

  if(found && found == element) {
    return "xpath://*[text()=\""+text+"\"]"
  }
}

Type of change

Please delete options that are not relevant.

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

How Has This Been Tested?

Used it internally

Checklist:

• [x] My code follows the style guidelines of this project. npm run lint passes with no errors.
• [x] I have made corresponding changes to the documentation
• [ ] I have added tests that prove my fix is effective or that my feature works
• [x] New and existing unit tests pass locally with my changes. npm run test passes with no errors.

[dolfje]

* What they can code or not
* Argument/s and type/s of what they get
* What they need to return
* If the need to use a function or not

At the moment, the input is just the element. And output is:

• undefined: when the current resolver has no solution and thus the default resolver has to be used
• string: an css selector path
• "xpath:" an xpath selector path
• "exclude": stop the resolution as this element its click event should be ignored (not implemented in this pull request, but already locally in my build)

Should I update the pull request, or should I wait for the complete rewrite?

[ianaya89]

@dolfje Let's wait a little bit until we plan the new selector. Will get back to this soon.

Thanks!

[toniopelo]

@ianaya89 Any plans to go further on this one ? In some cases relying on classnames can be problematic (randomly generated classnames for example).

[ianaya89]

@toniopelo we will start working soon on this, we had some delays because do not have enough bandwidth. But we planned a completely new engine for our selector's generator that will work in a more natural way avoiding class-name. Probably the same as playwright is doing right now

[ianaya89]

https://github.com/checkly/headless-recorder/issues/232