Migrating from native Shiny controls

The trap: empty does not mean the same thing

Native Shiny and glasstabs disagree about the starting state:

A migration that copies selected = NULL across changes the app’s initial filter from “nothing” to “everything.” Decide which behavior the app had, and write it explicitly — do not let the default decide for you. The behavior-preserving migration below uses selected = character(0) to keep the native empty start.

Before and after: a multi-select filter

Before, with native Shiny:

library(shiny)

regions <- c(North = "north", South = "south", East = "east")
data <- data.frame(
  region = c("north", "south", "east", "north"),
  cases = c(12, 8, 5, 3)
)

ui <- fluidPage(
  selectInput(
    "region",
    "Region",
    choices = regions,
    multiple = TRUE,
    selected = NULL
  ),
  tableOutput("rows")
)

server <- function(input, output, session) {
  output$rows <- renderTable({
    data[data$region %in% input$region, , drop = FALSE]
  })
}

shinyApp(ui, server)

After, with glasstabs. The downstream filter is untouched:

library(shiny)
library(glasstabs)

regions <- c(North = "north", South = "south", East = "east")
data <- data.frame(
  region = c("north", "south", "east", "north"),
  cases = c(12, 8, 5, 3)
)

ui <- fluidPage(
  useGlassTabs(),
  glassMultiSelect(
    "region",
    choices = regions,
    label = "Region",
    selected = character(0),
    theme = "auto"
  ),
  tableOutput("rows")
)

server <- function(input, output, session) {
  output$rows <- renderTable({
    data[data$region %in% input$region, , drop = FALSE]
  })
}

shinyApp(ui, server)

The example above is complete: it defines its dataset, both app halves, and the app object, so it runs end to end.

Two changes beyond the widget swap: useGlassTabs() once at the UI root (the one rule), and selected = character(0) preserving the native empty start. If the app actually wants the glasstabs default (all enabled selected), drop the selected argument and keep the filter — but then say so in the filter’s comments, because the next reader will otherwise assume the native default.

For a single-select the swap is selectInput() (without multiple = TRUE) to glassSelect(), with the same useGlassTabs() addition. The cleared state of a single-select returns NULL in both worlds, so no default trap applies there.

Update function mapping

The update semantics that have no native counterpart are the transaction options: preserve_selection, drop_invalid, and notify on the multi-select updater (see the linked-filters article). A migration that passes only choices and selected behaves like the native updater; the extra options are opt-in.

What native selectize can do that glasstabs cannot

Be candid about the gaps before migrating a selectize-heavy app:

• User-created choices (options = list(create = TRUE)): no equivalent. glasstabs choices come from the app, not the user.
• Selectize plugins (options = list(plugins = ...)): no equivalent — no drag-and-drop sorting, no remove-button plugin (tag pills have their own remove affordance, but it is not the plugin).
• Server-side selectize as a drop-in: the mechanism differs. Native selectize queries the server per keystroke through its own protocol; glasstabs server mode uses server = TRUE plus a *Server() helper with bounded results. The user-visible behavior is close, but the code is not interchangeable.

When a native control is still the better choice

• The app needs user-created choices or a selectize plugin above.
• The app must render a plain <select> with no JavaScript enhancement (for example, a no-JS fallback page).
• The list is tiny, static, and already working: a migration buys styling and consistency, not behavior, and that trade is not always worth the review.

For everything else — searchable dropdowns, multi-select filters, themed dashboards, server-backed large lists — the migration above is the whole job: swap the constructor, add useGlassTabs(), pin the initial selection explicitly, and remap the update calls.