elastic / eui

Elastic UI Framework 🙌
https://eui.elastic.co/
Other
6.07k stars 821 forks source link

[EUIDataGrid] Discuss - Extendable column rendering for EUIDataGrid #5943

Closed ghudgins closed 2 months ago

ghudgins commented 2 years ago

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

Consistency of table controls

Developer overhead

No means to find solutions from general tools

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

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.

image

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?

image

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)?

image

Advantages of current approach (reasons to close this issue)

CC @kertal

chandlerprall commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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[bot] commented 1 year ago

👋 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 commented 1 year ago

I think it is still valid

github-actions[bot] commented 8 months ago

👋 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[bot] commented 2 months ago

❌ 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.