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

Persist column width preferences #211

Merged
merged 5 commits into from
Aug 10, 2023
Merged

Persist column width preferences #211

merged 5 commits into from
Aug 10, 2023

Conversation

joelamb
Copy link
Contributor

@joelamb joelamb commented Aug 3, 2023

When columns are resized, the column widths are persisted to the preferences

@changeset-bot
Copy link

changeset-bot bot commented Aug 3, 2023

🦋 Changeset detected

Latest commit: 26bf7bc

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
ember-headless-table Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@github-actions
Copy link
Contributor

github-actions bot commented Aug 3, 2023

@@ -27,7 +27,11 @@ export function createHelpers(selectors: Selectors) {
let targetX = startX + delta;

triggerEvent(element, 'mousedown', { clientX: startX, button: 0 });
await new Promise((resolve) => setTimeout(resolve, 100));
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this ensures that the mouse down, drag and release events don't all happen in the same runloop

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isn't that what happens IRL, tho?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

without these pauses the mouseup trigger event fire before the new column-width data is available to be saved to preferences. IRL no-one drags a column that quickly.

Copy link
Contributor

@NullVoxPopuli NullVoxPopuli Aug 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

200ms is also quite long, and a big delay. most tests on my machine would take way longer with this change.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does a settled or something similar work or no?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ynotdraw settled didn't work. That's what I tried first.

@NullVoxPopuli I can get tests to pass with a single 50ms delay (tests fail even with a 10ms delay).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting! Do you know what's goin on within those 50ms?
Like, what are we waiting for?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The inline style width property of the table header cells of the two affected columns are being calculated and added to the DOM

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I bet we're missing some test waiters.

await settled should work, if possible.

Anywho, thanks for appeasing my questions!
I'm happy with things, given that this is a separate task to do

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Logged the issue here: #215

@@ -262,6 +262,7 @@ function columnsFor<DataType = any>(

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method upsets me. lol (I wrote it)

It was meant to be temporary.

I need to see how TanStack Table handles their column dependency calculations


let colPreferences = preferences.forColumn(columnToUpdate, ColumnResizing);

colPreferences.set('width', column.width.toString());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this width be a percentage so that when the table is loaded on a different sized browser, the columns have the same way of being sized?

I could see the argument either way.
Though, with fixed-column sizes across dynamic-sized browsers / devices, I'd think we'd only want to save the width of the columns that have specifically been adjusted by the user, so that dynamic widths can still be flexible.

like,

| set width | set width | dynamic width | dynamic width | dynamic width | set width |

Copy link
Contributor

@NullVoxPopuli NullVoxPopuli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Conditionally approved~ish

my only concern is the arbitrary delay in test-support, as this could more than double the test time of every test wanting to resize columns.

When resizing drag ends, the updated col widths for all visible
columns are saved to preferences.
If preferences exist they are used to set initial column widths.
@joelamb
Copy link
Contributor Author

joelamb commented Aug 4, 2023

Conditionally approved~ish

my only concern is the arbitrary delay in test-support, as this could more than double the test time of every test wanting to resize columns.

Tests reliably pass with just a single 50ms delay between the drag and mouse up - but will not pass with a shorter delay (or no delay)

Copy link
Contributor

@ynotdraw ynotdraw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to @NullVoxPopuli, going to approve, but it would be nice if we could get to the bottom of the delays in a follow up at some point.

@@ -28,6 +28,9 @@ export function createHelpers(selectors: Selectors) {

triggerEvent(element, 'mousedown', { clientX: startX, button: 0 });
triggerEvent(element, 'mousemove', { clientX: targetX, button: 0 });

await new Promise((resolve) => setTimeout(resolve, 50));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this do?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious as it seems like something I could reuse in the future...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a workaround that ensures that the calculation of the column width styles are complete and the DOM is updated before the test continues.

It's tracked to fix in #215

but is a necessary workaround for now.

@@ -309,6 +314,15 @@ function columnsFor<DataType = any>(
return visibility.columns;
}

if (sizing) {
assert(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: do we need to test for this new assert?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we currently test for any of the other asserts in this function

return this.options.width;
}

assert('saved width must be a string', typeof savedWidth === 'string');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit (non-blocking): do we need to test for this assert?


@action
save() {
this.tableMeta.saveColWidths(this.tableMeta.visibleColumnMetas);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: do we need to test for this save action?

"ember-headless-table": minor
---

Persists resized column widths to preferences
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: should mention the newly added save action and related asserts, i.e. will error if the column width is not a string.

@joelamb joelamb merged commit c3a3a5c into main Aug 10, 2023
25 checks passed
@joelamb joelamb deleted the jl-col-width-preferences branch August 10, 2023 08:58
@github-actions github-actions bot mentioned this pull request Aug 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants