emilyriederer / Rtistic

A hackathon-in-a-box / "cookbook" to help build an R package with custom RMarkdown themes and ggplot2 themes & palettes. This looks like a package but it is not intended to be installed as-is. It is a wireframe to be used by an individual or group to create their *own* package!

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Instructions for custom theme

gadenbuie opened this issue · comments

I've never used %+replace% but saw it was added in #1 and then I went and read more about it from the new using ggplot2 in packages vignette.

What kicked me off down this rabbit hole was that I had a hard time understanding this line in the theme_test() docs.

#' [ggplot2::theme_minimal()]. Any elements set by `theme_pomological()` will
#' overwrite the `base_theme` unless the specific parameter is explicitly set
#' to `NULL`.

I didn't propose a change to it because I'm not sure if the instruction is for the package author using this template or the final package user.

After reading the above vignette a few times, my understanding is that %+replace% works best when the base_theme in theme_test() is set internally rather than as an exposed argument. With this philosophy, the package author has full control over the theme output and doesn't have to worry about inheriting from a user theme.

If, on the other hand, the theme is meant to add a small bit of "style", then maybe what is needed is a function that returns a ggplot2::theme() object that can be added to an existing theme (something like theme_minimal() + theme_test_style(). I guess that the best approach depends on the template user's goals.

Thank you so much, @gadenbuie ! I really appreciate all of the helpful comments.

First, as somewhat of a sidenote, your remark about ambiguity who the instructions were aimed at was in itself very helpful in clarifying my thinking. I think I did blur the line here - both in the docs and code -between the support that the "developer" needs versus the final scaffolding that should exist for end-users. and between the interactive / package contexts.

Thanks also for the description of %+replace%. That makes a lot of sense, and now that you say it, I do see how the current combination could lead to some pretty confusing and undesirable side-effects. %+replace% also seems to require a lot more work on the developer's part, which possibly adds robustness but I don't think is the core goal for this specific project.

Thanks again! I had let this piece get fairly murky in intent, and I'm so glad you pointed that out.