Vega-Lite 2.0 updates #28
Comments
|
I’m not able to actively put time into this. However, the API in this package is fairly straight forward— you should essentially be generating lists from user provided parameters such that toJSON converts them into the appropriate JSON document for Vegalite to interpret. So if you want to have at it I can review.
http://www.jsonbecker.com/contact/
… On Nov 1, 2017, at 6:01 PM, Edward Visel ***@***.***> wrote:
Hi! Now that Vega-Lite 2.0 is out, can we update vegalite to add compatibility? The cross-filter interactions look super cool.
I've got a bit of time at the moment, so if there's a framework in which to assemble the pieces, I'm happy to help out.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I've started making updates for vega-lite 2.0 in my fork -- updating the JS libraries and making sure most existing functionality in package is supported, but no new features yet. @alistaire47 did you start working on this as well? Question for @jsonbecker and @hrbrmstr -- updating to vega-lite 2.0 will be much easier if there is no expectation of backwards-compatibility for the R package. If backwards compatibility is broken, that also presents an opportunity for other breaking changes, e.g. updating names to start with "vl_" prefix to avoid some namespace clash issues and facilitate auto-completion (e.g. #22 ). Perhaps making a new "vegalite2" package (that still builds on what has been done in this package but feels free to make such breaking changes) would be warranted? Or are you open to breaking changes in this package and a major new release? |
|
IMO, major version numbers suggest breaking changes. It’s been a long time since there was a cran release and I don’t think there is a pressing need to maintain compatibility. MRAN provide historical package code. We could also do a release on GH and offer the source from the 0.6 CRAN and 0.7 GH versions.
Lastly, I’d argue for major versioning to 2.0 to align with vegalite’s version number.
http://www.jsonbecker.com/contact/
… On Nov 18, 2017, at 4:33 PM, Alicia Schep ***@***.***> wrote:
I've started making updates for vega-lite 2.0 in my fork -- updating the JS libraries and making sure most existing functionality in package is supported, but no new features yet. @alistaire47 did you start working on this as well?
Question for @jsonbecker and @hrbrmstr -- updating to vega-lite 2.0 will be much easier if there is no expectation of backwards-compatibility for the R package. If backwards compatibility is broken, that also presents an opportunity for other breaking changes, e.g. updating names to start with "vl_" prefix to avoid some namespace clash issues and facilitate auto-completion (e.g. #22 ). Perhaps making a new "vegalite2" package (that still builds on what has been done in this package but feels free to make such breaking changes) would be warranted? Or are you open to breaking changes in this package and a major new release?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@AliciaSchep I started the same process, which made me realize that I didn't have much experience with the htmlwidgets backend, so I started working my way through, then distracted by work. Without digging into your code, I think you're further along, so I'm happy to contribute to your fork, if there's a useful way to divide up the tasks. While we're talking major, breaking changes, the other thing that could happen is to wrap this package so as to make a more ggplot-like API (with tidy eval |
|
ggvega was a start at this. I think I could be in scope of this package if it was still of interest but I think namespaces become a large issue.
I like how highcharter handles this with the hchart function so that may be a place to look for ideas.
https://github.com/hrbrmstr/vegalite/blob/master/R/ggvega.r
http://www.jsonbecker.com/contact/
… On Nov 18, 2017, at 7:31 PM, Edward Visel ***@***.***> wrote:
@AliciaSchep I started the same process, which made me realize that I didn't have much experience with the htmlwidgets backend, so I started working my way through, then distracted by work. Without digging into your code, I think you're further along, so I'm happy to contribute to your fork, if there's a useful way to divide up the tasks.
While we're talking major, breaking changes, the other thing that could happen is to wrap this package so as to make a more ggplot-like API (with tidy eval aes, etc.) so the learning curve is shallower. I'd argue that shouldn't be in this package, which is valuable as a direct wrapper, but as a skin of a skin. There's obviously a lot of thought that needs to go into getting an API right, though, and the vega-lite team clearly have, so maybe such a package shouldn't exist. Getting up-to-date obviously needs to happen first anyway, but I'm curious if y'all have thoughts.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
@jsonbecker major versioning at 2.0 and making release for current version on GH both sound good. @alistaire47 great, I will add you as a collaborator on my fork! Broad scale roadmap could look something like this:
I'm hoping to tackle the first two bullet points in the next few days. Would be awesome to get help figuring out what might be broken or not working as expected in R pkg with transition to newer JS libraries and also brainstorming/planning api for view composition and selections. With regards to higher level api, I think something like hchart function would be a nice addition. It looks like ggvega takes a vegalite spec and turns it into a ggplot; might be interesting to have something that goes the other way, like ggplotly in plotly package. Although since ggplotly works fairly well for purposes of turning a ggplot interactive I'm not sure its worth it to try to replicate that with vegalite here. |
|
Thanks, Alicia. This is a huge amount of work. In my view, those first three bullets would probably constitute a great PR that, when merged, could be releasable. I think going through to bullet 4 (which I could probably do off of that PR) might make for a nice 2.0. At that stage, we’d be working with the new vegalite version but not have implemented it’s new features yet and ensured compatibility or uncovered breaking changes.
Unless we expect layers, concat, repeat, and resolve to change the way users make charts that don’t make use of those features from an API standpoint, we could separate that work to a follow up release.
http://www.jsonbecker.com/contact/
… On Nov 18, 2017, at 11:32 PM, Alicia Schep ***@***.***> wrote:
@jsonbecker major versioning at 2.0 and making release for current version on GH both sound good.
@alistaire47 great, I will add you as a collaborator on my fork! Broad scale roadmap could look something like this:
Fix "cell" config -- in new vegalite it seems like config parameters that applied to "cell" now apply to "view" -- and sizing issues.
Add jsonvalidate validate support as suggested by #26 to help with debugging as new features get added
Ensure any other features previously possible with R package are still possible; I think jsonvalidate might help identify cases where there might not be an error and a plot still gets made but the json isn't quite right and something might be ignored
Maybe switch over naming scheme to be consistently "vl_"
Figure out best api for view composition then implement, potentially splitting up work on implementing layer, concat, repeat, and resolve. Some discussion of api for layers already in issue #16
Figure out best api for "selections" then implement. These seem like they'd be pretty natural to split up for implementation phase.
Maybe add some kind of higher level api
I'm hoping to tackle the first two bullet points in the next few days. Would be awesome to get help figuring out what might be broken or not working as expected in R pkg with transition to newer JS libraries and also brainstorming/planning api for view composition and selections.
With regards to higher level api, I think something like hchart function would be a nice addition. It looks like ggvega takes a vegalite spec and turns it into a ggplot; might be interesting to have something that goes the other way, like ggplotly in plotly package. Although since ggplotly works fairly well for purposes of turning a ggplot interactive I'm not sure its worth it to try to replicate that with vegalite here.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Yes, agree that first getting current features working properly with new JS versions and then submitting that as PR would be more sensible (and realistic) than trying to do all of the above at once. Adding new features from vegalite 2.0 could then be done feature by feature over time. The feature that I think will likely have biggest impact on API or at the least the internals of a large number of functions is Question about |
|
We could rewrite to view, alias cell_* to the view_* functions and shoot a warning that its deprecated and remove it later.
http://www.jsonbecker.com/contact/
… On Nov 19, 2017, at 4:55 PM, Alicia Schep ***@***.***> wrote:
Yes, agree that first getting current features working properly with new JS versions and then submitting that as PR would be more sensible (and realistic) than trying to do all of the above at once. Adding new features from vegalite 2.0 could then be done feature by feature over time. The feature that I think will likely have biggest impact on API or at the least the internals of a large number of functions is layers, so that one might be good to target first and maybe include in initial '2.0' release.
Question about cell_size function -- in new vegalite there is no longer a cell parameter in config, instead similar behavior comes from view within config. For the R pkg would it make sense to update cell_size and cell_config to view_size and view_config for consistency with vegalite API? Or better to keep the R api somewhat stable and keep function names but just change internals? My thinking is that updating the names makes sense, especially since the documentation for R function references documentation for vegalite, but could also understand wanting to keep the old names.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
It could be interesting to take a look at altair's approach of implementing vega-lite into the python environment. |
Hi! Now that Vega-Lite 2.0 is out, can we update
vegaliteto add compatibility? The cross-filter interactions look super cool.I've got a bit of time at the moment, so if there's a framework in which to assemble the pieces, I'm happy to help out.
The text was updated successfully, but these errors were encountered: