Vega-Lite 2.0 updates about vegalite HOT 10 CLOSED

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?

from vegalite.

It could be interesting to take a look at altair's approach of implementing vega-lite into the python environment.

from vegalite.

from vegalite.

from vegalite.

from vegalite.

@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.

from vegalite.

from vegalite.

@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.

from vegalite.

from vegalite.

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.

from vegalite.