Added dismissalert to remove arbitrary number of messages

[dipterix]

This PR is related to issue #29

A simple demo showing how it works:

library(shiny)

ui <- fluidPage(
  shinyalert::useShinyalert(),
  actionButton('a','Ok')
)

server <- function(input, output, session) {
  observeEvent(input$a, {
    shinyalert::shinyalert(
      'Warning',
      'Click OK to run code',
      callbackR = function(...){
        # procedure 1 runs for 3~4 seconds
        Sys.sleep(3 + runif(1))
        # Now dismiss modal
        shinyalert::dismissalert()
      }
    )
    shinyalert::shinyalert(
      'Scheduled!',
      'R is running, please wait for the result...', 
      showConfirmButton = FALSE
    )
  })
}

shinyApp(ui, server)

[dipterix]

Changes:

1. Renamed dismissalert to closeAlert
2. Added immediate option to shinyalert
3. closeAlert can choose number of alerts to be closed, or a specific alert with cbid given
4. Fixed some pre-existing doc issues.

I added myself to DESCRIPTION as ctb (contributor, providing piece of code) as convention, you can remove it if it causes some legal issues.

[daattali]

In the if statement I added a comment that the serialization isn't happening to prevent a performance issue #19

Did you notice that and test if this change is going to re-introduce that issue?

[dipterix]

I don't recommend params <- as.list(environment()) at the very beginning. Chances are too small for two alerts sharing the same cbid with runif postfix. If you get rid of the enclosing environment, digest::digest will be quite fast as everything else should be basic types and contain no environment. Alternatively you could use utils::capture.output({print(environment())}) to distinguish environments because the runtime environment of R functions will unlikely to be named, meaning its memory address will be printed, resulting in something like "<environment: 0x7f802d60a1b0>". Serializing string is much faster than serializing an environment.

[dipterix]

Or, if you do want to keep params <- as.list(environment()), you can create random cbid with no digests for alerts without callbacks. The returned cbid can be used to close that specific alert or writers can use that cbid to generate their own callbacks outside of shinyalert.

[daattali]

The line params <- as.list(environment()) is not for serialization or creating a unique ID, it was simply a way to get a list of all the function arguments values - default values for arguments that weren't provided and the user-supplied values for the arguments that were provided. Do you know of an alternative way to get all the arguments of the current function as a list?

But anyway, you're right that the digest isn't actually required , it was only to add some randomness. Instead of using the params hash plus a random integer, it might be better to just use the uuid package

[dipterix]

In that way you are right, but your function arguments contains no function except callbackR, which will be removed before serialization. Therefore serialization should be fast. Also personally I think using runif is good enough to create unique IDs unless people set seed before calling the function. In that case, you might want to consider utils::capture.output({print(environment())}) I proposed to ensure different IDs created.

[daattali]

Thanks for the great PR!

I apologize for being so picky but I do have a few things I would ask of you before merging:

• Remove all changes that are not directly related to closeAlert
• Files should end with a newline
• The immediate parameter is related but not should not go in the same PR as closeAlert
• It looks like some of the code (to create the callback id) can be reused instead of being used twice identically
• I don't see the use for the n argument in closeAlert. It seems very esoteric - what's the use case for that? I would prefer to just have cbid argument and if none is provided then you close everything

[daattali]

Is cbid not alwasy going to be a string?

[dipterix]

We can remove the if statement if you always include cbid in R code.

[daattali]

It wasn't before, but my understanding is that your PR ensures that cbid is ALWAYS going to be in the javascript parameters, in which case this check is redundant. Is that right?

[daattali]

Please use a better variable name

[daattali]

I made a commit that uses uuid instead of hashing the params, so that's not an issue anymore. Thanks for bringing this to my attention

[daattali]

@dipterix let me know if you plan on continuing this or if I should take over!

[dipterix]

I got fever. Please go ahead make changes if you feel necessary.

[daattali]

I'm working on some other packages this week, if you don't finish the PR by the end of the month I'll try to finish it :)

[daattali]

@dipterix Are you able to finish this PR?

[daattali]

I actually went through all your code and I'm mostly done integrating it. I might ask you for a PR soon :)

[dipterix]

Hi @daattali , sorry for the late reply. The conflicts have been resolved.

[daattali]

Merged in #37