Closed jamesscottbrown closed 7 months ago
Wonder if this isn't better facillitated in themes? (where colors are already defined) then all the functions would be universally available to packages from a central location..?
The color scales probably belond here, as they're mappings from data to colors, so is inherently visualization focused.
The theme definitions could potentially be moved, but they seem quite vis-focused (e.g., they have axis
/grid
/labels
attributes).
The theme definitions would ultimately be 'themes' expanded upon with other tokens. Those here are currently chart focussed, but eventually they should be centralised along with all the other tokens - which will be centrally in 'themes'. So they could start here, but they'd have to be moved. Timeline for all this tbd.
(also - colour scales valuable for maps?) And other potential ui elements that are perhaps not full charts - these might live in ui. so the colorscales could be consumed by all three packages - making 'themes' the best candidate for their location imho. unless we have some other utilities global area - but I don't think we should over complicate.
We've agreed to move this to a separate utils
package.
This adds the definitions of
ldnColors
,theme
,getColorScale()
, andgetThresholdBreaksColorsLabels()
from https://observablehq.com/@ldn/color-system, so that they can be easily imported by chart components or projects.After this has been published to npm, the notebook can be updated to import the functions form
@ldn-viz/charts
, so that there is a single source-of-truth.The functions
swatch()
/swatches()
/swatchGrid()
/asRamp()
/ramp()
haven't been added, as they are specific to showing color schemes/ramps in Observable notebooks.