Fixed the problem of finder or memory surge in multi-class situations#93
Fixed the problem of finder or memory surge in multi-class situations#93Yyunfan wants to merge 1 commit intoantonmedv:masterfrom
Conversation
…es exist at multiple levels in the DOM
|
dom case： |
|
A lot of changes.... |
| seedMinLength: 3, | ||
| optimizedMinLength: 2, | ||
| maxNumberOfPathChecks: Infinity, | ||
| maxNumberOfPathChecks: 50, // Much lower limit |
| while (current && current !== rootDocument) { | ||
| let totalGenerated = 0; | ||
|
|
||
| while (current && current !== rootDocument && i < 8) { // Limit depth |
There was a problem hiding this comment.
Better to introduce config option
| } | ||
|
|
||
| // Early exit if too many combinations | ||
| if (totalGenerated > 5000) { |
There was a problem hiding this comment.
Same, lets have a configuration.
| } | ||
| function wordLike(name) { | ||
| // Fast return for obviously generated IDs/classes (long or with numbers/special chars) | ||
| if (name.length > 30 || /\d{3,}/.test(name) || /@/.test(name)) { |
There was a problem hiding this comment.
This looks pin pointing to your specific case. Can we just check for name.length?
|
@antonmedv Thanks for review. Do these changes match your expected design? Except for some configuration issues that need to be extracted. It still maintains the original library features right? |
|
I guess, so. Main problem - selectors should be stable. |
2 participants
situation:
dom:
expect:
We need to get the selector as quickly as possible when using the finder library