-
Notifications
You must be signed in to change notification settings - Fork 326
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
Highlight matches in CB #8098
Highlight matches in CB #8098
Conversation
... actually, this implementation does not work when the module name is hidden (so, for submodules) |
Yes. The thing is that we always try to match the qualified path of given entry, even of those parts which are not visible. In this case, |
@farmaazon yeah, I realized that later. it should now work correctly in the current version |
const suffix = match[match.length - 1] | ||
if (suffix) yield { text: suffix, type: 'no-match' } | ||
} | ||
|
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'd highly prefer to have the algorithm for obtaining matched letters somewhere as API for Filtering
class, even as part of filter
method. If the filtering/scoring algorithm will change (and it might), one would not have to remember about another place in the code to fix.
I think the filter
method should return matched ranges, and label
field of Compnent
type could have information about matched letters in the label only. The code should be unit tested.
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.
@farmaazon wdym by this?
label
field ofComponent
type could have information about matched letters in the label only
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.
(do you mean the match
field should have information about matched letters in the label only?)
... oops, the new version doesn't quite work |
... oh, it's also missing unit tests |
@@ -64,7 +70,7 @@ export function qnJoin(left: QualifiedName, right: QualifiedName): QualifiedName | |||
* The element is considered a top element if there is max 1 segment in the path. | |||
*/ | |||
export function qnIsTopElement(name: QualifiedName): boolean { | |||
return (name.match(/\./g)?.length ?? 0) <= 2 | |||
return !/[.].*?[.].*?[.]/.test(name) |
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 this change, only I'm curious why it is here? It is more performant, or something?
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 haven't confirmed whether it's more important, but: it doesn't have to store the match strings, nor create an array, nor are there any conditionals caused by optional chaining
so at the very least i don't think it's less performant
interface ComponentLabel { | ||
label: string | ||
matchedAlias?: Opt<string> | ||
matchedRanges?: MatchRange[] |
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.
We will also want to highlight letters in matched alias at some point.
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.
yeah - this is why (i'm pretty sure) matchedRanges
is present even when matchedAlias
is present. i can add tests to verify the ranges are correct when the matchedAlias
is present?
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.
tests for matchedAlias
have now been added (which did catch a bug)
app/gui2/src/components/ComponentBrowser/__tests__/filtering.test.ts
Outdated
Show resolved
Hide resolved
@Frizi i think this should be ready for your review now |
const actualConsoleError = console.error | ||
console.error = () => {} | ||
try { | ||
const consoleError = vi.spyOn(console, 'error') | ||
// Invalid index | ||
new ReactiveIndex(db, (_id, _entry) => [[1, 1]]) | ||
db.set(1, 1) | ||
db.set(2, 2) | ||
expect(consoleError).toHaveBeenCalledOnce() | ||
expect(consoleError).toHaveBeenCalledWith( | ||
'Attempt to repeatedly write the same key-value pair (1,1) to the index. Please check your indexer implementation.', | ||
) | ||
} finally { | ||
console.error = actualConsoleError | ||
} |
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.
Instead of this manual spy restore, it's better to enable automatic mock restoring before each test.
Pull Request Description
Important Notes
h.m
matchHTTP_Method
- if this is not intentional, it seems like it might be more difficult to fix, unfortunately.HTTP_Method
.Screencast
highlight_matches.mp4
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:
The documentation has been updated, if necessary.Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
Unit tests have been written where possible.If GUI codebase was changed, the GUI was tested when built using./run ide build
.