Repository navigation
Changes to reactive values not displaying accurately #36
Description
Activity
- added a commit that references this issue
on May 8, 2019 Has this issue really been fixed? I added a
numericInputin theuifunction to @jcheng5's app to compare the behavior with thenumericInputcreated via renderUI in theserverfunction. What I observe is that without having touched any inputs the reactlog looks fine.input$xis initialized withNULLbut then picks up the value of 5.
However, when I DO touch the x input and step it to up to 6, and then launch reactlog again, the info displayed in the dependency graph and the info in the status bar do not match at step 13. The status bar says "Step: 13 input$x has a new value: int 6" while the graph says "input$x - 'int 5'". The graph info is the correct one.
That discrepancy does not occur withinput$y.library(shiny) library(reactlog) options(shiny.reactlog = TRUE) ui <- fluidPage( uiOutput("ui"), numericInput("y", "y", 10) ) server <- function(input, output, session) { output$ui <- renderUI({ numericInput("x", "x", 5) }) observe(label = "observe x", { print(paste("x:", input$x)) }) observe(label = "observe y", { print(paste("y:", input$y)) }) } shinyApp(ui, server)Reacted by Barret SchloerkeI believe this is a bug with the status bar within reactlog.
Thank you for the reproducible steps! If you hit the
lkey while the reactlog is open, it'll display the raw log value. The raw log value states the value to beint 5, while the status bar states it to beint 6.
The value
int 6should not appear until after the second idle stage ~ Step 20.
- added a commit that references this issue
on Jun 5, 2021 - added a commit that references this issue
on May 11, 2026 - added a commit that references this issue
on May 14, 2026
Set
options(shiny.reactlog=TRUE), then run this app:If you don't touch any inputs, you'll see that the
input$xvalue is 5. Now launch the reactlog. It'll say thatinput$xisNULL.I don't repro this problem without using the
renderUI; it's almost like the initial value beingNULLcauses the next value to be lost.For what it's worth, the 063-superzip example app is where I saw this first;
input$map_boundsstaysNULLlonger than it should.