interactive shiny development

[rstudiousername]

One of R's biggest advantages is that it's an interactive language. You can run individual lines of code to figure out what runs, what the output looks like, etc. But that interactivity largely disappears when developing a shiny app. There are reactive elements, the app looks in its own directory for files instead of the project directory, etc. You basically have to make a functional app before you can interact with it, which is a huge hurdle. What sorts of methods/techniques are available for interactively developing shiny apps so that I can see what's going on?

[prubin]

I don't consider the "functional app" part a huge hurdle. You can build the skeleton of the app and then add features piecemeal.

Regarding developing/debugging, two rather crude techniques I use are (1) sprinkling cat(), print() and str() commands in various places where I think there might be a problem, to see what the code is seeing, and (2) using lines like junk <<- some_reactive_thing(). This is running the app from RStudio. When I stop the app, junk pops up in the RStudio environment and contains the value of the reactive thing the last time that line executed. If something goofy is happening inside a function, after using lines like that to store all the function inputs in the global environment I can rename them to match what is in the code and then execute the code line by line to see where things go splat.

[nirgrahamuk]

If you make judicious use of shiny modules, to break out the larger app into smaller components, it can reduce the overhead or running/coding/rerunning.

aside from that I have 2 general strategies for interactively scripting out code that should live in some reactive block of an app, they are broadly equivalent with some pros/cons either way

1. drop a browser() or debug() at an appropriate code line, and then you can interactively code at that point. In such a way I can script out a section, then remove the browser and go on
   alternatively
2. drop a save_image() or equivalent (I made my own save_image wrapper function with qs package on the back end, and my wrapper users rlang::current_env() to be explicit about what its saving) ; Place such a device at the head of the reactive code to be written. In this mode of work, you would have wanted to concretize any reactive or input$ dependent variables within scope as local variables so that they will be appropriately captured via save_image. Then you can run the code. and similar to the concept of having made a variable global << this method has the advantage that you can restart your session, cleaning out all memory, and then reload the image from disk, i.e. easier to restart work.