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.
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
feat: suggest close matches using Levenshtein distance [POC] #836
Changes from 5 commits
371923b
5dac03a
788dbc2
e69fd6b
b12cb29
cd54847
8ee261f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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?