Row spanning breaks with aggregation when colum type is number and aggreation is sum/avg

[lauri865]

Steps to reproduce

Link to live example: https://react-ucq5za-nbk2ee.stackblitz.io

Steps:

1. Add a column with type number and aggregation as 'sum' (or average)
2. See the error: Error in /turbo_modules/@mui/[email protected]/hooks/features/aggregation/wrapColumnWithAggregation.js (23:34)
   apiRef.current.getRowId is not a function
3. When turning off unstable_rowSpanning the error disappears

Current behavior

Errors

Expected behavior

Works with aggregated columns

Context

As a side-note, while I love the new feature, I think the behaviour of spanning columns across rows should be explicit rather than implicit by default. Meaning that columns eligible to row spanning should be explicitly defined with rowSpanValueGetter, rather than opted out of through rowSpanValueGetter returning a null.

I threw it at all of our data grids, and there's usually an intent about making rows span based on the type of the data, and very few columns tend to be categorical by design to merit row spanning. However, the default behaviour of spanning matching values, while great for a demo, also matches a lot of random data that generally ought not to be spanned (random numbers that happen to be the same, updated_at dates, etc.). And some columns can be user defined, so ideally the row spanning should be intentional rather than assumed to avoid extra work of opting out most columns and unintentional spanning.

Your environment

npx @mui/envinfo

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

Search keywords: Row spanning, aggregation

[MBilalShafi]

I think the behaviour of spanning columns across rows should be explicit rather than implicit by default. Meaning that columns eligible to row spanning should be explicitly defined with rowSpanValueGetter, rather than opted out of through rowSpanValueGetter returning a null.

Thank you for your feedback. Your points make sense, but I'm unsure if it holds for all (or most of) the use cases. The motivation behind making row-spanning computation an opt-out (if the feature is active) is to provide a better/more autonomous developer experience.

For some cases, it might make more sense to keep it this way, for others, it might make sense otherwise, as you suggested.

I'd be happy to hear the feedback from the internal team and the community before deciding to update this behavior.

CC @mui/xgrid

[lauri865]

I appreciate the intention, just giving feedback based on our 15 different grids of various data, where it became very apparent that columns that we intended to span tended to be amongst the first few columns (usually categorical data like users, company, etc.), and the further right we went, the more random the matches became.

Imagine a list of stock prices – two stocks next to each other can randomly have the same price at some point in time, but there's little value in spanning them, as it may well change on next refresh. And it also adds to cognitive load to actually reading the data.

Or a list of customer orders – I would love to link together orders by the same customer and orders of the same product perhaps, but at the same time there may be 50 orders with a status "unpaid". Now I need to redesign the Status cell component to have a sticky position or something along the lines to be visible when scrolling. Which means that the default behaviour unknowingly breaks the UX if I'm not paying attention to every permutation of the view. And it might not even be apparent that this happens, because it may only do so when sort order is changed, and since I didn't test every permutation, I may have forgotten to turn this feature of for a column I didn't want it enabled for in the first place.

[github-actions]

This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue.
Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

Note

We value your feedback @lauri865! How was your experience with our support team?
We'd love to hear your thoughts in this brief Support Satisfaction survey. Your insights help us improve!