Make `session$destroy` preserve statically defined inputs

[ml-ebs-ext]

Context

I'm part of the team that develops the DaVinci modular ecosystem (think "Teal" except with a focus on data exploration rather than reporting).

Many of our modules have such a regular interface that we can describe their parameters semantically and generate UIs on the fly to configure them. Here's an example of how we can configure a lineplot display:

The left menu allows to configure the module through a point-and-click interface. The top-right section shows the equivalent code. The bottom-right section is the actual interface of the module as it will be displayed in the final application.

This app works by re-running the target module every time one of the left menu parameters changes. This is far from trivial due to leftover observers in the target module, which led us to develop an observer_dedup routine that works as advertised but relies on undocumented shiny internals. As you can imagine, we were very happy to see the work you've put in the recent ability to destroy reactive state feature.

Problem

The problem we're facing is that session$destroy() will remove all server side inputs regardless of whether they were introduced dynamically (renderUI/insertUI) or declared statically as part of the UI of the application. This means that a hypothetical static UI selectInput(ns('id'), ...) that defaults to its first option will no longer be available upon reload and any reactive that depends on input[['id']] will just fail until the user interacts with the selector.

At first glance this issue looks like just an ergonomic loss, but the impact that it has on the feedback loop of the users of this tool is severe. When you know that the target module will be in an error state after every parameter change, you think twice before touching anything. We would prefer our users to stay in a curious, playful state of mind.

We could rewrite all of our modules to avoid statically defined inputs, but we believe this issue hurts the usefulness session$destroy(), so we've decided to run our use case by you first and maybe save ourselves the trouble.

Request

• Would it be possible for session@destroy() to spare the server-side representation of statically defined inputs?

There are other formulas that would work for us. We would also be equally happy if the state of all inputs was preserved, perhaps conditional to an extra flag passed to session$destroy (e.g. session$destroy(id, preserve_input_state=TRUE)).

Thanks for considering our request!

[schloerke]

Thank you for the detailed writeup and pointing to your DaVinci repos!

(Claude and) I put together a minimal reprex and a couple of candidate fixes to pressure-test the idea, and I'd like to push back on the specific request while (hopefully) giving you a better path.

Reprex

Here's a Shiny app with a module that has a statically defined selectInput, whose UI is drawn once and left in the DOM. The server is re-run and session$destroy(id)'d on each "param change". This reproduces your report — after a re-run the <select> still shows "a" in the browser, but the server reads input$choice == NULL, and any reactive depending on it breaks until the user touches the widget.

# Requires a shiny with session$destroy() (from #4372).
library(shiny)

# The "target module": its UI has a STATICALLY defined selectInput.
targetUI <- function(id) {
  ns <- NS(id)
  tagList(
    selectInput(ns("choice"), "Static choice (defaults to 'a')", c("a", "b", "c")),
    verbatimTextOutput(ns("echo"))
  )
}

targetServer <- function(id, dataVersion) {
  moduleServer(id, function(input, output, session) {
    # dataVersion changes each re-run (like new params/data), forcing the output
    # to recompute -- so it actually observes the post-destroy input value.
    output$echo <- renderText({
      val <- input$choice
      if (is.null(val)) {
        sprintf("run #%s: input$choice is NULL  <-- BROKEN until user touches selector", dataVersion)
      } else {
        sprintf("run #%s: input$choice = %s", dataVersion, val)
      }
    })
    # See "symptom #2" below: destroy() wipes this output's `_hidden` clientData,
    # so without this the recreated output stays suspended and shows stale text.
    outputOptions(output, "echo", suspendWhenHidden = FALSE)
  })
}

ui <- fluidPage(
  actionButton("rerun", "Re-run target module (simulates a param change)"),
  uiOutput("module_ui")   # UI drawn ONCE and never changed, like your DR.R
)

server <- function(input, output, session) {
  MOD_ID <- "target"
  output$module_ui <- renderUI(targetUI(MOD_ID))
  targetServer(MOD_ID, dataVersion = 0)

  observeEvent(input$rerun, {
    session$destroy(MOD_ID)                     # tears down observers, outputs, AND inputs
    targetServer(MOD_ID, dataVersion = input$rerun)
  })
}

shinyApp(ui, server)

Tracing it through, there are actually two symptoms, and they share one root cause:

1. NULL input. destroy() wipes the server-side input mirror (input$destroyByPrefix). The browser widget is untouched, so it never rebinds and never re-sends its value — the server just sees NULL.
2. Suspended output. destroy() also clears the output's output_<id>_hidden clientData, and shiny treats a missing hidden flag as "hidden" → the recreated output is suspended and won't recompute. (That's the suspendWhenHidden = FALSE line above — without it, this symptom masks support additional capabilities of jslider #1 with stale text.)

Both are the same thing: session$destroy(id) tears down a scope — UI + server + reactive state — as one unit, but the app keeps the UI alive independently of the scope. Inputs are owned by the client; the server copy is just a mirror that repopulates when a widget binds. If the widget never rebinds, a server-side wipe is permanent (until manual interaction).

Not implementing session$destroy(preserveInputs=TRUE)

I prototyped the literal request — a session$destroy(id, preserveInputs = TRUE) that skips wiping inputs. It works for your all-static case, but it has an edge case I don't want to bake into the API: it preserves every input in the scope, including ones created dynamically via renderUI/insertUI whose DOM was removed. Those become stale server-side orphans the client will never update or clear — exactly the kind of leak your observer_dedup was built to prevent. A destroy() that reliably orphans state in mixed static/dynamic modules is a worse default than what shiny has today.

(I also tried a "client, please re-send your inputs" approach. It self-heals in one tick and handles dynamic inputs correctly, but it needs a client round-trip — a brief NULL window — and, notably, a naive unbindAll()/bindAll() does not work: the client's input-value cache is unaware the server dropped the value, so the re-send is deduped away. You have to force it past the cache with priority: 'event'. That wrinkle is a good sign that "resend a namespace" isn't as simple a primitive as it first looks.)

The recommendation: couple the UI lifecycle to the scope lifecycle

The reliable fix needs no shiny change — it's to make a re-run behave exactly like a fresh module load: when you destroy the scope, re-render its UI too, so the client tears down the old widgets and binds new ones (which re-send their values on bind, req()-guarded, just like page load). This fixes both symptoms at once, with no suspendWhenHidden hack and no orphan risk.

Here's the pattern I'd suggest for a generic runner like yours:

library(shiny)
`%||%` <- function(x, y) if (is.null(x)) y else x

# UI takes the value to show, so carried-forward state is explicit.
targetUI <- function(id, selected = "a") {
  ns <- NS(id)
  tagList(
    selectInput(ns("choice"), "Static choice", c("a", "b", "c"), selected = selected),
    verbatimTextOutput(ns("echo"))
  )
}

targetServer <- function(id, dataVersion) {
  moduleServer(id, function(input, output, session) {
    output$echo <- renderText({
      req(input$choice)   # normal "not yet bound" guard -- same as first load
      sprintf("run #%s: input$choice = %s", dataVersion, input$choice)
    })
    # No suspendWhenHidden hack: the re-rendered UI keeps the output element live.
  })
}

ui <- fluidPage(
  actionButton("rerun", "Re-run target module (simulates a param change)"),
  uiOutput("module_ui")
)

server <- function(input, output, session) {
  gen <- reactiveVal(0L)          # current generation
  carried <- reactiveVal("a")     # state I explicitly carry forward
  modId <- function(g) paste0("target_gen", g)

  # 1. UI re-renders every generation -> client rebinds -> inputs re-send.
  output$module_ui <- renderUI(targetUI(modId(gen()), selected = carried()))

  # 2. Server is (re)created every generation, in lock-step with the UI.
  observeEvent(gen(), targetServer(modId(gen()), dataVersion = gen()))

  observeEvent(input$rerun, {
    old <- gen()
    # 3a. Snapshot the state to keep BEFORE tearing down.
    carried(isolate(session$input[[paste0(modId(old), "-choice")]]) %||% carried())
    # 3b. Destroy the old scope as a whole; advancing the generation next also
    #     replaces its UI (a fresh namespace can't collide with stale state).
    session$destroy(modId(old))
    gen(old + 1L)
  })
}

shinyApp(ui, server)

Proposals (in priority order):

1. Couple UI to scope. Put the module UI under a uiOutput/renderUI that re-renders on the same trigger that re-runs the server. (Your DR.R already renders via renderUI, but the value is often identical() across runs, so reactiveVal skips invalidation and it never actually re-renders — that's the precise spot to change.)
2. Fresh "generation" namespace per run (target_gen0, target_gen1, …). A brand-new namespace can't collide with anything a module left behind — this removes your dependence on teardown being perfect and could retire observer_dedup entirely.
3. Carry preserved state forward explicitly — snapshot the old choice and pass it as the new widget's selected=. "The value survives" becomes an intentional, visible data flow instead of a reliance on a server cache, and it naturally does the right thing for dynamic inputs (you just don't carry forward ones whose widgets are gone).

For modules you control, the cleanest approach is to not destroy/recreate at all: instantiate the module once and feed new params/data in as reactive arguments so outputs recompute reactively. Destroy-and-recreate is really a workaround for modules that imperatively spawn observers on each run; since your tool evals arbitrary user module code it can't assume that discipline, which is why the generational pattern above is the pragmatic fit for the runner, while "create once, react to params" is what I'd suggest to your module authors.

Summary

• I'd rather not add preserveInputs to session$destroy() — it orphans dynamic input state and only masks an architectural mismatch.
• The mismatch is that your UI outlives the scope you're destroying. Re-render the UI as part of the destroy/re-run cycle and behavior becomes consistent with a normal module load, no shiny change required.
• The generational-namespace pattern should let you drop the observer_dedup internals.

Happy to look at a stripped-down version of one of your modules if the pattern doesn't map cleanly onto your setup!

[ml-ebs-ext]

Thanks for your quick and detailed reply! Here's are my thoughts:

I understand that session$destroy(preserveInputs=TRUE) preserves all inputs. That's why I named the parameter preserveInputs and not preserveStaticInputs. Dangling server-side inputs are only of aesthetic concern. No application that does an insertUI/removeUI on elements that contain selectors has or will misbehave. The server-side logic will remain dormant and the extra unreclaimed memory is a rounding error on any app.

Thanks for the proposals. I tried strategies approaching those before settling on observer_dedup. The thing about that snippet is that it composes nicely in many situations, as I documented in the "Examples of use" section of this blogpost. I requires almost no changes to solve three distinct issues and it remains self-contained, as it leaves the original code and reactive logic untouched. That's why I thought having something functionally equivalent in vanilla Shiny would be a welcome feature.

Thanks again for your time!