[DataGrid] Possibility to virtualize columns with dynamic row height

[martinhonza]

Summary 💡

Since there was a lot of improvement for scrolling wouldn't it be possible to explore the option to have virtualized columns if rows have height set to 'auto' ? Currently its disabled which causes some bigger table that we have to be more choppy.
I didn't study the implementation detail of dataGrid but it seems to me that height would need to be calculated just on initialization and when content changes ?

Examples 🌈

No response

Other requests

• https://mui.zendesk.com/agent/tickets/23253 (someone trying to migrate away from https://github.com/DevExpress/devextreme-reactive)

Order ID 💳 (optional)

No response

[m4theushw]

If we enable column virtualization, then when scrolling horizontally, the row may change its height because some column is bigger than the height available so far.

[martinhonza]

And wouldn't it be possible to calculate the height of full row on first render so we know what height the row should be and then switch on virtualization ? And recalculate the height on whole row only when data is changed for example ? It would slow down the initialization but speed up scrolls.

[martinhonza]

@romgrk Wouldn't you be able to look at this, if its possible/viable ? since you are doing a lot of performance optimizations. Thanks.

[romgrk]

I'm not sure what we could gain here. If we need to full-render the row at first anyway, then removing virtualized columns from the DOM after is not removing work, it's adding work.

The only thing that I could see helping here would be to enable per-column configuration of dynamic row height, in the sense that library users would pass in which specific columns have a dynamic height. This would allow us to virtualize all but those columns.

Another option could be to use the canvas text measurement APIs to calculate heights rather than the DOM, but that also requires to make the assumption that the cell is text-only, which may be viable but again requires library users to pass in configuration to allow us to make those assumptions.

I'll keep thinking about it, but those gains don't seem terribly attractive imho. We have bigger gains in other parts of the grid to realize before getting to this.

[masull]

@devexpress/dx-react-grid supports row and column virtualization with auto row height. I would like to migrate to mui data grid premium since the dx-react-grid is not actively maintained:

but I require column virtualization with auto row height, for performance. dx-react-grid sizes the rows based on the columns in the view port. The row height dynamically changes when horizontally scrolled. It is a nice user experience since the row sizes to only the data in the displayed columns, not the entire row.

Is there a way for me to implement my own row resizer by measuring the maximum dom height in the displayed columns? I would even settle for resizing to the max dom size of the entire row if I could get column virtualization.

[romgrk]

You could implement your own dimension calculation logic and return a pixel value rather than auto from getRowHeight. I think it might be viable to use the canvas text metrics to measure text content without going through the DOM.

[masull]

Olivier from MUI wrote the following:

We disabled it because it might result in jumpy behavior as row height could change during horizontal scrolling. We can make this configurable if requested. See #9738.

I'd like to request that column virtualization be configurable.

On our end, we used this workaround to virtualize in the cell renderer which is not ideal and lags:

const renderCell = (props) => {
    const BUFFER = 125;
    const headerElement = props.api.getColumnHeaderElement(props.field);
    if (headerElement) {
        const viewWidth = window.innerWidth || document.documentElement.clientWidth;
        const rect = headerElement.getBoundingClientRect();
        if (rect.right >= viewWidth + BUFFER || rect.left + BUFFER <= 0) {
            return null;
        }
    }
...

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

Note

@martinhonza How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.