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

recalculate column widths on column addition/subtraction #604

Open
jamesdixon opened this issue Aug 3, 2018 · 5 comments
Open

recalculate column widths on column addition/subtraction #604

jamesdixon opened this issue Aug 3, 2018 · 5 comments

Comments

@jamesdixon
Copy link

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
Copy link
Contributor

pzuraq commented Aug 3, 2018

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
Copy link
Author

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
Copy link
Contributor

pzuraq commented Aug 3, 2018

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
Copy link

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
Copy link
Contributor

bantic commented Jul 16, 2019

@sliptype We recently merged #690 which may fix the issues you are describing. Are you able to upgrade (to ember-table@2.0.0-beta.8) and see if that fixes things?

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

No branches or pull requests

4 participants