Create a QuickVega.jl package

[davidanthoff]

The idea would be to have an alternative API in the QuickVega.jl package that is not grammar-of-graphics based, but resembles the original API from https://github.com/johnmyleswhite/Vega.jl, i.e. the philosophy would be "one super simple function call to generate one type of plot".

In my mind we would have things like scatter(x, y) etc.

I think this package could also have functions like the ones in seaborn, i.e. really powerful functions that create quite complicated figures with one call.

The output of each of these function calls would be a VLSpec (or VGSpec) from this package here, i.e. we would reuse the whole display/save etc. functionality.

Once we have #242, I think this could become a really powerful and generic combination. For example, one could do things like

QuickVega.powerfull_fancy_something(...) |> @vlmod(title="NEW TITLE")

i.e. one could start with a template generated with a function in QuickVega.jl, and then get all the powerful manipulation options from a @vlmod macro (or even a @vgmod macro).

[ym-han]

Was there supposed to be a link to a package in "The output of each of these function calls would be a VLSpec (or VGSpec) from this package here, i.e. we would reuse the whole display/save etc. functionality"?

[davidanthoff]

No, so the idea would be that QuickVega.jl has a dependency on Vega.jl and VegaLite.jl, and the functions that are defined in QuickVega.jl return instances of either VLSpec or VGSpec.

[ym-han]

Right, gotcha!

[pablosanjose]

I think this and the associated @vlmod idea would be incredibly useful. The barrier of entry of VegaLite is not particularly low, I must say. Incremental construction/modification of plots might be easier to grasp and extend for many. Also, if I write VegaLite recipe for a type of mine, a user might easily want to tweak it, which the @vlmod approach would allow her to do. Otherwise, she'd be forced to dive into the recipe's code and tweak it directly.