Grids should save the states

[Orgoth]

Is your feature request related to a problem? Please describe.

It is completely annoying that I have to always switch back to the last page I was, since the grid resets to page 1 as soon as I confirm the upgrade of the agent, add an CVE to a filter or any other action which reloads the grid. 😑
This is a usability horror.
Accidentally clicking on an agent, CVE or Event also resets the configuration for rows per page back to 10 from 50 or 100. 😑

Describe the solution you'd like

If a column is moved, the sorting is changed or the number of entries to be displayed is changed, this definition must be saved in the browser's localStorage.
If the user then reloads the page, the definition is loaded from the localStorage and used instead of the initial definition.
This also applies when the grid is reloaded, for example after clicking on an entry and returning to the page.
The fact that the grid switches back to the last displayed page is extremely important, especially with regard to the checking of CVEs, if I am on page 3, 4, 6, 10 or even further, it is extremely annoying if a CVE is added to the filter that the grid then jumps back to page 1 and the displayed CVEs are reset to the default value.

A description and example can be found here: #482 (comment)

Describe alternatives you've considered

I can't think of anything at the moment.

Additional context

wazuh/wazuh#28059 (comment)
wazuh/wazuh#26765 (comment)

[Orgoth]

@Desvelao The persistence of the state "sorting, column visibility and column order" can be achieved as follows.

I would implement this in wz-data-grid.tsx or drilldown-data-grid.tsx.

As result, the states would be persistent for every user, since it is saved to the localStorage.

https://github.com/wazuh/wazuh-dashboard-plugins/blob/main/plugins/main/public/components/common/wazuh-data-grid/wz-data-grid.tsx
https://github.com/wazuh/wazuh-dashboard-plugins/blob/main/plugins/main/public/components/overview/github/panel/config/drilldown-data-grid.tsx

But I do not know if this is the right place.

My main concern is the name, which is needed to store the states within the localStorage.
In other frameworks, it is possible to give the component a name or an ID, which can then be used to store the data within the localStorage.

-> https://github.com/wazuh/wazuh-dashboard-plugins/blob/main/plugins/main/public/components/overview/github/panel/config/drilldown-repository.tsx#L41

example for a name or ID: wz-dg-vb-iv "this stands for wazuh-datagrid-vulnerabilitydetection-inventory"

import { useState } from "react";
import {
  EuiDataGrid,
  EuiDataGridColumnSortingConfig,
  EuiFlexGroup,
} from "@elastic/eui";

const columns = [{ id: "A" }, { id: "B" }];

// Retrieve the sorting state from local storage, or use default sorting
const getSortingState = () => {
  const savedSorting = localStorage.getItem("dataGridSorting");
  return savedSorting
    ? JSON.parse(savedSorting)
    : [{ id: "A", direction: "asc" }];
};

// Retrieve the column order state from local storage, or use default sorting
const getColumnOrderState = () => {
  const savedOrder = localStorage.getItem("dataGridColumns");
  return savedOrder ? JSON.parse(savedOrder) : ["A", "B"];
};

const DataGrid = () => {
  const [visibleColumns, setVisibleColumns] = useState(getColumnOrderState);

  // Initialize state with the sorting state
  const [sorting, setSorting] =
    useState<EuiDataGridColumnSortingConfig[]>(getSortingState);

  // Update sorting state and save to local storage
  const onSort = (sorting: EuiDataGridColumnSortingConfig[]) => {
    console.log(sorting);
    setSorting(sorting);
    localStorage.setItem("dataGridSorting", JSON.stringify(sorting));
  };

  const onReorderColumns = (columns: string[]) => {
    setVisibleColumns(columns);
    localStorage.setItem("dataGridColumns", JSON.stringify(columns));
  };

  return (
    <EuiFlexGroup direction="column">
      <EuiDataGrid
        aria-label="Minimal EuiDataGrid example with sorting persistence"
        columns={columns}
        columnVisibility={{
          visibleColumns,
          setVisibleColumns: onReorderColumns,
          canDragAndDropColumns: true,
        }}
        rowCount={10}
        inMemory={{ level: "sorting" }} // This allows the data grid to sort columns for us
        renderCellValue={({ rowIndex, colIndex }) => `${rowIndex},${colIndex}`}
        sorting={{
          columns: sorting,
          onSort,
        }}
      />
    </EuiFlexGroup>
  );
};

export default DataGrid;

[Desvelao]

Thank you @Orgoth for your suggestion.

In other frameworks, it is possible to give the component a name or an ID, which can then be used to store the data within the localStorage.

This is done in the agent table (Wazuh server API data) to persist the selected columns in the local storage. I think we could add this feature to the different tables to persist the sorting and items per page too.

For another hand, you asked for the data saved into saved queries and suggesting the ability to save the state of the grid too here: #482 (comment). Today we received the same question of another user, so this could be considered to be a feature. In this case, this should be analyzed because the saved queries are coming from OpenSearch Dashboards core. Moreover, the saved queries could be used in other view with more components not only the table, so in this case, maybe we should decided that data should be optionally saved.

I think persisting the table selections (such as visible columns, sorting, items per page) could enhance the user experience.

[Orgoth]

For another hand, you asked for the data saved into saved queries and suggesting the ability to save the state of the grid too here: #482 (comment). Today we received the same question of another user, so this could be considered to be a feature. In this case, this should be analyzed because the saved queries are coming from OpenSearch Dashboards core. Moreover, the saved queries could be used in other view with more components not only the table, so in this case, maybe we should decided that data should be optionally saved.

This was a misunderstanding of how it works, my suggestion also was to save it to the localstorage, so there are no concerns or problems regarding opensearch, since it is completely separated.

See my working tsx example above or the sandbox: https://codesandbox.io/p/sandbox/frosty-fog-8pstc5.

Since another wazuh contributor told me to create a pull request and do it by my self, I now try to provide working examples based on your used Framework.

https://github.com/elastic/eui