UX improvement for services and endpoint search
akashsharma95 opened this issue · comments
Use Case
Improve UX for services and endpoint search.
Proposal
Once the service panel is loaded and all the services are listed by querying graphql endpoint. Cache this services list on browser and do text search on that. Other way would be to add some debounce to reduce the number of API calls.
@aaron-steinfeld @anandtiwary @itssharmasandeep Any particular reason for current implementation?
To support server side paging, where we have no guarantee that we have the full result set in the browser. In this particular case, it may be a small enough result set that only a single page is populated, but in other places there could be thousands or even millions of results that we don't want to or can't feasible fetch at once, but still support search across the full result set. In other words, the server version is the more general case. Agree that keeping this on the client side would improve the user experience in scenarios with small data sets, and we can look to add support for that, either via config, or even better, making it dynamic based on the result set size (since we have enough info to know if the full set is loaded).
I think we did something similar for multiselect (supporting either client side or server side searching).
I like the idea of choosing client side search when we know we have loaded the full set.
Currently, we are triggering graphql api for all keystrokes, can we limit the api calls, by triggering only when the user stops typing for a time period (eg 2 second)
Currently, we are triggering graphql api for all keystrokes, can we limit the api calls, by triggering only when the user stops typing for a time period (eg 2 second)
That debounce behavior should already be in there, will check if that's broken.
Update: it is (at least as far as I could see on the version I'm running), but the default quiet period is short - 200ms. We can probably bump that up a bit.