Functions to help make patches to add signal?

[AliciaSchep]

Patches passed to vega_embed enable adding signals to a spec. It would be nice if there was a way to make the patch using vlbuildr

Possibly the vegaspec object could get an attribute that has the patch, and that gets added in by vegawidget? This would require changes in vegawidget -- thoughts @ijlyttle ? Or possibly vlbuildr could make its own classes so it can handle that (but would still use vegawidget at the end in the print method)

A function like vl_add_signal would add a signal not as part of the spec, but as an attribute which stores the object to use for patching. (Or maybe vl_patch_signal or vl_patch_add_signal, naming tbd)

The goal would be that the user doesn't have to remember the exact nested structure to use for the patch, but can create the right object with a fairly simple function call. Might need to go looking into the vega schema to see what exactly the format possibilities are...

[ijlyttle]

A couple of quick thoughts:

• I don't think a Vega-Lite spec with a signal would pass Vega-Lite validation, but this is not news to you and I suspect this is not a dealbreaker...

• There is a usermeta element available in the top-level of Vega-Lite. Perhaps the patching magic could happen on the vegawidget side, where it could look for something like:

{
  "usermeta": {
    "vegawidget": {
      "signals": [
        {"name": "bin_width", "value": 0.5},
        {"name": "another_bin_width", "value": 1.0}
      ]
    }
}

I'd be happy to consider something like this (you may have another idea for an implementation) as a default behavior of vegawidget: to look for this section in usermeta, then invoke vega_embed using the patch.

Just spitballing here, but let's say you had a function named vl_signal() that you could use like:

something %>%
  vl_encode_x(
    field = "temp", 
    type = "quantitative", 
    bin = list(step = vl_signal(bin_width = 0.5))
  )

The function could return something like list(signal = "bin_width"), but there would have to be some mechanism to put the signal definition into the top-level usermeta, which I don't quite see (but my sight is not perfect).

Edit

Perhaps vl_signal() could modify the spec sent to vl_encode_x() using <<-...

This might where you would use a vl_add_signal() function, perhaps to add to usermeta. This might be coming into focus for me, but I do not presume that "my" focus is "your" focus...

/Edit

Am I answering the right question?

[AliciaSchep]

I think so! (re the right question).

I had not thought about using usermeta in that way, and I really like that idea. I had been thinking of adding the info as an attribute to the vegaspec object, in which case it'd get lost when trying to inspect the json itself.

I was thinking something along the lines of what you suggest at the end:

something %>%
  vl_encode_x(
    field = "temp", 
    type = "quantitative", 
    bin = list(step = vl_signal("bin_width"))
  ) %>%
 vl_add_signal(name = "bin_width", value = 0.5)

vl_signal would just make list(signal = "bin_width") and vl_add_signal would add the right stuff to usermeta

[ijlyttle]

Your idea for vl_signal() and vl_add_signal() seems safer, <<- always makes me nervous 😬

I'll file an issue at vegawidget for the usermeta bit, and start on a PR threre!

[g3o2]

According to Dominik, there is apparently already unofficial support for signals in vega-lite. Consequently, there is risk of API conflicts in future. Maybe it is better not to add to vega-lite features in this package.

Alternatively, name the function such as to minimise such conflicts, e.g vl_usermeta_add_signal() ?

[ijlyttle]

If we are talking about the same thing, Dominik is talking about patching a Vega-Lite spec using vega-embed, which is, as I understand, the path we propose to follow.

In general, I think we can make it understood that support for signals in Vega-Lite is experimental, thus our support on the vegawidget side is equally experimental. Although Vega-LIte is becoming more stable, there are parts (exciting parts) that are "still cooking". Among the Vega-Lite early adopters in the R community, there is a lot of interest in signals; I think these folks will be able to assess the API risk.

Of course, anything I say as it applies to this package, I say under @AliciaSchep's watchful eye.

[AliciaSchep]

Perhaps the function could get named vl_patch_signal? To indicate it is tied to the patch mechanism. With notes in the docs about it being experimental and all that. And then if full support for signals is added then a new/different function would get added, probably vl_add_signal (depending on what the api is)?

[g3o2]

signals on their way: https://github.com/vega/vega-lite/releases/tag/v4.7.0

[ijlyttle]

Super, thanks for the heads-up - I'll have to take a closer look!

[g3o2]

Finally, signals have made it into the vega-lite 5 release -> parameters: https://vega.github.io/vega-lite/docs/parameter.html

[ijlyttle]

This looks like good news!

[AliciaSchep]

Closed with addition of parameter support in #72 (but still need to document / show examples)