You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Kibana, we're adding some advance search options to our global search bar. (elastic/kibana#74290)
No UI changes, just allowing for some basic query syntax.
Trying to make these changes uncovers two problems:
EuiSelectable always does its own filtering. This wasn't a problem before when the API was returning results that had a string match to the value so the filtering just returned everything back but with query syntax in the mix, EUI's string match filtering breaks down. This can be mostly turned off by passing in onSearch: () => {} into searchProps but a filter EUI-side technically does still happen on componentDidMount which, though isn't an issue for Kibana now, is still not really desired.
Proposed solution: add a boolean flag which controls whether or not EUI filters options (flag name totally up in the air, maybe optionFiltering?).
Alternative: key off of whether or not onSearch is passed in and use that as a de facto flag for the above (i.e., if onSearch is passed in, disable EUI-side filtering).
Using the onSearch workaround mentioned above, the rendered options lose the ability to highlight the searchValue because searchValue as EuiSelectable understands it is no longer correct.
Proposed solution: Allow passing in a searchValue which will get used in the rendered options for highlighting. (Actually, just implementing this could let us not disable the filtering happening above. This way, basically forcing results to have some representation that can be highlighted from the search value which is probably a good thing.) @cchaos did I understand from the EUI meeting that this is your preferred way forward?
Alternative: If EUI exported euiSelectableTemplateSitewideRenderOptions then Kibana could use it as the renderOption but pass in any searchValue it wants.
In Kibana, we're adding some advance search options to our global search bar. (elastic/kibana#74290)
No UI changes, just allowing for some basic query syntax.
Trying to make these changes uncovers two problems:
EuiSelectable always does its own filtering. This wasn't a problem before when the API was returning results that had a string match to the value so the filtering just returned everything back but with query syntax in the mix, EUI's string match filtering breaks down. This can be mostly turned off by passing in
onSearch: () => {}
intosearchProps
but a filter EUI-side technically does still happen oncomponentDidMount
which, though isn't an issue for Kibana now, is still not really desired.Proposed solution: add a boolean flag which controls whether or not EUI filters options (flag name totally up in the air, maybe
optionFiltering
?).Alternative: key off of whether or not
onSearch
is passed in and use that as a de facto flag for the above (i.e., ifonSearch
is passed in, disable EUI-side filtering).Using the
onSearch
workaround mentioned above, the rendered options lose the ability to highlight thesearchValue
becausesearchValue
as EuiSelectable understands it is no longer correct.Proposed solution: Allow passing in a
searchValue
which will get used in the rendered options for highlighting. (Actually, just implementing this could let us not disable the filtering happening above. This way, basically forcing results to have some representation that can be highlighted from the search value which is probably a good thing.) @cchaos did I understand from the EUI meeting that this is your preferred way forward?Alternative: If EUI exported
euiSelectableTemplateSitewideRenderOptions
then Kibana could use it as therenderOption
but pass in anysearchValue
it wants.CC @chandlerprall @ryankeairns @pgayvallet
I can start on a PR once I understand what the preferred way forward is.
The text was updated successfully, but these errors were encountered: