Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EuiDataGrid] Allow consumers to render their own non-virtualized data grid bodies #6523

Closed
cee-chen opened this issue Jan 12, 2023 · 1 comment · Fixed by #6624
Closed
Assignees

Comments

@cee-chen
Copy link
Member

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:

  1. Bypasses react-window virtualization entirely
  2. 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
@cee-chen cee-chen self-assigned this Jan 12, 2023
@cee-chen
Copy link
Member Author

cee-chen commented Jan 13, 2023

A couple of scratch notes from today:

The body component:

  • 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant