Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this branch, I’m trying to figure out how we could provide shorthand syntax for tooltips. So, rather than needing to repeat the channel definitions when declaring a tooltip, we could derive a tooltip from an existing mark (and possibly allow some overrides, say to suppress certain channels from appearing in the tooltip, or altering how the values are formatted).
As a first cut, I recycled the concept of channel aliases from the earlier PR #798. However, I don’t think this will be sufficient for initializers such as hexbin, because initializers can populate channels that are not declared in mark.channels, and thus we can’t create static aliases. That suggests that either we’d need to run the initializer on the tooltip mark (which is a bummer because it is duplicate effort and wouldn’t work with a nondeterministic initializer), or the tooltip should instead have a reference to the mark whose channel values we want to show in the tooltip. I think the latter is the way to go, but it’ll require some more plumbing to figure out how that would work… and also we should retain the ability to render an independent tooltip (attached to itself, in effect).
Getting this working is probably a blocker for #1304 because we shouldn’t land the proposed tooltip mark if we’ll have to redesign it substantially to support shorthand. But I think we’re pretty close to figuring this out.