[data grid] Column header labels still abbreviated after Autosize Columns

[AndreasDBS]

The problem in depth

We are building an enterprise web app that has lots of tables, and a table may have 20 or more columns. We want columns to be as wide as required, but not wider than that. Most importantly: column headers must always be readable, no matter if the sort order has changed and the sort icon is displayed.

Here comes the problem: take your excellent documentation as an example:
docs
First, you click on Autosize Columns in that example (the Include Headers option is ticked). You can see that as a result the Brand ID column is given a width which nicely fits the Brand ID label into the header, it's not too wide and not too narrow.

Now, choose to sort for the Brand ID column. The column header now displays the Sort-Arrow icon to indicate the ordering. However, that Icon overlaps the column header label, which is then abbreviated with "...". A subsequent use of the Autosize Columns button does not fix that.

We never want column header labels to be abbreviated. So, here is the question:

1. Is it possible to disable the abbreviation of column header labels?
2. Is it possible to somehow change the algorithm that calculates the width style attribute for column headers? We know which columns are used for ordering and could adjust the width with that information. There just need to be a way to hook into that algorithm. Is there a way for this?

Latest version tested: Mui Data Grid v7.22.2.

Your environment

`npx @mui/envinfo`

System:
OS: Windows 10 10.0.19045
Binaries:
Node: 20.17.0
npm: 10.8.2
npmPackages:
@emotion/react: ^11.13.3 => 11.13.3
@emotion/styled: ^11.13.0 => 11.13.0
@mui/base: 5.0.0-beta.58
@mui/core-downloads-tracker: 6.1.3
@mui/icons-material: ^6.1.3 => 6.1.3
@mui/lab: ^6.0.0-beta.11 => 6.0.0-beta.11
@mui/material: ^6.1.3 => 6.1.3
@mui/private-theming: 6.1.3
@mui/styled-engine: 6.1.3
@mui/system: 6.1.3
@mui/types: 7.2.18
@mui/utils: 6.1.3
@mui/x-charts: ^7.20.0 => 7.20.0
@mui/x-charts-vendor: 7.20.0
@mui/x-data-grid: 7.20.0
@mui/x-data-grid-pro: ^7.20.0 => 7.20.0
@mui/x-date-pickers: 7.20.0
@mui/x-date-pickers-pro: ^7.20.0 => 7.20.0
@mui/x-internals: 7.20.0
@mui/x-license: ^7.20.0 => 7.20.0
@types/react: ^18.2.14 => 18.2.15
react: ^18.2.0 => 18.2.0
react-dom: ^18.2.0 => 18.2.0
typescript: ^5.0.2 => 5.1.6

Search keywords: autoresize column width
Order ID: 79546

[michelengelen]

Hey @AndreasDBS and thanks for raising this issue here.

This is actually a bug. This part of the code indicates that the clientWidth of the sorting icon should be added to the width to prevent the described behavior:

mui-x/packages/x-data-grid/src/hooks/features/columnResize/useGridColumnResize.tsx

Lines 222 to 223 in 284d0e5

	(iconContainer?.clientWidth ?? 0) +
	(menuContainer?.clientWidth ?? 0);

The assumption and code looks ok, so I took a bit of time to investigate. It seems that the column headers are memoized pretty heavily and when getting the elements from the reference it is still in an old state. I tried to showcase that in this screenrecording:

Screen.Recording.2024-11-13.at.11.27.58.mov

What I do here is:

• store the element in the DOM to a variable in the chrome console
• apply sorting to enable the visibility on the element
• check visibility by running checkVisibility({ visibilityProperty: true }) on the iconContainer stored in the console variable
• then run autosizing and log iconContainer?.clientWidth and iconContainer?.checkVisibility({ visibilityProperty: true }) during the execution of extractColumnWidths

It shows that the clientWidth is 0 (should be 28) and checkVisibility returns false (should be true)

I'll add this to the board for the team to fix!

[michelengelen]

cc @romgrk since it might be related to virtualization ☝🏼

[AndreasDBS]

@michelengelen Thanks a lot to confirm that and for your quick response. I was already trying to look into that useGridColumnResize.js but am more than happy to hand this over to you. Cheers!

[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

@AndreasDBS 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.

[AndreasDBS]

Sorry, I just wanted to comment but pressed "Close with comment" by mistake.

[AndreasDBS]

So, github-project-automation changed this issue from Needs refinement to Backlog - what's going on here, is this issue still in the pipeline to get fixed, or is this issue lost due to my closing it by mistake? Should I enter a new one?

[michelengelen]

So, github-project-automation changed this issue from Needs refinement to Backlog - what's going on here, is this issue still in the pipeline to get fixed, or is this issue lost due to my closing it by mistake? Should I enter a new one?

Moved it back to the 'needs refinement' lane. Thanks for the heads up! 👍🏼

[AndreasDBS]

Hi guys, just wanted to say, I know you have a lot to do, and even though we have licensed your lib we can't demand anything.
I am really of fan of your work, but I think it is just fair to tell you that I can't further persuade my boss to ship our product with your datagrid with this simple bug.

As simple as this bug might look - we just cannot ship a product which hides what information is shown in columns.

[michelengelen]

Hi guys, just wanted to say, I know you have a lot to do, and even though we have licensed your lib we can't demand anything. I am really of fan of your work, but I think it is just fair to tell you that I can't further persuade my boss to ship our product with your datagrid with this simple bug.

As simple as this bug might look - we just cannot ship a product which hides what information is shown in columns.

Fair enough ... If it helps I can have a look today and try to fix before the release today.

[AndreasDBS]

That would be absolutely amazing, thank you!

[michelengelen]

Hey @AndreasDBS ... I found a solution, but it is not super ideal. Opened a PR anyways with backporting to v7. Lets wait for the reviews and go from there. Is that OK for you?

Good thing is that release day is today, so you could potentially use it by EOD or tomorrow!

[AndreasDBS]

That sounds fantastic! (A backport would be nice, really, we might not be allowed to ship with 8.x yet).
But hey, that's great news!

[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

@AndreasDBS 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.