Skip to content
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

Search in navigation #601

Open
jarrodek opened this issue Mar 4, 2019 · 3 comments
Open

Search in navigation #601

jarrodek opened this issue Mar 4, 2019 · 3 comments

Comments

@jarrodek
Copy link
Contributor

jarrodek commented Mar 4, 2019

Allow users to search through navigation (name + endpoint [+ method?]).
Currently the user has to scroll through the navigation pane to discover the endpoint. When the user is unfamiliar with the API is may cause problems with discoverability. Search input filtering out methods, endpoints, types, and documentation documents by provided query could fix this issue.

Con here is that the API Console works as a embeddable component and howting application UI most probably already contain some form of search capability. In this case the user could be confused about the intent of APIC internal search and application search. Also it is not good UX to provide two separate search options for a single application.

Proposed options:

1: Search API
This is already implemented in the api-navigation element but not exposed to the api-console API. The navigation has query property that filters out navigation tree. More work on the UX may be required.
Hosting application would use this API to connect the search action inside the application with API console. When the console is rendered the search UI should trigger search action in the console using the API.

2: Dynamic search UI
Less UX friendly option but allows to add search capability in the console out of the box. The navigation component always has search input which is hidden by default. The user can trigger the search via UI action (button click) and perform regular search.

Cons:

  • additional click to initiate the search action
  • separated search capabilities when the hosting application has search capability
  • possible confusion about intention of both search inputs

3: Configuration option to disable search
This would always render search input in the API navigation element but the console would expose configuration option to disable the input when required and the API to perform search. This way it would allow to expose search capability out of the box and fit the scenario when search is already exposed in the application.

@deiteris
Copy link

deiteris commented Aug 15, 2021

This is already implemented in the api-navigation element but not exposed to the api-console API.

But there are no problems with accessing the api-navigation element via the shadow root property, so what not exposed means here?

With the api-console-app element, you can simply extend the ApiConsoleApp class and add the search bar that simply does nav.query = e.target.value;.
image

With the api-console element, it is up to implementer. The implementer may access the api-navigation just the same way via the shadow root property, or extend the ApiConsole with a method that will get him its api-navigation and leverage the Search API functionality.

@jarrodek
Copy link
Contributor Author

The API is there in the navigation. There's no UI for it. The problem we have is integration with Exchange that has own search. We never invested into this problem enough to solve it.
The team may decide to do something about it but I am not sure if that's gonna be prioritized.

@deiteris
Copy link

deiteris commented Aug 17, 2021

Ah, well, the UI is not a big problem as I said above (at least for standalone projects), but if it is also related to an integration with the other solution for website search, then it's a different issue. Not pushing it, just saying that there is a solution :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

4 participants