Effectively Debugging Shiny Apps

Effectively debugging Shiny apps

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.

R shiny app errors with ui.R

textInput needs a label and submitButton doesn't.

Try this:

  textInput("input", "A Label"),
  submitButton("submit")

Also you have an additional comma after submitButton.

Unfortunately I'm quite new too R too, I have no suggestions to debug Shiny App.

R shiny app errors with ui.R

textInput needs a label and submitButton doesn't.

Try this:

  textInput("input", "A Label"),
  submitButton("submit")

Also you have an additional comma after submitButton.

Unfortunately I'm quite new too R too, I have no suggestions to debug Shiny App.

Shiny apps in R: how to structure them correctly

1. As you describe your current set up, the most obvious place to load your libraries is at the start of your global file. (Or at the start of app.R if you move to a single file configuration.) Though not exactly what the reprex package is designed for, you could probably use reprex to make sure that your code is reproducible and independent of anything you may have overlooked. (You've already identified the obvious issue with data files.) Look here for more information on reprex.

2. Indeed. This is a problem. If you must load the data from files, you need to find a way of providing them to your professor. Telling him to edit your code by hand is not a good way to start. Exactly how to do this depends on the infrastucture your institution has set up, so it's difficult to advise you what to do. Do you not have a shared area for your course? Ask your fellow students - or even your professor.

3. Whether you bundle the app in a single file or in seperate files is really a matter of choice. I don't think there's a wroing way and a right way. For me, the deciding factor is usually the size of the app. Large apps get several files. For small apps, separation is just an unnecessary complication. Another factor - that doesn't seem to be an issue here - is whether I see the app as a potential front end for some methodology that might be worthy of its own package. In that case, I develop the app as a front end, and the package itself as separate entities.

Code profiling for Shiny app?

A few (rough) ideas:

1. Profiling the app in the browser might help. I have a largish app that uses navbarPage and the page build speed was getting slow. Using profiling in Chrome (developer tools) identified the 'culprit'. A fix/improvement is in the works https://github.com/rstudio/shiny/issues/381#issuecomment-33750794
2. Run the profiler from a code window in your app. Using the shinyAce package (https://github.com/trestletech/shinyAce) I can edit (and run) code, including profilers from within the app (i.e., call reactives etc.). See link below (R > Code). Note that code evaluation is deactivated on the server but the source code for the app is on github if you want to try this out (see About page)
3. Write your code in regular R functions that are called by reactive functions. I am in the process of rewriting my app so that it can use knitr for 'reproducible research' (R > Report). This restructuring makes it easier to use profiling libraries from R(studio) without starting the app.
4. Rselenium is an R interface to Selenium, testing tools for web-apps (https://github.com/johndharrison/RSelenium). I have only just started using this but you perhaps you could use this with something like system.time to compare speeds for different components.

http://vnijs.rady.ucsd.edu:3838/marketing/

---

Related Topics