Skip to contents

Run a module using various UI libraries.

Usage

module2app2(ui_lib = options::opt("ui_lib"), ...)

Arguments

ui_lib

UI framework to use. Must be one of sdb for shinydashboard or bslib for bslib. Framework is set as an option, and not provided as an argument for each module, because it only changes at app launch time, and is the same for all modules in any one app. Ideally, it would be read from the shinyApp() call, but that does not seem to easily provide this information. (Defaults to "sdb", overwritable using option 'esOutput2.ui_lib' or environment variable 'R_ESOUTPUT2_UI_LIB')

...

Arguments passed on to shiny::shinyApp

ui

The UI definition of the app (for example, a call to fluidPage() with nested controls).

If bookmarking is enabled (see enableBookmarking), this must be a single argument function that returns the UI definition.

server

A function with three parameters: input, output, and session. The function is called once for each session ensuring that each app is independent.

onStart

A function that will be called before the app is actually run. This is only needed for shinyAppObj, since in the shinyAppDir case, a global.R file can be used for this purpose.

options

Named options that should be passed to the runApp call (these can be any of the following: "port", "launch.browser", "host", "quiet", "display.mode" and "test.mode"). You can also specify width and height parameters which provide a hint to the embedding environment about the ideal height/width for the app.

uiPattern

A regular expression that will be applied to each GET request to determine whether the ui should be used to handle the request. Note that the entire request path must match the regular expression in order for the match to be considered successful.

enableBookmarking

Can be one of "url", "server", or "disable". The default value, NULL, will respect the setting from any previous calls to enableBookmarking(). See enableBookmarking() for more information on bookmarking your app.

Details

Ideally, shiny modules should maintain the strict separation of concerns in web content between structure (HTML), style/layout (CSS) and interaction (JavaScript). Some higher level UI idioms in shiny design combine these concerns. For example, a shinydashboard::valueBox() or, equivalently, bslib::value_box() only look correct, when their emitted HTML is targeted by the appropriate CSS. This helper lets you check and test modules in various CSS contexts, using the options for ui_lib. The helper also sets an option for downstream modules, indicating which framework they are running in.

See also

Other helpers: theme_color_from_pred()