4.4 Deploying a packaged shiny application

It makes sense to structure shiny applications as a package to better control their dependencies. However, some structural conditions are required for the deployment of a packaged shiny application.

As already mentioned, one option is to use the golem package, which will initialize the shiny application with its framework that does support deployment of a shiny application as a package. But sometimes you may not want to add an entire framework to an existing application and instead add this support manually.

Since we did not find any good documentation of this online (as of Nov 2020), we investigated this ourselves and are happy to share our findings here.

4.4.1 Entry point

The application needs an entry point which should be named app.R and be situated in the root of the package, i.e. where DESCRIPTION and NAMESPACE are located.

It should contain only what is required for the entry point to be able to load the application, e.g.:

pkgload::load_all(export_all = FALSE, helpers = FALSE, attach_testthat = FALSE)
# PKG is the name of the packaged shiny application
# run_PKG_app is a function that wraps around shiny::shinyApp()
PKG::run_PKG_app()

run_PKG_app <- function() {
  shinyApp(ui = ui, server = server)
}
# where ui and server are both functions

4.4.2 server and ui

Both server and ui need to be functions in order to work in the packaged shiny application context. server should already be a function and it is enough to wrap ui into a function without any arguments or return statements.

In the beginning of the ui function, we also need to add a call to shiny::addResourcePath to make static resources available.

4.4.3 non-CRAN dependencies

Deploying a packaged shiny application which uses non-CRAN package sources like Github requires additional information in the DESCRIPTION file. Namely, the repository details of such dependencies must be included in a Remotes: field, so that tools like renv or remotes know where the packages should be retrieved from.