search

Borvik / ts-datatable

1 stars 6 forks source link

Grouping Oddity #26

Closed Borvik closed 3 years ago

Borvik commented 3 years ago

Group By - User Experience

Group by typically sorts by the columns that are being grouped.

If we want to share the URL to someone else so they see the same data, the sort should be included - therefore the group should be included.

You could say the same thing about visible columns, but we can't store all the data in the URL - it's messy for one, and there are character limits.

When group by is stored purely in the URL, it takes it out of the stored column order - and when the group by is removed from the URL manually, either by manually removing it, or navigating away from the page it can actually cause some weird column order issues (table column order may not match column config dialog due to columns essentially sharing a sort index).

If we store the group by in LocalStorage, then we can't share the sort of the group by.

If we use a hybrid approach, the UI can actually set both at once - the LocalStorage options can control the groups themselves, while the URL controls the sort order.

This leaves us with an interesting scenario in that a user can be given a URL that contains a group sort, and the data rows are in the order of the shared URL - but the group could either be non-existent or a different group. The groups would still work and the data would mostly be in the same order - at least on the same page.

The trick here is still - leaving the page and coming back. It likely wouldn't have the group sort in the URL, but it would still group the data.

Just not sure on the best approach for this.

Summarized Options:

  1. Pure URL - weird sort order issues
  2. LocalStorage - unable to share page properly
  3. Hybrid - weird group issue on coming back to page
  4. Other?
Borvik commented 3 years ago

I've come up with another hybrid method.

The basic concept is the same - use the URL for the sorting, and the LocalStorage for the actual grouping.

The difference is, store the full group data (prior it was just the column, now it's column & sort). The URL still controls the sort order, so if that were to change the groups would still be the defined user groups from LocalStorage, but the sort wouldn't match.

Another difference is, when we detect nothing in the URL - we can populate the URL from LocalStorage - preserving the group properly upon coming back to the page.

Borvik commented 3 years ago

After a discussion it was determined that pure URL, keeping column in main list but with some visual styling to show it's grouped - thus preserving the column order.

image

However, I have determined another issue with pure URL and would like your take. The issue is a default grouping.

The way the query state works, is if the state being set matches the default, then it is excluded from the URL. Also during parsing of the URL, if there is nothing - it uses the default. This allows stuff like page=1 to disappear from the query string when coming back to the first page. This also works for the sort order.

When grouping has a default, then it works the same way. However, unlike sort order, it can actually be removed. This actually leaves it in a weird state - where the URL is blank, a default is set, but there is no grouping (due to how the useQueryState hook is working - it set the URL and an internal state at the same time)

Any thoughts?

Maybe no default grouping - but still allow passing a group from the outside to specify the group.

Borvik commented 3 years ago

Maybe in that scenario an "empty" string in qs?