You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
geom_boxplot() demonstrates how nonstandard aesthetics for specific plot components can be scoped and handled within the layer constructor rather than built in to the ggproto. Several geometric objects in {ordr} are composite and should probably be refactored in this way.
The text was updated successfully, but these errors were encountered:
Based on further tinkering, i think nonstandard aesthetic variables should be handled in two distinct ways, depending on their behavior:
Variables that are not transformed before being passed to a $draw_*() function: Most commonly, these expect character strings; the stratum aesthetic in {ggalluvial} is an example. For all i know, errors might arise when they are passed the wrong kind of data, but for most use settings they should not require special handling.
Variables that are transformed before being passed to a Geom*$draw_*() function: Color aesthetics are the most conspicuous examples, but these also include aesthetics like shape and linetype that accept only special codes in a limited number of types. I believe they also include positional aesthetics, which are pre-processed at least during Stat*$compute_*(). To encourage the coherent treatment of plot layers, i think these should be treated somewhat as in the boxplot ggprotos and shortcuts: They should default to agree with their primary component counterparts and be customizable only to fixed aesthetic values, not variable values in the data.
geom_boxplot()
demonstrates how nonstandard aesthetics for specific plot components can be scoped and handled within the layer constructor rather than built in to the ggproto. Several geometric objects in {ordr} are composite and should probably be refactored in this way.The text was updated successfully, but these errors were encountered: