so I think it would be useful to return the event coordinates (i.e. bounding box of a brush or click event) to the R session, especially for EDA. The only way I think we could do this currently is via shiny. One thought I had would be to have an option that sets viewer to use shiny as a backend with runGadget(). This would still run the plot in the rstudio viewer but would allow our plot object to track events.

Here is a minimal example where df1 and df2 share the same volume id.

When concatenating scatter_plot and ts_plot using the second chunk of code, making a selection on scatter_plot doesn't show the relevant series in the ts_plot.

I'm aware that changing the dataset of ts_plot to df2 %>% left_join(df1, by = "id") will work, but the common id column should be sufficient for the two plots to be linked.

library(tibble)
library(lubridate)
#> 
#> Attaching package: 'lubridate'
#> The following objects are masked from 'package:base':
#> 
#>     date, intersect, setdiff, union

set.seed(123)
df1 <- tibble(
  id = 1:10,
  x = runif(10),
  y = runif(10)
)

df2 <- tidyr::expand_grid(
  id = 1:10,
  date = seq(ymd("2020/01/01"), ymd("2020/01/31"), by = "day")
) %>% 
  add_column(value = runif(nrow(.)))

df1
#> # A tibble: 10 x 3
#>       id      x      y
#>    <int>  <dbl>  <dbl>
#>  1     1 0.288  0.957 
#>  2     2 0.788  0.453 
#>  3     3 0.409  0.678 
#>  4     4 0.883  0.573 
#>  5     5 0.940  0.103 
#>  6     6 0.0456 0.900 
#>  7     7 0.528  0.246 
#>  8     8 0.892  0.0421
#>  9     9 0.551  0.328 
#> 10    10 0.457  0.955
df2
#> # A tibble: 310 x 3
#>       id date       value
#>    <int> <date>     <dbl>
#>  1     1 2020-01-01 0.890
#>  2     1 2020-01-02 0.693
#>  3     1 2020-01-03 0.641
#>  4     1 2020-01-04 0.994
#>  5     1 2020-01-05 0.656
#>  6     1 2020-01-06 0.709
#>  7     1 2020-01-07 0.544
#>  8     1 2020-01-08 0.594
#>  9     1 2020-01-09 0.289
#> 10     1 2020-01-10 0.147
#> # … with 300 more rows

^{Created on 2021-04-30 by the reprex package (v2.0.0)}

library(virgo)
selection <- select_interval()

scatter_plot <- df1 %>% 
  vega() %>% 
  mark_point(enc(x = x, y = y),
             selection = selection)

ts_plot <- df2 %>% 
  vega() %>% 
  mark_line(enc(x = date, y = value, group = id),
            selection = selection)

hconcat(scatter_plot, ts_plot)

I believe this is called detail in vega-lite https://vega.github.io/vega-lite/docs/line.html#line-detail

Should we implement this as enc(group = ...) or leave it as detail?

I tried running the first example and got the following.

could not find function "%>%"

You need to usethis::use_pipe()?

PS: great pkg! How very exciting!

Shall we handle missing values as is now? or different?

library(dplyr)
movies <- jsonlite::read_json(
  "https://vega.github.io/vega-editor/app/data/movies.json"
  , simplifyVector = TRUE)
movies <- movies %>%
  mutate(missing = is.na(IMDB_Rating) | is.na(Rotten_Tomatoes_Rating))
movies %>%
  vega(enc(IMDB_Rating, Rotten_Tomatoes_Rating, colour = missing)) %>%
  mark_point() %>%
  config(mark = list(invalid = NULL))

• vega inputs: input_*()
• shiny reactive inputs

Maybe:

• mark_mosaic(): https://vega.github.io/vega-lite/examples/rect_mosaic_labelled_with_offset.html
• mark_parallel(): https://vega.github.io/vega-lite/examples/parallel_coordinate.html
• mark_geoshape()

https://vega.github.io/vega-lite/examples/interactive_splom.html

vega(cars) %>%
  mark_point(enc(x = ac(c(x1, x2, x3)), y = ac(c(y1, y2, y3), vg_mean))) # or supports tidy select

The current implementation accepts one variable or a functional form of variable. It needs refactoring to support tidy select.

Kinda curious to see if we can take some inspiration from other langauges here:

Elm
https://package.elm-lang.org/packages/gicentre/elm-vegalite/latest

Julia
https://www.queryverse.org/VegaLite.jl/stable/

I think missing values / logical values aren't being properly handled. i.e.

penguins %>%
  vega() %>%
  mark_point(enc(x = bill_length_mm, y = bill_depth_mm, color = is.na(sex)))

Produces a legend where all points are undefined.

• 2021-01-25 Abstract submission for regular talks, panels, incubators and elevator pitches opens.
• 2021-03-15 Abstract submission closes

https://user2021.r-project.org/keydates/

Need to make this repo public before Jan 25.

Is this recommended @ijlyttle - if users want to save plots? Also with the knit print method?

Seems less confusing if users don't know about vega

Potential option is to write out to a tempfile to speed up rendering for large datasets.

Options are arrow or csv or json
https://github.com/vega/vega-loader-arrow

@ijlyttle has a bunch of event/signal/data listeners in vegawidget for use with shiny, should we re-export / alias them in virgo?

Should the data argument in virgo functions accept a shiny reactive()?

And would this be possible without shiny at all? One thought would be using sketch but not sure how mature that is.

cars <-
  jsonlite::fromJSON("https://vega.github.io/vega-editor/app/data/cars.json")

cars %>% 
  vega() %>% 
  mark_bar(
    enc(
      x = vg_count(), 
      y = Name, 
    )
  ) %>% 
  scale_y(breaks = NULL)

Error occurs at rescale_domain()

i.e facet_views(row = month(date)) ...

i.e. if you do:

vega()
vega(melbweather)
vega(melbweather, enc(x = ambient_temperature)

Should this produce an equivalent to geom_blank()

@ijlyttle @earowang - do you think it would be worthwhile making our design explicitly stated? I think what we've got so far is really exciting but I do think it would be worth clarifying the API spec, especially around the problems with interactivity?

Haven't seen any examples that link between different datasets with common keys.

• vega_set_size()
• vega_set_width/height()

Is this done via config?

All hyperlinks under the "learning more" section in the README are empty.

For debugging it's often useful to go to vg editor. Similar to #12 I think it would be useful to allow the user to open a virgo obj in the vega editor, manipulate it and then return the updated version to the R session. How to actually implement this is another question lol

Would be keen to get @ijlyttle view on this. One simple check would be to see if the json specs are valid according to the vega schema.

https://cran.r-project.org/web/packages/jsonvalidate/vignettes/jsonvalidate.html

• usethis::use_pkgdown()
• custom css for laying out gallery

All examples should be linked little Rmds

• show legend selection
• scale selection
• multiple selections and composition
• https://vega.github.io/vega-lite/examples/bar_count_minimap.html
• resolve views https://vega.github.io/vega-lite/examples/interactive_concat_layer.html

How to provide sugar / dplyr like interface for the vega-lite transformation API
https://observablehq.com/@uwdata/data-transformation?collection=@uwdata/visualization-curriculum

Could we use https://cran.r-project.org/web/packages/V8/ to listen signals generated by the virgo graphic on the R side?

As discussed, we don't want to over complicate the NSE data mask by incorporating selections directly. Here's a few ways that a selection can interact with the vega-lite spec:

1. transformations of the data (using "transform" field). Most commonly used to filter data based on the selection.

2. modifying the encoding spec via either "condition" or the "scale" fields.

For 2. I think we proposed using a verb based approach, that acts like an ifelse or case_when type function

selection <- select_interval(encoding = "x")
mtcars %>%
  vega() %>%
  mark_point(
    encoding = enc(x = wt, y = mpg, color = factor(cyl)),
    selection = selection) %>%
  where(selection, encoding = "opacity", 0.1, 1)

The where verb acts on the selection and the encoding to produce a true / false condition. In this case the where updates opacity channel so points are transparent on the x brush. Specifiying TRUE instead of a value would make it explicit that you are using the encoding already present. Like making points grey;

selection <- select_interval(encoding = "x")
mtcars %>%
  vega() %>%
  mark_point(
    encoding = enc(x = wt, y = mpg, color = factor(cyl)),
    selection = selection) %>%
  where(selection, encoding = "color", TRUE, "grey")

An alternate here would be to split these conditions into two functions, to represent conditional encodings:

selection <- select_interval(encoding = "x")
mtcars %>%
  vega() %>%
  mark_point(
    encoding = enc(x = wt, y = mpg, color = factor(cyl)),
    selection = selection) %>%
  encode_if(selection, encoding = "color", TRUE, "grey")

Or binding to a scale with scale_if()

There are probably other ways too!