Have been following along with Carson Sievert's RStudio webinar "Accessing and responding to Plotly events in Shiny".
I am trying to recreate his "refreshing the bars of a plotly chart rather than re-loading the chart entirely" within a Shiny Flexdashboard (instead of straight Shiny).
His most basic example (what I am trying to recreate) starts at 26:18.
I have been trying to have the bars refresh when a radio button selection is made (instead of just every 100 miliseconds, as in his video) but can't quite reproduce it.
I have made a gist -see link.
My impression is that this is a more optimized way of going about refreshing a chart, instead of the standard way (recreating the whole plot). So that's why I'm interested.
Great question! I think the meta version of your question is: "How can I leverage htmlwidget shiny proxies in rmarkdown?" In case you didn't know, there are other htmlwidgets besides plotly that allow you to modify an already rendered widget in a shiny app in a similar way (e.g., DT::dataTableProxy() and leaflet::leafletProxy()). An important aspect in the design of these proxy interfaces is that you need to know the ID of the shiny output you intend to target. AFAIK, the only way to specify the output ID of the shiny output in rmarkdown is to leverage prerendered documents. I'm not aware of pre-existing proxy+rmarkdown examples, but here is a minimal example with leaflet:
And here is another minimal example with plotly (note that you need to pass the session object to the proxy!)
Yeah, so that last example is exactly what I was aiming for.
And very interested to hear that it can be applied to the other html widgets, as well.
I will have investigate these and also keen to see the % speed increase this technique brings (with bigger data), as opposed to re-creating the whole chart each time a filter is clicked.
Basically, this question is a bit pre-emptive (I currently don't have an app requiring this performance boost)... but I'm imagining it might be best practice (if it isn't any more complicated to implement than the "normal" way).
I'm curious whether using the "runtime: shiny_prerendered" and "```{r, context="server"}" will have any unintended consequences to other components of the flex dashboard. Will do some investigating.
Basically, I'm interested in this optimisation sort of things because I've been burnt a bit before, with a Tableau dashboard that required three left-joins (and 30,000 rows became 500,000,000 rows). It had a couple seconds delay when using any filters (which was frustrating). So that's why I've converted to R's Flexdashboard, as you aren't restricted in reshaping datasources and, with techniques like this, can be very responsive.
So, thanks heaps for your response...
btw, hate to take up any more of your time but, if you are looking for another ggplot/Plotly/Flexdashboard challenge, I have another "legend in the sidebar" question over on Stack Overflow that might be another cakewalk for you...