Building ggplots — Build a ggplot with aesthetics (aes) and geoms

Data visualization has long been central to statistical computing, but for decades, the tools available in R and its predecessors relied on imperative, pen-on-paper metaphors: you told the computer exactly where to draw each line, bar, and label. The base graphics system in R, inherited from the S language of the 1970s, exemplified this approach—powerful but verbose, and difficult to compose or modify systematically. The fundamental problem was the absence of a coherent grammar that could decompose any visualization into reusable, interchangeable components, much the way a formal grammar decomposes natural language into parts of speech.

The core question ggplot2 answers is deceptively simple: how do you map abstract data columns onto the visual properties of graphical marks in a composable, declarative way? The answer lies in two interlocking concepts—aesthetic mappings (aes()) and geometric objects (geom_*())—that together form the backbone of every ggplot.

Building a ggplot is fundamentally an act of declaring relationships between your data and the visual channels of a chart. Rather than writing imperative instructions like 'draw a bar from (0,0) to (1,5),' you state that a column named revenue should be mapped to the y-axis and quarter to the x-axis, and then you specify that the resulting marks should be bars. This declarative paradigm separates what you want to show from how the rendering engine draws it, a principle familiar to CS students who have studied declarative languages or frameworks like SQL or React.

The diagram below illustrates how a ggplot is assembled layer by layer. At the bottom sits the data frame. Above it, the aesthetic mapping layer connects data columns to visual channels. On top of that, one or more geom layers render the marks. Finally, scales, coordinates, and themes provide the finishing touches. Each layer is independent: you can swap a geom_point() for a geom_line() without changing the data or aesthetics.

Notice the architectural similarity to a software stack: each layer depends on the one below it but is independently replaceable. This composability is the hallmark of the grammar of graphics and is what gives ggplot2 its remarkable flexibility compared to imperative plotting systems.

When you call aes(x = displ, y = hwy, color = class), you are not evaluating those column names immediately. Instead, non-standard evaluation (NSE) captures the unevaluated expressions as quosures—closures that pair an expression with the environment in which it should be evaluated. This is the same tidy evaluation machinery that powers dplyr's filter() and mutate(). The practical consequence is that aesthetic mappings are resolved lazily, at render time, when the data frame is available. This design enables inheritance: aesthetics defined in the top-level ggplot() call are inherited by every subsequent geom unless explicitly overridden.

Aesthetic Inheritance Rules

Aesthetics defined inside ggplot(aes(...)) are global aesthetics. Every geom layer inherits them. Aesthetics defined inside a specific geom_*(aes(...)) are local aesthetics and apply only to that layer. A local mapping overrides a global one if they conflict. Meanwhile, setting an aesthetic to a constant outside aes()—for instance, geom_point(color = "red")—is a fixed setting, not a mapping, and does not generate a legend.

The Geom–Stat Duality

Each geom is paired with a default stat (statistical transformation). For example, geom_bar() uses stat = "count" to aggregate raw data into bar heights, while geom_point() uses stat = "identity" and plots values as-is. You can override the default stat—geom_bar(stat = "identity") expects pre-computed heights—or equivalently use geom_col(), which is syntactic sugar for the same thing. Understanding this duality helps you predict when ggplot will transform your data versus when it plots raw values.

ggplot2 ships with over 40 geom functions, but a handful account for the vast majority of everyday visualizations. The table below catalogs the most common geoms alongside their required aesthetics, optional aesthetics, and default statistical transformations. Knowing which aesthetics a geom requires prevents the most common class of ggplot errors.

The matrix above is invaluable when debugging. If ggplot throws an error like geom_bar requires the following missing aesthetics: x, you can cross-reference the chart to confirm that x is indeed a required aesthetic for geom_bar(). Similarly, remembering that geom_bar() does not require y (because its default stat computes counts) explains why supplying both x and y often produces errors—use geom_col() instead.

Let us walk through building a complete ggplot using the built-in mpg dataset, which contains fuel economy data for 234 vehicles. Our goal is to create a scatter plot of engine displacement versus highway miles per gallon, colored by vehicle class, with a smoothed trend line overlay.

ggplot2's grammar-based approach delivers enormous advantages in expressiveness and reproducibility, but it also introduces a specific class of pitfalls that trip up even experienced R programmers. The table below contrasts the key strengths against the most frequently encountered limitations.

The aes() + geom_*() foundation extends seamlessly into advanced visualization paradigms. Understanding these connections situates today's concepts within the broader ggplot2 ecosystem and prepares you for more sophisticated analyses.

The critical insight is that every advanced technique above still relies on the same aes() + geom backbone you learned today. Faceting adds a dimension without changing how aesthetics or geoms work. Custom scales modify the mapping function between data values and aesthetic values but do not alter the data or the geom. Even animation with gganimate simply adds a transition_*() layer that interpolates between aesthetic states over time. Mastering the foundational grammar therefore provides exponential returns as you explore the ecosystem.