- 3 Minutes Wednesdays
- Posts
- 3MW (Arranging {gt} tables)
3MW (Arranging {gt} tables)
Guten Tag!
Many greetings from Ulm, Germany.
Buckle up, folks. Today we're doing advanced R stuff and we're combining this with HTML and CSS basics. But before we dive into our newsletter, let me remind you that all code can be found on GitHub. If you enjoy this newsletter, think about supporting my work with a coffee.
And if you’re a video person, check out my newest 150 seconds video on bar charts (Feedback on the video format is much appreciated).
Splitting {gt} tables
Recently, gt_split()
was released in {gt}
version 0.9. It helps us to split long tables into multiple sub-tables. Here's a 10-row table split into two 5-row tables.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/6e3da9ef-4bdc-4a3f-8274-2112093483db/image.png)
Unfortunately, this is not working properly in Quarto documents (but it works fine if you just run it in R). Whenever you try to render the table in a Quarto doc, you get this error.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/97b1ce90-d94b-44eb-a630-ead9716cc9e8/image.png)
I've already submitted a bug report on GitHub but until the next release we have to work around this bug. The error mentions something about knit_print()
. This tells us that the underlying function that is supposed to print the table into our Quarto document behind the scenes is not working properly.
What's the correct print() function?
All knit_print()
functions are named the same. They follow the pattern knit_print().[type]
. So we just have to figure out what data type gt_split()
returns.
Hence, we create a small table that we split with gt_split()
and save it into a variable. With class()
, we can find out the data type.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/3b2bf167-3b16-46e6-a019-9cb3c7c16513/image.png)
Accessing internal functions
Alright, let's have a look at {gt}
's internal print.gt_group()
function. This is not the same as knit_print.gt_group()
.
The former is the function that handles the output when we call gt_split()
in R (which we know works) and the latter is the faulty function that we need to overwrite.
We can access internal functions with the triple colon :::
. This way, we can find the gt:::print.gt_group()
function that is hidden inside of the package.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/22b8cb6f-55c2-4ede-992f-c4e2ff05fa5c/image.png)
Register the print function
Knowing a new function is pretty dandy. But it's not useful at all, if Quarto does not know that it's supposed to use this print function for it's own knit_print()
thingy.
So, we just have to tell Quarto - or more specifically the underlying knitr
engine, that it better uses the working print function when handling gt_group
s. In fancy terms, we register a new S3 method.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/1d262921-7fc8-47b1-9533-82d407c9070e/image.png)
Once the new method is registered, the Quarto document will render just fine. But to make sure that it displays the table properly, use the output: asis
code chunk option whenever you want to display a split table.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/2bb4200f-8e87-44fe-9419-e86ad419f6e2/image.png)
Cool, we fixed a bug. Now what?
Once you get the output working, gt_split()
splits each table with a line break so that tables will appear below each other.
But that's not necessarily what we want. Maybe, we want the two tables next to each other instead. So let's create our own print function by enhancing the one from {gt}
with a little bit of HTML and CSS magic. Here are the key ingredients:
Wrap all sub-tables into a
div
container withhtmltools::div()
Wrap the combined list of containers into another
div
container.Make our print function dependent on two variables
css_inner
andcss_outer
which we will use to add CSS to our new containers.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/e26109f1-df3c-405d-a81f-f250fc336171/image.png)
No need to register this new function. We’ll just call it, so that we can modify the CSS for each split table individually. For now, though, the output stayed the same. Let's change that.
Enable flexbox display
By default, div
containers always appear below each other. In order to rearrange them, you need to change the display
-style of the surrounding container.
This means that we have to change outer_css
. More specifically, we have to set outer_css = 'display: flex;'
. This activates the flexbox
display that puts div containers next to each other by default.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/e35abd19-9ad8-4215-8b74-4c02f0ab4d2c/image.png)
Spread out tables
Nice, the tables are next to each other. But they stick pretty close together.
Last week, we’ve learned that we can increase the space between elements with margins. The cool thing with flexboxes is that we can set the margins to auto
so that the containers spread out across the available space.
![](https://media.beehiiv.com/cdn-cgi/image/fit=scale-down,format=auto,onerror=redirect,quality=80/uploads/asset/file/c273a4dd-b546-4f0b-8328-dfff2dee7d78/image.png)
Alright, that’s a wrap. There’s lots more to learn about display styles and rearranging tables. We’ll continue on this path next week.
Hope you’ve enjoyed this week’s newsletter. If you want to reach out to me, just reply to this mail or find me on Twitter.
See you next week!
Albert 👋
Reply