rstudio
Throw warning/error when using `output: html_notebook` and `runtime: shiny`
Overview
When using output: html_notebook and runtime: shiny, the normal code chunk evaluation sometimes occurs and sometimes doesn't. This is what happens locally. However, if the app is deployed (at least to Connect and shinyapps.io), you never have code chunk evaluation. (The embedded Shiny app always works.)
@jcheng5 and I talked about how this is confusing and it may be better to either implement runtime: shiny for notebooks, or always warn/error if a user has both output: html_notebook and runtime: shiny. Currently, there is no warning or message that indicates that this is unsupported/undefined behavior. And since there's so much similarity between html_document and html_notebook (from a user's perspective), it isn't clear that this is unsupported.
The repro code is below, along with screenshots of both cases and the output of devtools::session_info('rmarkdown'). I couldn't really figure out if the runs when the code evaluation works vs the ones it doesn't are deterministic, but they appear random. The closest to reproducibility that I got to is that it usually starts off working, then it stops (though it may resume working again in future runs) and a good way to get it to work is to close and reopen the file...
Repro
---
title: "R Notebook"
runtime: shiny
output: html_notebook
---
```{r setup, include=FALSE}
library(dplyr)
library(shiny)
```
### Normal chunk evaluation
Sometimes it works, sometimes it doesn't. It never works when it's deployed.
```{r}
head(mtcars, 3)
```
---
### Shiny App Example
Always works.
```{r, echo=FALSE}
ui <- fluidPage(
numericInput('n', 'Number of obs', 200),
plotOutput('plot')
)
server <- function(input, output, session) {
output$plot <- renderPlot({
hist(runif(input$n))
})
}
shinyApp(ui, server)
```
Screenshots
Chunk code evaluation working:
Chunk code evaluation not working:
Session info:
devtools::session_info('rmarkdown')
devtools::session_info('rmarkdown')
## Session info -------------------------------------------------------------
## setting value
## version R version 3.4.2 (2017-09-28)
## system x86_64, darwin15.6.0
## ui X11
## language (EN)
## collate en_US.UTF-8
## tz Europe/Lisbon
## date 2017-10-11
## Packages -----------------------------------------------------------------
## package * version date source
## backports 1.1.0 2017-05-22 CRAN (R 3.4.0)
## base64enc 0.1-3 2015-07-28 CRAN (R 3.4.0)
## bitops 1.0-6 2013-08-17 CRAN (R 3.4.0)
## caTools 1.17.1 2014-09-10 CRAN (R 3.4.0)
## digest 0.6.12 2017-01-27 CRAN (R 3.4.0)
## evaluate 0.10.1 2017-06-24 CRAN (R 3.4.1)
## graphics * 3.4.2 2017-10-04 local
## grDevices * 3.4.2 2017-10-04 local
## highr 0.6 2016-05-09 CRAN (R 3.4.0)
## htmltools 0.3.6 2017-04-28 cran (@0.3.6)
## jsonlite 1.5 2017-06-01 CRAN (R 3.4.0)
## knitr 1.16 2017-05-18 CRAN (R 3.4.0)
## magrittr 1.5 2014-11-22 CRAN (R 3.4.0)
## markdown 0.8 2017-04-20 cran (@0.8)
## methods * 3.4.2 2017-10-04 local
## mime 0.5 2016-07-07 CRAN (R 3.4.0)
## Rcpp 0.12.13 2017-09-28 cran (@0.12.13)
## rmarkdown 1.6 2017-06-15 CRAN (R 3.4.0)
## rprojroot 1.2 2017-01-16 CRAN (R 3.4.0)
## stats * 3.4.2 2017-10-04 local
## stringi 1.1.5 2017-04-07 cran (@1.1.5)
## stringr 1.2.0 2017-02-18 CRAN (R 3.4.0)
## tools 3.4.2 2017-10-04 local
## utils * 3.4.2 2017-10-04 local
## yaml 2.1.14 2016-11-12 CRAN (R 3.4.0)
I tried many times and was never able to get the mtcars table in the output.
However, if I add stop("error!") in the chunk, the document fails to compile as expected, which means this code chunk has been evaluated. Actually if I call print() or knitr::kable() on the data frame, I can see the output every time. I did some further testing, and obviously there is something weird with printing values in code chunks, e.g. a character string is printed twice:
Currently I don't know the reason and I'm not entirely familiar with how notebooks work internally. Let's see if our notebook experts have any ideas: @jjallaire @jmcphers @kevinushey.
Doing some issue sanitizing in the repo and this is an old issue we may need to finally deal with.
@jjallaire, considering also the new shinyrmd runtime, does it make sense to have html_notebooks with a runtime ?
I am not sure as .nb.html won't be able to run the shiny app on its own, and I don't see the advantage over using html_document + runtime : shiny
Yes, html_notebook would indeed work with runtime: shinyrmd.
The advantage over runtime: shiny is that runtime: shiny requires a fresh server-side render for each new user of the document. This is problematic if it either takes more than a few seconds to render or if you expect to have lots of concurrent users.
