Implement Grouping

[malonecj]

Grouping is a key feature for the grid, and fills a lot of use cases for us. It is also several things to different people. We see this as:

Grouping

Choose a field (or fields) to group on, and then show the grid with expand and collapse based on this.
Further enhancements include allowing a way to also specify metrics, so that we can display summary info, whether thats number of records, or avg/sum/min/max

Key issues

• Means that the Grid needs to have a view of the entire data set, so this will need to be partly done inside ReactDataGrid, and partly in a data view adapter in front of the rowGetter
• Makes sorting and filtering more complex

Child rows

Using the same headers, but having expand and collapse on child items

Key Considerations

• How would we express this in the row data. Should it be a different prop, getter, or just a simple convention (ie if(row.children) { .. })?
• Shouldnt affect sort / filter. Though filter on children might be nice to have?
• Should this be n-dimension? using row.children should in theory be easy enough
• Will mean some state to track expand / collapse, and fundamental changes to equations on grid metrics (esp hieght)
• Need to consider how this works alongside frozen cols

Sub Grids

Having the ability to have master / detail tables, where the subgrid is entirely independent in structure (ie it has different headers, formatters, etc)
In theory this is an extension of child rows, but rather than row.children we have row.subGrids or similar

Key considerations

• Should be an extension of child rows, and so have the same considerations
• Need to ensure we stay performant
• do we keep the same convention (ie row.children) and then just sniff if these are rows, or a grid? Or be explicit (row.children vs row.subGrids)

[txm]

How far advanced are you with this detail? I'm guessing it won't be ready 'in a few days', so is there anything you can share to allow me to get started?

Thoughts so far ...

Grouping within the same table would affect the Column Sort, and not in a good way.
Would filtering work on the hidden rows?
I'm not sure of the difference between group by and child data.
Sub grids might work best (note sort and filter above) but would have to consider the performance.
In my use case my group or parent rows would be in left fixed columns, would right hand data be scrollable independently of each grid, or would they share the same column headings?

[bakesteve]

@txm updated the description with a brief summary of how we see this. And yep - good points on grouping and filter/sort. Also has an affect on the arhcitecture noted above (basically I cant group on apples if I can only see rows 1-20, but cant change that without killing perf and preventing ever having lazy load)

Means that child rows are most likely to happen sooner (though not in a few days..) and then we should be ok to extend that to independent sub grids (but agree, think there are more fundamental issues round perf, and ui responsiveness esp with frozen columns, scrolling, etc)

[Dreculah]

We're getting ready to have a go at a grouped row feature. I know from other technologies and frameworks that tree grids are tricky for the aforementioned reasons (sort, filter, performance) so this is going to take substantial effort to get right.

What is the best way for us to combine forces?

[veronicacuello]

If you have a formatter for the cells, can you specify what value is going to group by?