Can't trigger a second shinyalert based on result of first shinyalert

[aruu]

In a case where I want to show a Confirm modal depending on what a user does in the first modal, the second modal never appears (or appears sporadically).

Code is below, the issue persists even when using callbackR or saving the result in a separate reactiveValue first. The code does run because the print statement shows up but in my main larger app, the modal appears only in the RStudio viewer, and it managed to appear ONCE in-browser.

library(shiny)
library(shinyalert)

ui <- fluidPage(
  useShinyalert(),
  h1("Nothing to see here"),
  actionButton("action", "Click here!")
)

server <- function(input, output, session) {
  
  observeEvent(input$action, {
    shinyalert(
      "Welcome!",
      "What is your name?",
      type = "input",
      showCancelButton = TRUE
    )
  })
  
  observeEvent(input$shinyalert, {
    print(input$shinyalert)
    shinyalert(
      "Thank you for confirming your name",
      input$shinyalert,
      type = "success"
    )
  })
  
}

shinyApp(ui, server)

[daattali]

Thanks for the report and code!

You're right, I do notice that the second modal does show up very briefly and disappears. It's as if the sweetalert library calls an exit method to close all open modals but it does it too late, after the second one has been opened. I'll have to look into this, or accept any help from others!

More minimal example for testing:

library(shiny)
library(shinyalert)

ui <- fluidPage(
  useShinyalert(),
  actionButton("go", "go")
)

server <- function(input, output, session) {
  observeEvent(input$go, {
    shinyalert("box1", type = "input", inputId = "foo")
  })
  
  observeEvent(input$foo, {
    print("here")
    shinyalert("box2")
  })
}

shinyApp(ui, server)

[daattali]

It looks like this is actually a bug with sweetalert itself: t4t5/sweetalert#472 t4t5/sweetalert#253

Unfortunately it looks like it was never fixed (and never will be) in the version that I'm using for this package. It is fixed in the rewrite of sweetalert, but I explicitly chose to stick with the original sweetalert because it includes more features and is much simpler to use and I found it "snappier". This is an unfortunate bug, if there are many reasons to upgrade to the new sweetalert I will look into it, but if this is the only issue with the old one, then switching is not worth it.

As a hacky workaround, you can solve this by adding a delay before showing the second modal. That's what everybody suggested

[aruu]

Thanks for the informative and helpful responses! Sounds like what I was expecting, the workaround isn't that bad.

For completeness, here is the solution using a delay in R (so we don't need to go to the Javascript level)

library(shiny)
library(shinyalert)

ui <- fluidPage(
  useShinyalert(),
  actionButton("go", "go")
)

server <- function(input, output, session) {
  observeEvent(input$go, {
    shinyalert("box1", type = "input", inputId = "foo")
  })
  
  observeEvent(input$foo, {
    Sys.sleep(0.5)
    print("here")
    shinyalert("box2")
  })
}

shinyApp(ui, server)

[daattali]

@aruu I think I was able to fix this. Please try it and let me know if it works well. Note that your original example won't work properly because input$shinyalert will return the name for the first modal, and it'll return TRUE for the second modal

[aruu]

Looks great! Being able to use different IDs with these alerts helps make this nicer too :)

Yup I'm aware of that but just needed a quick and dirty example, but thanks for the notice.

[sanjmeh]

There is a strange problem that outweighs the current problem.
The input$shinyalert reactive does not trigger an event unless its value changes from TRUE to FALSE or vice versa and so the code inside the code block,

observeEvent(input$shinyalert,{

<..code to be executed..>

}

remains unexecuted if the value changes from TRUE to TRUE. How will we trigger the code if two times consecutively the CONFIRM button was pressed.

[daattali]

@sanjmeh Please post a minimal reproducible example if you think there's a bug.