Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

look at collapsing/renaming the visual channels #39

Open
heckj opened this issue May 31, 2022 · 0 comments
Open

look at collapsing/renaming the visual channels #39

heckj opened this issue May 31, 2022 · 0 comments
Assignees

Comments

@heckj
Copy link
Member

heckj commented May 31, 2022

Right now there's 3 different visual channels in the public API, which is rather confusing as well as cumbersome:

  • continuous
  • discrete (point)
  • discrete (band)

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 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.

@heckj heckj self-assigned this May 31, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant