[EUIDataGrid] Discuss - Extendable column rendering for EUIDataGrid

[ghudgins]

Please note the discussion label.

Feature description

Configurable method to allow custom heterogeneous rendering of data in EUIDataGrid.

Use Case / Problems

Solution data doesn't feel uniform across solutions & the platform

• As a security analyst I need to quickly visually recognize security events no matter where I find that data
• As an SRE I need to quickly visually recognize traces / logs data no matter where I find that data
• As a search developer I need to quickly visually recognize search indexes no matter where I find that data

Consistency of table controls

• As a user I need table sort controls to work the same no matter what table I am working with--especially for common tables that are rendering documents from Elasticsearch.

Developer overhead

• There are several document data tables across solutions & platform in the user experience.
• Teams maintain not only the rendering of documents but the tables and systems around these tables. In some cases, this causes feature drift from EUIDataGrid.

No means to find solutions from general tools

• As an SRE investigating custom data, logs, and traces at the same time in Discover I need to see all my results in one search, visually recognize which data is supported by solutions, and find click paths to apps in Elastic solutions that can tell me more

Silos of insight within observability ("Application Logs Initiative")

• As a developer instrumenting code I need to choose which observability tool/silo (Traces or Logs) to send my data to so I can avoid sending telemetry to a view in observability that won't help me later on. Sending data to the "wrong" tool can cost me time later in analyzing the results or, worse, may lead me to miss insights entirely.
• As a user searching logs I need to easily see when there are corresponding traces in one view so I can follow the investigation from logs to traces organically without having to leave logs empty handed and just try my luck in trace views

Solution & Design Ideas

This solution idea is here to spark discussion and generative thinking. How might EUIDataGrid support rendering that could be 1) triggered in certain data-driven circumstances (ECS metadata in this use case) and then 2) encapsulated so the rendering is maintained by each solution team (Elasticsearch documents in - custom rendering comes out) and 3) multiple renderers are bound to a single column of the EUIDataGrid

Example concept: Security event rendering

Security events are well suited for an alternative rendering as they were designed to be heterogeneous in a table already. There are many examples, this is just one.

Example concept: Traces rendering

Today's traces are intended for single viewing. It might be good to consider this UI/UX in a flyout for trace data. That being said, could we find a compact form factor for traces that would fit better in a data grid, convey the core of the data, and offer a user a way to either expand a flyout (with the full trace) or navigate to the right part of the observability solution?

Example concept: Search rendering

Search is spread out to reflect a search experience. Is there a more compact version of this that could tell the user visually it's search data, offer that button to open the data in search (or in a flyout)?

Advantages of current approach (reasons to close this issue)

• Deterministic design - content is predictable

CC @kertal

[chandlerprall]

Thank you so much for raising this discussion! It was my hope that we'd naturally arrive at this point after multiple Kibana implementations of the data grid existed. The use cases/problems make sense and provide a great argument for further exploration.

I think next steps here will be to verify multiple implementing teams agree with the problem set & proposed solution of some kind of shared library of "renderings"/"visualizations". If we can get buy in on a standardized rendering for a given data set or data type, then proceed to figure out ownership (likely shared) and where it should live (likely? a new module in eui, a la #5540).

Do you agree with that assessment, and would you like to own the next steps or do we need to find someone(s) to own?

[ghudgins]

yes - the verifying this is a requirement is the next step. I think I can own this for now but wanted to start to point attention to this as a solution (among other solution ideas). I think the action is on me to drive this coordination across teams!

[kertal]

I think next steps here will be to verify multiple implementing teams agree with the problem set & proposed solution of some kind of shared library of "renderings"/"visualizations". If we can get buy in on a standardized rendering for a given data set or data type, then proceed to figure out ownership (likely shared) and where it should live (likely? a new module in eui, a la #5540).

Shouldn't as step
a) EuiDataGrid support the rendering of complex react components inline and then as step
b) we could create a shared library in Kibana
Since I think the grid/eui does not necessarily need to provide special content / renderings / visualizations for this use case

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[kertal]

I think it is still valid

[github-actions]

👋 Hi there - this issue hasn't had any activity in 6 months. If the EUI team has not explicitly expressed that this is something on our roadmap, it's unlikely that we'll pick this issue up. We would sincerely appreciate a PR/community contribution if this is something that matters to you! If not, and there is no further activity on this issue for another 6 months (i.e. it's stale for over a year), the issue will be auto-closed.

[github-actions]

❌ Per our previous message, this issue is auto-closing after having been open and inactive for a year. If you strongly feel this is still a high-priority issue, or are interested in contributing, please leave a comment or open a new issue linking to this one for context.