-
Notifications
You must be signed in to change notification settings - Fork 456
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
feat: suggest close matches using Levenshtein distance [POC] #836
Closed
Closed
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
371923b
implement close-matches api
dougbacelar 5dac03a
implement closest matches suggestions on testId query
dougbacelar 788dbc2
remove empty lines
dougbacelar e69fd6b
add extra test
dougbacelar b12cb29
simplify conditional
dougbacelar cd54847
add computeCloseMatches config option
dougbacelar 8ee261f
remove custom implementatin of levenshtein
dougbacelar File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
import {getCloseMatchesByAttribute} from '../close-matches' | ||
import {render} from './helpers/test-utils' | ||
|
||
describe('getCloseMatchesByAttribute', () => { | ||
test('should return all closest matches', () => { | ||
const {container} = render(` | ||
<div data-testid="The slow brown fox jumps over the lazy dog"></div> | ||
<div data-testid="The rapid brown fox jumps over the lazy dog"></div> | ||
<div data-testid="The quick black fox jumps over the lazy dog"></div> | ||
<div data-testid="The quick brown meerkat jumps over the lazy dog"></div> | ||
<div data-testid="The quick brown fox flies over the lazy dog"></div> | ||
`) | ||
expect( | ||
getCloseMatchesByAttribute( | ||
'data-testid', | ||
container, | ||
'The quick brown fox jumps over the lazy dog', | ||
), | ||
).toEqual([ | ||
'The quick black fox jumps over the lazy dog', | ||
'The quick brown fox flies over the lazy dog', | ||
]) | ||
}) | ||
|
||
test('should ignore matches that are too distant', () => { | ||
const {container} = render(` | ||
<div data-testid="very-cool-div"></div> | ||
<div data-testid="too-diferent-to-match"></div> | ||
<div data-testid="not-even-close"></div> | ||
<div data-testid></div> | ||
<div></div> | ||
`) | ||
expect( | ||
getCloseMatchesByAttribute('data-testid', container, 'normal-div'), | ||
).toEqual([]) | ||
}) | ||
|
||
test('should ignore duplicated matches', () => { | ||
const {container} = render(` | ||
<div data-testid="lazy dog"></div> | ||
<div data-testid="lazy dog"></div> | ||
<div data-testid="lazy dog"></div> | ||
<div data-testid="energetic dog"></div> | ||
`) | ||
expect( | ||
getCloseMatchesByAttribute('data-testid', container, 'happy dog'), | ||
).toEqual(['lazy dog']) | ||
}) | ||
}) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,50 @@ | ||
import {makeNormalizer} from './matches' | ||
import calculateLevenshteinDistance from 'leven' | ||
|
||
const MAX_LEVENSHTEIN_DISTANCE = 4 | ||
|
||
export const getCloseMatchesByAttribute = ( | ||
attribute, | ||
container, | ||
searchText, | ||
{collapseWhitespace, trim, normalizer} = {}, | ||
) => { | ||
const matchNormalizer = makeNormalizer({collapseWhitespace, trim, normalizer}) | ||
const allElements = Array.from(container.querySelectorAll(`[${attribute}]`)) | ||
const allNormalizedValues = new Set( | ||
allElements.map(element => | ||
matchNormalizer(element.getAttribute(attribute) || ''), | ||
), | ||
) | ||
const iterator = allNormalizedValues.values() | ||
const lowerCaseSearch = searchText.toLowerCase() | ||
let lastClosestDistance = MAX_LEVENSHTEIN_DISTANCE | ||
let closestValues = [] | ||
|
||
for (let normalizedText; (normalizedText = iterator.next().value); ) { | ||
if ( | ||
Math.abs(normalizedText.length - searchText.length) > lastClosestDistance | ||
) { | ||
// the distance cannot be closer than what we have already found | ||
// eslint-disable-next-line no-continue | ||
continue | ||
} | ||
|
||
const distance = calculateLevenshteinDistance( | ||
normalizedText.toLowerCase(), | ||
lowerCaseSearch, | ||
) | ||
|
||
if (distance > lastClosestDistance) { | ||
// eslint-disable-next-line no-continue | ||
continue | ||
} | ||
|
||
if (distance < lastClosestDistance) { | ||
lastClosestDistance = distance | ||
closestValues = [] | ||
} | ||
closestValues.push(normalizedText) | ||
} | ||
return closestValues | ||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned about this increasing the performance issues we already have with
find*
queries which are expected to fail at least once. Any chance we could lazily calculate this value so it's only run when the error is actually displayed? I don't know whether this is possible.But perhaps my concern is unwarranted? Maybe this is faster than I think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point. I tested a few times on my local running
getByTestId('search', {computeCloseMatches: true})
vsgetByTestId('search', {computeCloseMatches: false})
.Not a reliable benchmark, but when false it finished consistently at around 20ms. When true finished at around 35ms. It increases with the number of elements found, but not by much. Might become slightly quicker with the recommended lib.
An alternative would be to throw functions for
find*
queries. And then check iftypeof lastError === 'function'
when waitFor times out.That might mean decoupling
find*
andget*
queries a bit or perhaps makeget
queries depend onfind
queries instead of the other way around.i.e: a
get*
query could be afind*
query with{timeout: 0, interval: Infinity}
? (not sure if that would work)Since that seems a bit involved, we could start with a config
computeCloseMatches
that defaults tofalse
and give that some testing?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with giving it a trial run and seeing what real-world experience with it will be like, so defaulting to disabled makes sense to me. Let's try it out using
leven
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kentcdodds do you think we should start with the testId query or add this feature to all 10 queries? Wondering if i can break down the work somehow...
Re. the performance concern. Maybe if we realise there is a huge performance impact we can skip the computation of close matches on
find*
queries(similar to what was done for therole
query here: #590There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure. What does everyone else think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO if the default is false, we can give it a try in more queries, though, this seems to me like a configuration that shouldn't be set to true by default at all, especially since it has a performance impact. I see this as something that will not be helpful in CI for example and will only take more time so if the developer wants to opt in they will have an option to do that.
Putting aside what I wrote above, I really like this PR and do think it can have a valuable impact so thanks for this :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please try a benchmark again using the new
leven
implementation?