Rework tbl_split and addition of vertical split (by cols)

[Melkiades]

What changes are proposed in this pull request?

• Added tbl_split_by_rows() and tbl_split_by_columns() to split tables horizontally (row-wise) and vertically (column-wise).
• Modified tbl_split() to handle both column and row split of tables.

#2216

@ddsjoberg I think this solution is quite clean as it allows to call the splitting only once and do both (vertical and horizontal). Note that is fully backwards compatible, so no deprecation cycle is needed. I set first column-wise split as I repute it more relevant than row-wise. It can be changed swiftly if you think it differently.

I changed the ambiguous names of horizontal and vertical splits with by_rows and by_columns that is more direct. We had major issues with horizontal and vertical name confusion and I would only have them in the docs.

Let me know what you think! I have not devised tests yet, but the example shows the functionality.

---

Reviewer Checklist (if item does not apply, mark is as complete)

• PR branch has pulled the most recent updates from main branch.
• If a bug was fixed, a unit test was added.
• Run pkgdown::build_site(). Check the R console for errors, and review the rendered website.
• Code coverage is suitable for any new functions/features: devtools::test_coverage()
• usethis::use_spell_check() runs with no spelling errors in documentation
• All GitHub Action workflows pass with a ✅

When the branch is ready to be merged into master:

• Update NEWS.md with the changes from this pull request under the heading "# gtsummary (development version)". If there is an issue associated with the pull request, reference it in parentheses at the end update (see NEWS.md for examples).
• Increment the version number using usethis::use_version(which = "dev")
• Run usethis::use_spell_check() again
• Approve Pull Request
• Merge the PR. Please use "Squash and merge".

[ddsjoberg]

Thanks @Melkiades ! I like the updated names!

Do you think we need row splitting by row number as well as variable (also, there is the rare gtsumary table that does not have the variable column)?

What is the utility in keeping tbl_split()? I am just seeing another function to maintain 😆

[Melkiades]

Thanks @Melkiades ! I like the updated names!

Do you think we need row splitting by row number as well as variable (also, there is the rare gtsumary table that does not have the variable column)?

I do not think having this option would be too confusing for users and I expect at a certain point they will wonder why it is not present already. It is also true that they can achieve it with sub-setting? If it is not too complex in implementation (I do not think so), I would add it.

What is the utility in keeping tbl_split()? I am just seeing another function to maintain 😆

I like it being the main handler of list splits, so when we already do not know what is going to happen, it devices to list splitting or to row/cols splits. The code is very clean like this (otherwise we would have two separate generics for tbl_split_by_rows and tbl_split_by_cols so to accept lists too. If you like this second most I can go on and replace fully tbl_split. It will need a deprecation cycle though

[Melkiades]

All inputs are welcome! @ayogasekaram @edelarua ^^

[Melkiades]

I will add footnotes handling later today or tomorrow ;) Let me know if these updates are good @ddsjoberg

[Melkiades]

@ddsjoberg ready for final review!

[ddsjoberg]

@Melkiades , this is looking great! Let's set up a meeting to discuss the comments!

[ddsjoberg]

THank you @Melkiades !

I think we just need one more change: Can you add a row_numbers argument to tbl_split_by_rows(). We need to have the ability to split tables by row numbers as not all tables have a variable column.

• Add the row_numbers argument
• Document the variables and row_numbers arguments together, e.g. @param variables,row_numbers <description>
• Add check that a user passed one and only one of variables and row_numbers argument.

Thanks!