Open niranjan94 opened 2 years ago
Well, I guess something like a config for custom penalties can be added.
Currently, now all attr gets a penalty: 0.5
.
Well, I guess something like a config for custom penalties can be added.
Currently, now all attr gets a
penalty: 0.5
.
@antonmedv That would be a good idea. With that one can choose to give a negative penalty for any attribute that needs to be prioritised to generate more reliable selectors. For example, data-testid
attributes.
Plus 1 for this feature.
this would give the users the possibility to prioritize criteria.
maybe not just prioritizing certain attributes over other attributes, but maybe also lower the priority of class or tag-name over attributes in general or certain attributes like the mentioned data-testid
.
Ps: we are using your library in Robot Framework Browser, which is a Playwright based library for Robot Framework. We added your lib in June 2021 and we are super happy about your contribution! https://robotframework-browser.org/ 😉
I’m thinking about the good API design for such feature.
I’m thinking about the good API design for such feature.
@antonmedv how about a new option called as penalties
with the type
type penalties = {
idName?: (name: string) => number;
attr?: (name: string, value: string) => number;
className?: (name: string) => number;
tagName?: (name: string) => number;
};
Or can change the type of the existing idName
, className
, tagName
, attr
properties to support a number
output that can be the penalty value in addition to the existing boolean
export type Options = {
idName: (name: string) => boolean | number
className: (name: string) => boolean | number
tagName: (name: string) => boolean | number
attr: (name: string, value: string) => boolean | number
...
}
The problem
Currently the library tries to generate selectors that are unique and as a short as possible. Which is great in most cases, but sometimes in a changing web-page, it results in selectors that are not future-proof .
If a page has one link to start with, the library would probably produce
a
as selector for that link. While this works for the webpage as is, it may not work when the webpage has another link added soon. (Example, take blogs or new websites for example where the links can keep changing). In such a case, having the ability to specific which attribute to always keep a part of the selector would help. (in this case,href
is a good candidate)How could the library support this ?
Perhaps some option where one can specify attributes to keep at a tag basis. And when the library sees an element have one of these tags, it includes it in the final selector even if that doesn't necessarily result in a shorter selector.
Great library btw 😄 Thank you