Confusion with SearchResultListWidget and AutoComplete

[Pooya-Oladazimi]

As I checked, the SearchResultListWidget is using the AutoComplete features in its search bar (equivalent to /select in ols)

https://semanticlookup.zbmed.de/api/select?q=data

This seems not correct to me since AutoComplete works as Jump To for a term. This means it shows a specific term. Selecting that term should navigate the user to that term not a search result. In the above example, if I select the first one NCIT:c25474, why should I get a list of hits? even though I selected a specific term?

Suggesion
This widget should use the SearchBarWidget as the search bar that is equivalent to /suggest endpoint in OLS.

[Pooya-Oladazimi]

@rombaum @jusa3
What is your opinion on this?

[rombaum]

@Pooya-Oladazimi you're right with your thoughts. There was an trouble in the past using suggest on this place. It should be replaced in the future. But the focus is at the moment on something else. Are you interested in swapping the API and find a better component for this?

[Pooya-Oladazimi]

@rombaum Swapping API? I do not get this.
I brought it up since there is already a component named SearchBarWidget, so makes sense to use this one IMO.

[rombaum]

Yes, but this one had issues and was not working as expected in the past for the result list. E.g. after selecting one suggestion the list was not closed directly. I think @jusa3 has more details what the concrete issues are.

There is also the idea to provide a combined widget such as ols is providing this for the search bar at the main page.

So to solve the current status the behavior of the searchbar widget must be changed a little bit. I think this would be a little tricky.

[Pooya-Oladazimi]

@rombaum Ah ok. Thanks.
I think we need to consider in which context this widget will be used. In the context of a terminology service, yes it makes sense to have both suggest and jumpTo box like ols and tib frontends. JumpTo in a terminology service navigates the user to a term detail table and tree. But in the context of a re-usable widget, the jumpTo has no use and people use the autocomplete to select a specific term (like a dropdown). So in this case having one suggest-box would be enough for the search IMO.

[rombaum]

I would say yes and no. In the context of an annotation tool a suggest would not be enough but they also probably didn't need the "jump to" functionality. The "jump to" functionality must be implemented also by the user of the widget. Since also the autocomplete widget will only provide data about the selected term. In the case of the SearchResultsListWidget there is a parameter which is called targetLink which could be used for a "jump to" functionality. By default this one is not required and empty.

[jusa3]

I agree in having a reusable and clear widget. An optional suggestion feature could either make the Autocomplete component more complicated or more powerful - how should we decide?

Problem is, that Elastic UI deprecated the EuiSuggest component in v89: https://github.com/elastic/eui/releases/tag/v89.0.0 (We have to deprecate the SearchBarWidget when updating Elastic UI). Users with a consuming React app are bound to use the Eui version of the widgets or < v88.
That's why I tried to build on what we already have with the Autocomplete here but other things got higher prioritized so I didn't have time yet to finish (add the jump to function) and test it properly. I don't now if it is even possible to define two separate functions (search and jump to) for the dropdown entries...

[Pooya-Oladazimi]

@rombaum @jusa3

Well, no it is not possible IMO. In TIB TS, we used two div and render suggest/jumpTo results in each one of them to mimic the dropdown behavior. So re-using the autocomplete widget is not feasible in this case. Unless we re-implement the autocomplete to use input+div that mimics a dropdown and then define a property to show/hide jumpTo/Suggest.
For now, I suggest using SearchBarWidget here and later thinking about adding jumpTo. At the moment using autocomplete for search does not make sense IMO.

[jusa3]

Selecting a term from an ontology from the autocomplete and then being directed to search results with all ontologies is irritating. I'm with @Pooya-Oladazimi to use the suggest without autocomplete in a first step. But I wouldn't use the SearchBarWidget with EuiSuggest because

• a use case wanted to update Elastic UI in their React app but couldn't because of the widgets
• the issue with EuiSuggest: SearchBarWidget: drop down menu does not close automatically when selecting a search value #46

Changing SearchBarWidget as @rombaum suggested e.g. by using EuiComboBox instead of EuiSuggest would be an option. EUI suggests to use either the more generic version of EuiSuggest that is EuiSelectable or copying the component source code of EuiSuggest to our application.

btw this is the PR changing suggest to autocomplete: #47

[jusa3]

EuiComboBox is the way to go if we want to have:

• Accepts custom values from user input
• Customizable option display

See elastic/eui#7049

#100