Double-click should resize data grid column to fit contents

[OzBob]

trafficstars

Preflight Checklist

• [X] I have installed the latest version of Storage Explorer.
• [X] I have checked existing resources, including the troubleshooting guide and the release notes.
• [X] I have searched for similar issues.

Problem

resizing column in Queue window does not reduce in size after it has been dragged to be very big

Desired Solution

double click => maximise width; dblclick when max => shrink to 'default' size.

Alternatives and Workarounds

No response

Additional Context

#4508

[MRayermannMSFT]

@OzBob thanks for sharing this feedback. We agree that the resizing columns behavior can be fairly wonky at times. Unfortunately the core of our column resizing behavior belongs to the data table library we are using and it is not going to be feasible for us to address your feature request with that library. We are in the process of investigating alternative libraries, and we will take your feature request into account when evaluating our options.

[craxal]

This should be done for all other data grids.

[craxal]

Investigating possible solutions. The tricky thing is figuring out the size of the cells to determine the width of the columns. We might do some kind of initial render with a predetermined column width then use an effect that re-renders the columns using the widest cell's width.

[craxal]

With some testing, I've found that getting accurate measurements from an initial rendering is difficult if the column width isn't known beforehand. We could just render all columns, but this can have performance problems if the data grid has a lot of columns. We solved the performance problem early on by only rendering columns that are visible. We insert leading and trailing regions with the same width as the unrendered columns to preserve natural scrolling behavior as though the columns were rendered. But we need an accurate measure of the columns widths to get the proper widths for these blank regions, which we can only get if we either render the columns (which gets expensive) or we know the width of the column ahead of time (which we don't have if the size is determined by the contents). This, of course, is problematic for content-fitting column sizes, because we won't know the column's width until it's rendered.

I have a few ideas for working around these issues:

• Internally keep track of the known column widths. Column widths are initialized with fixed columns widths. This will be updated after each render pass.
• Initially render a fixed number of columns. This number can be a constant or can be calculated by taking the available width of the view and dividing it by the default column size.
• Subsequent renders should become more efficient as the user scrolls and more column widths are updated.
• There may still be some error in calculating the column widths and the blank area, but the internal tracking should help minimize that.
• Calculating column widths will require refs to all cells, and max calculations for each column.

This is certainly a feature I would expect to have for any data grid-control, so we are definitely going to address this. Due to the amount of engineering this will require, we may need to delay this feature request to after 1.34.0.

[craxal]

I found a much simpler approach, which has been implemented. Auto-sizing only really needs to be applied when double-clicking the column sizer. So, when that happens, we can briefly construct a "probe" element containing the column being resized and attach it to the DOM. Its width becomes the column's new width, and we proceed with resizing as normal.