@Amit What you're describing exists, it's called htmlwidgets 
In the world of static graphics, there's ggplot2 which tries to be a general and flexible grammar, but there's still a whole world of packages that implement their own special snowflake plots on top of base or grid. In the world of interactive graphics, on the general/flexible side we have plotly, rbokeh, and (eventually) ggvis, while on the special snowflake side we have all the various htmlwidgets. Crosstalk is one way to bind them together, but it's extremely limited in scope, by necessity. The more general/powerful way to bind them together is Shiny.
3 Likes
Yeah, I was referring to htmlwidgets! And I like your analogy... I guess what I was wondering is whether htmlwidgets' role should be limited to snowflakes vs perhaps extending some parts of crosstalk more formally and then everything is a htmlwidget, including plotly/rbokeh/ggvis/ggraph.
When you say Shiny is the generalized unification (I hope you see what I did there) solution... will Shiny have some version of crosstalk on all displayed assets? Or (I guess more likely) will some chart types just never be usable as inputs and you're ok w/ that?
plotly and rbokeh are already htmlwidgets. Anything that's rendered into a rectangle of HTML/CSS/JavaScript, and needs to work "everywhere" (console, Shiny, R Markdown, RStudio viewer, saved as .html file) should be an htmlwidget. ggvis isn't, only because it predates htmlwidgets.
Will Shiny have some version of crosstalk on all displayed assets?
I don't really know what that means. Anyway, Crosstalk is mostly useful when Shiny is not an option for some reason, so your static .html file can still have some limited amount of inter-widget interactivity.
2 Likes
I'm referring to any html viz being used as outputs as well as inputs that would then filter the other viz on the page.
An example: Say I have a dashboard with two viz and would like for both to allow for dynamic filtering for the other viz. I guess that since each JS library is developed in exclusion, it's rather impossible to gather up all the different bindings... That's what I thought cross-talk would do, even in shiny...
(the gif cuts out but clicking on a word on that wordcloud filters the map as well)
So the question is: Does Shiny (or will Shiny) allow for this kind of two-way interaction? Or will all chart filtering be done from the Shiny widgets that we all know and love?
1 Like
But that reason could be a clincher, couldn't it. e.g you don't want to embed a relatively slow interactive method in a blog post
For a fun time, pull up the Q&A from this years RStudio conference where I asked Hadley about ggvis.
I understand the reason is a lack of priority with existing resources, to which my question would be: is mining some extra resources by crowdsourcing an option?
What I mean is that there are already many enthusiasts developing packages on their own, and many alternatives to ggvis, which is the exact opposite of your situation:
- you have the idea, the know-how, the ins and outs of the tidyverse, the process and all that, but you lack resources/time/priority,
- while R community has none of the former, but all of the latter (resource, that is)
3 Likes
Thanks for reference - If I'm correct you refer to 45m into this video: https://www.rstudio.com/resources/videos/all-things-r-and-rstudio/
Struck by JJ's comment that his vision has been for 75% of Tidyverse development to be led by people outside RStudio company. As I see it the various R/html bridges discussed here are a great example of this happening as intended. But while htmlwidget packages are awesome, as an ecosystem it is IMO quite fragmented, and confusing as to how everything fits together, and not all necessarily very 'tidy'.
I don't think the community has any expectation that RStudio/Hadley/Winston should drop everything. But what IMO we do need is an articulated strategic vision to enable the multitude of initiatives in this space to be more cohesive and, ideally, start to cluster around a smaller number of core components that can play an equivalent role to that of ggplot within the broad ecosystem that it has enabled.
3 Likes
Unfortunately developing the vision is most of the work. For an interactive grammar of graphics to be successful it needs a clear unifying vision. If the problem could simply be solved by more bodies I’d either hire someone or figure out how to get the community to help.
13 Likes
I see! Thank you. That makes sense now.
I totally agree! I think that plotly works best when not relying too much on the ggplot2 bindings with the plotly::ggplotly() function. It takes a little work to learn the plotly R api but I feel, in terms of approach to the development of the api, that Carson has taken great care in implementing a clear vision that is meant to integrate with tidyverse packages very nicely.
Specifically with plotly 4.0+ there were some breaking changes but really good ones in terms of the direction plotly has taken (thinking of the adoption of expressions ~). Most recently 4.7.1 hit CRAN, so things move quick!
If anyone is curious they can check out new features here or Carson's bookdown book on plotly here
4 Likes
The whole interactive graphics topic is too broad. I think it's almost impossible to expect someone generating an unified specification/implementation, or lead a group to work out one.
There are so many javascript based interactive graphics tech, and it's relatively simple to have a htmlwidget binding for some specific charts. However it's difficult to have an uniformed approach. It's like reinventing ggplot2 in web/javascript.
I think there are some low hanging fruits.
With Shiny you actually can have a lot of interactive control to your ggplot2 plot/basic plot, however the learning curve is a little bit steep, and the usage are scattered, not in a simple/modular fashion.
I managed to add zoom to any ggplot2 plot in Shiny. I also added some control to ggplot plots in my Shiny app, including point size, transparency, figure height, layout options etc. It's not really hard to do this, but there are a lot can be improved:
- The code to do these are scattered in ui, server, inside the ggplot call, outside of ggplot call (like the figure height), external zoom event observer etc.
- The control for a plot is kind of too big. It's better if they can be integrated with the plot, or collapse to switch gear icon.
I feel that if these points can be packaged into a easier to use fashion, it can solve a lot of basic usage already, and it will work with all your ggplot2/basic plots. You can also convert a ggplot plot into a shiny app running in RStudio viewer, so you can interactively check any plot in command line anytime.
1 Like
I also use GGVIS just specifically for the %>% opperator. It works and it gets the job done for me currently. Hoping for more soon.
There should be a dislike button on This comment.
I would love to press it.
I haven't seen Highcharter before! Very cool 
Highcharter is very slow. I tried creating a scatter plot of diamonds dataset and it crashed my R. Instead plotly is faster
1 Like
When using highcharter, pay attention to highcharts.com licensing (free for non-commercial use only).
7 Likes
Good hint - interestingly I cannot even open the webpage as highchart.com is part of an blocking list for "Ad and tracking servers" (https://hosts-file.net/default.asp?s=highcharts -> ATS - Ad/tracking servers). Justified or not... does not really speak for it.