Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Effectively debugging Shiny apps

Tags:

r

debugging

shiny

I have a complex Shiny app spread across multiple files that uses code from several packages. The app works when run locally in R Studio, but on my server it throws a generic error:

Error: do not know how to convert 'x' to class "Date"

This is probably a simple programming mistake, but figuring out exactly where that mistake is in the code is proving difficult.

How can I hunt down and fix the source of errors in Shiny apps? And what tools are available to do this in a systematic way?


There has been some discussion of similar problems on Google Groups.

like image 609
sdgfsdh Avatar asked Aug 10 '15 13:08

sdgfsdh


People also ask

How do you debug a Shiny code?

RStudio DesktopRestart RStudio, start your Shiny app, right-click on it, and you'll see a new Inspect Element option. Click it to launch the Safari JavaScript debugger.

Why is my Shiny app so slow?

There are many reasons why a shiny app runs slower than expected. The most common reason is the Shiny app code has not been optimized. You can use the profvis package to help you understand how R spends its time. You also might want to make sure your server is large enough to host your apps.

How do you structure a Shiny app?

A Shiny app consists of two parts, a user interface ( ui ) and an R session that runs code and returns results ( server ). These two parts can be in their own files called ui. R and server.


2 Answers

You can achieve logging on the server using a combination of logging and shinyjs.

install.packages("logging") install.packages("shinyjs") 

In your ui.R, bind shinyjs using shinyjs::useShinyjs:

library(shinyjs)  shinyUI(     fluidPage(         useShinyjs(), # etc... 

In your server.R, add logjs to the list of log handlers:

library(magrittr) library(shinyjs) library(logging)  basicConfig()  options(shiny.error = function() {      logging::logerror(sys.calls() %>% as.character %>% paste(collapse = ", ")) })  shinyServer(function(input, output, session) {      printLogJs <- function(x, ...) {          logjs(x)          T     }      addHandler(printLogJs) # etc... 

Then to print something, use loginfo.

Other Tips

  1. When running your app locally, such as from RStudio, use options(shiny.error = browser) or options(shiny.error = recover) to identify the source of errors.

  2. Put as much business logic into packages and external scripts as possible. Unit-test these whenever you suspect they are causing issues. The testthat package can help here.

  3. If you expect a variable to meet certain constraints, add an assertion. For example, if x should be a zoo, put assert_that(is.zoo(x)) near the top of your reactive.

  4. Beware of the default drop behaviour. Get into the habit of specifying drop = F whenever you want your result to be a data.frame.

  5. Try to minimize the number of variables (options, environment, caching, UI state, etc.) that a unit of code depends on. Weakly typed languages are hard enough to debug already!

  6. Use proper S4 and S3 classes instead of raw R structures where possible.

  7. dput will allow you to examine the internal structure of objects, and is very useful when trying to reproduce errors outside of an app.

  8. Try to do your debugging in an interactive console, not using print inside an app. This will allow you to iterate more quickly. When debugging outside of an app is not possible, try putting a browser() call just before the problem code.

  9. Never use sapply in non-interactive code. With an empty output, it will be unable to infer the type that you want and return an empty list. If your result should be a vector, use vapply. If your result should be a list, use lapply.

You should also look at Debugging Shiny Applications from the RStudio team.

like image 127
sdgfsdh Avatar answered Oct 03 '22 04:10

sdgfsdh


I'm surprised that the RStudio Shiny debug article is not mentioned. That article is very thorough in debugging and error processing.

You can check the log of your server, which should solve the question asked by OP more directly.

like image 31
dracodoc Avatar answered Oct 03 '22 03:10

dracodoc