Fixes attribute priority sorting bug #45
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi! Thanks for optimal-select -- it's been a big help.
I'm working on a project that involves generating many selectors, on pages not under my control. We're using this library. In writing tests for our project, we encountered some strange behaviors:
I traced the problem to a bug in
match
, when attribute patterns are being generated.The attribute sorting function in
findAttributesPattern
can encounter four scenarios:curr
andnext
are in the priority listcurr
nornext
are in the priority listcurr
is in the list butnext
is notnext
is in the priority list butcurr
is not.The old sort function didn't explicitly handle case 4, and so when it encountered elements with attributes not in the priority list, it a) tended to prioritize the unknown attributes over things like ids and b) didn't behave deterministically between browser versions.
This baby PR adds a single if statement to properly handle case 4.
It solves our bugs. It also should generate shorter selectors in some circumstances.
(Just noticed #35, which this fixes)