Vega-lite: Consider exposing "hover" encoding sets via conditional encoding

Created on 27 Mar 2020  路  2Comments  路  Source: vega/vega-lite

Using selection to implement hovering effects is largely inefficient (perf-wise), we could consider leveraging the Vega's hover encoding set like this:

color: {
  condition: {"hover": true, value: "green"},
  value: "red"
}

The tricky part is that the "hover" condition must never be an array (as we can 't mix it with other conditional encoding).

Enhancement RFC / Discussion

Most helpful comment

An alternative idea might be to reserve hover as a special name such that there cannot be any user-defined selection named hover. That way, we would not need to extend the surface area of condition, and can keep it to condition: {selection: "hover", value: "green"}. After all, the operation that occurs on hover is still a selection, it seems a little odd that we'd change how condition works because of implementation/Vega decisions?

(We could also consider having click being a similar kind of reserved/default selection.)

All 2 comments

An alternative idea might be to reserve hover as a special name such that there cannot be any user-defined selection named hover. That way, we would not need to extend the surface area of condition, and can keep it to condition: {selection: "hover", value: "green"}. After all, the operation that occurs on hover is still a selection, it seems a little odd that we'd change how condition works because of implementation/Vega decisions?

(We could also consider having click being a similar kind of reserved/default selection.)

I like the idea of having reserved selection names (similar to reserved signal names like width, height, padding, etc).

Was this page helpful?
0 / 5 - 0 ratings