Vega provides a way to construct visualizations from a JSON schema. I am often tempted to re-use schemas between projects, which leads to trying to make some generalized schemas that I can use in many different cases.1

I was recently working on a graph-based schema and tried to abstract away the name of the attribute used in labels. This proved to be difficult because of a few features of vega: (1) There is no way to get a field-name from a signal and (2) expressions are just strings. The two combined make it difficult to create a schema that abstracts out the names of fields.

I should not have been surprised by this, though…there are a LOT of fixed names in vega itself. fx and fy have special meaning in the force transform. id is integral to the way the tables work. path always written by linkpath2

This means when I work in vega, names are opinionated3. Cool, now I know. I will now try to do some abstraction at the presentation level rather than the data level…

  1. This is sort of like a “charting library”. I am aware that vega-lite is actually charting library built on vega. This is certainly adjacent, though not as invasive as vega-lite (which defines a new grammar that is in some ways at odds with Vega’s grammar). I am also aware that this might be a foolish goal. ↩

  2. To be fair, not all names are the subject of such strong opinions. For example, linkpath lets you set the field name to pull source & target from. However, sometimes Vega asserts its opinions strongly and there is no way to change them! ↩

  3. The part I keyed off of in the linked article is “Direction over Choice”. Vega gives choice in a lot of areas, but in other cases it gives direction. You are directed in how to handle names. You can choose how you get colors. ↩