You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The virtualization library used by EuiDataGrid makes several features that multiple teams (Discover, Security) extremely difficult to almost impossible. These features include expandable row details (#5638), col/row groups (#4636), and infinite scrolling (#2981).
Proposal
Expanding EuiDataGrid for every single extremely specific use case is quickly growing untenable. Many of the teams requesting these features additionally have very little interest in the virtualization portion of the EuiDataGrid, and/or want to roll their own (e.g. for infinite scrolling).
My proposal is to provide some kind of render function for EuiDataGrid (similar to renderCellValue, but for the entire data grid body) that:
Bypasses react-window virtualization entirely
Passes our EuiDataGridCell component (and any other params needed - investigated needed) to said render function, which allows consumers to completely customize however they want their cells rendered - e.g. custom row wrappers, etc.)
How feasible this be remains to be seen: this issue is primarily being opened for exploratory/investigation purposes.
Challenges that need to be thought through
Ensuring column widths are still correctly passed
Sorting/hiding works as before
Keyboard navigation and cell focus works as before
The text was updated successfully, but these errors were encountered:
The Cell and InnerElement components currently in data_grid_body.tsx is technically specific to react-window, but has a lot of logic that non-react-window rendering will need as well - some amount of DRYing out is required
Column widths, header, and footer instantiation will need to be extracted
Scrolling cells into view logic - should this be left as a react-window only piece of body logic? (probably, since consumers handling rendering should also handle scrolling, and if they're not virtualizing, .focus() should auto-scroll)
Brainstorming: do I want a data_grid_body and a data_grid_body_virtualized? Or should I move some of the items above into the top level data_grid.tsx file and call it a day
The cell component:
style coming in from react-window can be totally ignored
rowManager, rowHeightUtils, and setRowHeight are all semi-problematic items that are fairly deeply embeded in data_grid_cell and will need to be addressed
Complete control over rendering likely means that rowManager should simply not be used, to allow consumers to generate their own row wrappers
This will likely have accessibility implications. However, that is no longer on EUI to solve. Going down the "take over rendering" escape hatch approach means the consumer is in charge of all these problems, not EUI
rowHeightUtils will also likely not be usable as it is deeply enmeshed w/ react-window
Summary
The virtualization library used by EuiDataGrid makes several features that multiple teams (Discover, Security) extremely difficult to almost impossible. These features include expandable row details (#5638), col/row groups (#4636), and infinite scrolling (#2981).
Proposal
Expanding EuiDataGrid for every single extremely specific use case is quickly growing untenable. Many of the teams requesting these features additionally have very little interest in the virtualization portion of the EuiDataGrid, and/or want to roll their own (e.g. for infinite scrolling).
My proposal is to provide some kind of render function for EuiDataGrid (similar to
renderCellValue
, but for the entire data grid body) that:react-window
virtualization entirelyEuiDataGridCell
component (and any other params needed - investigated needed) to said render function, which allows consumers to completely customize however they want their cells rendered - e.g. custom row wrappers, etc.)How feasible this be remains to be seen: this issue is primarily being opened for exploratory/investigation purposes.
Challenges that need to be thought through
The text was updated successfully, but these errors were encountered: