Feature request: slot for groupBy

[Wardormeur]

Hi,
First of all, thanks for this library :)
When doing client-side grouping with groupBy, a lot of space is available and could contain relative information to the grouping.
Could it be possible to add a slot for those ?

[matfish2]

What sort of information did you have in mind? How would it be defined?
As it stands grouping is quite basic. It does NOT group the data itself into distinct arrays; it only handles the presentation (i.e it orders the data by the grouping value and once it finds a row with a different value it adds a separating row with the new value as the title).

One implementation I had in mind is adding a scoped slot with some sort of naming convention, say group__{columnValue}. That way the user can define additional HTML for every value. However, if you have a lot of values it can get cumbersome.

In short, I think it needs a more concrete specification.

[Wardormeur]

We're reworking our admin interface for clubs. In the booking interface, we have the notion of "Rooms"(Sessions in the interface), but club administrators also like to see the overall number of participants over all rooms. Hence we have a soft grouping on rooms ('sessions") as well as the overall listing of participants.
Those rooms have limitations (number of participants, number of mentors available), and those information would be quite useful at this soft-grouping level. The information is hence related to the grouping, like "a summary" of the grouping (in our scenario, number of tickets booked for this session, number of participants, number of tickets lefts..).
As an example, the green is all the available space that could be used to hold this data :

The group__{columName} could be enough rather than group__{columnValue} as the format would be equivalent to every "group" row, at least in my use case :)
Thanks for considering it !

[matfish2]

While the presentation format might be the same for all the groups, the meta data for the group still needs to be stored somewhere. So even if I were to use one group scoped slot (the column name would be redundant as the grouping is only done by one predefined column), the user would still have to associate the meta data with every specific value. E.g:

groupMetaData:{
   hardware:{
   participants:10,
   tickets:15  
},
  htmlcss:{
    participants:5,
    tickets:12  
 }
}

What do you think?

[Wardormeur]

You're right, my bad. We would definitely need a "customized" prop per slot which doesn't depends on the rows/grouped data. Normalizing the name to match may require something equivalent to the column's "headings", isn't it ?
I now get your original concern : requiring information which would depend upon filtering, and because it's a "display" grouping rather than a "data" grouping, those information would not update based on the filters. I'm definitely fine with that, for my current usage.

[matfish2]

Indeed. If it is "hardcoded" data for each grouping value, then there is no problem, and a groupMetadata option should do the trick. But if the data is derived from the group itself (i.e an aggregate measure such as number of records or the sum of a specific property) then only real model-level grouping would allow it.

I will set to implement my suggestion then.

[matfish2]

I've added the option. See documentation under Grouping. Give it a shot and let me know if it works as expected

[Wardormeur]

Works perfectly, thanks a lot !