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

AddSortableColumn, part deux #128

Closed
higgsja opened this issue Jan 20, 2023 · 2 comments
Closed

AddSortableColumn, part deux #128

higgsja opened this issue Jan 20, 2023 · 2 comments
Labels

Comments

@higgsja
Copy link

higgsja commented Jan 20, 2023

Gotta say, this as in incredibly useful add-on that has saved me a lot by not having to handle all the details! Some things to consider:

Further spelunking re: my earlier post.

It appears that the original design was for both Available and Selected to have the same characteristics (forEachGrid in addSortableColumn). This may now be limiting, particularly after adding the ability to rearrange Selected. The sortable attribute may not be appropriate at all for the Selected grid.

Consider that future flexibility to adjust Available and Selected characteristics independently may enable some functionality that is otherwise not possible or convoluted to construct.

In my case I've run into some issues that seem insurmountable (could be I'm not doing it right!) because:

  • I want Available to be sorted and Selected to be client managed in terms of ordering
  • If I use addSortableColumn, both Available and Selected are enabled as sortable.
    • The client can reorder Selected by moving items up or down
    • sort Selected using the header arrows
    • drag/drop an item into the now sorted Selected
    • then go back to their original sort (both up/down arrows visible) and that item (to them) shows up in a random spot
    • now requiring more work to move it to the right spot.
  • More important, using a Save button to persist the Selected items after a sort loses the client ordering entirely. Not intuitive. The only fix here is for the client to manually redo the ordering and save again.

It strikes me that allowing unique choices on Selected behavior will enable us to provide a more creative user experience.

A secondary issue, minor but interesting, is that there is a case where having a header for both Available and Selected is unnecessary, saving some screen real estate. For example:

  • Set Available as sortable, Selected as 'client managed' (or whatever, see above)
  • Developer delivers Available already sorted; client is never expected to need to re-sort Available, therefore no header required; adds will fall into the correct place as the column is sorted.
  • No header required for the Selected column
  • The preferences page identifies what the grid is about, e.g., "Stock Data Attributes"
  • The TwinColGrid ...GridCaption of "Available" and "Selected" suffices to describe what the columns are
  • Available and Selected would have the same header. In my case, it would be "Attribute"

There does not appear to be a way to eliminate the column headers, likely as the design relied on them for sorting.

Thanks for your consideration!

@higgsja
Copy link
Author

higgsja commented Jan 26, 2023

Discovered the 'createFirstHeaderRow' constructor:

  • solved I want Available to be sorted and Selected to be client managed in terms of ordering
  • solved If I use addSortableColumn, both Available and Selected are enabled as sortable.
  • solved More important, using a Save button to persist the Selected items after a sort loses the client ordering entirely. Not intuitive. The only fix here is for the client to manually redo the ordering and save again.

Most of the secondary issue is solved as well. What is left is that moving an item from Selected to Available puts that item at the bottom of the list rather than back in its original spot. Not intuitive.

Still think a future where each grid can be configured separately will create more flexibility ...

@javier-godoy
Copy link
Member

Hello.

It appears that the original design was for both Available and Selected to have the same characteristics.
This may now be limiting, particularly after adding the ability to rearrange Selected. The sortable attribute may not be appropriate at all for the Selected grid.

Yes, that was the original design. Then we realized that some use cases require different configurations on each side, thus we introduced public getters for each grid (getAvailableGrid / getSelectableGrid) so that they can be freely configured. TwinColGrid retains some addColumn methods for the common case of applying the same configuration to both grids.

Most of the secondary issue is solved as well. What is left is that moving an item from Selected to Available puts that item at the bottom of the list rather than back in its original spot. Not intuitive.

I understand that this issue can be closed, since what remains is already discussed in #127 (feel free to comment if you have further suggestions or questions)

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

No branches or pull requests

2 participants