Skip to content

Should *any* constant property be expressible, somehow, as a data-driven channel if desired? #175

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

Closed
Fil opened this issue Feb 25, 2021 · 5 comments
Labels
question Further information is needed

Comments

@Fil
Copy link
Contributor

Fil commented Feb 25, 2021

Mike's comment:

My working assumption is that Marks currently get to decide whether a property is a constant or a channel (or either, e.g., with maybeColor), so if a given Mark doesn’t expose what you want, we either need to change the Mark definition to make it more flexible, or extend the Mark to create a new one. I do think it ends up being simpler if a Mark implementation can declare something as a constant property, rather than needing to support every property as possibly being data-driven. Also, even for constant properties, you can make things somewhat data-driven by declaring multiple marks (as in the Marimekko example) and possibly filtering the data.

@Fil
Copy link
Contributor Author

Fil commented Feb 25, 2021

When tinkering with "plugins" (extending…), I found that I didn't need a proper Channel for most cases, even for data-driven values.

The only case where a channel is indispensable is when it concerns shared scales between marks. But, for example, a data-driven textAnchor: d => ƒ(d) needs to be called only at the rendering stage, which makes it much easier to support across all marks with a minimal change.

A good example might be in plot.symbols where the symbol type is data-driven, but doesn't go through a channel.

@mbostock mbostock added the question Further information is needed label Feb 25, 2021
@Fil
Copy link
Contributor Author

Fil commented May 24, 2021

This question comes up often, and it's not easy to remember which of the properties are constants (basically you discover by trying and failing).

Maybe marks should accept constants (without checking that they may be field names), but when their typeof is function, use the function. It would need to be passed the datum.

@mbostock
Copy link
Member

I don’t think we should do anything immediately here, and this issue has been open for a while, so I am going to close so we can focus on more actionable items. We can always revisit this issue if we keep being frustrated by certain options only being channels, but I think switching to everything potentially being a channel will add complexity and burden to mark implementations that we should avoid if possible.

@Fil Fil mentioned this issue Jun 2, 2022
14 tasks
@tobiassjosten
Copy link

Would it be an option to pick some properties and make those into channels? I'm thinking specifically of dy and dx for the text plot, which I right now would have loved to offset differently depending on the data.

@Fil
Copy link
Contributor Author

Fil commented Jun 19, 2022

Yes, see the work in progress #909

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is needed
Projects
None yet
Development

No branches or pull requests

3 participants