Run the small set of R codes locally (Machine) post deploying to R studio connect server

shiny
, , ,
#1

Hi all,

I have a R shiny application. However there is small set of codes in server.R file that runs only in local machine and does not run when I deploy in Rstudio connect server. So wanted to check if I can run these only locally post deploying to R studio connect server. please let me know If I have to produce reprex here :slight_smile:

#2

You can run locally anything you want but it is not going to be available for the app on the server. Can you please elaborate on your question? Vague questions get vague answers.

#3

Hi Vinay,
I think I understand you.
Please consider this demo that you can run locally and see one effect, and publish to shinyapps.io and see a different effect. Achieved by use of the interactive() function


library(shiny)

# Define UI for application that draws a histogram
ui <- fluidPage(
textOutput("outext")
)

# Define server logic required to draw a histogram
server <- function(input, output) {

    output$outext <- renderText({
       response <- ifelse(interactive(),"", "NOT ")
        paste0("I am ",response,"interactive")
    })
}

# Run the application 
shinyApp(ui = ui, server = server)
#4

Thanks.

Below is my reprex. The 2 lines of code in the server.R file can be run in local machine but not in Rstudio connect server. I mean the application will crash. Not sure

ui.R

library(shiny)
source("add.R")


# Define UI for application that draws a histogram
shinyUI(fluidPage(
  
  textOutput("greeting"),
  actionButton("show", "Show"),
  actionButton("checkme","checkme"),
  selectInput("Slider","Slider",choices = unique(iris$Species))
  )
  )

server.R

library(shinytest)
library(testthat)

shinyServer(function(input, output) {
  
  output$greeting <- renderText({
    paste0("Hello, ", input$name, "!")
  })
  app <- ShinyDriver$new(getwd())  ## cannot run this Rstudio connect server
  Checking_click_button <- app$setInputs(checkme = "click")  ## cannot run this Rstudio connect server
  
})
#5

I misunderstood, I assumed you were asking how to disable/avoid running some code once you publish. shinydriver test code would be an example of code that should not be run in this way, so my solution of testing if interactive vs deployed would have helped you keep the test code in the file (not sure why its a good idea? ) but avoid raising errors in the deployment.

It's my understanding that you can't / shouldnt run this code as part of an app deployment, because that would cause an app to run an app, and if the app is going to run a version of itself, you will have infinite recursive apps... maybe ?
As far as I know its simply not allowed.
Typically shinydriver would be used for testing, and wouldnt be part of a deployment ... perhaps there is some confusion on this point ?

#6

Cool. Let me explain the reason behind this. Basically I have written a code/function where in it checks if all the buttons, filtering, table output is getting updated or not (Basically a test case).

The test cases all starts with app <- shinyDriver$new(getwd()) and proceeds further. Yeah as you said, I can run this code and test the case in my local machine. But once I deploy to server, the application.

In case if it works in Server, what happens is, I will write another set of code so that it checks all input parameters are working or not. In case it is working , a pop up message telling, "Test cases are passed", If not, then "Test cases are not passed".

By doing this, a developer or a user will get to know that there is some issue with the application.

Makes sense ?: )

#7

Not really ...
what does it mean for an input parameter to work ?
are you testing your own calculations? or putting the code of the shiny framework to test ?
The latter is simply not worth doing. Any more than it would be worth your while to write tests of the shinydriver program which you run everytime before you run shinydriver, or tests for the tests of your tests.

I will make the statement that testing code, is about testing the design, so that you can expect once your code is deployed, it would have known behaviour, because you have tested for that in offline tests.

any live, or runtime issues should be handled in a completely different ways which are

  1. limiting the user to not pass breaking inputs
    things like using validate(need())... to give messages to the user when they try to do things you know they might try that you know wont work
  2. wrapping functions that might error in tryCatch({}) and providing handlers for warnings/errors, that keep the program in a functioning state (best if possible) or at least provide useful feedback for debugging and informing the user before the program dies.
#8

Hi , The below code if you run locally, you get Checking_click_button as 0 meaning that click button is working. This is a sample. In an application we find lots of input parameters. Makes sense ?:slight_smile:

 app <- ShinyDriver$new(getwd())  
 Checking_click_button <- app$setInputs(checkme = "click")
#9

you don't have to check that shiny actionbuttons are clickable... especially not everytime you launch the app for a user.
you need to assume that the button will respond as a button. Do you have a reason to doubt that the button is not a button ?

#10

Good point. There is a reason actually. That was a example I gave. Let me explain in detail again :slight_smile:

My intention is automate all possible scenarios (in future)

Scenario 1 : Say we have 3 inputs (the user needs to select 1st filter, 2nd Filter and click on Submit button so that table gets displayed. For this to happen, I can write below

# Filter1, Filter2 and Submit are inputs ID's declared in ui.R
Submit_table <- app$setInputs(Filter1 = "AAAA", Filter2 = "BBBB", Submit = "click")

Above code checks if filter1 is "AAAA" and filter2 is "BBBB" and submit is pressed, the table is displayed.

IF the table is really displayed, there will be no error. Or else there will be an error. Also we can check if the application crashes or not.

So like above there are lots of user defined features. So once we set the test cases and make sure all are run, we can be satisfied that application is not crashing, all inputs are working and so on.

Now makes sense ?:slight_smile:

#11

I'm afraid not Vinay, I want to help you not to waste your time....

The only purpose of code like :
Submit_table <- app$setInputs(Filter1 = "AAAA", Filter2 = "BBBB", Submit = "click")
is to test your application offline, that given particular inputs particular outputs will be set, and this can be a great way to quicky test an app being redeveloped for regression testing, that code changes being made, dont lead to a broken design.
This code is not suitable for any sort of realtime protection of the user experience, handling failure or reporting info to the developer in a live app. If you try to use it for incorrect purpose you will be frustrated, and you will have missed the 'correct' way to do these other kinds of tests and things that you need.

but lets ask the forum, they can teach me also if I have wrong ideas about this.

Did you understand at least that there are other things you should think about for your app. the validate(need()) stuff? and the tryCatch stuff ?

#12

Really thanks for the concern. But again I cannot ignore your points as well. All are worth. But yeah happy if others put there thoughts. This is something I am trying since a week. I really enjoyed doing this. But really thankful if I other put there thoughts.

#13

This topic was automatically closed 54 days after the last reply. New replies are no longer allowed.