Default labels from attributes (option 2) #5879
Open
+80
−28
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR aims to fix #4631 and fix #5894 and competes with #5878.
Briefly, this is also an attempt to derive default labels from the 'label' attribute.
In contrast to #5878, this resolves labels in the
ggplot_build()
stage, thereby circumventing some limitations of that approach discussed yonder. It also feels 'cleaner', as there is just a single place where default labels are determined and we have no need to moonlight inggplot_add()
methods (notable exception isggplot_add.labels()
for obvious reason that these are user specified non-default labels). The drawback is that we desecrateggplot_build()
.Let's demonstrate using plots that are limitations in the other PR.
Labels are not baked in at construction time, so
%+%
data replacement works as intended.Naively, it doesn't appear to work when
data
is not a data.frame.However, this is just because
subset()
drops attributes. If we usedplyr::filter()
that doesn't drop attributes, it works just fine.Created on 2024-05-02 with reprex v2.1.0
The choice is thus:
ggplot_build()
OR
ggplot_build()