-
Notifications
You must be signed in to change notification settings - Fork 8
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
[WIP] Reordering hidden columns #185
base: main
Are you sure you want to change the base?
Conversation
|
d42a1db
to
e1d905b
Compare
22b1ede
to
3e471a7
Compare
5795ecc
to
20234d1
Compare
Preview URLsGH Env: preview |
20234d1
to
62af988
Compare
62af988
to
0b0f086
Compare
As described in #152, the behaviour when reordering over hidden columns is incorrect. This test illustrates the expected behaviour so that we can fix the implementation.
To make it easier to play with show/hiding then moving columns
0b0f086
to
d6a1f27
Compare
In order to make the previously added test pass we need to give the column reordering plugin access to _all_ columns, not just the visible ones. When moving left or right we need to iteratively swap the position of adjacent columns, continuing until we have swapped with a visible column. There are some failing tests for internals of the component on this commit but they can be fixed up later. I want to see if the new UX is desirable.
By adding any missing columns to the end of the list whenever the data is passed _in_ we will be able to simplify any logic around reordering because it will know that it is dealing with a full set of columns
This is the next piece of guaranteeing that we are dealing with a full set of positions within the addon code. By verifying on input we can save ourselves verifying on every calculation / output.
It turns out that we can't test this functionality because we're hitting some asserts in other functionality which should now be considered unnecessary so we'll have to do some other cleaning up before this test can go green.
d6a1f27
to
3139ad6
Compare
@@ -297,11 +297,12 @@ module('Plugins | columnReordering', function (hooks) { | |||
assert.strictEqual(getColumnOrder(), 'A B C D'); | |||
}); | |||
|
|||
test('without setting the order of anything, we cannot retain the order of the columns when they are added or removed', async function (assert) { | |||
test.skip('without setting the order of anything, we retain the order of the columns when they are added or removed', async function (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.
This test is currently skipping because it fails.
The plugin no longer supports the columns being mutated after the initial render from outside the table. Is this a legitimate thing that consumers should be able to do or was it just a simple way to initially write this test?
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.
Maybe, there are 3 use cases that i'm aware of:
- reorder each column live / immediately (like in this repos demos)
- reorder after submitting a form (setting the whole order at once) -- this is something common in table settings menus -- and relie(d|s) on a duplicate version of the ColumnOrder class (i forget the name) to have the same behavior as the columns.
- same as above, but without form submit.editing in a menu immediately changes the table (a hybrid of the prior two approaches, ux wise)
In all 3 of these, order is mutated from outside the table, so maybe i'm missing something, and need to go through the code.
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.
reorder each column live / immediately (like in this repos demos)
This works by using the plugins API, not by mutating the passed array
reorder after submitting a form
There is an API for this too (setAll
IIRC)
editing in a menu immediately changes the table
I think that could use the API too...
I guess the bigger question is - should we expect consumers to use provided APIs to do things or should we let them mutate the inputs?
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 works by using the plugins API, not by mutating the passed array
Ah i see, that was the key part i was missing when you said mutation -- like a TrackedArray that has had additional columns added or removed or something.
should we expect consumers to use provided APIs to do things or should we let them mutate the inputs?
I mean, one of the nice things deriving data from inputs gets us is that all of that can be handled.
Like, it could be a choice to require tearing down and recreating whatever when additional data is added to the table, but predefining all that before rendering is a common enough pattern, where it should probably be ok... If people want to asynchronously add more columns, they could probably deal with extra computation needed to re-position, re-size, etc the existing columns in addition to the new columns.
Like, personally, i'm not a fan of (what i see as) breaking reactivity (we can't know how deep or shallow a reactive abstraction is, and when we assume any depth, we can inherently any consuming usage -- now, maybe the maintainence burden in too great here, and that's fine! An assertion or something could be added to communicate that mutating the array passed to the ColumnOrder class isn't supported (tho, idk how common of a use case it is -- it's all kind of 'possibilities' here ))
So that we don't need to worry about checking for and filling consecutive slots throughout the code
66919aa
to
41811bb
Compare
@vitch hey, great work. I'm curious: What did you end up doing here – are you using this functionality in a fork? |
Would there be interest in more distributed maintenance? repo could be transferred to https://github.com/universal-ember/ ? |
This PR addresses #152 by tweaking the way reordering is done...
From the commit message of the last commit:
There is also some implementation tweaks I'd like to make (using a
simple
for
loop would be more efficient because I could use the indexin the array to do the swapping) but I can do that in a separate
commit.
I'm also not sure if we could do away with or simplify the entire
swapWith
function (and maybe evenorderOf
?). There are someTODO
s in the code as well for edge cases to clean up. At the momentI'm looking for verification that the approach seems sound and the
generated UX is an improvement...