recalculate column widths on column addition/subtraction

[jamesdixon]

Hi there!

Had a quick question:

I have a basic table that depending on a parameter I send in, adds a column to the table. If I bounce back and forth between the table with and without the column, it appears that the column widths aren't always recalculated leaving me with column widths that aren't correct. I'm probably not doing a great job of conveying this, so here's a video to show you what I'm talking about: https://cl.ly/3E1H1P2t0722

For now, I'm just going to create a separate table with specific columns but wanted to see if you had any ideas.

Thanks again for all of your hard work on this addon. It's awesome!

Cheers.

[pzuraq]

Impressive looking app!

So, there are a few things at play here. We have some interesting constraints with Ember Table because of the occlusion:

1. We cannot rely on standard HTML table sizing of columns (where columns are fit to content naturally) because we remove and add rows to the table dynamically. If we relied on standard sizing, the columns would fluctuate as we scrolled, which is not ideal UX.

2. We must know column widths in advance, because of the above. If column widths are not provided by the user of the table, we have to calculate them ourselves.

It looks like you're using size-constraint="eq-container", but I'm not sure of the fill mode. It can't be first-column, because otherwise the Created column would never expand in the first place.

My recommendation is to use resizeMode='first-column' so that whenever the table is resized dynamically to fit the size constraint, it puts the delta into the first column. For the remaining columns, you can specify widths manually, so this shouldn't become an issue unless the user has actually manually messed with the column widths.

We could also consider clearing the cache of widths whenever the columns array changes, but I think in most cases that's the opposite of what users would expect, so I'm hesitant to make that change. Definitely open to discussing it though.

[jamesdixon]

Thanks, @pzuraq!

Appreciate the detailed reply! I actually am using fillMode="first-column" and sizeConstraint="eq-container" and, unfortunately, it didn't behave as you mentioned. However, I'm not using fixed width columns for the others. I'll give it a shot!

Thx!

[pzuraq]

Ah, good to know! Then for some reason, the fill mode isn't being respected. The last column should never be growing, and it is somehow. We need to figure that, I'll see if I can get a reproduction going and we can work it out

[sliptype]

I'm running into this when dynamically adding/removing columns and then dragging to reorder the columns. The drag indicators are no longer aligned with the columns.

Calling ensureWidthContraint (essentially clearing the width cache, like you mentioned) after the column addition fixes the issue but there is no good way to trigger it without resizing the table or changing the widthConstraint.

I think it would be great to have an option to clear the width cache when columns are updated. Or, accept a callback for when columns are updated and pass it a function that can be used to recalculate the width.

What do you think?

[bantic]

@sliptype We recently merged #690 which may fix the issues you are describing. Are you able to upgrade (to [email protected]) and see if that fixes things?