updateSelectizeInput can't handle `NA` when using `server = TRUE`

[ismirsehregal]

I'm wondering why updateSelectizeInput can't handle NA as a choice when using server = TRUE.

Is this a bug or expected behaviour?

library(shiny)

ui <- fluidPage(
  selectizeInput("variable1", "Variable:", c("a", "b")),
  selectizeInput("variable2", "Variable:", c("a", "b"))
)

server <- function(input, output, session) {
  updateSelectizeInput(inputId = "variable1", choices = NA, server = TRUE)
  updateSelectizeInput(inputId = "variable2", choices = NA, server = FALSE)
}

shinyApp(ui, server)

[nirgrahamuk]

its implied by how you phrase your question that you would wish the server=TRUE version would give a result equivalent to what you have shown would happen for server=FALSE.
The same effect could be acheived with

  updateSelectizeInput(inputId = "variable1", choices = "NA", server = TRUE)

[ismirsehregal]

Thanks for your reply!

Of course we can workaround this behaviour by mapping NA to some string before passing it to the choices.

However, I'm interested why there is an unequal result for an argument which (from my point of view) shouldn't affect the choices.

[nirgrahamuk]

I think that the server = FALSE version, is the one that breaks expectations, I wouldnt assume that NA (representing an absence of a value) would necessarily be interpreted as a literal string.
Looking at the implementation code, you can see that server TRUE / FALSE has a different approach to constructing the update. server = FALSE is using as.character to interpret the choices, whereas server = TRUE constructs a data.frame of choice/value label correspondences and so seems to preserve NA (as missing) in a way that casting NA to a character does not.

[ismirsehregal]

Thanks for investigating!

With my question I didn't want to say I prefer this behaviour over the other, I just wanted to point out that it's confusing that both approaches aren't aligned.

Same input - same output.

Accordingly I'm wondering if this was done intentionally.

[nirgrahamuk]

I can agree with you that the better alignment the better the software tooling would be from a users persepective.

I think any explanation must be rooted in the differences of implementation.

Shiny - Using selectize input (rstudio.com)

The client-side selectize input relies solely on JavaScript to process searching on typing. The server-side selectize input uses R to process searching, and R will return the filtered data to selectize. To use the server version, you need to create a selectize instance in the UI, and update it to the server version:

Perhaps an issue could be raised on the shiny github requesting better alignment, if the developers picked this up I would expect they would either, put additional effort into aligning it, or perhaps explain that the effort would be in some way impractical or low priority, though these things are hard to predict.

[ismirsehregal]

Thanks again for your feedback (and sorry for the misleading introduction).

I filed an issue here.