Extending ggplot2

This vignette documents the official extension mechanism provided in ggplot2 2.0.0. This vignette is a high-level adjunct to the low-level details found in ?Stat, ?Geom and ?theme. You'll learn how to extend ggplot2 by creating a new stat, geom, or theme.

As you read this document, you'll see many things that will make you scratch your head and wonder why on earth is it designed this way? Mostly it's historical accident - I wasn't a terribly good R programmer when I started writing ggplot2 and I made a lot of questionable decisions. We cleaned up as many of those issues as possible in the 2.0.0 release, but some fixes simply weren't worth the effort.

ggproto

All ggplot2 objects are built using the ggproto system of object oriented programming. This OO system is used only in one place: ggplot2. This is mostly historical accident: ggplot2 started off using proto because I needed mutable objects. This was well before the creation of (the briefly lived) mutatr, reference classes and R6: proto was the only game in town.

But why ggproto? Well when we turned to add an official extension mechanism to ggplot2, we found a major problem that caused problems when proto objects were extended in a different package (methods were evaluated in ggplot2, not the package where the extension was added). We tried converting to R6, but it was a poor fit for the needs of ggplot2. We could've modified proto, but that would've first involved understanding exactly how proto worked, and secondly making sure that the changes didn't affect other users of proto.

It's strange to say, but this is a case where inventing a new OO system was actually the right answer to the problem! Fortunately Winston is now very good at creating OO systems, so it only took him a day to come up with ggproto: it maintains all the features of proto that ggplot2 needs, while allowing cross package inheritance to work.

We'll start by creating a very simple stat: one that gives the convex hull (the c hull) of a set of points. First we create a new ggproto object that inherits from Stat:

The two most important components are the compute_group() method (which does the computation), and the required_aes field, which lists which aesthetics must be present in order to for the stat to work.

Next we write a layer function. Unfortunately, due to an early design mistake I called these either stat_() or geom_(). A better decision would have been to call them layer_() functions: that's a more accurate description because every layer involves a stat and a geom.

All layer functions follow the same form - you specify defaults in the function arguments and then call the layer() function, sending ... into the params argument. The arguments in ... will either be arguments for the geom (if you're making a stat wrapper), arguments for the stat (if you're making a geom wrapper), or aesthetics to be set. layer() takes care of teasing the different parameters apart and making sure they're stored in the right place:

We can also override the default geom to display the convex hull in a different way:

Stat parameters

A more complex stat will do some computation. Let's implement a simple version of geom_smooth() that adds a line of best fit to a plot. We create a StatLm that inherits from Stat and a layer function, stat_lm():

StatLm is inflexible because it has no parameters. We might want to allow the user to control the model formula and the number of points used to generate the grid. To do so, we add arguments to the compute_group() method and our wrapper function:

Note that we don't have to explicitly include the new parameters in the arguments for the layer, ... will get passed to the right place anyway. But you'll need to document them somewhere so the user knows about them. Here's a brief example. Note @inheritParams ggplot2::stat_identity: that will automatically inherit documentation for all the parameters also defined for stat_identity().

Picking defaults

Sometimes you have calculations that should be performed once for the complete dataset, not once for each group. This is useful for picking sensible default values. For example, if we want to do a density estimate, it's reasonable to pick one bandwidth for the whole plot. The following Stat creates a variation of the stat_density() that picks one bandwidth for all groups by choosing the mean of the "best" bandwidth for each group (I have no theoretical justification for this, but it doesn't seem unreasonable).

To do this we override the setup_params() method. It's passed the data and a list of params, and returns an updated list.

I recommend using NULL as a default value. If you pick important parameters automatically, it's a good idea to message() to the user (and when printing a floating point parameter, using signif() to show only a few significant digits).

Variable names and default aesthetics

This stat illustrates another important point. If we want to make this stat usable with other geoms, we should return a variable called density instead of y. Then we can set up the default_aes to automatically map density to y, which allows the user to override it to use with different geoms:

Exercises

Extend stat_chull to compute the alpha hull, as from the
alphahull package. Your
new stat should take an alpha argument.

Modify the final version of StatDensityCommon to allow the user to
specify the min and max parameters. You'll need to modify both the
layer function and the compute_group() method.

Compare and contrast StatLm to ggplot2::StatSmooth. What key
differences make StatSmooth more complex than StatLm?

Creating a new geom

It's harder to create a new geom than a new stat because you also need to know some grid. ggplot2 is built on top of grid, so you'll need to know the basics of drawing with grid. If you're serious about adding a new geom, I'd recommend buying R graphics by Paul Murrell. It tells you everything you need to know about drawing with grid.

A simple geom

It's easiest to start with a simple example. The code below is a simplified version of geom_point():

This is very similar to defining a new stat. You always need to provide fields/methods for the four pieces shown above:

required_aes is a character vector which lists all the aesthetics that
the user must provide.

default_aes lists the aesthetics that have default values.

draw_key provides the function used to draw the key in the legend.
You can see a list of all the build in key functions in ?draw_key

draw_panel() is where the magic happens. This function takes three
arguments and returns a grid grob. It is called once for each panel.
It's the most complicated part and is described in more detail below.

draw_panel() has three arguments:

data: a data frame with one column for each aesthetic.

panel_scales: a list containing information about the x and y scales
for the current panel.

coord: an object describing the coordinate system.

Generally you won't use panel_scales and coord directly, but you will always use them to transform the data: coords <- coord$transform(data, panel_scales). This creates a data frame where position variables are scaled to the range 0--1. You then take this data and call a grid grob function. (Transforming for non-Cartesian coordinate systems is quite complex - you're best off transforming your data to the form accepted by an existing ggplot2 geom and passing it.)

Collective geoms

Overriding draw_panel() is most appropriate if there is one graphic element per row. In other cases, you want graphic element per group. For example, take polygons: each row gives one vertex of a polygon. In this case, you should instead override draw_group().

There are a few things to note here:

We override draw_group() instead of draw_panel() because we want
one polygon per group, not one polygon per row.

If the data contains two or fewer points, there's no point trying to draw
a polygon, so we return a nullGrob(). This is the graphical equivalent
of NULL: it's a grob that doesn't draw anything and doesn't take up
any space.

Note the units: x and y should always be drawn in "native" units.
(The default units for pointGrob() is a native, so we didn't need to
change it there). lwd is measured in points, but ggplot2 uses mm,
so we need to multiply it by the adjustment factor .pt.

You might want to compare this to the real GeomPolygon. You'll see it overrides draw_panel() because it uses some tricks to make polygonGrob() produce multiple polygons in one call. This is considerably more complicated, but gives better performance.

Inheriting from an existing Geom

Sometimes you just want to make a small modification to an existing geom. In this case, rather than inheriting from Geom you can inherit from an existing subclass. For example, we might want to change the defaults for GeomPolygon to work better with StatChull:

These set default properties that are inherited by more specific settings. These are most useful for setting an overall "background" colour and overall font settings (e.g. family and size).

You should generally start creating a theme by modifying these values.

Complete vs incomplete

It is useful to understand the difference between complete and incomplete theme objects. A complete theme object is one produced by calling a theme function with the attribute complete = TRUE.

Theme functions theme_grey() and theme_bw() are examples of complete theme functions. Calls to theme() produce incomplete theme objects, since they represent (local) modifications to a theme object rather than returning a complete theme object per se. When adding an incomplete theme to a complete one, the result is a complete theme.

Complete and incomplete themes behave somewhat differently when added to a ggplot object:

Adding an incomplete theme augments the current theme object, replacing only
those properties of elements defined in the call to theme().

Adding a complete theme wipes away the existing theme and applies the new theme.

Creating a new facetting

One of the more daunting exercises in ggplot2 extensions is to create a new facetting system. The reason for this is that when creating new facettings you take on the responsibility of how (almost) everything is drawn on the screen, and many do not have experience with directly using gtable and grid upon which the ggplot2 rendering is build. If you decide to venture into facetting extensions it is highly recommended to gain proficiency with the above-mentioned packages.

The Facet class in ggplot2 is very powerfull as it takes on responsibility of a wide range of tasks. The main tasks of a Facet object are:

Define a layout; that is, a partitioning of the data into different plot areas (panels) as well as which panels share position scales.

Map plot data into the correct panels, potentially duplicating data if it should exist in multiple panels (e.g. margins in facet_grid()).

Assemble all panels into a final gtable, adding axes, strips and decorations in the process.

Apart from these three tasks, for which functionality must be implemented, there are a couple of additional extension points where sensible defaults have been provided. These can generally be ignored, but adventurous developers can override them for even more control:

Initialization and training of positional scales for each panel.

Decoration in front of and behind each panel.

Drawing of axis labels

To show how a new facetting class is created we will start simple and go through each of the required methods in turn to build up facet_duplicate() that simply duplicate our plot into two panels. After this we will tinker with it a bit to show some of the more powerful possibilities.

Creating a layout specification

A layout in the context of facets is a data.frame that defines a mapping between data and the panels it should reside in as well as which positional scales should be used. The output should at least contain the columns PANEL, SCALE_X, and SCALE_Y, but will often contain more to help assign data to the correct panel (facet_grid() will e.g. also return the facetting variables associated with each panel). Let's make a function that defines a duplicate layout:

This is quite simple as the facetting should just define two panels irrespectively of the input data and parameters.

Mapping data into panels

In order for ggplot2 to know which data should go where it needs the data to be assigned to a panel. The purpose of the mapping step is to assign a PANEL column to the layer data identifying which panel it belongs to.

Assembling the Facet class

Usually all methods are defined within the class definition in the same way as is done for Geom and Stat. Here we have split it out so we could go through each in turn. All that remains is to assign our functions to the correct methods as well as making a constructor

As is very apparent, the draw_panel method can become very unwieldy once it begins to take multiple possibilities into account. The fact that we want to support both horizontal and vertical layout leads to a lot of if/else blocks in the above code. In general this is the big challenge when writing facet extensions so be prepared to be very meticulous when writing these methods.

Enough talk - lets see if our new and powerful facetting extension works:

Extending existing facet function

As the rendering part of a facet class is often the difficult development step, it is possible to piggyback on the existing facetting classes to achieve a range of new facettings. Below we will subclass facet_wrap() to make a facet_bootstrap() class that splits the input data into a number of panels at random.

What we are doing above is to intercept the compute_layout and map_data methods and instead of dividing the data by a variable we randomly assigns rows to a panel based on the sampling parameters (n determines the number of panels, prop determines the proportion of data in each panel). It is important here that the layout returned by compute_layout is a valid layout for FacetWrap as we are counting on the draw_panel method from FacetWrap to do all the work for us. Thus if you want to subclass FacetWrap or FacetGrid, make sure you understand the nature of their layout specification.

Exercises

Rewrite FacetTrans to take a vector of transformations and create an additional panel for each transformation.

Based on the FacetWrap implementation rewrite FacetTrans to take the strip.placement theme setting into account.

Think about which caveats there are in FacetBootstrap specifically related to adding multiple layers with the same data.