It is important that the theme be calculated after the package is loaded. If not, the theme object is stored in the compiled bytecode of the built package, which may or may not align with the installed version of ggplot2! If your package has a default theme for its visualizations, the correct way to load it is to have a function that returns the default theme.
I don't really understand the reasoning. How is having a wrapper default_theme() function results in the theme being calculated after the package is loaded? Just based on the code, I would think calling either function results in the same behavior.
I just read that section and yeah this is nuanced but accurate. When you build and install your package, this approach ensures the visualization (and the custom theme) are not created and stored hard-coded into the package. Rather, the approach shown makes sure just the instructions for making the visualization (and theme etc) are stored in the package , and the visualization and it's theme get created fresh when called upon as the package is in use. The reason seems to be to maintain the flexibility for your package ggplot visualizations to adapt to future changes in ggplot2, if necessary.
Sorry, I am still missing something. If both theme_custom() and default_theme() functions are defined in the package, how can they be treated differently?
IDK much about ggplot2 themes, but there are a bunch of packages that creates themes: METACRAN search results
Also, if you don't get a good answer here, you can try to ping the ggplot2 maintainers in the ggplot2 issue tracker. It is mainly for issues, but I think it is OK to ask questions that people cannot answer here in the forum.
I had a similar reaction to yours, @igor , so I followed @Gabor's suggestion and posted a question on github:
The immediate response was a similar reaction by one of the maintainers:
Honestly, I'm a little surprised by this recommendation, or at least the wording of it. If you have a theme_custom() constructor, you wouldn't need a default_theme() wrapper.
I think the important bit to take away is that whenever you make a theme, always actually contruct it by running the contents through the theme() function. If you're making a package, don't save an already constructed theme to a variable or to disk, but have a function that builds the theme from stratch (or builds on a pre-existing theme).
So I expect the documentation you linked will be corrected soon, and in the meantime, you can find an alternative explanation of the do's and don't's in the reply to my post.