Grouped excel-like columns RFC

[ekeuus]

This is an initial proposal to implement excel-like column grouping like mentioned in #765 , #1066, #1287, #458, #410, #2031

It implements a "parent" column logic where you define a wrapper column that inherits the width and positions of its children. This means that one does not have to define the column groups beforehand with widths, but most of the logic stays as it is now. The API is taken from react-table and I think this makes more sense than having it as a fixed colspan logic, which one would have to maintain outside. For us it is a MUST HAVE feature in this absolutely brilliant library so that's also why I decided to try and RFC.

Some minor cleanup probably needed regarding having separate height variables for the two headers and maybe testing it with grouping and other features together? IMHO: I wouldn't even make it work with grouping since those flows don't make sense together.

Example of how it looks:
https://media.giphy.com/media/hIG3uvfLYanhiXa18m/giphy.gif

ReactDataGrid.mp4

[ekeuus]

@amanmahajan7 @nstepien

[amanmahajan7]

Thank you for the POC.

I can foresee a few issues with this approach.

1. It cannot handle more that 2 header rows
2. It relies on unique key to match the parent and the child rows. What happens when a key does not match or column does not have a parent key.

I think a better api would be use an implicit relationship between header rows so something like

interface ParentColumn {
   name: '',
   children: Array<Column | ParentColumn>;
}

interface Column {
}

This way we can specify any level of nesting

[amanmahajan7]

I have started a PR based on the above idea. Let me know if the api handles your use case.

[ekeuus]

I think the keys are not relevant tbh. The parent key can be anything (or even generated by rdg). The parent cell positioning is defined by the children's keys, so there is no other connection.

…

On Fri, 16 Apr 2021 at 20:48, Aman Mahajan ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In src/DataGrid.tsx <#2350 (comment)> : > @@ -82,7 +85,7 @@ export interface DataGridProps<R, SR = unknown> extends SharedDivProps { * Grid and data Props */ /** An array of objects representing each column on the grid */ - columns: readonly Column<R, SR>[]; + columns: readonly (Column<R, SR> | ParentColumn<R, SR>)[]; Thank you for the POC. I can foresee a few issues with this approach. 1. It cannot handle more that 2 header rows 2. It relies on unique key to match the parent and the child rows. What happens when a key does not match or column does not have a parent key. I think a better api would be use an implicit relationship between header rows so something like interface ParentColumn { name: '', children: Array<Column | ParentColumn>; } interface Column { } This way we can specify any level of nesting — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2350 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACTMG7RKU6C3XY7BZ35ZTQ3TJCA6TANCNFSM42HRAQXQ> .

[ekeuus]

Regarding the child rows, any ideas on what combinations would be required? Or some use cases so that it could be generalized. I am anyway thinking that fixed summary rows above the content could be cool. Basically same api as summary rows, and maybe even same key? Not sure if that covers the multiple header rows cases, since I don't know them yet.

…

On Fri, 16 Apr 2021 at 21:41, Ekke Tõiv Uustalu ***@***.***> wrote: I think the keys are not relevant tbh. The parent key can be anything (or even generated by rdg). The parent cell positioning is defined by the children's keys, so there is no other connection. On Fri, 16 Apr 2021 at 20:48, Aman Mahajan ***@***.***> wrote: > ***@***.**** commented on this pull request. > ------------------------------ > > In src/DataGrid.tsx > <#2350 (comment)> > : > > > @@ -82,7 +85,7 @@ export interface DataGridProps<R, SR = unknown> extends SharedDivProps { > * Grid and data Props > */ > /** An array of objects representing each column on the grid */ > - columns: readonly Column<R, SR>[]; > + columns: readonly (Column<R, SR> | ParentColumn<R, SR>)[]; > > Thank you for the POC. > > I can foresee a few issues with this approach. > > 1. It cannot handle more that 2 header rows > 2. It relies on unique key to match the parent and the child rows. > What happens when a key does not match or column does not have a parent key. > > I think a better api would be use an implicit relationship between header > rows so something like > > interface ParentColumn { > name: '', > children: Array<Column | ParentColumn>; > } > > interface Column { > } > > This way we can specify any level of nesting > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#2350 (review)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACTMG7RKU6C3XY7BZ35ZTQ3TJCA6TANCNFSM42HRAQXQ> > . >

[nstepien]

Now that we have column.colSpan(), I think you can use that feature together with aa custom header renderer to achieve the desired outcome, no?

[ekeuus]

Not 100%. I'd still prefer multiple header rows. But I am not sure how the api would look in that case when there wouldn't be any parent child relations. Any preference?

On Thu, 22 Apr 2021 at 18:45, Nicolas Stepien ***@***.***> wrote: Now that we have column.colSpan(), I think you can use that feature together with aa custom header renderer to achieve the desired outcome, no? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2350 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACTMG7XVZIMF7HLXSQYK2F3TKBHCTANCNFSM42HRAQXQ> .

-

[sandves]

Would love this feature. Any activity on this?

[alexey-koran]

Hi. Any updates? @nstepien

[ekeuus]

I might take a look at this today and see if I am able to implement it with the new API idea.

[alexey-koran]

I might take a look at this today and see if I am able to implement it with the new API idea.

Thank you!

[Anny88]

Good afternoon! Also think that grouped column is a very needed feature, my team would also love this. If possible, could you please have a look again?

[teneon]

Our project would also benefit from Column header groups. Any news on this?

[ekeuus]

I have a prototype open here #2684 but it has been kinda quiet for some time now

[paustint]

I know it's a year later and this is unlikely to get picked up, but would love to see this feature.

I am in the process of moving from a different commercial grid provider and when I started refactoring one of my use-cases I realized this feature was missing.

Was hoping to have the ability to re-create the same experience, but will have to look at other ways of presenting the info.

EDIT: I am going to look into summary rows and see if I can use that to solve this use-case. 🙏
EDIT2: I was able to solve my use-case using summary rows and spanning columns. It feel kinda hacky and column resizing is buggy and doesn't work on the spanned columns. But it works well enough for now.

[hyusetiawan]

I would love to see this pushed through, I am also in the middle of a project that requires column-level grouping. Unlikely due to how old the PR is but one can dream :)

[baur]

@amanmahajan7, @nstepien

Ths lib Ideal for our project but needs Column header groups. Any news on this?

It cannot handle more that 2 header rows

yes, in our case we need more than 2 rows

[isaac-arb]

yeah, I could benefit with this feature too

[amanmahajan7]

This has been implemented now
#3287