-
Notifications
You must be signed in to change notification settings - Fork 7
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
Conversation
so that it can be run independently of the other apps
🦋 Changeset detectedLatest commit: 26bf7bc The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
Preview URLsGH Env: preview |
6b17586
to
ecefa70
Compare
@@ -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)); |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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>( | |||
|
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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 |
There was a problem hiding this 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.
e02db2a
to
d83734f
Compare
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.
d83734f
to
7a09878
Compare
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) |
There was a problem hiding this 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)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does this do?
There was a problem hiding this comment.
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...
There was a problem hiding this comment.
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( |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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'); |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
.changeset/hot-bats-drum.md
Outdated
"ember-headless-table": minor | ||
--- | ||
|
||
Persists resized column widths to preferences |
There was a problem hiding this comment.
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.
When columns are resized, the column widths are persisted to the preferences