Build Customized Search Box upon EUI

[mw-ding]

Hey EUI experts,

This is Mengwei from CodeSearch team here. I am looking for inputs regarding building customized search box in EUI.

Ideally, the search box we are trying to build should have the follow traits:

1. Be able to show typeahead
2. Customize typeahead dropdown option items
3. Support structured query (no now, but in a near future)

For now, EuiComboBox could do 1, but not 2 for now. However, EuiSearchBar could do 3, but not really 1 or 2.

So do you guys have any inputs on this? My thoughts are maybe we should extend the source code of EuiCombobox or EuiSearchBar in our code base and build a component tailored particularly for our own purposes. Or do you guys have a better direction in mind, since you guys are more experienced.

Btw, a quick question regarding EuiComboBox, instead of select one of the options, is it able to submit the query like a normal inputbox does even when no options is matched?

Looking forward to hearing back.

[mw-ding]

I am trying to wrap the EuiComboBox with a EuiCombox and a EuiButton with submit type, but not sure where to specify the action field like the vanilla HTML form does. Any suggestions on this?

[snide]

Hi @mw-ding. Are you thinking something more along the lines of the Kibana search bar in dashboards?

If so, we do not have anything generically built in EUI for that purpose at the moment. @Bargs has talked about potentially building that as a component into EUI (vs. putting it into Kibana). It might be worth some discussion to see if there's a way we can build something for everyone.

A good way to start would be to show a wireframe or something with the functionality you need. I think I know what you're after, but I want to make sure.

[mw-ding]

@snide Thanks for the input. Yes, the search box in dashboard is exactly what we are looking for.

So it sounds like for now, moving along with our customized search box is the direction. We will take a look at the search bar source code in dashboard.

[snide]

I know that @Bargs is working in this code right now (the current one in Kibana master in Angular and we need to convert it). I'll let him pipe up, but this seems like a great place to work together.

[mw-ding]

good to know. Thanks @snide. We are using React + Typescript now, +1 on convert it. :) Or we can start work on it by ourselves.

[mw-ding]

@Bargs do you have any inputs on this?

[Bargs]

Hey, yep, Dave is correct that I'm currently working on converting the Kibana search bar and autocomplete to React and EUI. At the moment I'm still working within Kibana core, but at the moment I don't see any reason why we couldn't put this component in EUI. The current angular based search bar already does #1 and #2, so it's my goal to do both of those in the React version.

I'm out next week while I move across states, so it'll probably be a few weeks before my work is completed, reviewed, and merged.

[snide]

Talked with @weltenwort about this as well this morning. I told him I'd ping him here. He wanted it in EUI as well (easier to import there than from Kibana), and planned on using APM's reactified version till it was built out.

Might be good just to do a very short meeting over zoom before @Bargs leaves just to understand everyones needs. Then maybe @cchaos or I can put together some patterns to tee it up for everyone.

[mw-ding]

@Bargs, awesome to know that it's on the way. Yea, I think having 1 and 2 is great enough as a start.

@snide having a quick zoom sync on the timeline and planning would be awesome. I will send out the invitation soon.

[mw-ding]

@snide @Bargs Thanks for the inputs in the sync. I think late this Sept sounds good to us and appreciated if you can loop us in for the PRs along the way. Feel free to close this issue if necessary. :)

[cchaos]

So is the action-item on this one to move the auto-complete search bar pattern to EUI?

[Bargs]

The original plan was to move react based search bar into EUI if possible but we've never gotten to it. As part of the new platform migration the search bar and query bar were moved into their own "data" plugin where other apps can consume them. So in the world of the new platform I'm wondering if it is still necessary or if it still makes sense to have the query bar in EUI?

[snide]

Might want to ask @sqren. I remember him having opinions on this stuff.

[sorenlouv]

I think the current state where we have 4 separate versions of the kql search bar UI is not great. Would be good to have a single implementation that all teams used.
I don't have any strong opinions if this implementation should live in Kibana or EUI.

Generic autocomplete/typeahead
Something we have been looking for is a generic autocomplete/typeahead experience that is not tied to the Combobox (similar to Downshift).

Basically we need a component that:

1. takes an input query
2. allow us to perform an async search to get suggestions
3. feed the suggestions back into the typeahead which will display them as an absolutely position overlay
4. let the user select a suggestions (with mouse and/or keyboard).
5. When selected we want to handle (and display) the selection separately. It should not be added to input field (this is what the combobox does AFAIR)

We have looked at the Selectable component which seems like a better fit than the Combobox but ran into some problems - can't remember from the top of my head but I'll resume this effort for 7.3.

[timroes]

It's not 100% what the issue asks for, but since the discussion is very related I wanted to add the request/information to this issue.

I think we should have a base component for writing "query bars" (or similar) with auto completion as an EUI component. I think the KQL query bar itself is fine to live in the data plugin in Kibana, but we will need to move the Timelion auto completion from Angular over to React in the next year sometime. The canvas expression field also has it's own auto completion implementation at the moment.

Since it's not always that trivial to get auto completion right in terms of accessibility and we even could reuse the same auto completion item layout in different places (for one line auto completions), I think it would make sense moving the base component below the KQL filter bar to EUI, with the possibility to plug in your own custom auto completion and item components.

I would like to hear if the @elastic/kibana-design team would consider that a valid component to have in EUI, while we can still have an implementation for Timelion or KQL sit on top of that component in Kibana.

[chandlerprall]

I think @timroes's idea makes a lot of sense.

[timroes]

cc @maryia-lapata @sulemanof since we need to move the timelion visualize panel to EUI in the near future and would highly benefit from that generic autocomplete component there.

@chandlerprall Do you know if this is something we could somehow schedule in the near future?

[chandlerprall]

We'll need to figure out what component(s) / service(s) we need to build out in EUI, have a design pass, and then create it. I don't know how EUI-ready "the base component below the KQL filter bar" is, but it may save a good chunk of work.

I don't believe we'd have an availability to own this until the middle of September at the earliest, unless we wanted to re-prioritize things /cc @snide

[cchaos]

@andreadelrio Is actually in the process of re-creating these smaller pieces of the auto-complete in EUI right now. We won't be creating the actual logic mechanisms for deciding what options to show when but we will be able to provide the pieces that fit together.

I'm comfortable saying that the EUI-ification of Timelion would have this available in the 7.5 time frame.

For context, @timroes is talking about this auto-completer

[timroes]

@cchaos 7.5 timeframe would be awesome! Thanks a lot

[snide]

The display components side of this is fixed with #2270 which is merging shortly.

I'd highly suggest that the logic side of KQL move to EUI eventually because of how broadly it's being used, but that needs a champion from the Kibana side and I don't think we have the bandwidth for it anytime soon. Unless there are any complaints, I'm setting this issue to be closed with the merging of the above issue.

[timroes]

Thanks for merging that. I am currently looking through the docs and it seems that you can currently not anyhow customize the suggestion items, but just have one icon + label + description (but only string, no custom JSX) available? How could we achieve something like the timelion autocompletion with it, which has more complex items in it:

Of course we could/should happily also redesign how those items look when moving the timelion auto completion over to EUI, but I am still not exactly sure how to achieve that complexity without specifying custom JSX?

cc @sulemanof @maryia-lapata

[timroes]

Also on another note: from the EUI docs it seems the component isn't handling keyboard input correctly yet, and also has missing the appropriate ARIA tags (aria-activedescendant, aria-controls, etc.)? A complete example of ARIA in autocomplete can be found in the existing KQL implementation and I am sure @myasonik can gladly help out there if needed?

[snide]

@timroes I think with the timelion view you're proposing you're best served by using one of the monaco implementations floating around in Kibana (most recently used in Canvas) and that @poffdeluxe is making a more generic plugin. The suggest component is more tightly coupled with KQL's style of completion, which is a little more specific in nature.

All that said we should of course fix the aria labeling.

[mw-ding]

Wow, EuiSuggest! Awesome. Are we going to provide an option to group items into 2 levels?

[cchaos]

Closing this out as we highlighted using Kibana's Monaco editor for code completion and we have a Meta ticket for EuiSuggest accessibility issues #2404