Migrating from native Shiny controls

This guide converts an existing app without changing its downstream code. The filter logic stays identical; only the input construction and the update calls change. The one trap that breaks migrations is the empty-selection default — it is covered first, because it decides the rest.

The trap: empty does not mean the same thing

Native Shiny and glasstabs disagree about the starting state:

Control	selected = NULL means
selectInput(multiple = TRUE)	Nothing selected
glassMultiSelect()	Every enabled choice selected

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

Native	glasstabs	Notes
updateSelectInput(session, id, choices, selected)	updateGlassMultiSelect(session, id, choices, selected, ...) or updateGlassSelect(session, id, choices, selected, ...)	Choose by widget, not by the old call
updateSelectizeInput(session, id, choices, selected)	Same as above	Server-side selectize becomes server = TRUE + the *Server() helper, not an update call
label argument on the native updaters	No equivalent	The glasstabs updaters take no label; a label change means recreating the widget with renderUI()
selected = NULL (keep)	selected = NULL (keep)	Same meaning on both sides for updates
selected = character(0) (clear)	selected = character(0) (clear)	Same meaning on both sides for updates

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.