Allow passing a function as data

[thomasp85]

This PR will make it possible to supply a function as the data argument to the layer function. The function will be applied to the global data of the plot and the result will be used in the layer.

The change is proposed to give extension developers just a tad more power when building custom features. Currently (to my knowledge) data can only be intercepted by a compute_* in a stat, and modifications have already been applied at this point.

My personal need for this feature is that I'm developing a ggplot2 extension library for dealing with graph/network data, and this type of data is not really fitting for a single data.frame as normally accepted in ggplot2. My current solution (which involves this PR) is to convert the graph into two data.frames: one describing the nodes and one describing the edges. The edge data.frame will be added as an attribute to the node data.frame. On calls to edge specific geoms the layer will get a function extracting the edges, passed as the data argument ensuring that it is the edge data that is being made available to the stats and geoms.

The changes are quite minor and does not change ggplot2 behaviour unless a function is passed to the layer. In that case the call to fortify is pushed down from layer() to map_layout() where the function is called on the global data (plot_data).

[thomasp85]

Have just found a problem with the use of facets. Will ned to make some changes

[thomasp85]

It has been fixed now. The function is now applied during ggplot_build as part of data extraction from the layers

[hadley]

Why not just add fortify.function <- function(x, data) x ?

[thomasp85]

@hadley The documentation stated that fortify might become deprecated in the future, so I chose to just ignore that approach. If fortify will remain I can definitely work around by creating fortify methods...

[hadley]

This isn't the right place either - if you wanted to preserve this basic approach it would be better to add a get_data() method (probably needs a better name) to the layer object.

[hadley]

Fortify is here for now, so you should use it. If it changes in the future, the unit tests should pick it up.

On that note, you also need some unit tests ;)

[thomasp85]

I'll use fortify then. Ignore this PR.

Ah, yes - the unit tests. They will happen eventually, but I needed to make sure that I had the general structure in place. Also, they tend to make me loose interest in a project due to their dreadful nature :-) Having published mainly through Bioconductor I've been forced to use it though (which is definitely a good thing)

[thomasp85]

... And ggraph is a week old so I think I'm entitled to doing the fun stuff for now :-)

[thomasp85]

Reopening. fortify is called in layer() and doesn't have access to global data (as far as I can see). This PR is specifically meant for passing a function that is called on the global data... You had me confused with all this talk of fortify :-)

There will need to be some changes somewhere in ggplot2 for this to work. Should I redo the PR in the style of a get_data method to Layer as you proposed?

[hadley]

Yeah - I'd recommend a new PR with:

• fortify.function
• Layer$get_data()
• Some unit tests :)

[thomasp85]

Having slept on it I have some reservations with the approach (no - not the unit tests:-). But it is ultimately up to you.

The promise of fortify is to turn data into a tabular format. By cheating and using it to let a function slip through we are making the use case of fortifymore confusing.

I kind feel that passing a function is a beefed up version of passing waiver and therefore it should be resolved at the same place (which was why I started out with map_layout (but this didn't work because it comes too late for facetting). It seems strange to have a Layer$get_data() that will return a waiver, but on the other hand it would potentially result in a performance hit to expand waiver data at the same time as function data.

I would personally find it most clear if function data was handled by a specialised function right after layer_data had been extracted (a simple lapply that checks whether elements are functions and if so calls the function on plot_data).

Again - it is ultimately up to you. Just some concerns over the clarity of the implementation.

[hadley]

I don't feel that strongly about the fortify issue. I do think it makes sense to have a function that returns the data from the layer, however it is stored (either directly, as a waiver, or via a function) - and layer_data <- lapply(layers, function(y) y$data) is crying out for more generality.

[lock]

This old issue has been automatically locked. If you believe you have found a related problem, please file a new issue (with reprex) and link to this issue. https://reprex.tidyverse.org/