[data grid] Make row spanning triggering for each column explicit rather than implicit

[MBilalShafi]

Summary

The issue aims to validate the idea to make the row spanning behavior explicit for each column to avoid unnecessary computation unintentional computation.

A possible API interface change to achieve it:
The rowSpanning prop would be removed and colDef.rowSpanValueGetter would be an indicator of whether to span the rows for a particular column.

Quoting the original request:

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.

Originally posted by @lauri865 in #14691

Examples

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.

Motivation

No response

Search keywords: row spanning

[lauri865]

Just to be clear, my thoughts revolved only around UX/DX and not performance on this one. Since the first paragraph says "to avoid unnecessary computation", I just wanted to make the distinction.