Add a configuration setting for default "Rows Per Page" setting in Management

[brhumphe]

Describe the feature:
The "Rows Per Page" option for any management screen is constantly reset to just 10 rows, which is often inadequate. A preference option to set the row count would avoid constantly having to adjust this setting over and over again. At a minimum, the option should persist for a specific page during a session.

Describe a specific use case for the feature:
Avoiding repetitive actions that impede use of management screens. It's a minor paper cut but it is something I find myself doing constantly.

[elasticmachine]

Pinging @elastic/kibana-design (Team:Design)

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[bevano8]

This would be great

[bluikko]

And the same for "Open search" screen for opening a saved search in Discovery would be great. 10 is just way too small.

[jbyroads]

Just went looking in Kibana Advanced Settings for this exact thing. That seems like a logical location to me for a place to set this option.

[ilya-chumakov]

Still no such setting?

[s7an-it]

Bump, this makes huge sense for log analysis...

[wynnchel]

Stumbled about this enhancement request and ask politely for it. This is in my opinion a default feature any software should have.

[flash1293]

@elastic/shared-ux / @clintandrewhall is this something you would be interested in?

[cchaos]

There's already an advanced setting called something like "Saved objects per page" however none of the management views seem to use it. Either we need to push on the respective owners to update to use this setting, or perhaps Shared UX could create a simple wrapping component around EuiBasicTable/EuiInMemoryTable to ensure the setting is utilized.

[mattkime]

Perhaps this is something shared-ux could 'own' where 'own' means 'make simple, notify kibana app owners, and track progress'

[humblearab]

Why is this still not a feature?

Constantly having the update the Rows per page steals hours of my time.

😭

[Helios-23]

This missing feature would greatly improve usability of Kibana. havint to reset this value EVRY time the page reloads makes searching and usability very limited.

[g0tr3wt]

Is this really still an open item?! What do we have to do to expose this as a setting in the UI?

[elasticmachine]

Pinging @elastic/appex-sharedux (Team:SharedUX)

[elasticmachine]

Pinging @elastic/platform-deployment-management (Team:Deployment Management)

[osmanis]

@alisonelizabeth @shubhaat

[sophiec20]

In stack management, there are multiple different Rows per page options. These should be standardised and the default should be increased.

As at 8.7, Visualize and Dashboards use 10, 20, 50 and have 20 as the default.

Stack Management uses a variety of the following, almost always with a default 10.
10, 20, 50
10, 25, 50
10, 50, 100
10, 20, 50, 100

Where possible (unless there are strong reasons not to) it seems sensible that we should try to align.
10, 20, 50 (default 20).

Until we have alignment on "Rows per page", then it will be difficult to implement this as a global advanced setting.
I recommend we align the options and increase the default as a first step.

[Helios-23]

I would go so far as to say standardize on 10, 25,50,100
And have the default be 25. This would be much more usable and easily fits on most browsers.

[humblearab]

Yes, 25 seems to be sensible. 10 is just way too low.

And again this should persist for some time, maybe even persist to the account so one does not have to keep on setting it on every page load.

Frankly, it's always a test of my patience 😐

[yuliacech]

I think in Kibana we should rely on EUI's defaults values for itemsPerPage: 50 and itemsPerPageOptions: [10, 20, 50, 100] (docs).

[sophiec20]

Let's double check the EUI default is intentional. I can't actually see anywhere we use 50 as the default value (but I've not checked exhaustively). And 20 / 25 feels better for a single page as we generally have a bit of padding in lists.

As clarification, my suggestions are given with the intent of standardising lists of things in Management e.g. lists of indices, transforms, data views, templates. I do not mean to suggest we apply the same to tables of data e.g. Discover, data previews

[cee-chen]

I think in Kibana we should rely on EUI's defaults values for itemsPerPage: 50 and itemsPerPageOptions: [10, 20, 50, 100] (docs).

Let's double check the EUI default is intentional. I can't actually see anywhere we use 50 as the default value (but I've not checked exhaustively).

👋 Hi, EUI team here.

So unfortunately (sorry to be the bearer of bad news), the default for the standalone <EuiTablePagination> component is irrelevant in scenarios that involve EuiBasicTable/EuiInMemoryTable/EuiDataGrid (basically, pagination within tabular data). This is because the API for the tables themselves require consumers to pass their own pagination.pageSize number/state (instead of using the defaults set by EUI).

That requirement is in place so that consumers can respond to/set pageSize dynamically either based on external changes or based on onChange callbacks caused by the user changing pageSize. What that means is that there is no default, and every single instance of a table or datagrid with pagination is setting its own individual pageSize (which is likely 10 if they copied EUI's docs example).

Also, even if EUI changed its API so that pageSize is no longer required and can be internally controlled by an EUI default, the horse is kinda already out of the barn - every single table/grid implementation already in Kibana would need to be updated to have their custom pageSizes removed.

So... now that we've established the breadth of work needed, my strong suggestion would be to handle this at Kibana's app-ex/shared-ux level, not at EUI's (since there's no shortcut and every Kibana table/datagrid implementation will need to be tweaked in any case). My suggestion would be similar to what Caroline already mentioned above:

perhaps Shared UX could create a simple wrapping component around EuiBasicTable/EuiInMemoryTable to ensure the setting is utilized.

I'd suggest either a component that handles pagination internally for all apps, e.g. <KibanaBasicTableWithPagination>/<KibanaDataGridWithPagination> - or a hook, useKibanaTablePagination() that populates the pagination object with a more sensible Kibana-wide pageSize default, and handles updating Kibana settings based on user changes.

[vadimkibana]

Ideally, IMO, there would be no pagination and pagination settings at all, where possible. Instead there would be "infinite scroll", i.e. as user scrolls to the bottom and there are more results - the new items are seamlessly loaded or maybe already available in the cache. It would be nicer for the user and way simpler code for Kibana to maintain.

[mdefazio]

I would like to avoid infinite scrolling, at least as a broad implementation/replacement for pagination. Happy to discuss that further, but it would involve some bigger changes for the experience of these pages.

In hopes of summarizing a few things here:

• Sounds like we're in agreement that we would like a set standard for page count options. The preference would be to remove 10, and instead go for [25, 50, 100].
• To handle this, it's best to create a Shared UX owned wrapper, rather than have each team manage their own implementation of the pageSize.
• This wrapper would be applied to Management pages only. Broader use can be considered separately.
• This array of options (and the default), should be available as a setting for the space.
• We should be saving the pageSize selection in localStorage so it persists for a user.

Let me know if those are incorrect or have differing opinions.

[Helios-23]

Sounds fantastic! Cant happen soon enough!

…

On Fri, Apr 28, 2023, 7:55 PM Michael DeFazio ***@***.***> wrote: I would like to avoid infinite scrolling, at least as a broad implementation/replacement for pagination. Happy to discuss that further, but it would involve some bigger changes for the experience of these pages. In hopes of summarizing a few things here: - Sounds like we're in agreement that we would like a set standard for page count options. The preference would be to remove 10, and instead go for [25, 50, 100]. - To handle this, it's best to create a Shared UX owned wrapper, rather than have each team manage their own implementation of the pageSize. - This wrapper would be applied to Management pages only. Broader use can be considered separately. - This array of options (and the default), should be available as a setting for the space. - We should be saving the pageSize selection in localStorage so it persists for a user. Let me know if those are incorrect or have differing opinions. — Reply to this email directly, view it on GitHub <#56406 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK426OG6YBI3HMTJBX5JMPDXDOO2XANCNFSM4KNZKVWA> . You are receiving this because you commented.Message ID: ***@***.***>

[bevano8]

Waited 3+ years for this. Gonna be a game changer 😁

[rlevytskyi]

Having this simple but big improvement would be very helpful.

[ElenaStoeva]

In #186997 we introduced a SharedUX package that allows tables in Kibana to store user preferences for 'Rows per page' and sort criteria in local storage (for each table). This functionality has been added to the tables in Index Management, Ingest Pipelines, and Index Lifecycle Policies.

I'll leave it to @elastic/appex-sharedux to decide how to proceed with this issue, including whether to extend this functionality to additional tables in Stack Management, some of which are owned by different teams.

[petrklapka]

Adding this to SharedUX planned work for next quarter. Remaining scope:

• Audit remaining tables where this behavior is problematic and should be improved.
• Either chase down the owning team or implement ourselves.

[petrklapka]

Note from convo with @sebelga : Target for 8.17FF, persist user settings in local storage per table. Get as many tables done as possible.