Tables with row groups

[simonsteiger]

Hi,

Thank you for this excellent package!

I often have to work with data that has subgroups nested in several groups. In tables I typically represent that with row groups (I'm taking this term from gt's "nomenclature" https://gt.rstudio.com/).

I've written a simple function to take care of this and was wondering if having such a feature as part of SummaryTables.jl would generally be of interest.

This draft is missing tests and support for a lot of keywords, but I'm happy to add those.

using DataFrames, SummaryTables

data = DataFrame(
    group=repeat(["group x", "group y", "group z"], inner=2),
    subgroup=repeat(["subgroup x", "subgroup y"], outer=3),
    a=collect(1:6),
    b=reverse(collect(1:6)),
)

rowgroup_table(data, :group)

I personally don't like leaving the subgroup column header in, so I would call rename(df, :subgroup => "") before, but I've omitted that here.

[jkrumbiegel]

I'm wondering if this could be a part of simple_table. It looks like your table has no other structure that would warrant a completely new table function. In general, the other special tables have grouping builtin if they need to because it's central to their functionality. Here it's more the presentation that's changed. gt does have a different concept where they try to build any table out of semantic building blocks, which in my experience doesn't always work. So here it's just Cells or some specific table function, which is why I'm wondering if and where it fits.

[simonsteiger]

I fully agree with that! I was also feeling some friction / misfit with the existing API.

It wasn't too much work to figure out how to extend simple_table the way I wanted to (I mostly browsed through the code for table_one and simple_table). That being said, it still felt like a feature that could be relevant to others as a pre-written function, so I thought I'd ask you.

Could it be an alternative to have a docs page showing how to use Cell to manually customise tables? Here, extending simple_table to a table with row groups could be an example then. (I guess I should say that I'm happy to write a draft for that)

[jkrumbiegel]

You mean combining table functions with the basic infrastructure of Cells? I guess I haven't thought about that kind of augmentation yet, I always thought either or

[simonsteiger]

Sorry for not being very clear there.

You mean combining table functions with the basic infrastructure of Cells?

I guess it would be possible to add a rowgroup_col keyword to simple_table as you suggested in your first reply, if that's what you're referring to. But I am also not sure if it fits with the approach that SummaryTables takes compared to PrettyTables or gt.

Regarding the docs suggestion, I was thinking about extending the Infrastructure section of the docs with an example bringing together the examples from the subsections on Table, Cell, and CellStyle.

Reading through those convinced me that I could set up the table with row gaps as I'd like, but to get there I still consulted the source code for table_one and simple_table. That's of course not a big issue, but giving a more "narrated" example might help other users who want to use SummaryTables not for the builtin functionality that, e.g., table_one brings but for the styling options.

(For context, I have struggled to find a Julia package that allows me to format tables and write to .docx. I'm effectively using SummaryTables as a gt replacement, which is – as you said – not what SummaryTables intends to be.)

[jkrumbiegel]

Ah if you want to write formatted tables to docx more freely, it might make sense to work directly with WriteDocx.jl and add some convenience functions on top of that. SummaryTables only supports that one style because that's what we need and what's common for publications.

But yes a docs section on making your own table function and using all the building blocks would be great as well

[simonsteiger]

I've decided to create a package for the custom table styling functions I had in mind (https://github.com/simonsteiger/StyledTables.jl).
The result is a Matrix{Cell} that is converted to a SummaryTables.Table for display and rendering to different output formats. I wonder if it's OK to depend on internals of SummaryTables (i.e., what's listed under Infrastructure in the SummaryTables docs) or if you'd suggest another approach here.

PS: I hope it is OK that I effectively copied + adapted your logo! I think the SummaryTables logo is really sleek (and all the others you have made, too!) and wanted to somehow illustrate that StyledTables is built on top of / closely related to SummaryTables.

[simonsteiger]

@jkrumbiegel Sorry to tag you here, I am not sure if this might not have shown up in your notification flow. It's of course not an urgent issue – I just want to make sure my comment didn't fly under the radar. :)

[jkrumbiegel]

Ah no worries, just forgot to respond :)

The data structures in infrastructure are considered public, so yeah go ahead and use those. Use the keyword constructors though rather than the positional low-level ones so your stuff doesn't break if I decide to add a field, that's how I intended this to work.

And sure no problem if you adapt the logo!

I actually thought about making a gt like interface for SummaryTables as well, so I'll check out yours at some point, too

[simonsteiger]

Perfect, thanks a lot for your reply and the clarification about the keyword constructors. :) I'd be happy if some of the things I worked on came in handy with your planned gt interface of course. If it makes sense to transfer some code to a new package, I'd be happy to do that, too.