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
In my ideal world, the public API would just be VisualChannel, but the signatures on the channels themselves make that hard to navigate. Continuous resolves internally to Double, and discrete uses String as a placeholder, but is ultimately more about a collection of hashable entities that can be distinguished from each other.
The computations to make a band from a discrete channel are specific to spacing and depend entirely on the size of the range, but rather feel like its additional complexity in the scales OutputType that I could be moving up the stack, away from Scale itself and having a specific Scale type that returns a Band to a means of computing a band on a discrete scale and not having a separate type.
That, in turn, would collapse the number of types down to two - at which point potentially renaming them as ContinuousChannel and DiscreteChannel might be more than sufficient.
The specific type that I need, and what I do with it, is defined by the Mark that's using the channel - so Bar is currently using this scale that outputs a Band, but I found for labelling the bars, I ended up needing that middle value that would be returned by PointScale as well, which make the whole Band thing feel excessively complicated.
The text was updated successfully, but these errors were encountered:
Right now there's 3 different visual channels in the public API, which is rather confusing as well as cumbersome:
And that's not yet counting adding any histogram/binning capability to convert a continuous value into a discrete collection, continuous or discrete mechanisms that map values into color ranges, or handling the odd "tick value" complexities of Dates as a continuous or discrete value.
In my ideal world, the public API would just be
VisualChannel
, but the signatures on the channels themselves make that hard to navigate. Continuous resolves internally toDouble
, and discrete uses String as a placeholder, but is ultimately more about a collection of hashable entities that can be distinguished from each other.The computations to make a band from a discrete channel are specific to spacing and depend entirely on the size of the range, but rather feel like its additional complexity in the scales OutputType that I could be moving up the stack, away from Scale itself and having a specific Scale type that returns a
Band
to a means of computing a band on a discrete scale and not having a separate type.That, in turn, would collapse the number of types down to two - at which point potentially renaming them as
ContinuousChannel
andDiscreteChannel
might be more than sufficient.The specific type that I need, and what I do with it, is defined by the Mark that's using the channel - so
Bar
is currently using this scale that outputs aBand
, but I found for labelling the bars, I ended up needing that middle value that would be returned byPointScale
as well, which make the whole Band thing feel excessively complicated.The text was updated successfully, but these errors were encountered: