Change the group and bin width; hover over the bars.

User interface (front end): the controls, plots, tables, layout, and explanations the user sees in the browser.

Server (back end): R code that selects data, calculates summaries, and generates the content for those outputs.

Reactivity connects them: Shiny tracks which outputs depend on which inputs and updates them when needed.

The plot’s location belongs to the UI; the code that creates its content belongs to the server.

Download the Week 6 ZIP from NOW. Unzip the whole folder into your existing module project.

Your existing module project/
  week-06-shiny-basics-reactivity/
    minimal_app.R
    starter_app.R
    slider_app.R
    01_read_and_modify_a_shiny_app.Rmd
    data/
      participant_reaction_times.csv

Keep the files inside the Week 6 folder. Do not move individual scripts or CSVs elsewhere, or work inside the ZIP.

Open 01_read_and_modify_a_shiny_app.Rmd and click Knit. Keep the HTML guide beside the source files; its contents menu helps you find each section.

The unfinished chunks are skipped when knitting. Read the HTML; edit the Rmd or named R script, not the HTML.

Core outcome: one working histogram app with two purposeful controls and enough text for another person to understand it.

Each stage: Together: inspect an example, Your turn: modify and test, then Together: check what happened. No typing along with live coding.

library(shiny)

ui <- fluidPage(
  numericInput("number", "Choose a number", value = 5),
  textOutput("double")
)

server <- function(input, output) {
  output$double <- renderText({
    input$number * 2
  })
}

shinyApp(ui, server)

Together: guide section First: run the minimal app together. Open minimal_app.R. Use Run App, not Knit, for the app scripts. Locate the UI and server; we will now trace how the app works.

shinyApp(ui, server) combines the interface and server to start the app.

server <- function(input, output) {
  output$double <- renderText({
    input$number * 2
  })
}

• <- stores these instructions under the name server.
• function(input, output) defines the function and its arguments.
• The body inside {} defines how to produce the app’s output.

Shiny calls the server function when a user opens the app, supplying input and output.

Functions define instructions. Reactivity manages when dependent output calculations update; a function is not automatically reactive.

Shiny also uses $ to access named parts of input and output. These are special Shiny objects, not data frames, but data frames allow us to illustrate what $ does.

example_data <- data.frame(
  number = 1:5, doubled = (1:5) * 2
)
example_data
#>   number doubled
#> 1      1       2
#> 2      2       4
#> 3      3       6
#> 4      4       8
#> 5      5      10
example_data$doubled
#> [1]  2  4  6  8 10

For a data frame, $doubled selects the column named doubled.

Your turn: guide section Use $ with a data frame. Complete the Rmd blank to select the original number column, then test it.

ui <- fluidPage(
  numericInput(
    inputId = "number",          # Internal input name
    label = "Choose a number",  # Visible label
    value = 5
  ),
  textOutput("double")          # Internal output name
)

UI elements are separated by commas. The final element has no trailing comma.

server <- function(input, output) {
  output$double <- renderText({  # Output name: double
    input$number * 2            # Input name: number
  })
}

output$double matches textOutput("double") in the UI.

renderText() reads input$number: change the input and Shiny recalculates the result.

Control changes update the dependent output, not the whole server function.

Your turn: predict the result for 7, then test it. Together: check trace number from numericInput() to input$number, and double from output$double to textOutput().

The supplied data contain 72 participant means, not trial-level reaction times. Each mean combines familiarisation conditions.

ggplot(d_participants,
       aes(x = mean_rt)) +
  geom_histogram(binwidth = 100) +
  labs(x = "Reaction time (ms)",
       y = "Participants")

The Shiny task is to let a reader change which observations appear and how they are grouped.

The output type changes, but the names still have to match. The familiar ggplot code goes inside renderPlot().

selectInput(
  inputId = "modality",    # Internal input name
  label = "Output group", # Visible label
  choices = c("Spoken output" = "speech",
              "Written output" = "writing")
)

• inputId = "modality" gives the control its internal name: read its value as input$modality.
• The user sees the label and readable choice names.
• Data values are speech and writing, not the displayed choice names.

Adding the selector alone does not change a plot that never uses its value.

Together: filter() keeps rows that satisfy a condition, keeping all columns.

output$rt_plot <- renderPlot({
  selected_data <- filter(
    d_participants, modality == input$modality
  )
  ggplot(selected_data, aes(x = mean_rt)) +
    geom_histogram(binwidth = 100)
})

modality is a data column; input$modality is the selected value. == tests whether they are equal for each row.

Selecting "speech" keeps the 33 spoken-group rows. <- stores this subset as selected_data; the original data are unchanged.

Changing the selection makes renderPlot() recalculate. No reactive() function is needed yet.

Open starter_app.R; use Part 1 of the Rmd instructions (about 15 minutes).

• Complete the UI output name, the filter’s input name, and the plotting dataset.
• After editing code: save, stop the app, and run again.
• Change the group: does the histogram update?

When testing controls: keep the app running.

The structure and selector are supplied. Use the connection examples on the slides to complete the blanks.

Your turn: make and test the three connections using the example.

Together: check which line makes the group selection affect the plot, and why the output names must match.

Together: predict what happens when only the UI name changes. Check how matching the two names repairs the connection.

Also check the Console for errors, commas between UI elements, and closing brackets. Test one change at a time.

Bins are intervals on the x-axis; each bar counts the participants whose values fall within that interval. Bin width is the interval’s size, here in milliseconds.

• What persists: most values cluster around 1,200–1,400 ms in both plots.
• What changes: narrow bins show small peaks and gaps; wider bins merge them and can hide detail.
• Why a slider? Readers can check whether a pattern holds across widths. The same 33 participants and their values stay fixed.

Add the control to the UI:

sliderInput("binwidth",         # Internal input name
            "Bin width (ms)",  # Visible label
            min = 25, max = 300, value = 100, step = 25)

Use its name inside renderPlot():

geom_histogram(binwidth = input$binwidth)

Here, the selected value is a number. It replaces a fixed number in familiar ggplot code.

input$modality and input$binwidth are both read inside the plot’s render function. A change to either causes the plot to update.

# Describe what each observation represents.
p("Each value represents one participant's mean
   reaction time across familiarisation conditions.")

helpText("Only participants in the selected output
          group are included in the histogram.")

A useful explanation identifies the data, units, selection, and limits of interpretation.

A comment beginning with # is for the programmer. The app user cannot see it.

Open slider_app.R; use Part 2 of the Rmd instructions (about 25 minutes).

• Complete the slider label, starting value, input connection, and two text blanks.
• Find where p() and helpText() appear, then write useful data and control explanations.
• After editing code: save, stop the app, and run again.
• Hold the group fixed while trying several widths.
• Compare your help text with a neighbour’s: what changes with bin width, and what stays the same? Revise one sentence if needed.

When testing controls: keep the app running.

Keep text accurate and brief. Explain what each control changes, not just what it is called.

Your turn: complete and test the app; use the slider example as a model.

Check why does changing bin width not change the participant count. Compare your help texts.

Everyone: read Wickham (2021), Chapter 1: Your first Shiny app, sections 1.1-1.5, ending with Adding behaviour.

As you read, connect the example to today’s app:

• Which parts belong to the UI and which to the server?
• Where do the input and output names connect?
• Why does changing an input update an output?

No written submission or book exercises are required. Section 1.6 introduces shared reactive expressions: optional preparation for next week.

Optional reference: Shiny helpText documentation.

Independent work, or if there is time in class. Use the guide section Optional: add a dynamic summary.

Goal: display the selected participant count and bin width above your histogram. Unlike helpText(), this text updates when a control changes.

1. Run extension_app.R and test its summary, then stop it.
2. In your slider_app.R, add textOutput("selection_note") before plotOutput() in the UI.
3. Copy output$selection_note <- renderText({ ... }) block into the server, alongside the plot block. The guide shows exactly where both parts belong.

Inside renderText(), filter() selects the group, nrow() counts its participants, and paste() joins the values into a sentence.

Check: switching from spoken to written output changes the count from 33 to 39. Changing bin width updates the displayed width, while the count stays fixed.

Further change: include the selected group in the summary using input$modality.