jcheng5

#initialize
library(datasets)
library(ggplot2) 

#helper function (convert vector to named list)
namel<-function (vec){
		tmp<-as.list(vec)
		names(tmp)<-as.character(unlist(vec))
		tmp
	}

jcheng5

library(shiny)

columnFilterUI <- function(id) {
  ns <- NS(id)
  uiOutput(ns("filter_container"))
}

columnFilter <- function(input, output, session, df, col_num, choice_filter) {
  # This renders a selectInput and only re-renders when the selected data
  # frame changes. (i.e. it doesn't re-render when filters change state.)

jcheng5

library(shiny)
# Also uses parallel, shinyjs, tools

# Create a long-running task, executed in a forked process. (Doesn't work on Windows)
# 
# The return value is a promise-like object with three
# methods:
# - completed(): FALSE initially, then TRUE if the task succeeds,
#   fails, or is cancelled. Reactive, so when the state changes
#   any reactive readers will invalidate.

jcheng5

shinyServer(function(input, output) {
  output$filetable <- reactiveTable(function() {
    if (is.null(input$files)) {
      # User has not uploaded a file yet
      return(NULL)
    }
    
    input$files
  })
})

jcheng5

# Nothing to see here
shinyServer(function(input, output) {
})

jcheng5

Shiny without reactivity

In order to contrast Shiny's reactive programming model with the imperative programming techniques of traditional UI programming, here's a demonstration of what it looks like when you take Shiny's UI libraries and HTTP/websocket IO model, but remove the reactive programming aspects of it.

The original application code is here. In comparison, this strawman code is:

• More verbose. The server function is more than twice as long.
• Less efficient. During startup, the updateSelectedData() function runs twice, and updateClusters() and updatePlot() each run three times. Only one time each should be needed, which is what happens with the reactive version.
• Less maintainable. When a particular input changes, the question of which update functions need to be called, and in what order, is critical for correctness. In non-trivial apps this is very difficult to

jcheng5

###############################################
##
##    Attempt no 2 at building a shiny web app
##    for AB Testing use - using global.R
##
##    global.R - loading and defining variables for the global environment
##
###############################################

# Pallette used in some charts as a general indicator color for better or worse that the control group

jcheng5

# Returns a reactive that debounces the given expression by the given time in
# milliseconds.
#
# This is not a true debounce in that it will not prevent \code{expr} from being
# called many times (in fact it may be called more times than usual), but
# rather, the reactive invalidation signal that is produced by expr is debounced
# instead. This means that this function should be used when \code{expr} is
# cheap but the things it will trigger (outputs and reactives that use
# \code{expr}) are expensive.
debounce <- function(expr, millis, env = parent.frame(), quoted = FALSE,

jcheng5

library(shiny)
library(ggplot2)

function(input, output) {

  dataset <- reactive({
    diamonds[sample(nrow(diamonds), input$sampleSize),]
  })

  output$plot <- renderPlot({

jcheng5

library(shiny)
library(datasets)
library(ggplot2)

tg <- ToothGrowth
tg$dose <- factor(tg$dose)

# Define server logic
shinyServer(function(input, output) {