shiny icon indicating copy to clipboard operation
shiny copied to clipboard

Request: allow deleting an input that was removed using `removeUI()`

Open daattali opened this issue 6 years ago • 13 comments

Currently, when an input is removed using removeUI(), its UI is deleted from the DOM but the input still lives from the server's perspective. It would be great if it was possible to clear that input completely.

Personal opinion: I would want this to be the default behaviour, because an input that does not exist on the page should not exist in the server - it's a bit of a logical discrepancy - but that breaking change might cause a lot of trouble so perhaps adding a parameter to removeUI() to do this would be helpful.

daattali avatar Apr 09 '19 14:04 daattali

For anyone looking for a workaround until this gets implemented, my solution meanwhile it to set the value of any removed inputs to NULL using javascript, with Shiny.onInputChange("input", 'null')

daattali avatar Apr 22 '19 07:04 daattali

Here's a reprex of this issue:

library(shiny)
ui <- fluidPage(
  actionButton("rmv", "Remove UI"),
  textInput("txt", "This is no longer useful", "plop")
)

# Server logic
server <- function(input, output, session) {
  observeEvent(input$rmv, {
    removeUI(
      selector = "#txt"
    )
  })
  observe({
    invalidateLater(1000)
    print(input$txt)
  })
}

shinyApp(ui, server)

I definitely second the idea of removing the value from the input list if the input is not there anymore.

The removeUI() function which can remove any part of the UI has to be kept, but there could be a removeInput() function, to be more specific to target the inputs.

ColinFay avatar Aug 29 '19 10:08 ColinFay

Just dropping a thought here. If you're managing the lifecycle of modules using objects from a bespoke class system, for example, R6, you can register your takedown code as the finalizer function of the module object. The finalizer function will run as the object is garbage collected.

iqis avatar Jul 21 '20 02:07 iqis

For anyone looking for a workaround until this gets implemented, my solution meanwhile it to set the value of any removed inputs to NULL using javascript, with Shiny.onInputChange("input", 'null')

Thank you so much for solution. Is this way to update all variable in 'input' as null ? Could I just update one variable as null? Thanks in advance.

changwn avatar Aug 11 '21 18:08 changwn

@ColinFay thank you for the clear example. I'm surprised at how few examples I can find of removing the input / server data along with the UI.

I've taken the example above and built out a working example that shows a method of removing both the UI and the server elements. My approach wraps the textInput into a module as this is typically the scenario I am in when I use removeUI - I want to remove all the UI elements for a module and its data from wherever I am storing the data.

In the below module_values <- reactiveVal(list()) holds the data for each module, I can't use a reactiveValues() as elements can't be removed from such a 'list'. The work is all done by the add_module function which adds the module's data into module_values and (if required) sets up an observeEvent which will tear down the UI for the module and remove its entry from module_values.

Very happy to take advice on the approach. Hopefully this helps others in the future!

library(shiny)
library(purrr)

## Text Module ----

textUI <- function(id) {
  div(
    id = NS(id, "ui"),
    actionButton(NS(id, "remove"), "Remove UI"),
    textInput(NS(id, "text"), "This is no longer useful", "plop")
  )
}

textServer <- function(id) {
  moduleServer(id, function(input, output, session) {
    list(
      text = reactive(input$text),
      delete = reactive(input$remove)
    )
  })
}


## Main App ----

# utility to hide away the mess of updating the reactiveVal(list())
update_values <- function(values, name, value) {
  vals <- values()
  vals[[name]] <- value
  values(vals)
}

add_module <- function(values, name, server, delete_hook = NULL, remove_selector = NULL) {
  # add module server's return to values list
  update_values(values, name, server)
  
  # if module has a reactive we should monitor for deleting, do so
  if (!is.null(delete_hook)) {
    observeEvent(
      server[[delete_hook]](), {
        removeUI(selector = remove_selector)  # remove the ui
        update_values(values, name, NULL)  # remove the server from our values list
      },
      once = TRUE
    )
  }
}

ui <- fluidPage(
  actionButton("addModule", "Add Module"),
  verbatimTextOutput("wordsOutput")
)

server <- function(input, output, session){
  # can't use reactiveValues as can't remove items from them
  module_values <- reactiveVal(list())
  
  observeEvent(input$addModule, {
    id <- paste("module", input$addModule, sep = "-")
    insertUI(selector = "#addModule", where = "afterEnd", ui = textUI(id))
    add_module(
      module_values,
      name = id,
      server = textServer(id),
      delete_hook = "delete",
      remove_selector = paste0("#", NS(id, "ui"))
    )
  })
  
  words <- reactive({ 
    map(module_values(), ~.x$text())
  })
  
  output$wordsOutput <- renderPrint(words())
}

shinyApp(ui, server)

Azureuse avatar May 03 '22 17:05 Azureuse

@ColinFay thank you for the clear example. I'm surprised at how few examples I can find of removing the input / server data along with the UI.

I've taken the example above and built out a working example that shows a method of removing both the UI and the server elements. My approach wraps the textInput into a module as this is typically the scenario I am in when I use removeUI - I want to remove all the UI elements for a module and its data from wherever I am storing the data.

In the below module_values <- reactiveVal(list()) holds the data for each module, I can't use a reactiveValues() as elements can't be removed from such a 'list'. The work is all done by the add_module function which adds the module's data into module_values and (if required) sets up an observeEvent which will tear down the UI for the module and remove its entry from module_values.

Very happy to take advice on the approach. Hopefully this helps others in the future!

library(shiny)
library(purrr)

## Text Module ----

textUI <- function(id) {
  div(
    id = NS(id, "ui"),
    actionButton(NS(id, "remove"), "Remove UI"),
    textInput(NS(id, "text"), "This is no longer useful", "plop")
  )
}

textServer <- function(id) {
  moduleServer(id, function(input, output, session) {
    list(
      text = reactive(input$text),
      delete = reactive(input$remove)
    )
  })
}


## Main App ----

# utility to hide away the mess of updating the reactiveVal(list())
update_values <- function(values, name, value) {
  vals <- values()
  vals[[name]] <- value
  values(vals)
}

add_module <- function(values, name, server, delete_hook = NULL, remove_selector = NULL) {
  # add module server's return to values list
  update_values(values, name, server)
  
  # if module has a reactive we should monitor for deleting, do so
  if (!is.null(delete_hook)) {
    observeEvent(
      server[[delete_hook]](), {
        removeUI(selector = remove_selector)  # remove the ui
        update_values(values, name, NULL)  # remove the server from our values list
      },
      once = TRUE
    )
  }
}

ui <- fluidPage(
  actionButton("addModule", "Add Module"),
  verbatimTextOutput("wordsOutput")
)

server <- function(input, output, session){
  # can't use reactiveValues as can't remove items from them
  module_values <- reactiveVal(list())
  
  observeEvent(input$addModule, {
    id <- paste("module", input$addModule, sep = "-")
    insertUI(selector = "#addModule", where = "afterEnd", ui = textUI(id))
    add_module(
      module_values,
      name = id,
      server = textServer(id),
      delete_hook = "delete",
      remove_selector = paste0("#", NS(id, "ui"))
    )
  })
  
  words <- reactive({ 
    map(module_values(), ~.x$text())
  })
  
  output$wordsOutput <- renderPrint(words())
}

shinyApp(ui, server)

I guess this only works with reactive value as a middle layer whilst the input is still there?

iqis avatar May 10 '22 18:05 iqis

Have we got any updates regarding this issue? It would be indeed quite useful to have a removeInput() function, instead of having to find some clunky workaround.

aeynaud avatar Jun 23 '22 05:06 aeynaud

Hi everyone, I have been struggling for a few days now regarding this issue.

A user can create a cage (for storing animals) in my app. The cage has an ID given by the user, say - 22818. This ID will be used to generate all following dependencies dynamically (buttons to open cage, modify, add animals etc..) each of the inputs created will contain "22818" (modify22818, addAnimal22818 etc..). Where this becomes an issue is when the user deletes cage 22818 and re-creates the same cage in the same session. All dependencies are re-created with the same id and this causes problems and crashes the app. I could potentially make it so that every input is truly unique, but I am not sure how to keep track of them and make sure they interact with the proper cage.

When deleting that cage, destroying all inputs that come up from a grep of pattern "22818" would solve the issue, but I am aware that there could be better options.

I am open to any suggestions/workaround, thank you very much in advance.

aeynaud avatar Jun 23 '22 14:06 aeynaud

I wouldn’t use the real ID to make those input IDs unique, I’d make them unique using a random value that has no relation to anything.

Back to the larger issue in the thread, it seems like there are related features of 1) removal of input values from the input object (by client, by server, or both); 2) destruction of a group of observers/outputs all at once.

jcheng5 avatar Jun 23 '22 21:06 jcheng5

Just assign the moduleServer call to a variable:

all_reactive_values[[ns("my_module-server")]] <-
    moduleServer(id, function(input, output, session) {

Then remove server with all_reactive_values[[ns("my_module-server")]]$destroy()

Along with the removeUI functions and remove_inputs shown above, this should remove the module completely, right ?

Context: I am creating dynamic modules and updating modules by calling the moduleServer function repeatedly. So each observeEvent were triggered n number of times the moduleServer was called. It was imperative to clear out the existing old moduleServers and inputs before calling the moduleServer again. I only update the moduleServer, not the moduleUI. The UI remains same and not removed or updated.

anirbanshaw24 avatar Nov 16 '22 09:11 anirbanshaw24

I wouldn’t use the real ID to make those input IDs unique, I’d make them unique using a random value that has no relation to anything.

Back to the larger issue in the thread, it seems like there are related features of 1) removal of input values from the input object (by client, by server, or both); 2) destruction of a group of observers/outputs all at once.

I think item 2 is needed as well. It would be very helpful to have a removeUI analog removeServer that would destroy any inputs, observers, and outputs. That way when a module is removed the server elements can be removed in addition to client elements.

For modules that are inserted and removed based on user input, developers could follow a pattern like

# when module is added
insertUI(my_module_ui('id'))
my_module_server('id')

# when removed
removeUI('id')
removeServer('id')

asbates avatar Jun 02 '23 01:06 asbates