Shiny Exercises in R: 25 Real-World Practice Problems

ui <- fluidPage(
  titlePanel("Hello Shiny"),
  sidebarLayout(
    sidebarPanel(textInput("name", "Your name", "")),
    mainPanel(textOutput("greeting"))
  )
)

server <- function(input, output, session) {
  output$greeting <- renderText({
    paste0("Hello, ", input$name, "!")
  })
}

ex_1_1 <- shinyApp(ui, server)

Explanation: Every Shiny app pairs a ui (an htmlTag object) with a server (a function of input, output, session). The reactive link is input$name -> renderText({...}) -> output$greeting. Because renderText re-runs whenever its referenced inputs change, no explicit observer is needed. Keep this skeleton memorised; nearly every Shiny app is a richer version of these eight lines.

ui <- fluidPage(
  numericInput("a", "a", 0),
  numericInput("b", "b", 0),
  verbatimTextOutput("sum")
)

server <- function(input, output, session) {
  total <- reactive(input$a + input$b)
  output$sum <- renderPrint(total())
}

ex_1_2 <- shinyApp(ui, server)

Explanation: A reactive() expression is lazy and cached: it only re-evaluates when one of its dependencies changes, and total() returns the cached value on subsequent reads. Without reactive(), doubling the use of input$a + input$b would recompute it twice. renderPrint differs from renderText because it dispatches the value through print(), so vectors and lists format with [1] prefixes.

ui <- fluidPage(
  titlePanel("Old Faithful Eruptions"),
  sidebarLayout(
    sidebarPanel(sliderInput("bins", "Bins", min = 5, max = 50, value = 20)),
    mainPanel(plotOutput("hist"))
  )
)

server <- function(input, output, session) {
  output$hist <- renderPlot({
    hist(faithful$eruptions, breaks = input$bins,
         col = "steelblue", main = NULL, xlab = "Eruptions (min)")
  })
}

ex_1_3 <- shinyApp(ui, server)

Explanation: renderPlot captures the entire plotting region: anything that produces a base R or grid graphic between the braces is rendered into the plotOutput. The histogram is bimodal because eruptions cluster into short (~2 min) and long (~4.5 min) categories, which is exactly the surprise this dataset is famous for. Setting main = NULL keeps the title-bar real estate for the titlePanel.

ui <- fluidPage(
  titlePanel("mtcars Explorer"),
  tabsetPanel(
    tabPanel("Summary", verbatimTextOutput("summary")),
    tabPanel("Table",   tableOutput("table")),
    tabPanel("Plot",    plotOutput("plot"))
  )
)

server <- function(input, output, session) {
  output$summary <- renderPrint(summary(mtcars))
  output$table   <- renderTable(mtcars, rownames = TRUE)
  output$plot    <- renderPlot(plot(mtcars$wt, mtcars$mpg, pch = 19))
}

ex_1_4 <- shinyApp(ui, server)

Explanation: tabsetPanel lets one app present several views without crowding the UI; only the active tab's outputs are visible, but all outputs are still computed by default. For expensive computations you can wrap them with bindCache or move them into eventReactive triggered by tab change to defer the work. tableOutput is a simple HTML table; for sortable, paged tables prefer DTOutput (used in Section 5).

ui <- dashboardPage(
  dashboardHeader(title = "mtcars Ops"),
  dashboardSidebar(),
  dashboardBody(
    fluidRow(
      valueBox(nrow(mtcars),                       "cars",      icon = icon("car"),   color = "blue"),
      valueBox(round(mean(mtcars$mpg), 2),         "mean mpg",  icon = icon("road"),  color = "green"),
      valueBox(max(mtcars$hp),                     "max hp",    icon = icon("bolt"),  color = "orange")
    )
  )
)

server <- function(input, output, session) {}

ex_1_5 <- shinyApp(ui, server)

Explanation: shinydashboard is a CSS theme on top of plain Shiny that gives you the recognisable header + sidebar + body chrome. valueBox is the headline-number widget every ops dashboard needs; for reactive numbers you would wrap each one in renderValueBox and emit it from the server, but for static snapshots like this the calls can live directly in the UI.

ui <- fluidPage(
  selectInput("sp", "Species", choices = levels(iris$Species)),
  tableOutput("head"),
  verbatimTextOutput("summ")
)

server <- function(input, output, session) {
  filtered <- reactive(iris[iris$Species == input$sp, ])
  output$head <- renderTable(head(filtered()))
  output$summ <- renderPrint(summary(filtered()))
}

ex_2_1 <- shinyApp(ui, server)

Explanation: Without reactive(), both output$head and output$summ would each recompute iris[iris$Species == input$sp, ], and any heavier filter would be billed twice. The reactive() wrapper memoises the result and invalidates only when input$sp changes. Call it like a function: filtered(). This pattern is the single most useful idiom in non-trivial Shiny apps.

ui <- fluidPage(actionButton("go", "Notify me"))

server <- function(input, output, session) {
  observeEvent(input$go, {
    showNotification("Saved", type = "message", duration = 3)
  })
}

ex_2_2 <- shinyApp(ui, server)

Explanation: observeEvent reacts to the named event (here input$go) and ignores all other reactives accessed in its body. Crucially, it does NOT run on app start because the button counter is 0; a plain observe({...}) block referring to input$go WOULD run once at start. Use observeEvent for side effects: notifications, writes, modal launches. Use eventReactive when you need the gated result to feed an output.

ui <- fluidPage(
  actionButton("draw", "Re-sample"),
  verbatimTextOutput("stats")
)

server <- function(input, output, session) {
  sample_vals <- eventReactive(input$draw, rnorm(1000))
  output$stats <- renderText({
    x <- sample_vals()
    sprintf("mean = %.4f  sd = %.4f", mean(x), sd(x))
  })
}

ex_2_3 <- shinyApp(ui, server)

Explanation: eventReactive is the "I want a button-gated reactive value" tool: the body only runs when its trigger fires, and the resulting reactive returns the last computed value on subsequent reads. It is the natural pair to observeEvent. The output stays empty until the first click because, like a reactive(), calling sample_vals() before it has ever run returns an silent.shiny.error, which renderText skips gracefully.

ui <- fluidPage(
  selectInput("sp", "Species",
              choices = c("", levels(iris$Species)),
              selected = ""),
  plotOutput("box")
)

server <- function(input, output, session) {
  output$box <- renderPlot({
    validate(need(nzchar(input$sp), "Please pick a species"))
    sub <- iris[iris$Species == input$sp, ]
    boxplot(sub$Sepal.Length, main = input$sp)
  })
}

ex_2_4 <- shinyApp(ui, server)

Explanation: need(cond, msg) returns NULL when cond is truthy and a validation error otherwise; validate() catches that and quietly renders msg instead of crashing the output. This is the right way to guard expensive renderings on optional inputs. Throwing a regular stop() would paint a red error box in the UI, which is jarring; validate paints a calm, italicised hint.

ui <- fluidPage(
  textInput("name", "Name", "Selva"),
  numericInput("version", "Version", 1),
  actionButton("save", "Save"),
  verbatimTextOutput("msg")
)

server <- function(input, output, session) {
  saved <- eventReactive(input$save, {
    paste0("Saved name=", isolate(input$name),
           " at version ", isolate(input$version))
  })
  output$msg <- renderText(saved())
}

ex_2_5 <- shinyApp(ui, server)

Explanation: eventReactive(input$save, ...) already gates on the button, but inside the body any input$name reference would create a reactive dependency, so changing the name between clicks would re-fire. Wrapping each input in isolate() reads its current value WITHOUT creating a reactive dependency. The combination "trigger via eventReactive, read via isolate" is the standard pattern for save/submit/commit buttons.

ui <- fluidPage(
  selectInput("sp", "Species", choices = sort(unique(as.character(iris$Species)))),
  tableOutput("tbl")
)

server <- function(input, output, session) {
  output$tbl <- renderTable(head(iris[iris$Species == input$sp, ]))
}

ex_3_1 <- shinyApp(ui, server)

Explanation: Computing choices from the data, instead of hardcoding c("setosa", "versicolor", "virginica"), is what makes the app self-updating when new data arrives. For very large vectors, sort once at app start (as here in ui) rather than on every render. If the choices themselves depend on a reactive input (cascading dropdowns), use updateSelectInput from the server side.

ui <- fluidPage(
  dateRangeInput("rng", "Window",
                 start = "1990-01-01", end = "2000-12-31"),
  plotOutput("line")
)

server <- function(input, output, session) {
  output$line <- renderPlot({
    d <- economics %>% filter(date >= input$rng[1], date <= input$rng[2])
    ggplot(d, aes(date, pce)) + geom_line(colour = "steelblue") + theme_minimal()
  })
}

ex_3_2 <- shinyApp(ui, server)

Explanation: input$rng returns a length-2 Date vector, so subscript with [1] and [2]. The economics dataset is bundled with ggplot2 and ships pre-loaded once you call library(ggplot2); that is why no data(economics) is needed. For very long series, do the filter inside a reactive() and use it across multiple outputs (Exercise 2.1) instead of refiltering inside every renderPlot.

ui <- fluidPage(
  checkboxInput("adv", "Show advanced", FALSE),
  conditionalPanel(
    condition = "input.adv == true",
    numericInput("n", "Sample size", 100, min = 10, max = 5000),
    selectInput("dist", "Distribution", c("normal", "uniform"))
  ),
  plotOutput("hist")
)

server <- function(input, output, session) {
  output$hist <- renderPlot({
    n    <- if (isTruthy(input$n))    input$n    else 100
    dist <- if (isTruthy(input$dist)) input$dist else "normal"
    x <- if (dist == "uniform") runif(n) else rnorm(n)
    hist(x, col = "grey80", main = NULL)
  })
}

ex_3_3 <- shinyApp(ui, server)

Explanation: conditionalPanel's condition is a JavaScript expression evaluated client-side, so it uses input.adv with a dot, not input$adv. Because the hidden inputs are not yet attached to the DOM when the checkbox is off, input$n is NULL initially; isTruthy is the canonical guard that returns FALSE for NULL, "", NA or empty vectors. Hide things to keep the UI calm; defer them to keep the server fast.

ui <- fluidPage(
  selectInput("cyl", "Cylinders", c(4, 6, 8)),
  downloadButton("dl", "Download CSV")
)

server <- function(input, output, session) {
  subset_df <- reactive(mtcars[mtcars$cyl == as.numeric(input$cyl), ])

  output$dl <- downloadHandler(
    filename = function() paste0("mtcars_", input$cyl, ".csv"),
    content  = function(file) write.csv(subset_df(), file, row.names = TRUE)
  )
}

ex_3_4 <- shinyApp(ui, server)

Explanation: downloadHandler needs two functions: filename returns the suggested file name shown in the browser dialog, and content writes the bytes to the file path Shiny supplies. Pair it with downloadButton(id, label) in the UI; the id must match. Because input$cyl is a string from selectInput, cast it to numeric before filtering or use string equality on as.character(mtcars$cyl).

ui <- fluidPage(
  actionButton("up",   "Up"),
  actionButton("down", "Down"),
  verbatimTextOutput("count")
)

server <- function(input, output, session) {
  state <- reactiveValues(n = 0L)
  observeEvent(input$up,   state$n <- state$n + 1L)
  observeEvent(input$down, state$n <- state$n - 1L)
  output$count <- renderText(state$n)
}

ex_3_5 <- shinyApp(ui, server)

Explanation: reactiveValues() is the mutable counterpart of reactive(): many writers, many readers, no caching of derived values. Anything that reads state$n (here renderText) re-fires when n changes; anything that writes (here the two observers) does not create a read dependency. Avoid <<- and global variables in Shiny apps; they break when a second user session opens. reactiveValues is session-scoped by default and is the right tool.

histUI <- function(id, label = "Bins") {
  ns <- NS(id)
  tagList(
    sliderInput(ns("bins"), label, 5, 50, 20),
    plotOutput(ns("plot"))
  )
}

histServer <- function(id, data) {
  moduleServer(id, function(input, output, session) {
    output$plot <- renderPlot({
      hist(data, breaks = input$bins, col = "steelblue",
           main = NULL, xlab = NULL)
    })
  })
}

ui <- fluidPage(histUI("e", "Eruptions bins"))
server <- function(input, output, session) histServer("e", faithful$eruptions)

ex_4_1 <- shinyApp(ui, server)

Explanation: NS(id) returns a namespacing function so the UI's bins input becomes e-bins in the rendered DOM, preventing id collisions when the module is reused. moduleServer creates an isolated input/output/session scope so the server logic only sees its own namespaced ids. Modules are how Shiny apps stay maintainable past a few hundred lines; a module is the Shiny equivalent of a function.

histUI <- function(id, label = "Bins") {
  ns <- NS(id)
  tagList(
    sliderInput(ns("bins"), label, 5, 50, 20),
    plotOutput(ns("plot"))
  )
}

histServer <- function(id, data) {
  moduleServer(id, function(input, output, session) {
    output$plot <- renderPlot({
      hist(data, breaks = input$bins, col = "steelblue", main = NULL)
    })
  })
}

ui <- fluidPage(
  fluidRow(
    column(6, histUI("e", "Eruptions")),
    column(6, histUI("w", "Waiting"))
  )
)
server <- function(input, output, session) {
  histServer("e", faithful$eruptions)
  histServer("w", faithful$waiting)
}

ex_4_2 <- shinyApp(ui, server)

Explanation: The two instances share NO state because NS("e") and NS("w") namespace the bins slider into e-bins and w-bins. This is the payoff of writing a module: a non-trivial widget can be parameterised and dropped wherever it is needed without copy-paste drift. Compare to a non-modular version where you would maintain two parallel sets of input ids and two separate render expressions.

pickerUI <- function(id) {
  ns <- NS(id)
  selectInput(ns("sp"), "Species", choices = levels(iris$Species))
}

pickerServer <- function(id) {
  moduleServer(id, function(input, output, session) {
    reactive(iris[iris$Species == input$sp, ])
  })
}

ui <- fluidPage(pickerUI("p"), tableOutput("tbl"))

server <- function(input, output, session) {
  filtered <- pickerServer("p")
  output$tbl <- renderTable(head(filtered()))
}

ex_4_3 <- shinyApp(ui, server)

Explanation: A module's server function can RETURN anything it likes; returning a reactive() is the canonical way to expose a value to the parent without exposing the internal input ids. The parent calls pickerServer("p") and stores the returned reactive in a local name, then reads it with filtered() like any other reactive. This is how you build composable Shiny apps without leaking namespaces.

pickerUI <- function(id) {
  ns <- NS(id)
  selectInput(ns("sp"), "Species", choices = levels(iris$Species))
}
pickerServer <- function(id) {
  moduleServer(id, function(input, output, session) {
    reactive(iris[iris$Species == input$sp, ])
  })
}

tableUI <- function(id) {
  ns <- NS(id)
  tableOutput(ns("tbl"))
}
tableServer <- function(id, data) {
  moduleServer(id, function(input, output, session) {
    output$tbl <- renderTable(head(data(), 6))
  })
}

ui <- fluidPage(pickerUI("p"), tableUI("t"))

server <- function(input, output, session) {
  filtered <- pickerServer("p")
  tableServer("t", filtered)
}

ex_4_4 <- shinyApp(ui, server)

Explanation: The contract between modules is a function call: the picker exposes a reactive returning a filtered data frame, the table accepts that reactive and renders the head. Neither module knows the other's namespace, so you can swap implementations freely. This same pattern scales to dozens of modules in production apps: each module owns its UI, its input ids and its server logic, communicating only through arguments and return values.

ui <- fluidPage(
  sliderInput("ct", "Carat", min = 0.2, max = 5, value = c(1, 3), step = 0.1),
  plotOutput("scatter")
)

server <- function(input, output, session) {
  output$scatter <- renderPlot({
    d <- diamonds %>% filter(carat >= input$ct[1], carat <= input$ct[2])
    ggplot(d, aes(carat, price, colour = cut)) +
      geom_point(alpha = 0.4) +
      theme_minimal()
  })
}

ex_5_1 <- shinyApp(ui, server)

Explanation: A two-handle slider returns a length-2 numeric vector, used here as input$ct[1] and input$ct[2]. alpha = 0.4 is the right default for overplotted scatterplots like diamonds, which has 53,940 rows. For very large data you would either pre-aggregate (heatmap-style) or use geom_hex(); rendering 50k+ points in ggplot2 every keystroke is the leading cause of sluggish Shiny apps.

ui <- fluidPage(DTOutput("tbl"))

server <- function(input, output, session) {
  output$tbl <- renderDT(
    datatable(mtcars,
              filter   = "top",
              rownames = TRUE,
              options  = list(pageLength = 10))
  )
}

ex_5_2 <- shinyApp(ui, server)

Explanation: DT::datatable is the standard widget when a static tableOutput is not enough: sorting, paging and column-level filtering all come free. filter = "top" puts a small input under each header row; values are coerced to the column's type, so numeric columns get range sliders, factors get dropdowns and characters get text boxes. For very large tables, pair with server = TRUE so DT pages the data server-side.

ui <- fluidPage(plotlyOutput("p"))

server <- function(input, output, session) {
  output$p <- renderPlotly({
    df <- mtcars
    df$label <- rownames(df)
    g <- ggplot(df, aes(wt, mpg, colour = factor(cyl), text = label)) +
      geom_point(size = 3) +
      theme_minimal()
    ggplotly(g, tooltip = c("wt", "mpg", "colour", "text"))
  })
}

ex_5_3 <- shinyApp(ui, server)

Explanation: ggplotly walks the ggplot graphics stack and converts each layer into a plotly trace, preserving aesthetics and faceting. The text aesthetic carries the row label into the tooltip without changing the visual; tooltip = c(...) whitelists which fields show. Plotly is heavier than base plotting and adds ~3MB to the page, so reserve it for charts that genuinely benefit from hover and zoom.

ui <- fluidPage(
  plotOutput("sc", brush = "br"),
  verbatimTextOutput("sel")
)

server <- function(input, output, session) {
  output$sc <- renderPlot(plot(mtcars$wt, mtcars$mpg, pch = 19,
                               xlab = "wt", ylab = "mpg"))
  output$sel <- renderPrint({
    brushedPoints(mtcars, input$br, xvar = "wt", yvar = "mpg")
  })
}

ex_5_4 <- shinyApp(ui, server)

Explanation: Brushing turns a plot into an interactive selector: brush = "br" on the plotOutput exposes input$br, a list with the brush coordinates. brushedPoints filters the source data frame to the rows whose xvar/yvar values fall inside the rectangle. This is the simplest way to add drill-down to a Shiny app; combine with a DTOutput for a click-rectangle-see-rows pattern that analysts love.

ui <- fluidPage(
  actionButton("go", "Run slow job"),
  plotOutput("h")
)

server <- function(input, output, session) {
  result <- eventReactive(input$go, {
    withProgress(message = "Drawing samples...", value = 0, {
      out <- numeric(0)
      for (i in 1:5) {
        Sys.sleep(1)
        out <- c(out, rnorm(20000))
        incProgress(1 / 5)
      }
      out
    })
  })
  output$h <- renderPlot(hist(result(), col = "steelblue", main = NULL))
}

ex_6_1 <- shinyApp(ui, server)

Explanation: withProgress opens a progress notification scoped to the surrounding reactive context; incProgress(amount, detail) advances it by amount (a fraction of 1) and optionally updates the detail label. Without progress feedback, any computation over ~2 seconds feels broken to users. For chained pipelines, prefer Progress$new() with explicit $set(value, detail) calls; for one-shot loops like this, withProgress + incProgress is enough.

ui <- fluidPage(
  theme = bs_theme(
    bg        = "white",
    fg        = "navy",
    primary   = "#0d6efd",
    base_font = font_google("Inter")
  ),
  titlePanel("Old Faithful"),
  sliderInput("bins", "Bins", 5, 50, 20),
  plotOutput("p")
)

server <- function(input, output, session) {
  output$p <- renderPlot(hist(faithful$eruptions, breaks = input$bins,
                              col = "steelblue", main = NULL))
}

ex_6_2 <- shinyApp(ui, server)

Explanation: bslib::bs_theme() builds a Bootstrap 5 theme from a small set of variables; passing it to fluidPage(theme = ...) swaps in compiled CSS at app start. font_google() fetches the named font from Google Fonts and wires up the @font-face rule for you. For interactive theme exploration during development call bs_theme_preview(theme) in your R console; once happy, hard-code the values as above.