Add ability to minimize and expand groups in the frontend

[kgodey]

Problem

Users may want to minimize or expand groups while looking at a grouped view.

Proposed solution

We should implement this functionality in the frontend.

Additional context

• See conversation on Sorting and Grouping #450

[mathemancer]

As a part of this issue, the implementer should try to fix the bug noted in my comment on #862 (the comment is here)

[seancolsen]

@mathemancer said:

Note that in the new version, the count looks editable, and is also slightly misaligned.

Thanks for pointing that out! In 33fab3b I was trying to make a quick fix to address the fact that previously the count was styled identically to the values meaning that if I group by a column with the name count, the presentation would be ambiguous. I agree that it looks editable and think we ought to fix that which should be easy.

I'm curious about the "slightly misaligned" bit. Can you elaborate? I didn't intend to change any of that behavior. I did spend some time thinking about alignment though (but I'm not sure we're thinking about the same kind of alignment). With the behavior before my fix, I noticed that the counts on different groups were not horizontally aligned with respect to each other, which I found aesthetically disappointing. The reason is that the count comes after the values and the values can have different widths. Hypothetically, we could align all the counts with the count that ends up being positioned furthest to the right based on the width of the value, but implementing that would be somewhat tricky (either we'd reposition it with JavaScript, or we'd wrap the entire table display in a CSS grid which might make it somewhat tricky to deal with the column sizing too). I briefly experimented with placing the count before the values, but it looked confusing to have the count intermingled with the id column that will commonly display first.

[pavish]

@seancolsen The previous grouping implementation did not focus on the styling aspect.

We initially had an infinite scroll view which had a slightly different view for grouping with additional margin and padding for each group (similar to how it is in airtable), then we decided to go with pagination which shows group headers similar to how rows are displayed.

The UX for alignment of values and count within group header is not well defined yet. We would have to discuss with @ghislaineguerin once to decide upon that, including where to show the arrow indication that shows/hides the groups and how to position values when the table is horizontally scrolled.

[pavish]

@kgodey I'm removing help wanted for this issue and restricting it to maintainers because this issue involves having to handle showing/hiding rows on the virtual row list, which touches on the core part of how our tables are displayed. Our current pagination view is built on top of the virtual list making it performant when rows > 100 and have complex dom elements each.

@seancolsen This would restrict us to keep the rows flattened (we cannot have a component that wraps rows in a group as you mentioned in #862 (comment)). This would make animations tricky and the logic slightly complex, but the benefits of the virtual list outweigh these annoyances by a great deal.

[mathemancer]

I'm curious about the "slightly misaligned" bit. Can you elaborate?

Sorry, I should have been more precise: I noticed that the vertical alignment was affected by the font differences (at least with the fonts installed on my system). Here's a screenshot of the "after" with a line drawn to show the issue.

If you zoom in to view the image full-size, you'll notice that "Status: Application" is directly on the line, but "count: 38" is above it. For "count", this isn't so bad since it's in a different font size, but because the "38" is in the same font as "Status: Application", I find the fact that it's not on the same horizontal plane a bit jarring.

[mathemancer]

After some experimenting, the effect of the floating 38 is exacerbated if you zoom your browser window in further as well (in the UI, not the picture).

[seancolsen]

@kgodey Can we defer this feature until after the alpha release? Users should be able to use Mathesar without this feature, and as @pavish mentioned above, there are some tricky considerations to take into account during implementation.

[kgodey]

@seancolsen I'll move it to the UI Styling milestone for now, we can figure out what we're doing in terms of styling when it comes to it.

[pavish]

Blocked by #1073

[github-actions]

This issue has not been updated in 90 days and is being marked as stale.

[kgodey]

I'm closing this since we don't have current plans to work on this and there's not enough detail for a community contributor to pick this up. We can open a new issue when we have more implementation details.

If you're a user and you'd like us to work on this, please comment here to help us gauge interest in this feature.