[DISCUSS] Datagrid component specifications

[snide]

Summary

The EUI tables are great, but they don't provide the level of density and scalability that we need for tools like Discover, data viz and ML. This spec proposes we either adjust our tables or add a new component to deal with those needs. This spec also assumes that our current Search and filter components will work with these new data grids the way our tables currently do.

Guiding principles

We're aiming at two crowds with these features:

1. Data scientists and analysts who like looking at raw data
2. People who are familiar with the UI (not the markup) of Excel / Sheets

This is not a replacement for CRUD tables (which the EUI tables do quite well with). This component is primally aimed at a need for data analysis.

Required additional features

These are on top of what we already do in EuiTable. For example... we still should retain row based actions in the way we currently provide them.

The style of table styles should be automatically decided by the content

• Engineers should pass in their data array and we should try to assume the type of content (number, string, filterable type)

One of the biggest problems with our current tables is that people often don't utilize the type prop on the data being provided. For example, any numeric value should be right aligned and presented in a monospace font. Any consistantly long form content should be automatically truncated and have a tooltip applied...etc. It would be nice to figure out ways to do this automatically based upon the content we're given.

You should be able to define the columns displayed in the grid

• An engineer should be able to provide a full list of columns available in the grid
• An engineer should be able to provide the initially visible columns available in the grid
• A user should be able to optionally change the visible columns from the provided list.

A good UI example of how we can do this by providing a display options menu that shows the available and visible columns in a list.

Alternatively, this can be done in a modal with sort

You should be able to sort the results against multiple columns at once

• An engineer should be able to provide initial ordering rules to a data grid
• A user should be able to shift click to apply additional columns at once

https://datatables.net/examples/basic_init/multi_col_sort.html

You should be able to define the order of the columns

• An engineer should be able to define the order the columns are presented in
• A user should be able to optionally change the order of the visible columns

You should be able to apply styling to data grids through props

Off-hand I think the following styling props / abilities should be available

• The ability to stripe rows
• The ability to force rows to stay one line (currently we do this on a cell by cell basis, which makes the messy)
• The ability to provide horizontal borders
• The ability to provide vertical borders
• The ability to provide the overall "size" density. This would define the base font size used and the padding in each cell.

You should be able to set row grouping for data grids

• Engineers should be able to provide a specific column to group results upon
• Users should optionally be given the ability through the UI to define the grouping mechanic

Row groups will help categorize data into easy to scan content. As an example. Given {names, age, city and country}. I should be able to group the results by country.

You should be able to output a CSV of any data grid

I don't know where this belongs, and it might need to be at the Kibana level, but it would be nice to always give people a very quick way to output the exact data in a visible table (meaning just the columns that are visible) into a CSV format

You should be able to optionally allow grids to scroll

• Engineers should be able to set a prop to allow a table to scroll within it's provided container
• This setting should be dynamic with respect to screen size

You should be able to set fixed columns and headers in scrollable tables

For when the above is present

• Engineers should be able to pre define any number of fixed columns. These columsn would always appear first in the list.
• Users should optionally be able to define any column as "sticky / fixed" which would add it to this list.

You should be able to resize column width at will

• Engineers should be able to set the initial width of columns

You should be able to provide an arbitrary color or icon to individual cells to make them stand out

• An engineer should be able to provide a color and/or iconType to any row or cell to give them context in the group.

We should make a decision on our search mechanisms and tooling

The KQL autocomplete interface exists in Kibana to sort content. We use a more simple "github" style system in EUI. Should they coexist? Should we bring autocomplete to the EUI version?

Reference material

• Design better data tables
• Data tables

[snide]

@elastic/machine-learning @elastic/apm-ui @zumwalt @elastic/kibana-app @MichaelMarcialis @elastic/cloud-design We're gearing up to start on providing true data tables / grids to EUI. If you have any requirements please let us know.

[benwtrent]

@elastic/ml-ui ping ^^ Looks really interesting :D

[formgeist]

If they're meant to extend the existing tables, I don't think we have any additional requirements. We sometimes have elements like i.e. the Impact bar (which is a the EuiProgress component) inside a cell as a visualization. Not sure if this is part of it, but perhaps it should support visualizations from i.e. charts inside the table for micro-visualizations. One example could be to show error rate (histogram) for a specific trace or transaction. Just something to have in mind.

[sophiec20]

Looking forward to this - am liking the option for a denser data view.

[tveasey]

This sounds great! Being able to shade all cells by a matrix of numeric values (one for each cell) would be a nice feature for ML use cases such as displaying feature importance.

For such cases one usually has (row normalised) collections of numbers. One would shade the cells with higher values for this quantity darker and cells with lower values lighter. (Note the numbers are not actually displayed in the table just used for shading.)

[timroes]

One practical feature for us, that as far as I saw isn't on the list yet, would be the possibility to add Options (or most likely an option menu) to each individual column header. That way we are able to provide additional configuration options per column, which might be very useful especially in discover.

[0asp0]

sounds really great. What about the ability to rename a column? just the label, not the field. Sometimes I place a saved search on a dashboard to have the possibility to view some aggregations and detailed events at a single place. Then for the guys who work at dasboard layer it would be nice if I can rename the columns to make object.subobject.error.class being shown as errorClass. Sometimes the labels / field names are longer than the data.

[MonDeveloper]

This should be considered a must have, I guess it because everytime I tried to convince Business people to use Kibana, after a week they told me:

could you export data on Excel please, I'm not able to do anythink except 'find'

...and, sadly, they were right

[mmourafiq]

Is there any plans to add selection to the datagrid component?

[snide]

Is there any plans to add selection to the datagrid component?

Yes, it is on the near term roadmap.

https://github.com/elastic/eui/issues/2504

[seraphjiang]

when could data grid support filter by columns

[chandlerprall]

@seraphjiang Providing built-in search/filtering capabilities is a lower priority, and not currently scheduled. We have seen many different ways apps want to expose to their uses for filtering, from a basic text entry to a search grammar to a visual query builder, and are still exploring the options in this area. At the same time, it is fairly straight-forward for an application to build its own filtering layer and limiting the data going into EuiDataGrid.

[snide]

This is closable now that data grid is fairly mature. Any items still left will be converted to new issues.