Enable User Defined Theme Elements

[nhamilton1980]

This issue is at the suggestion of Hadley, based on the following:

#2305

I am the author of the ggtern package, which requires a whole bunch (50+) of new theme elements outside of the standard ggplot2 themes defined in the non-exported .element_tree object.

In this issue I will speak of my experience with ggtern, however, it is possible that any extension author may face the same problem.

The complexity of ggtern (and its sensitivity to changes within ggplot2) can be HUGELY reduced if there was a mechanism for extension authors such as myself to be able to create their own theme elements, and add them to the .element_tree. The solution I had proposed within the above link (via use of R6 class) had resolved this, with no impinging effect or risk to existing ggplot2 functionality.

Because I cannot add new theme elements, this means that I need to duplicate the .element_tree within the ggtern package, and add my new theme elements / hierarchies. This in turn means that many of the plot construction routines also needs to be held as a duplicate inside the ggtern library, leading to fragilities and vulnerabilities to changes within base ggplot2, which happens almost every year. I am trying to remove these fragilities.

To me it seems very logical for extension authors to be able to create their own theme elements. At the moment there is no way to do this to my knowledge other than the method used in ggtern, which is far from ideal. The theme element tree offered by ggplot2 is quite substantial, but by no means is it exhaustive, as has been demonstrated in ggtern, requiring dozens more for it to function properly.

[clauswilke]

I have reviewed your pull request. If I understand correctly what you need for ggtern, your proposed solution seems way overengineered. In particular, adding a whole new class model (R6) to ggplot2 doesn't seem warranted. I'd also like to point out that your code doesn't follow the tidyverse style guide (http://style.tidyverse.org/), in particular with respect to spaces around if, else, {, and after commas.

If all you need is the ability to add new theme elements, that functionality can be achieved with one new function, add_element(). The only issue is that direct assignment to .element_tree is not possible, so it'd have to be stuck into an environment, like so:

element_env <- new.env(parent = emptyenv())
element_env$element_tree <- list()

add_element <- function(key, element_def) {
  if (is.null(element_env$element_tree[[key]])) {
    element_env$element_tree <- c(
      element_env$element_tree,
      setNames(list(element_def), key)
    )
  } else {
    warning("trying to redefine existing element.")
  }
}

Now, we can do:

add_element("text", ggplot2:::el_def("element_text"))
add_element("title", ggplot2:::el_def("element_text", "text"))
add_element("text", ggplot2:::el_def("element_line"))
# Warning message:
# In add_element("text", ggplot2:::el_def("element_line")) :
#   trying to redefine existing element.

element_env$element_tree[["text"]]
# $class
# [1] "element_text"
# 
# $inherit
# NULL
# 
# $description
# NULL

Not sure why you would need all the other features you make available, such as overwriting theme elements on the fly. Would you ever have the situation where a theme element's definition would change after the initial package setup?

[hadley]

Is this the same as #1730?

[nhamilton1980]

Yes, seems so.

[nhamilton1980]

Claus, Thanks, sure perhaps my proposed solution was a bit over the top, I am really not too fussed how the end goal is achieved. Your solution seems simpler, I agree, however I wanted to make sure the base set of theme elements couldn’t get messed around with, whist still providing the ability for users to add new elements.

[clauswilke]

Nicholas,

I wanted to make sure the base set of theme elements couldn’t get messed around with, whist still providing the ability for users to add new elements.

That would be the case with my proposed approach, since theme elements can be added but only if the name isn't taken yet. Is this sufficient for you, or do you need additional features?

[nhamilton1980]

Yes that would be fine.

[clauswilke]

I think a solution along those lines can be found. However, unfortunately I think it's too late for 2.3.0. I think a reasonable goal would be to try to add the extension functionality ggtern needs into the next version after 2.3.0, so that bug reports such as nicholasehamilton/ggtern#16 and wilkelab/cowplot#88 can be closed.

[nhamilton1980]

Fantastic. This will be extremely beneficial to me.

[clauswilke]

See also #2649 for a different problem that requires a similar technical fix: a currently hard-coded list needs to become user-configurable.