Add .visibility_condition mixin methods to gos.Track

[sehilyi]

Before Update:

gos.Track(data).mark_text().encode(...,
  visibility=[
      gos.VisibilityCondition(operation="LT", measure="width", threshold="|xe-x|", transitionPadding=30, target="mark"),
      gos.VisibilityCondition(operation="LT", measure="zoomLevel", threshold=10, target="track")
  ]
)

After Update:

gos.Track(data).mark_text().encode(...).visibility_condition(
   operation="LT", measure="width", threshold="|xe-x|", transitionPadding=30, target="mark")
).visibility_condition(
   operation="LT", measure="zoomLevel", threshold=10, target="track"
)

[manzt]

I think this is a great idea! FWIW, I don't think visibility exactly belong in .encode(...) and rather .properties would be more appropriate usage currently.

The ambiguity arises because encoding fields (for simplicity, fields with type Channel) are not nested under a field themselves but alongside "mark", "style", "dataTransforms", visibility, etc.

For this reason, .encode(...) must accept any key-word argument. For example, you could equivalently pass width, height, data to .encode as well as any gos.Channel to .properties(...).

I worry that this could become confusing for users, but adding this additional mixin should certainly prevent users from specifying visibility in .encode or .properties.

As a side note, if gosling were to group channels within a key (e.g. "channel" or "encoding"), then it would be easier to restrict the usage.

{
  data: { ... },
  width: { ... },
  height: { ... },
  mark: "bar",
  channels: { x: ..., y: ... },
  visibility: [ ... ],
  dataTransform: [ ... ],
}

In this case, you can't set x directly in gos.Track(...) or gos.Track(...).properties(...). I know this would be a somewhat substantial schema change, but something worth considering in my opinion.

[sehilyi]

Thank you for sharing this!

Recently, I actually also ran into an issue where I can get benefit from grouping channels (e.g., encoding: { x... }). Also, the only reason for not grouping channels I think was to avoid deeper hierarchy, but I don't think this is a critical issue here.

I think I can change the schema (and other related codes and examples) in the Gosling and open a PR for this.