POC: ignore()
for aesthetic evaluation.
#5418
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 explores #5290 (comment).
While #5290 tackles the same issue on the data side of things, this PR aims to use mechanics similar to
after_scale()
.Briefly, this PR introduces
ignore()
as an aesthetic evaluation modifier, which then causes scales to skip doing anything with or calculating anything from these modified aesthetics.Here are some notes:
Layer$computed_mapping
. Scales have plenty of opportunities to read/write from/todata
independent of the layer. This caused an issue on how to transfer that information to the scales.Layer$geom$draw_*()
function, which needs the original names. The 'solution' in this PR is to temporarily redefine the definition of position aesthetics in theLayer$draw_geom()
method.annotate()
to preserveignore()
'd variables.At a first glance, results are pretty similar to #5290.
Created on 2023-09-13 with reprex v2.0.2
However, this is only the case for very straightforward layers that do not reparametrize anything. For example, if you'd have to translate x/width parameters to xmin/xmax parameters, this approach doesn't keep track of what should be ignored.
Created on 2023-09-13 with reprex v2.0.2
Whereas #5290's approach bakes the ignoring part into the data, which begets the intended effect for these bars.
Created on 2023-09-13 with reprex v2.0.2
At this point, I think #5290 has more benefits than this approach.