R
Completed
-
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
95: Working with Nested Lists
Imagine you're organizing a physical archive of project files. You don't just throw every single piece of paper into one giant box. Instead, you have a filing cabinet (the main list). Inside that cabinet, you have drawers (the first level of nesting). Inside each drawer, you have manila folders (the second level), and inside those folders, you finally find the actual documents or sticky notes (the values).
In R, a nested list is exactly that: a list where one or more of the elements are themselves lists. It's the primary way we handle hierarchical data—the kind of stuff you'll see constantly when you start working with JSON APIs or complex model outputs from packages like lme4 or caret.
Mapping the Archive to the Code
Let's take that archive analogy and turn it into a real scenario. Suppose we're tracking data for a few software projects. Each project has a name, a lead developer, and a sub-list of current milestones.
projects <- list(
project_alpha = list(
lead = "Sarah",
milestones = list(
m1 = "API Design",
m2 = "Database Schema"
)
),
project_beta = list(
lead = "Marcus",
milestones = list(
m1 = "Frontend Prototype",
m2 = "User Testing"
)
)
)
Here is how the analogy maps:
- The Cabinet: The
projectslist itself. - The Drawer:
projects$project_alpha. This is a list containing everything about Project Alpha. - The Folder:
projects$project_alpha$milestones. This is another list nested inside the first one. - The Document:
projects$project_alpha$milestones$m1. This is the final string, "API Design".
Drilling Down with Double Brackets
You've probably used the $ operator, which is great when you know the names of your elements. But in a professional production environment, you'll often be looping through lists where the names are dynamic. That's where double brackets [[ ]] come in.
I'll be honest: the difference between [ ] and [[ ]] is where most R beginners get tripped up. Remember that [ ] returns a slice (a smaller list), while [[ ]] returns the actual content inside that slice.
# This returns a list containing the project_alpha list
slice <- projects[1]
# This returns the actual list for project_alpha
content <- projects[[1]]
# To get the first milestone of the first project:
milestone_val <- projects[[1]][[2]][[1]]
# Result: "API Design"
Think of [[ ]] as "reaching inside" the container. To get to that first milestone, we reached into the cabinet [[1]], then into the milestones folder [[2]], and finally grabbed the first single item [[1]].
Surgical Edits to Deeply Buried Data
Updating a nested list is straightforward once you've navigated to the specific "document" you want to change. You just use the assignment operator <- at the end of your navigation path.
Let's say Project Beta just finished its first milestone and moved to "Beta Release". You don't need to redefine the whole list; you just target that one leaf node:
projects$project_beta$milestones$m1 <- "Beta Release"
If you're using indices instead of names, it looks like this:
projects[[2]][[2]][[1]] <- "Beta Release"
One quick tip from experience: when your lists get more than three levels deep, stop and ask yourself if you should be using a data.frame or a tibble. Nested lists are powerful, but if you find yourself writing [[1]][[4]][[2]][[1]], your code becomes a nightmare to debug because it's impossible to tell what those numbers actually represent just by looking at them.
📋 Practical Task
Building a Multi-City Weather Archive
You need to create a nested list structure to store weather observations for three different cities. Each city should be a named element in the main list. Inside each city, create two nested lists: metadata (containing the country and timezone) and readings (containing a list of temperatures for 'Monday', 'Tuesday', and 'Wednesday').
Your requirements:
- Create the nested list for cities: "London", "Tokyo", and "New York".
- Assign a temperature value to each day for each city.
- Update the temperature for Tokyo on Tuesday to a new value using double brackets
[[ ]]. - Extract and print only the timezone for New York using the
$operator.
There are no comments for now.