Default labels from attributes (option 1) #5878
Closed
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 it competes with #5879.
Briefly, an attempt is made to derive default labels from the 'label' attribute.
Less brief,
make_labels()
now accepts adata
argument. When there are simple symbolic mappings, these are evaluated and searched for a label attribute. There are some limitations with this approach that are detailed below.To give an example we can give the
mtcars
dataset some label attributes.Notice in the plot below that all default labels are derived from the attribute, regarless of whether it comes from the global mapping, the layer mapping or data pronoun use.
When we use a standalone
+ aes(...)
it also yields the exact same plot.As for the limitations, here are some that I noticed.
When using layer data, global aesthetics do not get searched.
Also, when the data is a function, the labels cannot be retrieved.
The data also isn't
fortify()
'ed or in any way preprocessed.Created on 2024-05-02 with reprex v2.1.0
The labels are also baked in at the time the layers are added, so doing the following:
Does not give the attribute labels.
These limitations could be resolved if the labels were derived in the
ggplot_build()
step, but as that function is somewhat sacred, I tried this approach first. Also, as this does not have an on/off switch, this PR will break some plots (but hopefully for the better).Despite these limitations, I think this is an improvement over the current situation. See #5879 for a second option with fewer limitations.