-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Data Structures
-
Section 4: Data Manipulation
-
Section 5: Visualization and Statistics
-
Section 6: Advanced R
-
Section 7: Practical Projects
-
Section 8: Interview Practice
-
Section 9: More Practice Exercises
-
Section 10: Shiny Apps in Depth
-
Section 11: More Data Wrangling
-
Section 12: Tidyverse Deep Dive
-
Section 13: Statistical Modeling Deep Dive
-
Section 14: Machine Learning in R
-
Section 15: R Visualization Deep Dive
-
Section 16: R Package Development Deep Dive
-
Section 17: R for Reproducible Research
-
Section 18: R and Databases
-
Section 19: R Performance Optimization
-
Section 20: Bioinformatics and Specialized R
-
Section 21: More Shiny Practice
-
Section 22: More Practice Exercises
-
Section 23: R Data Structures Deep Dive
-
Section 24: More Interview and Review
-
Section 25: R for Business Analytics
-
Section 26: R Text Mining and NLP
-
Section 27: R Spatial Data Analysis
-
Section 28: R Deep Learning
-
Section 29: Advanced Statistical Techniques
-
Section 30: R Object Systems Deep Dive
-
Section 31: R Environments and Metaprogramming
-
Section 32: R for Finance
-
Section 33: R for Clinical and Health Data
-
Section 34: More Shiny Advanced Practice
-
Section 35: R Data Cleaning Deep Dive
-
Section 36: R Reporting Automation
-
Section 37: More Practical Projects Round 2
-
Section 38: R Ecosystem and Career
-
Section 39: More Visualization Practice
-
Section 40: R for Experimentation
-
Section 41: R for Genomics and Bioinformatics Deep Dive
-
Section 42: R for Marketing Analytics
-
Section 43: R Data Import/Export Deep Dive
-
Section 44: R String Processing Deep Dive
-
Section 45: R for Actuarial and Insurance Analytics
-
Section 46: R Testing and Quality Assurance Deep Dive
-
Section 47: R Version Control and Collaboration
-
Section 48: R Advanced Functional Programming
-
Section 49: R for Supply Chain and Operations
-
Section 50: More Practice Exercises Round 3
-
Section 51: R Dashboards and BI Integration
-
Section 52: R Data Governance and Ethics
-
Section 53: More Modeling Practice
-
Section 54: R Final Capstone Projects
-
Section 55: R for Sports Analytics
-
Section 56: More Interview Practice Round 2
-
Section 57: R Networking and APIs
-
Section 58: R for Environmental Science
-
Section 59: R Notebook and Documentation Practices
-
Section 60: More Data Wrangling Mastery
-
Section 61: R for A/B Testing at Scale
-
Section 62: R Package Ecosystem Deep Dive
217: Capstone: Building a Public Health Surveillance Dashboard
Listen, before we dive into the code for this capstone, I want to clear something up. I've seen a lot of developers approach their first dashboard by thinking: "A dashboard is just a collection of a few ggplot2 graphs put on a webpage."
If that were true, you'd just be making a website with screenshots. In a real public health surveillance context—say, tracking a spike in Influenza-like Illnesses (ILI) across several counties—that approach fails the moment a user interacts with the data. If you put your data filtering logic directly inside your renderPlot function, R will re-calculate that entire filter every single time any single element on the page changes. When your dataset grows from a few hundred rows to a few hundred thousand, your dashboard will lag, freeze, and eventually crash. That's not a tool; it's a liability.
The Mistake: Treating Reactivity as a Plotting Detail
When people treat the dashboard as a "gallery," they write code that looks like this:
# The "Slow" Way
output$casePlot <- renderPlot({
# Filtering happens INSIDE the render function
filtered_data <- all_cases %>%
filter(region == input$region_select,
date >= input$date_range[1],
date <= input$date_range[2])
ggplot(filtered_data, aes(x = date, y = cases)) + geom_line()
})
Now, imagine you have three different plots and a summary table all using that same filtered data. In the "Slow Way," R performs that filter() operation four separate times every time the user moves the date slider. It's redundant and wasteful. I've seen this crash production servers during actual health crises because the developer didn't account for the computational overhead of redundant filtering.
The Correction: Building a Reactive Data Pipeline
The secret to a professional surveillance dashboard is the reactive() expression. Think of it as a "cached" version of your data that only updates when its specific dependencies change. You create a single source of truth for your filtered data, and then your plots simply "consume" that truth.
Here is how we're actually going to structure the capstone project:
# The "Professional" Way
# 1. Create a reactive expression for the filtered dataset
filtered_data <- reactive({
# This only runs when input$region_select or input$date_range changes
all_cases %>%
filter(region == input$region_select,
date >= input$date_range[1],
date <= input$date_range[2])
})
# 2. The plots now just call the reactive expression as a function
output$casePlot <- renderPlot({
ggplot(filtered_data(), aes(x = date, y = cases)) + geom_line()
})
output$summaryTable <- renderTable({
filtered_data() %>% summarize(total = sum(cases))
})
Notice the parentheses in filtered_data()? That's the tell-tale sign of a reactive object. By separating the data processing from the data visualization, the dashboard stays snappy. For a public health official trying to identify an outbreak in real-time, those few seconds of latency can be the difference between a useful tool and a discarded one.
In this capstone, we aren't just plotting lines; we are building a pipeline. We'll be using bslib to give it a modern, "government-grade" look, and we'll be implementing observeEvent to handle specific alerts—like triggering a warning notification when the case count exceeds a predefined epidemiological threshold.
📋 Practical Task
Implementing a Region-Specific Outbreak Alert Trigger in the Surveillance Dashboard
You have been provided with a basic Shiny app skeleton that tracks disease cases. Currently, the app displays a plot and a table, but it doesn't proactively warn the user if a region has entered an "outbreak" state (defined as more than 500 cases in the selected time window).
Your Task:
- Create a
reactiveexpression that calculates the total sum of cases for the currently selected region and date range. - Add a
uiOutputelement to the UI namedoutbreak_alert. - Implement a
renderUIfunction on the server side that checks the total cases. If the total is greater than 500, it should return adivwith a red background and the text "WARNING: Outbreak Threshold Exceeded!". If it is below 500, it should return an emptydivor a green "Stable" message. - Ensure that the alert updates instantly when the region or date range is changed.
There are no comments for now.