-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate freeze/thaw behavior inconsistencies #1791
Comments
Here's an example of library(shiny)
ui <- fluidPage(
uiOutput("ui"),
actionButton("redraw", "Redraw"),
p("Status:", textOutput("status", inline = TRUE))
)
server <- function(input, output, session) {
output$ui <- renderUI({
input$redraw
freezeReactiveValue(input, "outval")
textInput("outval", "Dynamic input", value = "hello")
})
output$status <- renderText({
input$redraw
tryCatch({
input$outval
"Thawed"
}, error = function(err) {
"Frozen"
})
})
}
shinyApp(ui, server) If you click "Redraw" without changing the value from "hello", then the output only sees the input as frozen. The correct behavior would be for the input to only be frozen for a brief moment (the time between One solution for this would be for every |
Similar problem as my previous comment, but this time with library(shiny)
ui <- fluidPage(
textInput("outval", "Dynamic input", value = "hello"),
actionButton("update", "Update"),
p("Status:", textOutput("status", inline = TRUE))
)
server <- function(input, output, session) {
observeEvent(input$update, {
freezeReactiveValue(input, "outval")
updateTextInput(session, "outval", value = "hello")
})
output$status <- renderText({
input$update
tryCatch({
input$outval
"Thawed"
}, error = function(err) {
"Frozen"
})
})
}
shinyApp(ui, server) The previous solution I proposed would not help for this case. |
1. freezeReactiveValue(input, "x") is called, inside a renderUI or in an observer that then calls updateXXXInput 2. Some reactive output tries to access input$x, this takes a reactive dependency but throws a (silent) error 3. When the flush cycle ends, it automatically thaws What's *supposed* to happen next is the client receives the new UI or updateXXXInput message, which causes input$x to change, which causes the reactive output to invalidate and re-run, this time without input$x being frozen. This works, except when the renderUI or updateXXXInput just so happens to set input$x to the same value it already is. In this case, the client would detect the duplicate value and not send it to the server. Therefore, the reactive output would not be invalidated, and effectively be "stalled" until the next time it is invalidated for some other reason. With this change, freezeReactiveValue(input, "x") has a new side effect, which is telling the client that the very next update to input$x should not undergo duplicate checking.
1. freezeReactiveValue(input, "x") is called, inside a renderUI or in an observer that then calls updateXXXInput 2. Some reactive output tries to access input$x, this takes a reactive dependency but throws a (silent) error 3. When the flush cycle ends, it automatically thaws What's *supposed* to happen next is the client receives the new UI or updateXXXInput message, which causes input$x to change, which causes the reactive output to invalidate and re-run, this time without input$x being frozen. This works, except when the renderUI or updateXXXInput just so happens to set input$x to the same value it already is. In this case, the client would detect the duplicate value and not send it to the server. Therefore, the reactive output would not be invalidated, and effectively be "stalled" until the next time it is invalidated for some other reason. With this change, freezeReactiveValue(input, "x") has a new side effect, which is telling the client that the very next update to input$x should not undergo duplicate checking.
1. freezeReactiveValue(input, "x") is called, inside a renderUI or in an observer that then calls updateXXXInput 2. Some reactive output tries to access input$x, this takes a reactive dependency but throws a (silent) error 3. When the flush cycle ends, it automatically thaws What's *supposed* to happen next is the client receives the new UI or updateXXXInput message, which causes input$x to change, which causes the reactive output to invalidate and re-run, this time without input$x being frozen. This works, except when the renderUI or updateXXXInput just so happens to set input$x to the same value it already is. In this case, the client would detect the duplicate value and not send it to the server. Therefore, the reactive output would not be invalidated, and effectively be "stalled" until the next time it is invalidated for some other reason. With this change, freezeReactiveValue(input, "x") has a new side effect, which is telling the client that the very next update to input$x should not undergo duplicate checking.
Isn't this fixed and could be closed? |
The text was updated successfully, but these errors were encountered: