Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] Ability to prioritize certain attributes over keeping the selectors as short as possible. #53

Open
niranjan94 opened this issue Jan 1, 2022 · 5 comments
Labels
enhancement New feature or request

Comments

@niranjan94
Copy link

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.

{
  prioritizeAttributes: {
    tag: [<the attributes>]
  }
} 

Great library btw 😄
Thank you

@niranjan94 niranjan94 changed the title [Feature request] Ability to prioritize certain attributes over keeping the selectors as short as possible. #174 [Feature request] Ability to prioritize certain attributes over keeping the selectors as short as possible. Jan 1, 2022
@antonmedv antonmedv added the enhancement New feature or request label Mar 7, 2023
@antonmedv
Copy link
Owner

Well, I guess something like a config for custom penalties can be added.

Currently, now all attr gets a penalty: 0.5.

@antonmedv antonmedv mentioned this issue Mar 7, 2023
@niranjan94
Copy link
Author

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.

@Snooz82
Copy link

Snooz82 commented Jul 31, 2023

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/ 😉

@antonmedv
Copy link
Owner

I’m thinking about the good API design for such feature.

@niranjan94
Copy link
Author

niranjan94 commented Jul 8, 2024

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
  ...
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants