-
Notifications
You must be signed in to change notification settings - Fork 184
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
Comments
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 A good example might be in plot.symbols where the symbol type is data-driven, but doesn't go through a channel. |
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. |
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. |
Would it be an option to pick some properties and make those into channels? I'm thinking specifically of |
Yes, see the work in progress #909 |
Mike's comment:
The text was updated successfully, but these errors were encountered: