-
Notifications
You must be signed in to change notification settings - Fork 837
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
[EuiInMemoryTable] Allow consumers to use non-EQL plain text search with special characters #7175
Merged
cee-chen
merged 9 commits into
elastic:main
from
cee-chen:memory-table-plaintext-search
Sep 18, 2023
Merged
Changes from 4 commits
Commits
Show all changes
9 commits
Select commit
Hold shift + click to select a range
463a854
[setup] move unused `SchemaType` export to main `EuiSearchBar`
cee-chen ff7f6ed
[tech debt] Convert `EuiSearchBox` to function component + i18n text
cee-chen 65e5205
Add new `plainTextSearch` prop that allows consumers to treat user se…
cee-chen bf1235e
Fix test errors w/ non-HTML attributes being passed via `...rest`
cee-chen 74f96cc
Add documentation toggle for searching plain text/special characters
cee-chen 4d8fd29
changelog
cee-chen 17d31b5
Merge branch 'main' into memory-table-plaintext-search
cee-chen feb7a91
[PR feedback] Change `searchPlainText` prop name to `searchFormat`
cee-chen 40d2ea3
Fix broken backslash search :tada:
cee-chen File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
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
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 not 100% convinced this PR is the right way to go, so I'm opening it to get earlier thoughts from the rest of the team.
I don't love this prop name or the "plain text" terminology I'm using - I'm open to other ways to describe "text that does not follow EQL filtering syntax and thus allows users to search for special characters"
I experimented with different ways to pass this flag in the
search
object, e.g.<EuiInMemoryTable search={{ plainText: true }} />
, but it ended up causing a bunch of type headaches down the line so I abandoned it in favor of a top-level prop. Let me know if you have thoughts/preferences on thisThere 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.
Just thinking out loud, what about
searchInputFormat: 'eql' | 'text'
or justsearchFormat
?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 love it! I'll go with
searchFormat
!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.
searchFormat
prop update: feb7a91There 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.
Also, leaving some extra thoughts just for more context, in case future devs come by this PR and are like "why did they do things this way":
When I mentioned this above, I was referring to the fact that this "plain text" search is still essentially using EQL under the hood, primarily to execute over every
item
passed to the memory table. This potentially isn't as performant as it could be if we were using a more rawEuiFieldSearch
input and skipping usingEuiSearchBar.Query.parse
entirely.However, in the end, I think this is a simpler approach to go with because while skipping EQL entirely might be more performant, this at least isn't less performant than current behavior, and additionally has much less dev overhead/testing required (we'd have to write a brand new utility to execute/iterate over every single item otherwise).
In the future, something might change to necessitate a bigger break between EQL and non EQL search - but in the interim, I think this is an okay compromise between performance and developer time spent.