-
Notifications
You must be signed in to change notification settings - Fork 418
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
Improve search (make fuzzy again and more robust) #932
base: develop
Are you sure you want to change the base?
Conversation
Additional finding, debugging the implementation: We do no longer tokenize between spaces, this makes it impossible to match two works, such as this: |
This comment was marked as outdated.
This comment was marked as outdated.
fix: correct popup menu search on duplicate entries Related to bpmn-io/diagram-js#932
Related to bpmn-io/diagram-js#932 and friends.
Is there a playground where I can try this out? Alternatively, if you need my review, could you please do a quick screen capture to demonstrate the changes? Thanks! |
Cf. bpmn-io/bpmn-js#2235 (comment). I'll give you an E2E demo once I'm done with implementing the search, unless you want a demo earlier, to discuss what we do (did), and why. |
9b3228e
to
1fbd403
Compare
The implementation for comparing entries did not properly account for entries that are "equal", and whenever they occur it ran into a loop. The implementation proposed does two things: * First we simplify the existing logic to be a two step filter + sort mechanism * Second, the search comparison is simple and robust, and handles equality well. This should fix the loop issues we're seeing. Related to camunda/web-modeler#10940
Reverts 34a65d32abc0c80cc822be13c440c61757ae6376
We ensure that for every entry that is a match we _always_ provide tokens. This ensures that a user can rely on these tokens being there, i.e. to render the results. Related to bpmn-io/bpmn-js#2235
I updated this PR to be fuzzy again, and solve all other outstanding issues. Just now tests revealed that we're not fully fuzzy, actually match too many things, cf. original comment in the popup menu that I subscribe to:
Our current behavior, leading to more search results popping up is:
Need to do another round tomorrow. |
Now ready to be reviewed. |
a68c85e
to
08996a2
Compare
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.
Great work! 🎖️
This ensures we properly handle fuzzy results (again), where parts of the search is matched across different keys. This ensures we're not overly strict in filtering things. Related to bpmn-io/bpmn-js#2235
Tokens returned by `search` are now recognized by the component, this makes conversion simpler.
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 did some review up to my limited knowledge. Mostly catching some smaller things
|
||
results.splice(index, 0, result); | ||
return items.flatMap((item, idx) => { |
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.
idx
seems not to be used anywhere
@@ -54,6 +54,7 @@ export default function PopupMenuComponent(props) { | |||
scale, | |||
search, | |||
emptyPlaceholder, | |||
searchFn, |
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 we have some type definition for this?
matched?: string; | ||
normal?: string; | ||
}; | ||
|
||
type ModernToken = { |
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.
NABD, but maybe calling this just Token
is fine? as moving forward this is going to be our default token type right?
} else { | ||
htmlText += escapeHTML(t.normal); |
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.
so the normal
property is not used anymore? What was the purpose of it before?
@@ -739,6 +741,7 @@ describe('features/popup-menu - <PopupMenu>', function() { | |||
const props = { | |||
entries: [], | |||
headerEntries: [], | |||
searchFn: searchFn, |
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.
searchFn: searchFn, | |
searchFn, |
@@ -139,6 +139,17 @@ describe('features/searchPad', function() { | |||
} ]; | |||
} | |||
|
|||
if (pattern === 'modern') { |
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 think we should check legacy and treat modern as just the new default. But maybe I miss something fundamental here
One general question that crossed my mind when I was playing with it: |
Proposed Changes
We found various issues with our existing search, both in terms of robustness and behavior:
This PR solves these issues, while keeping the generally desirable properties:
The overall goal is to offer a snappy, robust, and intuitive search behavior, and I'd like to put up to a test if we accomplished that:
Try it out via
Checklist
To ensure you provided everything we need to look at your PR:
@bpmn-io/sr
toolCloses {LINK_TO_ISSUE}
orRelated to {LINK_TO_ISSUE}