kubernetes
Search incrementally as the user types
I am looking to implement a 'search as you type' feature for the dashboard that would automatically update your search results every n-seconds. People on my team have been asking for this because it would help with longer queries where results might be found earlier on in typing but instead they type the entire query. It could also help people correct their queries if they make a mistake before they are finished typing.
I think a good first step might be to make a proof-of-concept demo and see what the load on the api is like with different update frequencies. If it turns out that we need to implement a cache or data structure like suffix tree I'm down to do it, but it might not be necessary given a long enough load time. Any more suggestions/thoughts would be appreciated!
In inbox the search is executed if the typing in the input field is idle for about 1 second. I think we should copy this behavior
We have to remember that they have complex logic behind this kind of search and probably also some cache server in between frontend and real server. I'd wait with such feature and start with 'autocomplete' behavior described in #2134.
I think the performance requirements will not change with a behavior similar to inbox. It is more like 'we press automatically enter if the user stops typing'. It is rather UX than a functional change. I assume it would be simple to implement
IMO it does impact the performance. Let's consider that you have a big cluster with over 1k pods and during the 'search' instead of 1 request user 'accidentally' (because of the search as you type feature) fires 3 requests. Add to that few other users that are also using search functionality at the same time and we might have a problem.
One request is already quite heavy as we are downloading pretty much all resources from the cluster. Single request from our frontend triggers over 25 requests to the apiserver. Additionally they are all async so until first batch of requests is finished second request from our frontend might come in and trigger next batch of requests to apiserver.
Implementing and testing on a small cluster is not reliable. We already know that on a big clusters our workloads page loads quite long and there are only 7 resources to display. Giving user option to fire multiple search requests (even unintentionally) will be problematic for sure.
Second thing is that inbox actually triggers search as soon as you type anything (you can check network traffic). If we'd add 1 sec delay then it's no better then just typing and hitting enter. Actually it would be faster and we'd avoid unintentionall request.
'Autocomplete' should be more than enough as you can already inspect names of resources that match your query and you can find what you're looking for sooner.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen comment.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten /remove-lifecycle stale
@maciaszczykm Hi, from the issue it seems you are looking for an autosuggest search. If no one is working on this issue can I pick it up..?
