Defaults and Hiding Controls

Finding valid keys

Defaults keys map directly to the argument names of the underlying plot function. The quickest way to find them is the module’s *InputsUI() help page, e.g. ?dittoViz_scatterPlotInputsUI. The Plot parameters and defaults section lists every wired argument, its UI label, and its built-in default.

For inputs that come from the uniform tab helpers (Axes, Legend, Lines, Plotly), see ?uniform_axes_inputs_ui, ?uniform_legend_inputs_ui, ?uniform_lines_inputs_ui, and ?uniform_plotly_inputs_ui respectively.

Validation

get_default() (used internally by every module) accepts an optional validator predicate. If the value you supply fails validation — e.g. passing a string where a logical is expected — the module silently falls back to its built-in default rather than erroring. This means a typo in a key is silent; double-check key names against the help page if a default appears to have no effect.

Reactive defaults: driving inputs from app state

Sometimes a parameter needs to follow your app rather than be fixed once. A common case is a colour mapping that should track a column the user has selected elsewhere in the app. For this, any individual entry in defaults may be a reactive() or a reactiveVal() instead of a plain value:

library(VizModules)

ui <- fluidPage(
    selectInput("colour_col", "Colour by", choices = c("cyl", "gear", "carb")),
    sidebarLayout(
        sidebarPanel(uiOutput("controls")),
        mainPanel(dittoViz_scatterPlotOutputUI("p"))
    )
)

server <- function(input, output, session) {
    plot_defaults <- list(
        x.by = "wt",
        y.by = "mpg",
        color.by = reactive(input$colour_col)
    )

    output$controls <- renderUI({
        dittoViz_scatterPlotInputsUI("p", mtcars, defaults = plot_defaults)
    })

    dittoViz_scatterPlotServer("p", data = reactive(mtcars), defaults = plot_defaults)
}

shinyApp(ui, server)

Pass the same list to both *InputsUI() and *Server(), as you would for static defaults. Because the UI needs access to the reactive, build it inside renderUI() (the UI seed is taken with isolate(), so this does not cause the controls to re-render whenever the reactive changes).

You get three guarantees:

• The parameter tracks the reactive. Every change flows through to the plot.
• The control stays correct and editable. The Color By selector shows the current column, and the user can still change it.
• The plot renders once per change. The value is resolved server-side, in the same reactive flush as the data, so there is no flicker.

Semantics worth knowing:

• An external change always wins. If the user has picked a different colour column in the module and then changes the app-level selector, the selector’s value replaces their choice.
• Reset restores the reactive’s current value, not the value it held at startup.
• Only reactive() and reactiveVal() are recognised. A plain function is treated as a literal default value, not as something to call.
• Composite widgets sync cosmetically only. The plot always uses the current value, but a compound control that does not accept a generic value message — custom.models in the scatter module is the one to watch — will not re-display it. Reactive defaults are not supported for that input.

Passing defaults through createModuleApp() and *App()

defaults is forwarded all the way through the app factory:

plotthis_BoxPlotApp(
    defaults = list(
        x.by     = "Species",
        y.by     = "Sepal.Length",
        pt.size  = 0
    )
)

The same defaults list is accepted by createModuleApp() directly:

app <- createModuleApp(
    inputs_ui_fn = plotthis_BoxPlotInputsUI,
    output_ui_fn = plotthis_BoxPlotOutputUI,
    server_fn    = plotthis_BoxPlotServer,
    data_list    = list("iris" = iris),
    defaults     = list(x.by = "Species", y.by = "Sepal.Length")
)
if (interactive()) runApp(app)

Use case: app-level fixed parameters

A common pattern is to fix a column mapping or aesthetic so that app users cannot change it, while still applying it to every plot:

server <- function(input, output, session) {
    dittoViz_scatterPlotServer(
        "p",
        data        = reactive(mtcars),
        defaults    = list(color.by = "cyl"),
        hide.inputs = "color.by"
    )
}

The colour mapping is always cyl, and the control for it never appears.

This composes with reactive defaults: a hidden control whose default is a reactive() still drives the plot, because the value is resolved server-side rather than read back from the (now invisible) input. That is the cleanest way to lock a parameter to app state entirely.

Available tab names

Tab names are module-specific. Inspect the inputs list inside the relevant *InputsUI() source, or open ?<module>InputsUI and look for the tab headings described there. Common tabs across most modules include: