When building visualizations with ggplot2 in R I decided to create specialized functions that encapsulate plotting logic for some of my creations. In this case instead of commonly used aes function I had to use its alternative – aes_string – for aesthetic mapping from a string.
And now goes this handy tip:
while original aesthetic mapping function aes accepts x and y parameters by position:
aes_string even though silently accepts them won’t work like this:
It will run to compile plot object without problems but when plot p (returned from the function my_plot_fun) executed this rather cryptic error appears:
Error in as.environment(where) : ‘where’ is missing
What it means is that ggplot never got aesthetics defined right. This is due to aes_string function lacking the same position parameters as in its aes counterpart above. Instead, define both x and y parameters (and others if necessary) by name:
One more vote for using aes_string in place of aes comes from CRAN submission policy, i.e.:
In principle, packages must pass
R CMD checkwithout warnings or significant notes to be admitted to the main CRAN package area. If there are warnings or notes you cannot eliminate (for example because you believe them to be spurious) send an explanatory note as part of your covering email, or as a comment on the submission form.
(source: CRAN Repository Policy)
What happens is that
R CMD check reports notes like this for every aes call:
It turns out that the most sensible solution is using aes_string instead.