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
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.
The text was updated successfully, but these errors were encountered:
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;.
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.
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.
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 :)
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 theapi-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:
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.
The text was updated successfully, but these errors were encountered: