[Enhancement] Incremental search in Saved Objects page

[sagarmore-in]

Describe the bug

In OpenSearch Dashboard when we navigate to Hamburger Menu -> Stack Management -> Saved Objects and try to search any listed items we don't see filtered results as we type, in case of other search boxes present on other pages the incremental search is working as expected.

To Reproduce Steps to reproduce the behavior:

1. Click on 'Hamburger Menu'
2. Click on 'Stack Management'
3. Click on 'Saved Objects'
4. Try to search any listed items, don't see filtered results as we type

Expected behavior It should show filtered result from the listed items as we type in search box

OpenSearch Version version: 2.4.1

Dashboards Version "version": "2.0.0" & "version": "3.0.0"

Plugins Not enabled any plugin, using the default settings

Screenshots

Host/Environment (please complete the following information):

• OS: Windows
• Edge Version 108.0.1462.76 (Official build) (64-bit)

Additional context Would like to contribute to repository to fix this bug in order to make search box behavior consistent across application

[ashwin-pc]

@snmore1990 Thanks for opening this issue. Also appreciate you volunteering to help implement this change and would love to support you in submitting that change if we do decide to implement it. I wouldn't categorize this however as a bug since the search here is closer to the Query search for Dashboards as opposed to a regular search bar (Selecting a type from the drop down will show you that). It is also a search that refetches the data everytime the search value changes which can be expensive.

That actually leads to my concerns about enabling incremental search here and would love to hear thoughts from you and others about it. This search unlike other searches in the management page refetches all saved object data since we only have access to the paginated data in the beginning. This is because there can be large number of saved objects with new ones being added all the time. I breifly enabled it myself and noticed that the search was not as responsive as i expected and resulted in a lot of queries being made to the backend. Debouncing the query will help, but that would require making a change to the underlying EUI (Now OUI) component EuiSearchBar to add some form of debouncing logic since the incremental feature is implemented there. Or we can also make the incremental feature optional or toggleable, but im less inclined with that approach. @kgcreative @KrooshalUX What are your thoughts about this?

[pjfitzgibbons]

@ashwin-pc @snmore1990 This seems somewhat related to the feature for exteneded Dashboard Lists #1866 The approach we'll take there is a debounce within the "search" (fetch?) callback attached to the EUISearchBox. Within that callback, an Rxjs pipeline is used to debounce, filter, paginate, and transform the SavedObjects data, then presented to front-end. At that point, performance issues are fully on the backend OS engine. IF there continues to be a performance issue, we'll need to rethink how we query the backend - a bit lower level engineering than this front-end feature.

It might be worth noting the (not so central) use case of OS as a secondary index to large OLTP datasets. If direct query of SavedObjects turns out to be truly a performance issue, we may need to have an architectural discussion around what a secondary index of .kibana would look like for searching.