jthomasmock / gtExtras

A Collection of Helper Functions for the gt Package.
https://jthomasmock.github.io/gtExtras/
Other
195 stars 27 forks source link

Impossible to correctly print gt with plot from for loop #57

Closed AshesITR closed 2 years ago

AshesITR commented 2 years ago

Related to #56. Tested on CRAN and jthomasmock/gtExtras@f170283 If the table generating code sits in a function, there seems to be no way to correctly print a gt containing a gt_plt_dist() column:

---
title: "R Notebook"
output: html_document
---
```{r}
dummy_data <- tibble::tibble(
  a = 1:2,
  b = list(1:2, 3:4)
)
f <- function() {
  gt::gt(dummy_data) |>
    gtExtras::gt_plt_dist(column = b, type = "histogram") |>
    print()
}

for (i in 1) {
  f()
  cat("boop.\n")
}
f <- function() {
  gt::gt(dummy_data) |>
    gtExtras::gt_plt_dist(column = b, type = "histogram") |>
    knitr::knit_print()
}

for (i in 1) {
  f()
  cat("boop.\n")
}


Renders to
![render](https://user-images.githubusercontent.com/2363178/174594449-3d9dfc75-4d93-4261-94ec-f0bdd25c555d.png)

So using `knit_print()` (which would produce correct output) doesn't show the table at all and using `print()` shows a broken second row.
jthomasmock commented 2 years ago

Almost nothing is impossible with R 😉

This is a knitr "problem" wrapping a pandoc feature. See this issue/note from Yihui on Stackoverflow.

The problem is Pandoc's Markdown treats indented lines (by four spaces) as literal code blocks (<pre></pre>).

You can see that behavior in your screenshot with the <tr><td> being printed as a literal code block.

For now you could protect against this behavior by removing any repeated whitespace.

```{r, results = 'asis'}
f <- function() {
  tbl <- gt::gt(dummy_data) |>
    gtExtras::gt_plt_dist(column = b, type = "histogram") |> 
    gt::as_raw_html() |> 
    gsub(x = _, pattern = "\\s+", " ") |> 
    gt::html() |> 
    print()

}

for (i in 1) {
  f()
  cat("boop.\n")
}

![Screen Shot 2022-06-20 at 10 17 43 AM](https://user-images.githubusercontent.com/29187501/174634054-e0afcb50-2857-47b3-b132-72780e9d9bcd.png)

As far as new development in `gtExtras`, I don't believe that a new print method is appropriate for the package until I can do quite a bit of testing for interactive or more traditional use as opposed to some conflicts with `knitr`. 

I was able to reproduce this behavior with just adding inline SVG in `gt` itself, so I'll explore if an issue on the default `gt` method is appropriate.
AshesITR commented 2 years ago

Thank you very much for the quick reply! I found out that knit_print() |> cat() works as well, since knit_print.gt_tbl ends in knitr::asis_output() of a character vector. The latter isn't auto-printed, but can be manually printed using cat().

jthomasmock commented 2 years ago

I found out that knit_print() |> cat() works as well, since knit_print.gt_tbl ends in knitr::asis_output() of a character vector.

This will probably be the ideal solution given that I don't particulary want to create a separate class of gt_tbl.