The middle step of the pipeline: partial config -> complete config ->
render. Fills in every value that can be derived from the data, and stamps
each one "derived" in the config's origin map.
Arguments
- config
ChartConfig: The chart configuration.
- data
Optional Data frame or named list: The data to plot. When
NULL, the config'sdat_pathis read if it has one.- ...
Passed to methods.
Value
ChartConfig subclass object, with every derivable value filled in.
Details
Resolution is its own step rather than a set of fallbacks inside the option builders, and that is what makes an output config honest. A value derived during rendering would have to be reconstructed to write it down; a value derived here is simply part of the document that then gets rendered. Reading a complete config and rendering it become the same operation.
Two things are deliberately not resolved:
Anything describing the display surface – width, height, aspect ratio, container geometry. Those belong to the interface, are recomputed by each one, and are never written into a document: a height computed for an IDE pane is wrong in a large web canvas.
Anything with nothing to derive from. Labels come from column names, so a config that names no columns gets no labels.
Resolving is idempotent and never overwrites a value that is already
set, so resolving twice is the same as resolving once. compile() relies on
that: it resolves up front, and a builder it shares with draw() may resolve
again without changing the result.
Data is optional. With none available, the values that need it are simply not
derived; the ones that come from the column names still are. That makes
resolve() total – it has no failing input – so a caller can always ask for
the most complete config obtainable from what it has.
Examples
# Axis limits come from the data; the labels come from the column names.
resolve(setup_ScatterConfig(x = "wt", y = "mpg"), data = mtcars)@xlim#> [1] 1.35656 5.58044