Row Grouping & Aggregation

[tannerlinsley]

Row Grouping & Aggregation

[lukaswelinder]

I'm vetting table components for work and this is one of our key requirements. I like what you have going, so let me review the source over the weekend to assess the scope.

If you could recommend where to look first, that would help a lot. Thanks.

[tannerlinsley]

I'll take a look in the morning myself. We can chat more on the slack org if you want.

…

On Wed, Dec 7, 2016 at 10:35 PM Lukas Welinder ***@***.***> wrote: I'm vetting table components for work and this is one of our key requirements. I like what you have going, so let me review the source over the weekend to assess the scope. If you could recommend where to look first, that would help a lot. Thanks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCfMUKNz5sTUj-cODe55_r2y5YYyUks5rF5cHgaJpZM4KfII0> .

[tannerlinsley]

Adding row grouping and aggregation will likely need several additions and edits throughout the entire core. These are some of the requirements/ideas I have in mind out of the gate:

• Row Groups should be infinitely nestable?
• Grouping needs to run pre-sort
• Grouping is achieved using same column mechanics eg. using a string fieldName, or callback d => d.fieldName
• When the bottom level of a grouping is reached, sorting needs to run inside that grouping level (this way sub-items are sorted when exanded), then sorting can work its way up to the parent level of the data using any aggregated data from the group to sort
• Aggregation happens after grouping
• Default and type-aware aggregations
• Utilize built-in aggregations via string or imported const eg. RowAggregation.avg
• Aggregation callbacks on columns to customize any column
• Pagination should respect sub-rows
• State will need to be manageable both internally and externally (I think the best way to do this is by using reserved keys on the actual rows of data as opposed to mapped metadata). This will probably make it much easier to handle infinitely grouped rows.
• If a row is expanded, its child rows will be inserted after it, at the same dom depth, but with a className to denote its nesting level
• That className should be configurable just like everything else
• When there are any row groups in a table whatsoever, a column will need to be generated at the beginning of each row to control expansion (probably an html arrow out of the box). This column should be completely optional, and should use an internal api that would be available to use in any normal table cell (dogfood that shiz). This way, if someone wants to build their own grouping controls, they can do whatever the heck they want, however they want to do it.
• The grouping model should be transmitted with onChange events. This way: sorting, pagination, and now grouping can all be controlled easily serverside.
• Groupings callbacks will work by returning any unique primitive value (uniqueness will only be detected using a single level equality check, so don't return arrays or objects)
• The grouping model will need to be an array of objects, so it can support names and id's for the groupings. Similarly to sorting, if a grouping uses a custom callback, it will need an ID that it can be sent serverside (since functions cannot).

Thoughts?

[lukaswelinder]

@tannerlinsley Sorry for the delay, been quite busy.

Awesome list, thanks for taking the time to put that together. I think the infinite nesting makes it much more challenging to implement, but its usefulness outweighs that.

The operation order (grouping then sorting) is a good idea, especially for performance on massive lists. Do you imagine the sorting controls on the group or globally on the table head?

Pagination should respect sub-rows.

Not sure I follow what you mean by this. Do you mean that pagination of collapsed groups counts rows and not groups? ie: 3 groups w/ 30 items, 10/page would show a single group per page? I do see the challenge here thought...

State will need to be manageable both internally and externally (I think the best way to do this is by using reserved keys on the actual rows of data as opposed to mapped metadata).

By actual rows do you mean key or ref on the components, or are you talking about references to the original objects?

The grouping model should be transmitted with onChange events.

I think this is a great idea. Also, regarding this and the above snippet, should there be a way to disabled or prevent internal state (make it a fully controlled component)?

This and next week I will be diving into working with the library; our initial implementation doesn't require anything fancy, so it'll give me a chance to get a feel for when you already have in place.

I'll circle back early January with more detailed thoughts and feedback.

[tannerlinsley]

This is going to become a higher priority for me very soon. I plan on hopefully having support for this out by the end of February.

I think the best option for now is to assume a like-schema for sub-rows and implement what we have discussed in previous comments to achieve this.

I'll comment again when I begin to work on this if anyone is interested in collaborating on the effort.

:)

[tannerlinsley]

Just released 4.0.0 which was a big overhaul of the display logic and styling. Everything is flexbox now, which should lay a lot of the groundwork for what we're talking about here.

Along with those styling upgrades, a new subComponent prop allows you to utilize each rows data and return any custom react component of your choosing. You can see it in action here

This is merely a simple proof of concept of how we could implement pivoting and row-grouping in a serious manner. But we also get another win here. Let me explain:

If you're data already contains aggregated rows and drill through data, you can easily pass nested Tables without having to do any aggregation at all. You could even utilize subComponents for charting, large-format meta-data or other types of drill-through.

I'll be working on the actual pivoting and grouping logic in the weeks to come.

[tannerlinsley]

Implemented with 8fa7975! Huzzah!

[lukaswelinder]

Congrats on the release @tannerlinsley, great job on the implementation.

Wish I could have lended a hand; things have just been a little too busy lately 😬

[tannerlinsley]

Thanks! I'm sure they're is much more to polish but it works! Let me know what you think?

…

On Fri, Jan 20, 2017 at 11:27 AM Lukas Welinder ***@***.***> wrote: Congrats on the release @tannerlinsley <https://github.com/tannerlinsley>, great job on the implementation. Wish I could have lended a hand; things have just been a little too busy lately 😬 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFUmCcYO1Dtj3oYLMzLZGsVqaHFdNET-ks5rUPyEgaJpZM4KfII0> .